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.