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

[Simon Glass]

Hi,

On 5 October 2016 at 08:39, Michal Simek <monstr at monstr.eu> wrote:
> 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.

I have not got into this yet. But I'm really keen on SPL being the
first thing that runs, and it calling into ATF bits as needed. This
allows verified boot to work correctly, since we can add signatures to
the images, etc. It also is easier to follow IMO.

Long term, I am wondering if ATF could be a library instead of a
separate binary? Or perhaps it could be build so that it can be linked
against.

Binman aims to make it easier to create these images with 4-5 separate
binaries. At some point I'm going to look at ATF in a bit more detail.

Regards,
Simon