>> > 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@xxxxxxxxx> wrote: > On Fri, Jun 29, 2018 at 2:01 AM Raphaël Poggi <poggi.raph@xxxxxxxxx> wrote: >> >> Hi Guillaume & Andrew, >> >> >> Le ven. 29 juin 2018 à 01:46, Andrey Smirnov >> <andrew.smirnov@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx >> > 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@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
