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 ? Thanks, Raphael _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
