[U-Boot] How to support ATF on u-boot

[U-Boot] How to support ATF on u-boot

[Kever Yang]

Hi U-boot Maintainers,

     I want to upstream a new SoC named RK3399 from Rockchip which is
AARCH64/ARMv8, we need to support Arm Trust Firmware base on U-boot.

     Right now we are using a miniloader(just like SPL in U-boot) to 
load ATF/U-boot,
and PC jump from miniloader to ATF and then to U-boot(with CPU change to 
EL2 mode or nsEL1),
then U-boot load kernel/rootfs as usual.

     The ATF support for RK3399 has already upstream
     Could you give your opinion on how to support ATF on U-boot upstream?
When I asked Simon Glass offline, he suggest if we can build ATF as part 
of the
U-boot build process, perhaps with a script in U-boot tree,

Perhaps something like:

make rk3399_board_defconfig
make
./scripts/build-atf-image rk3399_board
^^ new script

In any case, a good README would help.


Thanks,
- Kever

[U-Boot] How to support ATF on u-boot

[Simon Glass]

+Tom

Hi,

On 19 June 2016 at 20:59, Kever Yang <kever.yang@rock-chips.com> wrote:
> Hi U-boot Maintainers,
>
>     I want to upstream a new SoC named RK3399 from Rockchip which is
> AARCH64/ARMv8, we need to support Arm Trust Firmware base on U-boot.
>
>     Right now we are using a miniloader(just like SPL in U-boot) to load
> ATF/U-boot,
> and PC jump from miniloader to ATF and then to U-boot(with CPU change to EL2
> mode or nsEL1),
> then U-boot load kernel/rootfs as usual.
>
>     The ATF support for RK3399 has already upstream
>     Could you give your opinion on how to support ATF on U-boot upstream?

To follow up on this, I think we need a better solution for building
firmware images. I'm going to look at writing a tool to handle this. I
hope to have some patches out by the end of July.

> When I asked Simon Glass offline, he suggest if we can build ATF as part of
> the
> U-boot build process, perhaps with a script in U-boot tree,
>
> Perhaps something like:
>
> make rk3399_board_defconfig
> make
> ./scripts/build-atf-image rk3399_board
> ^^ new script
>
> In any case, a good README would help.
>
>
> Thanks,
> - Kever
>
>

Regards,
Simon

[U-Boot] How to support ATF on u-boot

[Andreas Färber]

Hi Kever,

Am 20.06.2016 um 04:59 schrieb Kever Yang:
>     I want to upstream a new SoC named RK3399 from Rockchip which is
> AARCH64/ARMv8, we need to support Arm Trust Firmware base on U-boot.
> 
>     Right now we are using a miniloader(just like SPL in U-boot) to load
> ATF/U-boot,
> and PC jump from miniloader to ATF and then to U-boot(with CPU change to
> EL2 mode or nsEL1),
> then U-boot load kernel/rootfs as usual.
> 
>     The ATF support for RK3399 has already upstream
>     Could you give your opinion on how to support ATF on U-boot upstream?
> When I asked Simon Glass offline, he suggest if we can build ATF as part
> of the
> U-boot build process, perhaps with a script in U-boot tree,
> 
> Perhaps something like:
> 
> make rk3399_board_defconfig
> make
> ./scripts/build-atf-image rk3399_board
> ^^ new script
> 
> In any case, a good README would help.

I've started looking into RK3368 for my GeekBox, which raises a similar
issue. Are you working on that as well or just RK3399?

Personally I think that the approach the HiKey has taken is the best,
i.e. decouple U-Boot from ATF and just supply a README for how to make
it work with U-Boot as ATF payload.

Obviously it would help to integrate your loaderimage tool into mkimage.

Also, what is the difference between your trust_merger tool and ATF's
fip_create / fiptool?

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)

[U-Boot] How to support ATF on u-boot

[Andre Przywara]

Hi,

On 13/07/16 13:27, Andreas F?rber wrote:
> Hi Kever,
> 
> Am 20.06.2016 um 04:59 schrieb Kever Yang:
>>     I want to upstream a new SoC named RK3399 from Rockchip which is
>> AARCH64/ARMv8, we need to support Arm Trust Firmware base on U-boot.
>>
>>     Right now we are using a miniloader(just like SPL in U-boot) to load
>> ATF/U-boot,
>> and PC jump from miniloader to ATF and then to U-boot(with CPU change to
>> EL2 mode or nsEL1),
>> then U-boot load kernel/rootfs as usual.
>>
>>     The ATF support for RK3399 has already upstream
>>     Could you give your opinion on how to support ATF on U-boot upstream?
>> When I asked Simon Glass offline, he suggest if we can build ATF as part
>> of the
>> U-boot build process, perhaps with a script in U-boot tree,
>>
>> Perhaps something like:
>>
>> make rk3399_board_defconfig
>> make
>> ./scripts/build-atf-image rk3399_board
>> ^^ new script

