Re: Troubles running qemu64 target

["Raphaël Poggi" <poggi.raph@gmail.com>]

Hi Guillaume & Andrew,


Le ven. 29 juin 2018 à 01:46, Andrey Smirnov
<andrew.smirnov@gmail.com> a écrit :
>
> Guillaume:
>
> I haven't used QEMU ARM64 version of the code, but I have spent some
> time on i.MX8M which is ARM64 as well. See my comments below.
>
> On Thu, Jun 28, 2018 at 6:46 AM ranquet guillaume
> <ranquet.guillaume@gmail.com> wrote:
> >
> > Hello.
> >
> > I'm pretty new to barebox and I'm having some troubles running the
> > qemu64 target.
> > to top it off, I'm also new to the ARM world... and this is my first
> > attempt at looking at a bootloader...
> >
> > I'm having trouble porting some hardware to barebox... and while I'm
> > waiting for a JTAG probe, I though I could have some fun with qemu64
> > :)
> >
> > The boot stops pretty early in the flow. way before anything can be
> > printed on the serial. I have attached gdb to the qemu-system.
> > The "qemu-system" seems to be stuck when trying to execute an stp with
> > the stack pointer as the destination.
> >
> > I'm having the feeling that I have a configuration issue because sp = 0x0
> >
> > x27            0x0      0
> > x28            0x0      0
> > x29            0x0      0
> > x30            0x0      0
> > sp             0x0      0x0
> > pc             0x40000000       0x40000000 <start>
> > cpsr           0x400003c5       1073742789
> > fpsr           0x0      0
> > fpcr           0x0      0
> > (gdb) disassemble
> > Dump of assembler code for function start:
> > => 0x0000000040000000 <+0>:     b       0x40000048 <start+72>
> >    0x0000000040000004 <+4>:     nop
> >    0x0000000040000008 <+8>:     nop
> >    0x000000004000000c <+12>:    nop
> > ...
> >   0x0000000040000048 <+72>:    b       0x40013444 <barebox_arm_reset_vector>
> >
> >
> > then we are branching to <barebox_arm_reset_vector>
> > Dump of assembler code for function barebox_arm_reset_vector:
> > => 0x0000000040013444 <+0>:     stp     x29, x30, [sp, #-16]!
> >    0x0000000040013448 <+4>:     mov     x29, sp
>
> The above looks like barebox_arm_reset_vector's preamble to me, which
> it would have since:
>
> a) It is not declared as __naked
>
> b) AFAIK, __naked is not supported on AArch64 version of GCC, so even
> if it was it wouldn't help
>
> >    0x000000004001344c <+8>:     bl      0x40000050 <arm_cpu_lowlevel_init>
> >
> > with sp still equals to 0x0.
> >
> > stepping from there seems to get me "stuck"...
> > when interrupting gdb (Ctrl-C) and dumping the registers, I'm getting
> > the feeling I'm out of barebox code with pc equals 0x200
> >
> > x29            0x0      0
> > x30            0x0      0
> > sp             0x0      0x0
> > pc             0x200    0x200
> > cpsr           0x3c5    965
> > fpsr           0x0      0
> >
> >
> > It's probably some kind of configuration issue...? though I see no
> > code to set sp before that stp instruction.
>
> IMHO this doesn't look like a configuration issue and I agree there's
> no code to set SP up.
>
> > I tried toying with the memory map, setting stack and text base
> > addresses, but it doesn't seem to fix my issue.
> > Or maybe it's okay to decrement sp while it's equal to 0x0?
>
> AFAIK, it would be OK if underlying emulated hardware had any kind of
> memory mapped at the end of address space (sp would wrap in that
> case), but as far as I can tell QEMU ARM64 virt platform doesn't,
> which I think is the reason you are seeing the result you are seeing.
>
> > Any ideas? comments?
>
> I am not sure about the proper way to resolve this, I'd be curious to
> hear from Raphael (original author, CC'd in this reply) and how this
> worked for him first. However you can very quickly verify/disprove
> your bad SP value theory by doing:
>
> set $sp=0xBFFFFFF0
>
> before letting the processor hit those SP instructions when you step
> through it and see if barebox runs fine after that.
>
> Thanks,
> Andrey Smirnov
>
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox



Thank you for adding in CC.

I have looked at bit at this issue, indeed the fact that "
barebox_arm_reset_vector" is not naked, is not good.

I did not catch this issue by the time I have get my work merged,
because it was not crashing (don't know why...).

I have test with the master branch and barebox crashs but I can have
some serial output:

   barebox 2018.06.0-00145-gfe040e0-dirty #1 Fri Jun 29 09:06:54 DST 2018

   Board: ARM QEMU virt64
   DABT (current EL) exception (ESR 0x9400004b) at 0x0000000000000000
   elr: 000000004100cad8 lr : 000000004100cac4
   x0 : 00000000000000f0 x1 : 0000000000000001
   x2 : 00000000bffefd2c x3 : 00000000ffffffff
   x4 : 0000000000000008 x5 : 0000000000000000
   x6 : 0000000040c06710 x7 : 0000000000000000

Anyway, the qemu virt board is broken.

I will try to work a bit on this in the week end.

Andrew, how do you set up the stack on the imx8 board ?

Thanks,
Raphael

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox