[1/1] boot/arm-trusted-firmware: use prebuilt BL33 images
diff mbox series

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
Related show

Commit Message

Etienne Carriere Nov. 22, 2018, 3:22 p.m. UTC
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(-)

Comments

Thomas Petazzoni Nov. 29, 2018, 10:04 p.m. UTC | #1
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
Etienne Carriere Nov. 30, 2018, 9:53 a.m. UTC | #2
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
Sergey Matyukevich Dec. 1, 2018, 8:18 p.m. UTC | #3
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
Etienne Carriere Dec. 3, 2018, 10:36 a.m. UTC | #4
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
Thomas Petazzoni Aug. 3, 2019, 8:08 p.m. UTC | #5
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
Etienne Carriere Aug. 9, 2019, 3:09 p.m. UTC | #6
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

Patch
diff mbox series

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