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

[Ibai Erkiaga Elorza]

I’ve been playing around with this use case recently and although I’m not sure if I followed the right steps for this use case but so far I identified the following gaps:


  1.  U-Boot SPL does not populate the kernel entry point on the spl_invoke_atf, the Falcon mode seems to not be still supported
  2.  The ATF is built with RESET_TO_BL31=1 which does not get the arguments from the previous bootloader (it is supposed BL31 is the first bootloader). I’m not sure why it is compiled this way but the platform.mk for zynqmp forces it.
  3.  The arm_bl31_early_platform_setup implementation of zynqmp does not process the input arguments (arg0=bl31_param and arg1=FDT) to get the kernel entry point and to pass the FDT address to the kernel

Regards
Ibai

From: meta-xilinx-bounces at yoctoproject.org <meta-xilinx-bounces at yoctoproject.org> On Behalf Of Peter Smith
Sent: 14 June 2019 08:55
To: Michal Simek <michals at xilinx.com>
Cc: meta-xilinx at yoctoproject.org
Subject: Re: [meta-xilinx] SPL->ATF->Linux

I have been following along with interest, do you know if this would work if we wanted to load Xen i.e. to boot a Xen Dom0?
Best Regards
Peter


On Fri, 14 Jun 2019 at 08:36, Michal Simek <michal.simek at xilinx.com<mailto:michal.simek at xilinx.com>> wrote:
On 13. 06. 19 17:22, Jean-Francois Dagenais wrote:
> Thanks Michal!
>
> This is awesome. I can certainly use this. Please review my assumptions below...
>
>> On Jun 12, 2019, at 07:39, Michal Simek <michal.simek at xilinx.com<mailto:michal.simek at xilinx.com>> wrote:
>>
>> Create bif like this.
>> Image - one partition load addr 0x80000 as data
>> dtb - one partition load addr 0x100000000 as data
>>
>> ATF - one partition (as today) EL3
>> Trampoline code below() EL2-ns with filled kernel start to 0x80000 and
>> dtb at 0x100000000
>>
>> fsbl starts ATF and it will pass handoff structure and primary program
>> will be trampoline executed in EL2 which will just pass proper arguments
>> to kernel.
>
>
> So in essence, the program below becomes a standalone binary file which
> essentially replaces "u-boot.bin" correct? Let's call it linux-boot.bin
> (inspired by comment in code below).
>
> This would mean that boot.bin file must contain linux-boot.bin so FSBL loads it
> to RAM prior to passing execution to ATF. If correct, linux-boot.bin must be
> loaded at 0xfffc8000 (if following the example below), correct?
>
> If I understand all this correctly, I could either use FSBL with a boot.bin
> containing basically everything needed to boot up to the kernel, including
> linux-boot.bin. Or I could use SPL inside an u-boot's mkimage made boot.bin
> configured to load a FIT image containing atf, linux-boot.bin,kernelImage,dtb ?
>
> If I understand FIT correctly, it is basically a "better", more straight forward
> way to load multiples binaries into RAM rather than messing with
> CONFIG_SPL_FS_LOAD_ARGS_NAME, CONFIG_SYS_SPL_ARGS_ADDR,
> CONFIG_SPL_FS_LOAD_KERNEL_NAME and CONFIG_SPL_FS_LOAD_PAYLOAD_NAME... correct?

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.

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.

Thanks,
Michal





--
_______________________________________________
meta-xilinx mailing list
meta-xilinx at yoctoproject.org<mailto:meta-xilinx at yoctoproject.org>
https://lists.yoctoproject.org/listinfo/meta-xilinx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-xilinx/attachments/20190614/0c7f171f/attachment.html>