boot/arm-trusted-firmware: use prebuilt BL33 images

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 <[email protected]>

---
 boot/arm-trusted-firmware/Config.in               | 22 +++++++++++++++++++++-
 boot/arm-trusted-firmware/arm-trusted-firmware.mk |  4 ++++
 2 files changed, 25 insertions(+), 1 deletion(-)

Hello Etienne,

Quoted 11 lines · Etienne Carriere

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.

Quoted 5 lines

Signed-off-by Etienne Carriere <[email protected]>

---
 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
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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.

Hello Etienne,

Quoted 10 lines

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.

...

boot/arm-trusted-firmware/Config.in line 3

Quoted 7 lines

boot/arm-trusted-firmware/Config.in +1 -1

@@ -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

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.

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
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com