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

[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

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

[Michal Simek]

Hi Masahiro,

2016-10-04 20:19 GMT-07:00 Masahiro Yamada <yamada.masahiro@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.

Thanks,
Michal




>
>
>
> --
> Best Regards
> Masahiro Yamada
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>



-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform

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

[Simon Glass]

Hi,

On 5 October 2016 at 08:39, Michal Simek <monstr@monstr.eu> wrote:
> Hi Masahiro,
>
> 2016-10-04 20:19 GMT-07:00 Masahiro Yamada <yamada.masahiro@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

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

[Masahiro Yamada]

Hi Simon,


2016-10-06 1:50 GMT+09:00 Simon Glass <sjg@chromium.org>:

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


ATF is runtime firmware, so it will stay there while the system is running.
On the other hand, the memory allocated for U-Boot can be freed
after the system boot up.


In the first place, this is a license issue.

U-Boot GPL vs ATF BSD.

I think they can not be linked together.




-- 
Best Regards
Masahiro Yamada

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

[Masahiro Yamada]

Hi Michal,


2016-10-05 23:39 GMT+09:00 Michal Simek <monstr@monstr.eu>:
> Hi Masahiro,
>
> 2016-10-04 20:19 GMT-07:00 Masahiro Yamada <yamada.masahiro@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.


Ah, now I see.

The idea I came up with was
to put every ATF stuff into spl_board_prepare_for_boot().



>
> We are using only BL31 and nothing else.


But, prior to commit f3d1cc2ff387ffe22ccd1bdcb2a998ec46149c6d
(ARM64: zynqmp: Enable SPL for all zynqmp boards),

BootROM -> fsbl -> ATF BL31 -> U-Boot -> Linux

was the only supported solution, yes?



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


Yes.  This is one big advantage of using SPL over BL2.




-- 
Best Regards
Masahiro Yamada

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

[Michal Simek]

Hi Masahiro,

2016-10-05 19:34 GMT-07:00 Masahiro Yamada <yamada.masahiro@socionext.com>:

> Hi Michal,
>
>
> 2016-10-05 23:39 GMT+09:00 Michal Simek <monstr@monstr.eu>:
> > 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.
>
>
> Ah, now I see.
>
> The idea I came up with was
> to put every ATF stuff into spl_board_prepare_for_boot().
>


In our ATF implementation we are using structure for passing information
from
fsbl (which loads all images) to ATF to tell ATF what to do.
It means I could use this function to prepare the same in SPL.



>
>
>
> >
> > We are using only BL31 and nothing else.
>
>
> But, prior to commit f3d1cc2ff387ffe22ccd1bdcb2a998ec46149c6d
> (ARM64: zynqmp: Enable SPL for all zynqmp boards),
>
> BootROM -> fsbl -> ATF BL31 -> U-Boot -> Linux
>
> was the only supported solution, yes?
>

yes correct.



>
>
>
> >>
> >>
> >> 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.
>
>
> Yes.  This is one big advantage of using SPL over BL2.
>

right. It is not only about drivers. Also fdt support and high level
functions.
ZynqMP for example has USB dfu boot mode which would be a little bit painful
to do in bl2 but it is almost for free with current SPL.

Thanks,
Michal


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform

[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@monstr.eu> wrote:
>> Hi Masahiro,
>>
>> 2016-10-04 20:19 GMT-07:00 Masahiro Yamada <yamada.masahiro@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>

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

[Simon Glass]

Hi Masahiro,

On 5 October 2016 at 20:02, Masahiro Yamada <yamada.masahiro@socionext.com>
wrote:
> Hi Simon,
>
>
> 2016-10-06 1:50 GMT+09:00 Simon Glass <sjg@chromium.org>:
>
>> 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.
>
>
> ATF is runtime firmware, so it will stay there while the system is
running.
> On the other hand, the memory allocated for U-Boot can be freed
> after the system boot up.

That is changing, e.g. with EFI_LOADER. Also it is possible on x86 that
some code may hang around (if SMM etc. is implemented in U-Boot).

>
>
> In the first place, this is a license issue.
>
> U-Boot GPL vs ATF BSD.
>
> I think they can not be linked together.

Ah OK.

Is it not permitted to link a BSD library into U-Boot? Anyway, that is not
so important I suppose.

Regards,
Simon

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

[Dan Handley]

Hi all

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

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

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

[Michal Simek]

On 12.10.2016 13:18, Mike Looijmans wrote:
> 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.


I haven't had a time but Simon sent binman which can solve at least the
part of this.

Thanks,
Michal