Hi, can you send your bif file?
M On 19. 06. 19 22:27, Jean-Francois Dagenais wrote: > Hi Michal, guys, > > Any ideas Michal? I have been debugging this for 4 days and it doesn't > look like I'm moving ahead much. You made it sound so simple but it is > not so simple apparently... > > Since my last post below, I have hacked head.S to include > _inval_dcache_area so as to make the branch call nearer and it works. > (Which is weird in itself... but all I do now is stretching my > knowledge, so I'm having fun here!) > > I am able to reach start_kernel from main.c. Then things start getting > weird... > > Here's my debug boot log: > https://pastebin.com/QxA0AQfh > > This is where things stop making sense... > > I placed a few breakpoints in start_kernel after this line and I end up > stuck here: > > > > Please help guys!! Or should I direct to linaro or linux-arm mailing lists? > > Here, "HELP" could just be a debugging technique I might use, a > configuration, a debug flag somewhere, etc. > > Thanks all! > > >> On Jun 14, 2019, at 18:14, Jean-Francois Dagenais >> <jeff.dagen...@gmail.com <mailto:jeff.dagen...@gmail.com>> wrote: >> >> Hi Michal, guys, >> >>> On Jun 14, 2019, at 03:20, Michal Simek <michal.si...@xilinx.com >>> <mailto:michal.si...@xilinx.com>> wrote: >>> >>> If you want to boot just linux without u-boot you can simply run >>> FSBL->ATF->linux-boot.bin->Linux. That's what I have described in >>> previous email. And I would put linux-boot.bin to RAM out of Linux image. >> >> Yup, I got that. Thanks for your very precious help. I am deep into >> debugging this with xsdk 2019.1 now. I have a breakpoint at 0x80000 >> and in assembly, I can see it executing "blpreserve_boot_args" (in >> arch/arm64/kernel/head.S), then jump to preserve_boot_args and when it >> hits "b _inval_dcache_area // tail call", the Disassembly window shows: >> 00000000000949c0: .word 0x00000409 >> 00000000000949c4: .word 0x0060004e >> 00000000000949c8: .word 0x40000409 >> 00000000000949cc: .word 0x0060004e >> ... >> Then issuing a "step into" again at the debugger makes the CPU jump at >> PC:0xa048814450408200 !! >> >> When I boot using the usual u-boot proper, once in linux Image, it >> follows the same route in head.S, and after a single step into that >> same "b _inval_dcache_area", it looks much better, i.e. assembly >> instructions. >> >> >> >> Looking at register dumps between the two sequences, I noticed "Vector >> Base Address Register (EL2)" register looks well initialized on the >> u-boot proper side, and uninitialized with value: 0xa048814450408140, >> which is way to close to the PC above to be a coincidence! >> >> So it looks like u-boot proper left the MMU perhaps, or something in >> the CPU state which makes things run smoother than if not. >> >> I'm seeing what I guess are significant discrepancies in these registers: >> Translation Table Base Register 0 (EL2) >> u-boot: 000000003ffe0000, linux-boot.bin: 0000000100801310 >> >> 3:4:2:0:2, Translation Control Register (EL2) >> u-boot: 80823518, linu-boot.bin: 80800000 >> >> 3:4:10:2:0, Memory Attribute Indirection Register (EL2) >> u-boot: 000000ff440c0400, linux-boot.bin: 400012080024000c >> >> 3:4:12:0:0, Vector Base Address Register (EL2) >> u-boot: 000000003ff12800, linux-boot.bin: a048814450408140 >> >> >> I am no Arm64 CPU architecture expert. Maybe someone can translate >> this info into hints without us having to read (and understand) the >> whole ARM64 TRM doc? Something like "The ATF did not cleanup such and >> such" or whatever. >> >> >>> >>> And sure you can use SPL instead of FSBL which likely don't need to use >>> any trampoline code (linux-boot.bin). If this is packed in FIT I also >>> think that you don't need to use any trampoline for booting. But I >>> didn't test it to be 100% sure. >> >> Actually, I rather like the monolithic boot.bin that bootgen creates. >> Maybe this can also be done with mkImage... At this point though, for >> our current use cases, I seen not advantages for using spl, so far. >> >> If I were though, I'm not sure how I would achieve everything without >> linux-boot.bin... I suppose I would have to make ATF come back to the >> SPL code using the handoff structure so SPL can proceed with falcon >> booting the kernel? This would most likely require new code in SPL >> right? Thanks for adding a few details. >> >> Anyway, thanks all of you for your interest and support! >> > -- _______________________________________________ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
