[U-Boot] SPL load ARM Trusted Firmware BL31?

[Michal Simek]

Hi Masahiro,

2016-10-04 20:19 GMT-07:00 Masahiro Yamada <yamada.masahiro at socionext.com>:

> Hi.
>
> Recently I implemented ARM Trusted Firmware BL31 for my SoCs.
>
> But, I am wondering how the boot-flow should be.
>
>
>
> Here is my situation.
>
>
> [1]
> When my company developed its first ARMv8 SoC,
> I had to bring up the system very quickly.
>
> I was familiar with U-Boot and Linux to some extent, but not with ATF
> at that time.
> Also I was too pressed, so I decided to build up the system without ATF.
>
> The boot-flow was like this:
>
>   BootROM  ->  U-Boot SPL  -> U-Boot proper -> Linux
>
> In this flow, the secure runtime firmware is missing,
> so I used Spin-Table for the enable-method.
>
>
> [2]
> Now I finished porting ATF BL31.
> The low-level init code (basic SoC init + DRAM initialization)
> already exists in U-Boot SPL.
> So, I am currently re-using SPL, like follows:
>
>  BootROM ->  U-Boot SPL  -> ATF BL31 -> U-Boot proper (=BL33) -> Linux
>
>
> As far as I know, SPL can not load multiple images such as BL31, BL32, BL33
> (here BL32 is optional).
> So, I hacked my SPL to load multi images
> and jump to BL31.
>

this is not entirely truth. If you look at zynqmp you will find out that if
you
work with atf as kernel and full u-boot as dtb then u-boot SPL can load two
images.
This is what I use. It is a trick but I am not using any changes to get it
work.




>
>
>
>
> [3]
> I am guessing most vendors use vendor-specific firmware for low-level init
> because I see many of ARMv8 SoCs disabling CONFIG_SPL.  Correct?
>

I do use SPL exactly how as used without ATF. It means low level init is
done in SPL in EL3.


>
>  Boot ROM  ->  Vendor proprietary firmware -> ATF BL31  ->  U-Boot or
> UEFI (=BL33) -> Linux
>
>
>
>
> [4]
> Is it a good idea to implement everything in ATF like Juno/FVP?
>
>  BL1 -> BL2 -> BL31 -> U-Boot or UEFI (BL33) -> Linux
>

We are using only BL31 and nothing else.


>
>
>
>
>
> Recently I saw Simon's binman patches.
> It provides a fancy way to pack multiple firmware components into a
> single image,
> but I did not see the systematic way to load every entry in the image.
>   (under way?)
>
>
> I was wondering if I should move my low-level init code
> from SPL to ATF BL2 or somewhere.
>
> Comments are welcome.
>

I use bootrom -> SPL -> ATF -> full u-boot.

I want to use SPL because we have all device drivers in u-boot and
in ATF we have only serial driver. If you want to use BL2 just for low
level init stuff
you can but it is the question if this brings you any value.

Anyway check zynqmp. It is not perfect solution but it is at least temporary
solution for just this case.
FIT image has an option to add more images with load address and I think
this is a support
we should support in SPL. (doc/uImage.FIT/multi-with-loadables.its)
Also there will be probably need to mark images with EL level this targets.

Thanks,
Michal




>
>
>
> --
> Best Regards
> Masahiro Yamada
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>



-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform