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
