Re: Troubles running qemu64 target

[ranquet guillaume <ranquet.guillaume@gmail.com>]

>> > set $sp=0xBFFFFFF0

Indeed, I'm so used to debug coredumps with gdb, I didn't even think
about that :)

it gets me a little bit further, but execution is ending up in hang()
pretty quickly.
I need to find a bit of time to investigate further.

I made a dirty workaround, calling setup_stack() just before barebox_arm_entry()
just to get me going.

Thx,
Guillaume.

On Fri, Jun 29, 2018 at 7:59 PM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:
> On Fri, Jun 29, 2018 at 2:01 AM Raphaël Poggi <poggi.raph@gmail.com> wrote:
>>
>> 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 ?
>>
>
> Ideally start_nxp_imx8mq_evk is declared as __naked which, if it was
> working, would've removed its function prologue/epilogue and we could
> either set up the stack at that point or, if looking at disassembly
> showed no stack usage, we could wait until that would be done as apart
> of barebox_arm_entry().
>
> However, given how __naked wasn't working on AArch64 for me and I
> didn't want to majorly change what ENTRY_FUNCTION() does, I just
> settled to exploit the fact that i.MX8M uses MaskROM firmware that
> implements initial bootstrapping (fetching the image from the medium,
> executing DCD, etc.) which sets up some initial stack for its internal
> needs and can be used until we reach barebox_arm_entry() where SP
> would be properly set up.
>
> Thanks,
> Andrey Smirnov

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