| Message ID | 1508406333-27138-3-git-send-email-jagan@amarulasolutions.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | board: Add Allwinner A64/H5 boards | expand |
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. 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 pass BL31. What do you think ? Thomas
+ Andre On 21-Oct-2017 11:06 PM, "Thomas Petazzoni" < thomas.petazzoni@free-electrons.com> 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. 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 pass BL31. What do you think ? Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com <div dir="auto"><div>+ Andre<br><div class="gmail_extra"><br><div class="gmail_quote">On 21-Oct-2017 11:06 PM, "Thomas Petazzoni" <<a href="mailto:thomas.petazzoni@free-electrons.com">thomas.petazzoni@free-electrons.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br> <div class="quoted-text"><br> On Thu, 19 Oct 2017 11:45:24 +0200, Jagan Teki wrote:<br> <br> > +# sunxi64-post-build script<br> > +#<br> > +# Allwinner A64/H5 firmware consists of three parts:<br> > +# 1) U-Boot's SPL<br> > +# 2) ARM Trusted Firmware (ATF)<br> > +# 3) U-Boot proper.<br> > +#<br> > +# The SPL will load both ATF and U-Boot proper along with the right device<br> > +# tree blob (.dtb) and will pass execution to ATF (in EL3), which in turn will<br> > +# drop into the U-Boot proper (in EL2).<br> > +#<br> > +# As the ATF binary will become part of the U-Boot image file, you will need<br> > +# to build it first and export ATF variable to built U-Boot proper. Since<br> > +# buildroot not take of building ATF first and export the binary, this post-build<br> > +# script build the u-boot.itb<br> <br> </div>Thanks for this explanation. However, I am not too happy with the<br> solution you propose. Indeed, the U-Boot build system already has all<br> the logic to produce the u-boot.itb, provided the BL31 environment<br> variable is defined.<br> <br> I think the problem is that the ATF package currently only supports<br> the case where ATF embeds U-Boot (that is for example how it works on<br> the ARM Juno platform if I remember correctly<br> (configs/arm_juno_defconfig) or on Marvell platforms. This explains why<br> the arm-trusted-firmware package depends on uboot.<br> <br> The sunxi scenario is different because it wants ATF to be built<br> *before* U-Boot, so basically the opposite.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">This wasn't only the case with sunxi it's been the U-Boot FIT behaviour..even rockchip do follow same build process.</div><div dir="auto"><br></div><div dir="auto">Ideally FIT need input files to produce blob like dtb.</div><div dir="auto"><br></div><div dir="auto">Added Andre he will give some more insight.</div><div dir="auto"><br></div><div dir="auto">Jagan.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> So I would propose:<br> <br> * An option in ATF to decide if it needs U-Boot to be built before or<br> not.<br> <br> * An option in U-Boot to decide if it needs ATF to be built before or<br> not.<br> <br> * An option in U-Boot to pass custom variable on the build command<br> line so that we can pass the path to BL31. Or directly an option<br> that will make <a href="http://uboot.mk" rel="noreferrer" target="_blank">uboot.mk</a> pass BL31.<br> <br> What do you think ?<br> <font color="#888888"><br> Thomas<br> --<br> Thomas Petazzoni, CTO, Free Electrons<br> Embedded Linux and Kernel engineering<br> <a href="http://free-electrons.com" rel="noreferrer" target="_blank">http://free-electrons.com</a><br> </font></blockquote></div><br></div></div></div>
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). Best regards, Thomas
On Sun, Oct 22, 2017 at 5:59 PM, Thomas Petazzoni <thomas.petazzoni@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 thanks!
On Thu, Oct 26, 2017 at 4:50 PM, Jagan Teki <jagan@amarulasolutions.com> wrote: > On Sun, Oct 22, 2017 at 5:59 PM, Thomas Petazzoni > <thomas.petazzoni@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 Seems like FIP need for BL33, I've sent new series please have a look. thanks!
On Fri, Oct 27, 2017 at 2:02 AM, André Przywara <andre.przywara@arm.com> wrote: > On 26/10/17 19:13, Jagan Teki wrote: >> On Thu, Oct 26, 2017 at 4:50 PM, Jagan Teki <jagan@amarulasolutions.com> wrote: >>> On Sun, Oct 22, 2017 at 5:59 PM, Thomas Petazzoni >>> <thomas.petazzoni@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!
diff --git a/support/scripts/sunxi64-post-build.sh b/support/scripts/sunxi64-post-build.sh new file mode 100755 index 0000000..359bd1d --- /dev/null +++ b/support/scripts/sunxi64-post-build.sh @@ -0,0 +1,32 @@ +#!/usr/bin/env bash +# +# 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 + +# source .config +source ${BR2_CONFIG} + +ATF_BUILD_DIR=arm-trusted-firmware-${BR2_TARGET_ARM_TRUSTED_FIRMWARE_VERSION}/build +ATF_PLAT_DIR=${ATF_BUILD_DIR}/${BR2_TARGET_ARM_TRUSTED_FIRMWARE_PLATFORM}/release +ATF_BIN_PATH=${ATF_PLAT_DIR}/${BR2_TARGET_ARM_TRUSTED_FIRMWARE_ADDITIONAL_VARIABLES}.bin +UBOOT_BUILD_DIR=${BUILD_DIR}/uboot-${BR2_TARGET_UBOOT_VERSION} +MKIMAGE=${UBOOT_BUILD_DIR}/tools/mkimage +DTB_NAME=${BR2_LINUX_KERNEL_INTREE_DTS_NAME#*/}.dtb + +cd ${UBOOT_BUILD_DIR} +export BL31=${BUILD_DIR}/${ATF_BIN_PATH} +${UBOOT_BUILD_DIR}/board/sunxi/mksunxi_fit_atf.sh ${UBOOT_BUILD_DIR}/arch/arm/dts/${DTB_NAME} > u-boot.its +${MKIMAGE} -f u-boot.its -E $BINARIES_DIR/u-boot.itb
For building U-Boot proper in allwinner A64/H5 ATF need to build first and ATF binary need to be exported, since buildroot not taking care of this process this script will do the same build during post-build. Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> --- support/scripts/sunxi64-post-build.sh | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100755 support/scripts/sunxi64-post-build.sh