| Message ID | 1542900148-17204-1-git-send-email-etienne.carriere@linaro.org |
|---|---|
| State | Rejected |
| Headers | show |
| Series | [1/1] boot/arm-trusted-firmware: use prebuilt BL33 images | expand |
Hello Etienne, On Thu, 22 Nov 2018 16:22:28 +0100, Etienne Carriere wrote: > This change allows one to build ATF with an externally built > BL33 image or with the U-boot as BL33 boot stage. > > This change introduces a new configuration directive for TF-A to > specify when BL33 stage is provided as a prebuilt image: > BR2_TARGET_ARM_TRUSTED_FIRMWARE_PREBUILT_BL33. > > If BR2_TARGET_ARM_TRUSTED_FIRMWARE_PREBUILT_BL33 is enabled, the > buildroot configuration shall specify the BL33 binary image location: > BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL33_IMAGE. > > Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> > --- > boot/arm-trusted-firmware/Config.in | 22 +++++++++++++++++++++- > boot/arm-trusted-firmware/arm-trusted-firmware.mk | 4 ++++ > 2 files changed, 25 insertions(+), 1 deletion(-) Thanks for this contribution. Could you explain the use case/rationale for this change ? In which situation do you want to use prebuilt BL33 images, as opposed to having another Buildroot package that builds (or downloads) them ? Best regards, Thomas
On Thu, 29 Nov 2018 at 23:04, Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > > Hello Etienne, > > On Thu, 22 Nov 2018 16:22:28 +0100, Etienne Carriere wrote: > > This change allows one to build ATF with an externally built > > BL33 image or with the U-boot as BL33 boot stage. > > > > This change introduces a new configuration directive for TF-A to > > specify when BL33 stage is provided as a prebuilt image: > > BR2_TARGET_ARM_TRUSTED_FIRMWARE_PREBUILT_BL33. > > > > If BR2_TARGET_ARM_TRUSTED_FIRMWARE_PREBUILT_BL33 is enabled, the > > buildroot configuration shall specify the BL33 binary image location: > > BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL33_IMAGE. > > > > Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> > > --- > > boot/arm-trusted-firmware/Config.in | 22 +++++++++++++++++++++- > > boot/arm-trusted-firmware/arm-trusted-firmware.mk | 4 ++++ > > 2 files changed, 25 insertions(+), 1 deletion(-) > > Thanks for this contribution. Could you explain the use case/rationale > for this change ? In which situation do you want to use prebuilt BL33 > images, as opposed to having another Buildroot package that builds (or > downloads) them ? Rational is to relax the BR arm-trusted-firmware (ATF) package regarding support for alternate BL33 boot stages. Current package supports only U-boot as ATF BL33 and using an alternate boot stage mandates changes in boot Config.in and arm-trusted-firmware.mk. I understand that I did not setup this the right way as my proposal does not implies BR is the build/install of the alternate boot stage. Maybe I should discard BR2_TARGET_ARM_TRUSTED_FIRMWARE_PREBUILT_BL33 an introduce something like ..._BL33_PACKAGE to specify the package BR shall build as a dependency for ATF (i.e "uboot" if BR2_TARGET_ARM_TRUSTED_FIRMWARE_UBOOT_AS_BL33=y). In this case ..._BL33_IMAGE would need to provide the BL33 binary image file name that is expected from directory $(BINARIES), i.e "u-boot.bin". Or maybe discard this change and if another boot stage shall be support, one need to propose specific changes in BR ATF for that BL33 boot stage. Your though? For info: I have a former change regarding BL32 (instead of BL33) I have not yet pushed to the ML. I wait for OP-TEE OS package to land [1] before proposing change in ATF for OP-TEE as BL32 or an alternate BL32 with the same model as this alternate BL33. regards, etienne > Best regards, > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com
Hello Etienne, > This change allows one to build ATF with an externally built > BL33 image or with the U-boot as BL33 boot stage. > > This change introduces a new configuration directive for TF-A to > specify when BL33 stage is provided as a prebuilt image: > BR2_TARGET_ARM_TRUSTED_FIRMWARE_PREBUILT_BL33. > > If BR2_TARGET_ARM_TRUSTED_FIRMWARE_PREBUILT_BL33 is enabled, the > buildroot configuration shall specify the BL33 binary image location: > BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL33_IMAGE. ... > --- a/boot/arm-trusted-firmware/Config.in > +++ b/boot/arm-trusted-firmware/Config.in > @@ -1,6 +1,6 @@ > config BR2_TARGET_ARM_TRUSTED_FIRMWARE > bool "ARM Trusted Firmware (ATF)" > - depends on BR2_aarch64 && BR2_TARGET_UBOOT > + depends on BR2_aarch64 Could you please clarify why do you want to get rid of this dependency ? IIUC so far all the arm64/atf boards supported by BR make use of U-Boot. If you plan to use this feature for a board with any other type of bootloader, then maybe it makes sense to add board config as well. In this case other developers will be able at least build-test this particular config swtich when testing their own ATF changes. Regards, Sergey
On Sat, 1 Dec 2018 at 21:20, Sergey Matyukevich <geomatsi@gmail.com> wrote: > > Hello Etienne, > > > This change allows one to build ATF with an externally built > > BL33 image or with the U-boot as BL33 boot stage. > > > > This change introduces a new configuration directive for TF-A to > > specify when BL33 stage is provided as a prebuilt image: > > BR2_TARGET_ARM_TRUSTED_FIRMWARE_PREBUILT_BL33. > > > > If BR2_TARGET_ARM_TRUSTED_FIRMWARE_PREBUILT_BL33 is enabled, the > > buildroot configuration shall specify the BL33 binary image location: > > BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL33_IMAGE. > > ... > > > --- a/boot/arm-trusted-firmware/Config.in > > +++ b/boot/arm-trusted-firmware/Config.in > > @@ -1,6 +1,6 @@ > > config BR2_TARGET_ARM_TRUSTED_FIRMWARE > > bool "ARM Trusted Firmware (ATF)" > > - depends on BR2_aarch64 && BR2_TARGET_UBOOT > > + depends on BR2_aarch64 > > Could you please clarify why do you want to get rid of this dependency ? > IIUC so far all the arm64/atf boards supported by BR make use of U-Boot. > If you plan to use this feature for a board with any other type of > bootloader, then maybe it makes sense to add board config as well. In this > case other developers will be able at least build-test this particular > config swtich when testing their own ATF changes. > Hello Sergey, Maybe I should start from the whole picture of my intentions (I tried to be short). I would like to bring (at least ease) support for OP-TEE on ATF aware platforms in BR OP-TEE is a compliant BL32 image (secure OS) ATF is able to boot. This scheme covers arm64 platforms but also some 32bit arm platforms (since ATF v1.5), assuming OP-TEE support this platfrom. I have submitted patches to integrate OP-TEE components as BR packages [1], before I submit the changes in boot/arm-trusted_firmware to support this package. (in the end, I plan to submit a new Qemu/arm board that boots OP-TEE and a Linux OS through ATF + U-boot). Assuming OP-TEE package ([1]) is merged in BR, I saw 2 options for BR to build ATF with OP-TEE support: 1/ Hard code OP-TEE support in BR package ATF on the same model as U-Boot as BL33 support in ATF. => Config.mk defines a specific xxxx_OPTEE_AS_BL32. => arm-trusted-firmware.mk defines the expected binary image filename(s). 2/ Allow ATF Config.mk & arm-trusted-firmware.mk to be more flexible for supporting alternate BL32 images, being OP-TEE or something else. One would set the build deps and BL32 image filename(s) from its board config, not from the BR ATF package. The patch reviewed in this thread proposes scheme 2/ above applied to BL33 stage. It is true that all boards currently supported in BR that uses ATF with a BL33 stage do use U-Boot as BL33. There is currently not specific need for alternate BL33 packages. From the same perspective, when i will submit OP-TEE support, there will be no specific need for alternate BL32 outside OPTEE. SO the question is: it interesting to allow a BR board config to define its BL32/BL33 stages or should these be tied to ATF config/make script in BR? To be clear on my expectations: I do not formerly need such a flexible support. I currently only use U-boot as BL33 and OP-TEE as BL32 in my BR setup. I would understand that the scheme proposed here is rejected. Regards, etienne [1] http://lists.busybox.net/pipermail/buildroot/2018-November/236558.html > Regards, > Sergey
Hello Etienne, Thanks for the very long time it took to get back to you. On Mon, 3 Dec 2018 11:36:40 +0100 Etienne Carriere <etienne.carriere@linaro.org> wrote: > Maybe I should start from the whole picture of my intentions (I tried > to be short). > > I would like to bring (at least ease) support for OP-TEE on ATF aware > platforms in BR > OP-TEE is a compliant BL32 image (secure OS) ATF is able to boot. > This scheme covers arm64 platforms but also some 32bit arm platforms > (since ATF v1.5), assuming OP-TEE support this platfrom. > I have submitted patches to integrate OP-TEE components as BR packages > [1], before I submit the changes in boot/arm-trusted_firmware to > support this package. > (in the end, I plan to submit a new Qemu/arm board that boots OP-TEE > and a Linux OS through ATF + U-boot). > > Assuming OP-TEE package ([1]) is merged in BR, I saw 2 options for BR > to build ATF with OP-TEE support: > > 1/ Hard code OP-TEE support in BR package ATF on the same model as > U-Boot as BL33 support in ATF. > => Config.mk defines a specific xxxx_OPTEE_AS_BL32. > => arm-trusted-firmware.mk defines the expected binary image filename(s). > > 2/ Allow ATF Config.mk & arm-trusted-firmware.mk to be more flexible > for supporting alternate BL32 images, being OP-TEE or something else. > One would set the build deps and BL32 image filename(s) from its board > config, not from the BR ATF package. > > The patch reviewed in this thread proposes scheme 2/ above applied to > BL33 stage. > It is true that all boards currently supported in BR that uses ATF > with a BL33 stage do use U-Boot as BL33. There is currently not > specific need for alternate BL33 packages. > From the same perspective, when i will submit OP-TEE support, there > will be no specific need for alternate BL32 outside OPTEE. > > SO the question is: it interesting to allow a BR board config to > define its BL32/BL33 stages or should these be tied to ATF config/make > script in BR? > > To be clear on my expectations: I do not formerly need such a flexible > support. I currently only use U-boot as BL33 and OP-TEE as BL32 in my > BR setup. I would understand that the scheme proposed here is > rejected. Thanks for the clearer explanation. It would have been great to have exactly this explanation in the commit log in the first place! The proposed scheme is not ideal because for example the custom pre-built BL33 cannot be provided by another Buildroot package, as you cannot express the dependency. If all you're interested in is supporting OPTEE-OS, then I would recommend just add explicit support for it as an optional BL32 in ATF, without trying to be too flexible. If however you really want something that is very flexible, to allow both custom BL32 and BL33, then a possible solution is to create virtual packages: atf-bl32 and atf-bl33. optee_os would be a provider of atf-bl32, and U-Boot/Barebox could be providers of atf-bl33. This also allows custom packages in BR2_EXTERNAL, that package some custom BL32/BL33 to be providers of atf-bl32 or atf-bl33. This is of course more complicated to implement. Perhaps it is wise to wait and see if there really is a need for something like this. In the mean time, if what you want is just OPTEE-OS as BL32, keep it simple and add explicit handling for it in ATF. Thanks! Thomas
Hello Thomas, Thanks for the feedback. > The proposed scheme is not ideal because for example the custom > pre-built BL33 cannot be provided by another Buildroot package, as you > cannot express the dependency. > > If all you're interested in is supporting OPTEE-OS, then I would > recommend just add explicit support for it as an optional BL32 in ATF, > without trying to be too flexible. > > If however you really want something that is very flexible, to allow > both custom BL32 and BL33, then a possible solution is to create > virtual packages: atf-bl32 and atf-bl33. optee_os would be a provider > of atf-bl32, and U-Boot/Barebox could be providers of atf-bl33. This > also allows custom packages in BR2_EXTERNAL, that package some custom > BL32/BL33 to be providers of atf-bl32 or atf-bl33. This is of course > more complicated to implement. Perhaps it is wise to wait and see if > there really is a need for something like this. > > In the mean time, if what you want is just OPTEE-OS as BL32, keep it > simple and add explicit handling for it in ATF. I had UEFI in mind as it can be a BL33 boot stage used by ATF for 64bit Arm platforms. But it's not built from Buildroot, as pointed from [1]. Yet I get your point about the need for clean dependency management in a pristine Buildroot package. Maybe I or someone can come up with a better proposal some day to address this. Anyway, thanks again for all your feedback and detailed argumentation. [1] https://github.com/buildroot/buildroot/blob/2019.05.x/board/aarch64-efi/readme.txt#L31 Regards, etienne > > Thanks! > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com
diff --git a/boot/arm-trusted-firmware/Config.in b/boot/arm-trusted-firmware/Config.in index 885d93e..679153d 100644 --- a/boot/arm-trusted-firmware/Config.in +++ b/boot/arm-trusted-firmware/Config.in @@ -1,6 +1,6 @@ config BR2_TARGET_ARM_TRUSTED_FIRMWARE bool "ARM Trusted Firmware (ATF)" - depends on BR2_aarch64 && BR2_TARGET_UBOOT + depends on BR2_aarch64 help Enable this option if you want to build the ATF for your ARM based embedded device. @@ -73,12 +73,18 @@ config BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL31 config BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL31_UBOOT bool "Build BL31 U-Boot image" + depends on BR2_TARGET_UBOOT select BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL31 help Generates a U-Boot image named atf-uboot.ub containing bl31.bin. This is used for example by the Xilinx version of U-Boot SPL to load ATF on the ZynqMP SoC. +choice + prompt "Select BL33 stage for the trusted firmware" + help + Select BL33 stage for the trusted firmware. + config BR2_TARGET_ARM_TRUSTED_FIRMWARE_UBOOT_AS_BL33 bool "Use U-Boot as BL33" depends on BR2_TARGET_UBOOT @@ -88,6 +94,20 @@ config BR2_TARGET_ARM_TRUSTED_FIRMWARE_UBOOT_AS_BL33 gets built before ATF, and that the appropriate BL33 variable pointing to u-boot.bin is passed when building ATF. +config BR2_TARGET_ARM_TRUSTED_FIRMWARE_PREBUILT_BL33 + bool "Use an externally built BL33 image set" + help + This option allows to use an prebuilt BL33 boot stage with + the Arm trusted firmware. + +endchoice + +config BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL33_IMAGE + string "File path of the externally built BL33 image" + depends on BR2_TARGET_ARM_TRUSTED_FIRMWARE_PREBUILT_BL33 + help + Path of the prebuilt BL33 image if any. + config BR2_TARGET_ARM_TRUSTED_FIRMWARE_ADDITIONAL_VARIABLES string "Additional ATF build variables" help diff --git a/boot/arm-trusted-firmware/arm-trusted-firmware.mk b/boot/arm-trusted-firmware/arm-trusted-firmware.mk index 23f4936..913b2fa 100644 --- a/boot/arm-trusted-firmware/arm-trusted-firmware.mk +++ b/boot/arm-trusted-firmware/arm-trusted-firmware.mk @@ -37,6 +37,10 @@ ARM_TRUSTED_FIRMWARE_MAKE_OPTS += BL33=$(BINARIES_DIR)/u-boot.bin ARM_TRUSTED_FIRMWARE_DEPENDENCIES += uboot endif +ifneq ($(BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL33_IMAGE),) +ARM_TRUSTED_FIRMWARE_MAKE_OPTS += BL33=$(call qstrip,$(BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL33_IMAGE)) +endif + ifeq ($(BR2_TARGET_VEXPRESS_FIRMWARE),y) ARM_TRUSTED_FIRMWARE_MAKE_OPTS += SCP_BL2=$(BINARIES_DIR)/scp-fw.bin ARM_TRUSTED_FIRMWARE_DEPENDENCIES += vexpress-firmware
This change allows one to build ATF with an externally built BL33 image or with the U-boot as BL33 boot stage. This change introduces a new configuration directive for TF-A to specify when BL33 stage is provided as a prebuilt image: BR2_TARGET_ARM_TRUSTED_FIRMWARE_PREBUILT_BL33. If BR2_TARGET_ARM_TRUSTED_FIRMWARE_PREBUILT_BL33 is enabled, the buildroot configuration shall specify the BL33 binary image location: BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL33_IMAGE. Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> --- boot/arm-trusted-firmware/Config.in | 22 +++++++++++++++++++++- boot/arm-trusted-firmware/arm-trusted-firmware.mk | 4 ++++ 2 files changed, 25 insertions(+), 1 deletion(-)