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

[Masahiro Yamada]

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.




[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?

 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





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.



-- 
Best Regards
Masahiro Yamada