I am not sure we should trigger an ATF build on building U-Boot. In my
build process for the Pine64 I just point to the compiled binary and
leave it up to the user to take care of compiling that. ATF builds are
really easy and fast, for the Pine64 it's just: "make PLAT=sun50iw1p1
bl31" for instance and takes only a few seconds.

>> In any case, a good README would help.
> 
> I've started looking into RK3368 for my GeekBox, which raises a similar
> issue. Are you working on that as well or just RK3399?
> 
> Personally I think that the approach the HiKey has taken is the best,
> i.e. decouple U-Boot from ATF and just supply a README for how to make
> it work with U-Boot as ATF payload.

Interestingly ATF itself considers U-Boot a payload, as it provides its
own bootstrapping parts which take a similar role as U-Boot's SPL.
So the official ATF build process (at least for Juno) lets you specify
the location of the U-Boot binary to be included in their FIP image.

OTOH, some boards (like the Pine64) only use the runtime component of
ATF, so including it in U-Boot makes more sense (see below). I guess
this is similar for Rockchip?

> Obviously it would help to integrate your loaderimage tool into mkimage.

FWIW, I extended SPL's FIT loading to support loading multiple images.
With this I was able to combine (non-SPL) U-Boot, ATF and multiple DTs
into one FIT image and attach that to the SPL.
I even managed to include a kernel and initrd in there, fwiw.
I will post those patches soonish.

Cheers,
Andre.

> Also, what is the difference between your trust_merger tool and ATF's
> fip_create / fiptool?
> 
> Regards,
> Andreas
> 

[U-Boot] How to support ATF on u-boot

[Andreas Färber]

Hi,

Am 13.07.2016 um 14:45 schrieb Andre Przywara:
> On 13/07/16 13:27, Andreas F?rber wrote:
>> Am 20.06.2016 um 04:59 schrieb Kever Yang:
>>>     I want to upstream a new SoC named RK3399 from Rockchip which is
>>> AARCH64/ARMv8, we need to support Arm Trust Firmware base on U-boot.
>>>
>>>     Right now we are using a miniloader(just like SPL in U-boot) to load
>>> ATF/U-boot,
>>> and PC jump from miniloader to ATF and then to U-boot(with CPU change to
>>> EL2 mode or nsEL1),
>>> then U-boot load kernel/rootfs as usual.
>>>
>>>     The ATF support for RK3399 has already upstream
>>>     Could you give your opinion on how to support ATF on U-boot upstream?
>>> When I asked Simon Glass offline, he suggest if we can build ATF as part
>>> of the
>>> U-boot build process, perhaps with a script in U-boot tree,
>>>
>>> Perhaps something like:
>>>
>>> make rk3399_board_defconfig
>>> make
>>> ./scripts/build-atf-image rk3399_board
>>> ^^ new script
> 
> I am not sure we should trigger an ATF build on building U-Boot. In my
> build process for the Pine64 I just point to the compiled binary and
> leave it up to the user to take care of compiling that. ATF builds are
> really easy and fast, for the Pine64 it's just: "make PLAT=sun50iw1p1
> bl31" for instance and takes only a few seconds.
> 
>>> In any case, a good README would help.
>>
>> I've started looking into RK3368 for my GeekBox, which raises a similar
>> issue. Are you working on that as well or just RK3399?
>>
>> Personally I think that the approach the HiKey has taken is the best,
>> i.e. decouple U-Boot from ATF and just supply a README for how to make
>> it work with U-Boot as ATF payload.
> 
> Interestingly ATF itself considers U-Boot a payload, as it provides its
> own bootstrapping parts which take a similar role as U-Boot's SPL.
> So the official ATF build process (at least for Juno) lets you specify
> the location of the U-Boot binary to be included in their FIP image.
> 
> OTOH, some boards (like the Pine64) only use the runtime component of
> ATF, so including it in U-Boot makes more sense (see below). I guess
> this is similar for Rockchip?

As a distro, like you say above, I wouldn't want to rebuild any
components of ATF each time U-Boot changes. It also complicates modeling
package dependencies. So I would want to build ATF and U-Boot separately
and then combine them in a third step when building an actual board
image. Supplying a script wouldn't hurt, while integration into `make`
would be problematic.

The other issue I see is who would take care of mirroring ATF updates
into U-Boot. By keeping the repos separate it will be easier for users
to follow arm-trusted-firmware.git master branch or to use forks/patches
where necessary. Too many vendors are missing in mainline ATF, so a
single git submodule wouldn't handle the potential diversity.

Do you have any ATF code from Allwinner that could be integrated into
mainline? For Amlogic S905 I only have blobs unfortunately and have been
discussing with Dan Handley how to adapt at least the mainline tools to
handle their quirks for avoiding per-vendor fip_create tools.

Cheers,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)

[U-Boot] How to support ATF on u-boot

[Andre Przywara]

Hi Andreas,

On 13/07/16 14:25, Andreas F?rber wrote:
> Hi,
> 
> Am 13.07.2016 um 14:45 schrieb Andre Przywara:
>> On 13/07/16 13:27, Andreas F?rber wrote:
>>> Am 20.06.2016 um 04:59 schrieb Kever Yang:
>>>>     I want to upstream a new SoC named RK3399 from Rockchip which is
>>>> AARCH64/ARMv8, we need to support Arm Trust Firmware base on U-boot.
>>>>
>>>>     Right now we are using a miniloader(just like SPL in U-boot) to load
>>>> ATF/U-boot,
>>>> and PC jump from miniloader to ATF and then to U-boot(with CPU change to
>>>> EL2 mode or nsEL1),
>>>> then U-boot load kernel/rootfs as usual.
>>>>
>>>>     The ATF support for RK3399 has already upstream
>>>>     Could you give your opinion on how to support ATF on U-boot upstream?
>>>> When I asked Simon Glass offline, he suggest if we can build ATF as part
>>>> of the
>>>> U-boot build process, perhaps with a script in U-boot tree,
>>>>
>>>> Perhaps something like:
>>>>
>>>> make rk3399_board_defconfig
>>>> make
>>>> ./scripts/build-atf-image rk3399_board
>>>> ^^ new script
>>
>> I am not sure we should trigger an ATF build on building U-Boot. In my
>> build process for the Pine64 I just point to the compiled binary and
>> leave it up to the user to take care of compiling that. ATF builds are
>> really easy and fast, for the Pine64 it's just: "make PLAT=sun50iw1p1
>> bl31" for instance and takes only a few seconds.
>>
>>>> In any case, a good README would help.
>>>
>>> I've started looking into RK3368 for my GeekBox, which raises a similar
>>> issue. Are you working on that as well or just RK3399?
>>>
>>> Personally I think that the approach the HiKey has taken is the best,
>>> i.e. decouple U-Boot from ATF and just supply a README for how to make
>>> it work with U-Boot as ATF payload.
>>
>> Interestingly ATF itself considers U-Boot a payload, as it provides its
>> own bootstrapping parts which take a similar role as U-Boot's SPL.
>> So the official ATF build process (at least for Juno) lets you specify
>> the location of the U-Boot binary to be included in their FIP image.
>>
>> OTOH, some boards (like the Pine64) only use the runtime component of
>> ATF, so including it in U-Boot makes more sense (see below). I guess
>> this is similar for Rockchip?
> 
> As a distro, like you say above, I wouldn't want to rebuild any
> components of ATF each time U-Boot changes. It also complicates modeling
> package dependencies. So I would want to build ATF and U-Boot separately
> and then combine them in a third step when building an actual board
> image. Supplying a script wouldn't hurt, while integration into `make`
> would be problematic.

I agree, that's why we do for the Pine64, with an off-tree (compiled)
tool for the moment, but with some simple mkimage -f later on.

> The other issue I see is who would take care of mirroring ATF updates
> into U-Boot. By keeping the repos separate it will be easier for users
> to follow arm-trusted-firmware.git master branch or to use forks/patches
> where necessary. Too many vendors are missing in mainline ATF, so a
> single git submodule wouldn't handle the potential diversity.
> 
> Do you have any ATF code from Allwinner that could be integrated into
> mainline? For Amlogic S905 I only have blobs unfortunately and have been
> discussing with Dan Handley how to adapt at least the mainline tools to
> handle their quirks for avoiding per-vendor fip_create tools.

Allwinner provided a tarball with ATF sources, based on the older v1.0
release. I put that into a commit and cleaned it up radically [1]. Next
step would be to do a proper upstream port, which I already started, but
stopped for the time being due to missing time and lack of priority.

As for the tools side, as mentioned we only use bl31 (at least for now)
and let (eventually) SPL do the rest. So I use "mkimage -f pine64.its"
on U-Boot build instead of building a FIP image on the ATF build.

Cheers,
Andre.

