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

[Mike Looijmans]

On 11-10-16 13:00, Dan Handley wrote:
>> 

Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijmans at topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





-----Original Message-----
>> From: Masahiro Yamada [mailto:yamada.masahiro at socionext.com]
>> Sent: 05 October 2016 04:19
>> Hi.
>>
>> Recently I implemented ARM Trusted Firmware BL31 for my SoCs.
>>
>> But, I am wondering how the boot-flow should be.
>>
> I'm no U-Boot expert but as ARM Trusted Firmware (TF) maintainer, I feel I should say something here.
>
> In general we expect partners to take the bits of TF that work best for them. So all the bootflows discussed in this thread are valid as far as I'm concerned:
>
> Proprietary Boot ROM -> Proprietary firmware -> TF BL31 -> U-Boot -> Linux
>
> Proprietary Boot ROM -> U-Boot SPL -> TF BL31 -> Full U-Boot -> Linux
>
> TF BL1 -> TF BL2 -> TF BL31 -> U-Boot or UEFI (BL33) -> Linux

Regardless of choice here, it would be nice if all those blobs could be 
combined into a single image. Currently the system spends most of its boot 
time looking up binaries, and copying them around from device into memory and 
then relocate them to a final destination.

The current situation is that I need to create a bunch of tiny flash 
partitions: SPL, BL31, U-boot, devicetree, ...

What I WANT to have is just one "boot" partition that holds SPL, BL31 and 
u-boot, and then have big u-boot access a filesystem (UBI, FAT or EXT) to 
continue from there.




>
> We've gone to some effort to make TF as interoperable as possible with other boot firmware. If there's more we can do here, please let us know.
>
> As Michal said in an earlier mail, which bootflow you choose depends on what brings you the most value. Others have stated the advantages of U-Boot SPL over TF BL2, which I can't disagree with. But there may be other factors to consider, for example:
>
> * Interoperability with other boot firmware (e.g. UEFI) or other OS.
> * Integration with proprietary secure software (which permissively licensed software allows).
> * Alignment with ARM's Trusted Board Boot Requirements (TBBR) document.
>
> Each vendor needs to make their own decisions here.
>
> Regarding TF BL31, we'd prefer this to remain the EL3 Runtime Software on AArch64 platforms, because:
>
> * It is the deployment vehicle for ARM support code, which is constantly evolving (e.g. ARM architectural support, ARM CPU support, errata workarounds, plus other fundamental IP support).
> * It has upstream integration with various Trusted OS.
> * It helps standardization by providing reference code for PSCI and potentially other future industry standards.
>
> There may be other runtime resident firmware present, but we expect these to execute at a lower EL.
>
> One area that may be worth exploring is whether more can be done to help integration of the early TF secure world initialization code into other boot firmware (e.g. proprietary Boot ROMs or U-Boot SPL). This could be useful on platforms where TF BL1 is not used or TF BL31 is not the first software to execute on the CPU after reset.
>
> I hope that helps (and is not too controversial!).
>
> Regards
>
> Dan.
>
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>