Hi, On 22/10/17 11:15, Jagan Teki wrote: > + Andre > > On 21-Oct-2017 11:06 PM, "Thomas Petazzoni" > <[email protected] > <mailto:[email protected]>> wrote: > > Hello, > > On Thu, 19 Oct 2017 11:45:24 +0200, Jagan Teki wrote: > > > +# sunxi64-post-build script > > +# > > +# Allwinner A64/H5 firmware consists of three parts: > > +# 1) U-Boot's SPL > > +# 2) ARM Trusted Firmware (ATF) > > +# 3) U-Boot proper. > > +# > > +# The SPL will load both ATF and U-Boot proper along with the > right device > > +# tree blob (.dtb) and will pass execution to ATF (in EL3), which > in turn will > > +# drop into the U-Boot proper (in EL2). > > +# > > +# As the ATF binary will become part of the U-Boot image file, > you will need > > +# to build it first and export ATF variable to built U-Boot > proper. Since > > +# buildroot not take of building ATF first and export the binary, > this post-build > > +# script build the u-boot.itb > > Thanks for this explanation. However, I am not too happy with the > solution you propose. Indeed, the U-Boot build system already has all > the logic to produce the u-boot.itb, provided the BL31 environment > variable is defined. > > I think the problem is that the ATF package currently only supports > the case where ATF embeds U-Boot (that is for example how it works on > the ARM Juno platform if I remember correctly > (configs/arm_juno_defconfig) or on Marvell platforms. This explains why > the arm-trusted-firmware package depends on uboot. > > The sunxi scenario is different because it wants ATF to be built > *before* U-Boot, so basically the opposite. > > > This wasn't only the case with sunxi it's been the U-Boot FIT > behaviour..even rockchip do follow same build process. > > Ideally FIT need input files to produce blob like dtb. > > Added Andre he will give some more insight.
So yes, ATF supports *multiple* ways of integration: - On the Juno it has the capability of loading images - from NOR flash, so not a big deal. This means the BL1 and BL2 stages read the BL31 (containing the PSCI runtime) and BL33 (U-Boot or EDK2), also this uses the ATF defined FIP image format. - For other platforms (like rockchip or sunxi) we usually load from MMC or SPI flash. So using the traditional ATF approach would mean to have MMC and SPI drivers in the early ATF stages, also do the DRAM initialization there. Since ATF is BSD licensed, it's more involved than just copying some code from U-Boot. So the pragmatic approach - which ATF actually embraces - is to just use a subset of the whole ATF (BL31) and do the rest via some platform specific firmware: which is U-Boot's SPL in our case, since it already has support for this hardware. Other platform (most ARM64 servers) tend to have their proprietary early-init firmware there. So I virtually know nothing about buildroot, but it might not be a good idea to shoehorn the second approach into the Juno ATF build scheme. As I believe that in fact more platforms use the second approach, it might be worthwhile to introduce some extra code in buildroot to support that specifically instead of working around the Juno ATF way. Maybe it can be modelled as some U-Boot FIT build process with an additional requirement, similar to a binary blob? Cheers, Andre. > > Jagan. > > > So I would propose: > > * An option in ATF to decide if it needs U-Boot to be built before or > not. > > * An option in U-Boot to decide if it needs ATF to be built before or > not. > > * An option in U-Boot to pass custom variable on the build command > line so that we can pass the path to BL31. Or directly an option > that will make uboot.mk <http://uboot.mk> pass BL31. > > What do you think ? > > Thomas > -- > Thomas Petazzoni, CTO, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com > > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