[1] https://github.com/apritzel/arm-trusted-firmware/commits/allwinner

[U-Boot] How to support ATF on u-boot

[Kever Yang]

Hi Andre,

On 07/13/2016 08:45 PM, Andre Przywara wrote:
> Hi,
>
> On 13/07/16 13:27, Andreas F?rber wrote:
>> Hi Kever,
>>
>> Am 20.06.2016 um 04:59 schrieb Kever Yang:
>>>      I want to upstream a new SoC named RK3399 from Rockchip which is
>>> AARCH64/ARMv8, we need to support Arm Trust Firmware base on U-boot.
>>>
>>>      Right now we are using a miniloader(just like SPL in U-boot) to load
>>> ATF/U-boot,
>>> and PC jump from miniloader to ATF and then to U-boot(with CPU change to
>>> EL2 mode or nsEL1),
>>> then U-boot load kernel/rootfs as usual.
>>>
>>>      The ATF support for RK3399 has already upstream
>>>      Could you give your opinion on how to support ATF on U-boot upstream?
>>> When I asked Simon Glass offline, he suggest if we can build ATF as part
>>> of the
>>> U-boot build process, perhaps with a script in U-boot tree,
>>>
>>> Perhaps something like:
>>>
>>> make rk3399_board_defconfig
>>> make
>>> ./scripts/build-atf-image rk3399_board
>>> ^^ new script
> I am not sure we should trigger an ATF build on building U-Boot. In my
> build process for the Pine64 I just point to the compiled binary and
> leave it up to the user to take care of compiling that. ATF builds are
> really easy and fast, for the Pine64 it's just: "make PLAT=sun50iw1p1
> bl31" for instance and takes only a few seconds.
I have send my patch set today, get bl31 from ATF is easy, still need some
rockchip tools to do the package and load the image.
>
>>> In any case, a good README would help.
>> I've started looking into RK3368 for my GeekBox, which raises a similar
>> issue. Are you working on that as well or just RK3399?
>>
>> Personally I think that the approach the HiKey has taken is the best,
>> i.e. decouple U-Boot from ATF and just supply a README for how to make
>> it work with U-Boot as ATF payload.
> Interestingly ATF itself considers U-Boot a payload, as it provides its
> own bootstrapping parts which take a similar role as U-Boot's SPL.
> So the official ATF build process (at least for Juno) lets you specify
> the location of the U-Boot binary to be included in their FIP image.
>
> OTOH, some boards (like the Pine64) only use the runtime component of
> ATF, so including it in U-Boot makes more sense (see below). I guess
> this is similar for Rockchip?
Yes for now, but I think there might be a secure OS in the future.
>
>> Obviously it would help to integrate your loaderimage tool into mkimage.
> FWIW, I extended SPL's FIT loading to support loading multiple images.
> With this I was able to combine (non-SPL) U-Boot, ATF and multiple DTs
> into one FIT image and attach that to the SPL.
> I even managed to include a kernel and initrd in there, fwiw.
> I will post those patches soonish.
Great, good news! Simon also want to enable the SPL support for ATF when we
discuss this issue offline, so I think we can see this feature enabled 
very soon.

Thanks,
- Kever
>
> Cheers,
> Andre.
>
>> Also, what is the difference between your trust_merger tool and ATF's
>> fip_create / fiptool?
>>
>> Regards,
>> Andreas
>>
>
>

[U-Boot] How to support ATF on u-boot

[Simon Glass]

Hi,

On 14 July 2016 at 06:14, Kever Yang <kever.yang@rock-chips.com> wrote:
> Hi Andre,
>
>
> On 07/13/2016 08:45 PM, Andre Przywara wrote:
>>
>> Hi,
>>
>> On 13/07/16 13:27, Andreas F?rber wrote:
>>>
>>> Hi Kever,
>>>
>>> Am 20.06.2016 um 04:59 schrieb Kever Yang:
>>>>
>>>>      I want to upstream a new SoC named RK3399 from Rockchip which is
>>>> AARCH64/ARMv8, we need to support Arm Trust Firmware base on U-boot.
>>>>
>>>>      Right now we are using a miniloader(just like SPL in U-boot) to
>>>> load
>>>> ATF/U-boot,
>>>> and PC jump from miniloader to ATF and then to U-boot(with CPU change to
>>>> EL2 mode or nsEL1),
>>>> then U-boot load kernel/rootfs as usual.
>>>>
>>>>      The ATF support for RK3399 has already upstream
>>>>      Could you give your opinion on how to support ATF on U-boot
>>>> upstream?
>>>> When I asked Simon Glass offline, he suggest if we can build ATF as part
>>>> of the
>>>> U-boot build process, perhaps with a script in U-boot tree,
>>>>
>>>> Perhaps something like:
>>>>
>>>> make rk3399_board_defconfig
>>>> make
>>>> ./scripts/build-atf-image rk3399_board
>>>> ^^ new script
>>
>> I am not sure we should trigger an ATF build on building U-Boot. In my
>> build process for the Pine64 I just point to the compiled binary and
>> leave it up to the user to take care of compiling that. ATF builds are
>> really easy and fast, for the Pine64 it's just: "make PLAT=sun50iw1p1
>> bl31" for instance and takes only a few seconds.
>
> I have send my patch set today, get bl31 from ATF is easy, still need some
> rockchip tools to do the package and load the image.
>>
>>
>>>> In any case, a good README would help.
>>>
>>> I've started looking into RK3368 for my GeekBox, which raises a similar
>>> issue. Are you working on that as well or just RK3399?
>>>
>>> Personally I think that the approach the HiKey has taken is the best,
>>> i.e. decouple U-Boot from ATF and just supply a README for how to make
>>> it work with U-Boot as ATF payload.
>>
>> Interestingly ATF itself considers U-Boot a payload, as it provides its
>> own bootstrapping parts which take a similar role as U-Boot's SPL.
>> So the official ATF build process (at least for Juno) lets you specify
>> the location of the U-Boot binary to be included in their FIP image.
>>
>> OTOH, some boards (like the Pine64) only use the runtime component of
>> ATF, so including it in U-Boot makes more sense (see below). I guess
>> this is similar for Rockchip?
>
> Yes for now, but I think there might be a secure OS in the future.
>>
>>
>>> Obviously it would help to integrate your loaderimage tool into mkimage.
>>
>> FWIW, I extended SPL's FIT loading to support loading multiple images.
>> With this I was able to combine (non-SPL) U-Boot, ATF and multiple DTs
>> into one FIT image and attach that to the SPL.
>> I even managed to include a kernel and initrd in there, fwiw.
>> I will post those patches soonish.
>
> Great, good news! Simon also want to enable the SPL support for ATF when we
> discuss this issue offline, so I think we can see this feature enabled very
> soon.

Just to follow up, I send a series that adds a 'binman' tool. I have
not added specific support for ATF but it should be very easy to do
so, once the image layout is defined.

Regards,
Simon

[U-Boot] How to support ATF on u-boot

[Kever Yang]

Hi Andreas,

On 07/13/2016 08:27 PM, Andreas F?rber wrote:
> Hi Kever,
>
> Am 20.06.2016 um 04:59 schrieb Kever Yang:
>>      I want to upstream a new SoC named RK3399 from Rockchip which is
>> AARCH64/ARMv8, we need to support Arm Trust Firmware base on U-boot.
>>
>>      Right now we are using a miniloader(just like SPL in U-boot) to load
>> ATF/U-boot,
>> and PC jump from miniloader to ATF and then to U-boot(with CPU change to
>> EL2 mode or nsEL1),
>> then U-boot load kernel/rootfs as usual.
>>
>>      The ATF support for RK3399 has already upstream
>>      Could you give your opinion on how to support ATF on U-boot upstream?
>> When I asked Simon Glass offline, he suggest if we can build ATF as part
>> of the
>> U-boot build process, perhaps with a script in U-boot tree,
>>
>> Perhaps something like:
>>
>> make rk3399_board_defconfig
>> make
>> ./scripts/build-atf-image rk3399_board
>> ^^ new script
>>
>> In any case, a good README would help.
> I've started looking into RK3368 for my GeekBox, which raises a similar
> issue. Are you working on that as well or just RK3399?
I'm working on RK3399 platform now, but the rk3368 should be the same.
>
> Personally I think that the approach the HiKey has taken is the best,
> i.e. decouple U-Boot from ATF and just supply a README for how to make
> it work with U-Boot as ATF payload.
Yes, I'm cleaning a patchset just like HiKey with a readme to support ATF,
but in Rockchip way and Rockchip tools.
>
> Obviously it would help to integrate your loaderimage tool into mkimage.
For the loaderimage integrate into mkimage, I think it depends on if we need
the Rockchip miniloader in the future. If the SPL support the package 
and parse
multi image including ATF, then we can use everyting from U-boot.
>
> Also, what is the difference between your trust_merger tool and ATF's
> fip_create / fiptool?
I didn't look into ATF's fip_create/fiptool so far, the trust_merger 
tool is to package
the  ATF binary/binaries in format for Rockchip miniloader.

Thanks,
- Kever
>
> Regards,
> Andreas
>