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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot