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