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

[Michal Simek]

On 5.10.2016 09:50, Simon Glass wrote:
> 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.

Isn't this already supported if I pretend that ATF is Linux kernel
and dtb is full U-Boot.

> 
> 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.

I should look at it when you send it because for boot.bin generation
could be useful.

Thanks.
Michal



-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161005/c9e9de22/attachment.sig>