[meta-xilinx] SPL->ATF->Linux

[Jean-Francois Dagenais]

Hi Michal, guys,

> On Jun 14, 2019, at 03:20, Michal Simek <michal.simek at 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 "bl	preserve_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!