On Fri, Oct 27, 2017 at 2:02 AM, André Przywara <andre.przyw...@arm.com> wrote: > On 26/10/17 19:13, Jagan Teki wrote: >> On Thu, Oct 26, 2017 at 4:50 PM, Jagan Teki <ja...@amarulasolutions.com> >> wrote: >>> On Sun, Oct 22, 2017 at 5:59 PM, Thomas Petazzoni >>> <thomas.petazz...@free-electrons.com> wrote: >>>> Hello, >>>> >>>> On Sun, 22 Oct 2017 12:05:52 +0100, André Przywara wrote: >>>> >>>>>> 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. >>>> >>>> Thanks for summarizing the context. >>>> >>>>> 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? >>>> >>>> And this is exactly what I was suggesting Jagan to do: extend Buildroot >>>> so that it covers the U-Boot-bundles-ATF scenario (sunxi/rockchip, >>>> etc.) in addition to the already supported ATF-bundles-U-Boot scenario >>>> (Juno). >>> >>> Based on the ATF build this look not an exact U-Boot-bundles-ATF >>> scenario. Whether for Juno(ATF-bundles-U-Boot scenario) or for SUNXI, >>> ATF want a dependence to build U-Boot first atleast for FIP point. >>> >>> ARM_TRUSTED_FIRMWARE_MAKE_OPTS += \ >>> CROSS_COMPILE="$(TARGET_CROSS)" \ >>> BL33=$(BINARIES_DIR)/u-boot.bin \ >>> >>> Here BL33 need u-boot.bin to export for building FIP in default that >>> could be the reason of making ARM_TRUSTED_FIRMWARE_DEPENDENCIES += >>> uboot >>> in atf. >>> >>> I tried to build for U-Boot-bundles-ATF scenario by not to dependent >>> U-Boot so that U-boot build later. Since at this movement there is no >>> U-Boot build, ATF is unable to get the BL33, I don't know whether this >>> BL33 is needed for all because I'm trying for BL31. >>> >>> Build Log: >>> ------------- >>> un50iw1p1 all fip >>> make[1]: Entering directory >>> `/mnt/jagan/buildroot/buildroot-sun32/output/build/arm-trusted-firmware-aa75c8da415158a94b82a430b2b40000778e851f' >>> make[1]: Nothing to be done for `bl31'. >>> make[1]: *** No rule to make target >>> `/mnt/jagan/buildroot/buildroot-sun32/output/images/u-boot.bin', >>> needed by `build/sun50iw1p1/release/fip.bin'. Stop. >>> make[1]: *** Waiting for unfinished jobs.... >>> Building sun50iw1p1 > > Why do build a fip then? > Please read board/sunxi/README.sunxi in the U-Boot sources, it tells you > how to build ATF: namely using the "bl31" target, and not "all fip" as > for the Juno, for instance.
Yes, ie what I founded out. Currently buildroot is doing 'all fip', I've fixed and patches in ML. thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.