Rb3gen2: Add support for Open Boot firmware (TF-A, OP-TEE and U-Boot) build #1172

b49020 · 2025-10-30T05:38:44Z

Currently the open boot firmware stack has only been enabled on RB3Gen2 platform which can be built using following:

$ kas build ci/qcs6490-rb3gen2-core-kit.yml:ci/open-boot-firmware.yml

And currently the boot stack includes TF-A, OP-TEE and U-Boot. In future the plan is to enable upstream edk2 as well. Along with that the next target for open boot firmware is Lemans based IoT EVK platform.

Right now the build generates 2 firmware payloads as bl2.elf (unsigned) and fip.elf (test signed using qtestsign). It is required to sign bl2.elf with QTI signature using sectools but in future the plan is to drop QTI signature requirement with an updated release of XBL/XBL-SEC.

Once signing is done, one need to update following binaries in qcomflash tarball and then proceed with QDL flashing:

tz.mbn -> bl2.mbn
uefi.elf -> fip.elf

b49020 · 2025-10-30T06:47:17Z

Any ideas how can I fix the yocto run checks here? I have already added meta-arm as dependency for meta-qcom and added meta-arm repo to be part of repos in the KAS base.yml file. However, the build still says:

ERROR: Layer meta-qcom depends on meta-arm and isn't found.

koenkooi · 2025-10-30T08:52:11Z

Any ideas how can I fix the yocto run checks here? I have already added meta-arm as dependency for meta-qcom and added meta-arm repo to be part of repos in the KAS base.yml file. However, the build still says:
ERROR: Layer meta-qcom depends on meta-arm and isn't found.

I'm not sure if ordering matters in KAS, but could you try changing the repo section to this?

  meta-arm:
    url: https://git.yoctoproject.org/git/meta-arm
    layers:
      meta-arm-toolchain:
      meta-arm:

That's the only thing that stood out to me as a difference from a working config with meta-arm included.

ndechesne · 2025-10-30T08:53:04Z

Check --dependency in ci/yocto-check-layer.sh

ci/open-boot-firmware.yml

recipes-security/optee/optee-test-qcm6490.inc

ci/open-boot-firmware.yml

recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend

recipes-security/optee/optee-os-tadevkit_%.bbappend

recipes-security/optee/optee-os_%.bbappend

b49020 · 2025-10-31T12:19:19Z

PR updated to incorporate review comments.

ci/yocto-check-layer.sh

b49020 · 2025-11-04T09:23:13Z

Although I have fixed the CI issues which were related to this PR however the current CI failure:

Parsing recipes...ERROR: /work/oe-core/meta/recipes-kernel/linux/linux-yocto_6.17.bb: Unable to get checksum for linux-yocto SRC_URI entry qcom.scc: file could not be found

doesn't seem to be related to this PR, any ideas?

quaresmajose · 2025-11-04T10:45:35Z

This was maybe because of the OE-core updated last night, there are some kernel changes on that. I will take a look on the fail.

quaresmajose · 2025-11-04T11:36:25Z

Should be fixed with #1186

ricardosalveti · 2025-11-04T23:04:08Z

Please rebase.

Open boot firmware recipes for TF-A and OP-TEE comes from meta-arm, so lets add an explicit dependency on meta-arm. Signed-off-by: Sumit Garg <[email protected]>

Add RB3Gen2 platform specific support leveraging base trusted-firmware-a recipes from meta-arm. It allows to generate unsigned bl2.elf and test signed fip.elf as per TF-A documentation here [1]. [1] https://github.com/qualcomm-linux/trusted-firmware-a/blob/qcom-next/docs/plat/qti/rb3gen2.rst Signed-off-by: Sumit Garg <[email protected]>

Add OP-TEE recipes override for RB3Gen2 leveraging the base recipes from meta-arm. Also, enable TF-A build to consume OP-TEE OS as the BL32 image. Signed-off-by: Sumit Garg <[email protected]>

U-Boot is an option for BL33 payload with TF-A, so let's add the corresponding RB3Gen2 U-Boot recipe support. Along with that let's limit RB1 changes to the corresponding machine. Signed-off-by: Sumit Garg <[email protected]>

Add support for open boot firmware based on TF-A, OP-TEE and U-Boot specific machine features for RB3Gen2. Signed-off-by: Sumit Garg <[email protected]>

Currently the open boot firmware stack has only been enabled on RB3Gen2 platform which can be built using following: $ kas build ci/qcs6490-rb3gen2-core-kit.yml:ci/open-boot-firmware.yml And currently the boot stack includes TF-A, OP-TEE and U-Boot. In future the plan is to enable upstream edk2 as well. Along with that the next target for open boot firmware is Lemans based IoT EVK platform. Right now the build generates 2 firmware payloads as bl2.elf (unsigned) and fip.elf (test signed using qtestsign). It is required to sign bl2.elf with QTI signature using sectools but in future the plan is to drop QTI signature requirement with an updated release of XBL/XBL-SEC. Once signing is done, one need to update following binaries in qcomflash tarball and then proceed with QDL flashing: - tz.mbn -> bl2.mbn - uefi.elf -> fip.elf Signed-off-by: Sumit Garg <[email protected]>

At this point due to QTI signature requirement, the LAVA boot test for RB3Gen2 can't be enabled. However, lets add the CI build test with open boot firmware. Signed-off-by: Sumit Garg <[email protected]>

b49020 · 2025-11-06T05:08:52Z

PR rebased, thanks @quaresmajose for the CI fix.

github-actions · 2025-11-06T07:19:35Z

Test run workflow

Test jobs for commit `2376dc9`

b49020 · 2025-11-07T05:53:04Z

The CI is all green now, a gentle ping for any further comments here.

ndechesne · 2025-11-07T09:23:19Z

conf/machine/qcs6490-rb3gen2-core-kit.conf

 MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += " \
    packagegroup-rb3gen2-firmware \
    packagegroup-rb3gen2-hexagon-dsp-binaries \
+    packagegroup-optee \


we probably don't want when optee is not enabled/available. no?

I added checks for "optee" as a machine feature within the "packagegroup-optee" since yocto-check-layers complained about it. Adding a machine feature check here felt redundant but I can add it if you want.

i see. I think it should be the other way around. packagegroup-optee should include them always, and we should include the packagegroup here only when optee is enabled.

I did that initially, but yocto-check-layers complained about "packagegroup-optee" as an independent entity since a machine compatible is required to build optee-test and others.

we need to figure out if this is the right thing to do..

Okay, let me add machine check here as well for consistency.

ndechesne · 2025-11-07T09:26:16Z

conf/machine/qcs6490-rb3gen2-core-kit.conf

                      qcom/qcs6490-rb3gen2-vision-mezzanine.dtb \
                      "

+EXTRA_IMAGEDEPENDS += "${@bb.utils.contains('MACHINE_FEATURES', 'tfa', 'trusted-firmware-a', '', d)}"


is tfa a new MACHINE_FEATURE?

Yeah, it is a new machine feature since you asked for it in previous review.

we should document them, somehow, somewhere..

Okay, I can document them here conf/machine/include/qcom-common.inc.

ndechesne · 2025-11-07T09:31:41Z

ci/open-boot-firmware.yml

+
+local_conf_header:
+  firmware: |
+    MACHINE_FEATURES:qcm6490:append = " tfa optee u-boot"


I don't know if it's a functional difference or not.. but we usually put the :append or :prepend first in the list of overrides.

I don't like changing the MACHINE config in the KAS config file. I would rather have a difference machine, what do you think?

I don't think having a different machine makes sense here. Since here we are building a different boot firmware (open vs closed source) for the same machine like we do for supporting different kernel versions for the same machine.

but we usually put the :append or :prepend first in the list of overrides.

Sure, I will fix that.

I don't know if it's a functional difference or not.. but we usually put the :append or :prepend first in the list of overrides.

It is: foo:soc:append appends to foo:soc, which then override full foo value. foo:append:soc: makes foo:append work only on soc, which then appends to the existing foo variable without redefining it completely.

I also don't like the idea of changing MACHINE_FEATURES here. I'd prefer if we have enabled MACHINE_FEATURES for all machines that support TF-A and then used COMBINED_FEATURES in order to determine whether to use a normal boot flow or a TF-A based one.

I like the COMBINED_FEATURES.
We will then need to decide if we have an 'open boot' distro ;)

It feels like we are moving in a direction to build open boot firmware and package closed boot firmware during a common build like for RB3Gen2 in this case. The build artifacts will contain both but what is present in the device flashing tarball is based on open-boot feature present in COMBINED_FEATURES. Does that sound reasonable?

ndechesne · 2025-11-07T09:33:33Z

.github/actions/compile/action.yml

    required: true
  kernel_dirname:
    required: true
+  firmware_dirname:


having a new machine would simplify the CI config here.

Yeah, but we already have different kernel versions built. I think similarly we can support open vs closed firmware builds. However, adding new machine for just open boot firmware will just make all the supported CI artifacts 2x the current number. So, I think current approach in this PR is more scalable.

I don't understand why it would double the artifacts.

I don't really like how we add 'variants' for kernel and now firmware in the CI config. Perhaps we can combine the kernel and firmware into a 'variant' attribute, so that we don't keep adding more and more in there?

I don't understand why it would double the artifacts.

I mean if we add a new machine here then all the different distro and kernel versions will have to be built twice.

Perhaps we can combine the kernel and firmware into a 'variant' attribute, so that we don't keep adding more and more in there?

I am mostly interested to run open boot firmware builds using qcom-next kernel since for fully feature complete we will be contributing patches in kernel for OP-TEE support to enable all the peripherals. So, let me know how you would like to see the variants here.

lumag · 2025-11-07T11:02:41Z

conf/layer.conf

 BBFILE_PRIORITY_qcom = "6"

-LAYERDEPENDS_qcom = "core"
+LAYERDEPENDS_qcom = "core meta-arm"


Well... If OP-TEE is not a required feature, this should be handled via dynamic layers rather than layer dependency

No please, boot firmware is an essential component of any Yocto BSP layer. The fact that meta-qcom uses proprietary boot firmware blobs is unfortunate. Here, meta-arm is providing the common recipes for TF-A, OP-TEE as well as edk2 for Arm based platforms is an essential dependency as we are starting to support open boot stack on Qcom platforms.

Have a look at meta-ti for your reference here [1].

[1] https://git.yoctoproject.org/meta-ti/tree/meta-ti-bsp/conf/layer.conf

I'd still ask it to be handled via a dynamic layer inside meta-qcom. We try to depend only on OE-Core, however we use other layers to provide extended functionality.

Sorry but this isn't extended functionality but an essential function of the BSP layer to allow building boot firmware from source.

At this point, the basic functionality is to use the blobs. I welcome the usage of OS components and OP-TEE, but I don't want to enforce that dependency on everybody.

At this point, the basic functionality is to use the blobs.

Is that what meta-qcom as an open source BSP layer would enforce its users to use by default even if the open boot stack becomes a viable option in future?

but I don't want to enforce that dependency on everybody.

But you are ready to enforce a practice not at all followed by other open source BSP layers? What extra burden do you think meta-arm brings which isn't there for say meta-ti layer?

At this point OP-TEE & TF-A - based stack:

is not enabled by default on any of the platforms

doesn't work out of the box outside of QTI

is provided for a single SoC

Having all of that in mind, as I wrote, I'd welcome the introduction of TF-A & OP-TEE based boot stack (and documenting that in the README), but I don't want to make everybody pull in that dependency. When it's decided that the open boot stack is a default option for any of the targets, we can flip it.

is not enabled by default on any of the platforms

What do you mean by default here? One that is enforced by Qualcomm for every OEM? Or rather we give OEMs the choice to select among open vs closed boot firmware stacks. There are already various IoT and Auto OEMs asking for the open boot firmware stack.

doesn't work out of the box outside of QTI

As I said this is being worked upon to enable it outside QTI. Also, the next step for me is to add support for upstream edk2 whose recipes are also currently provided by meta-arm which will work out of the box as of now.

is provided for a single SoC

As I said in the PR itself, the plan is to support Kodiak and Lemans initially, but it will be scalable to other SoCs too with less effort.

but I don't want to make everybody pull in that dependency.

Sooner or later, we need to add that dependency as otherwise how can we enable OEMs to build open boot stack in the same build environment.

When it's decided that the open boot stack is a default option for any of the targets, we can flip it.

As I said above, we should really be offering a choice for OEMs to build open boot stacks. And I don't understand when you would feel it's the right time to flip. You need to really understand; the open boot firmware stack is an essential feature of any open source Yocto BSP layer which people expect to be available by default.

is not enabled by default on any of the platforms

What do you mean by default here? One that is enforced by Qualcomm for every OEM? Or rather we give OEMs the choice to select among open vs closed boot firmware stacks. There are already various IoT and Auto OEMs asking for the open boot firmware stack.

OEM devices are not supported by this layer. Inside this layer we provide generic code and also support for Qualcomm-manufactured devices. I know that there are use-cases which require OP-TEE and TF-A. But I really don't understand what you are arguing here about.

doesn't work out of the box outside of QTI

As I said this is being worked upon to enable it outside QTI.

That doesn't change the current status of these changes.

Also, the next step for me is to add support for upstream edk2 whose recipes are also currently provided by meta-arm which will work out of the box as of now.

That's perfect and really interesting.

is provided for a single SoC

As I said in the PR itself, the plan is to support Kodiak and Lemans initially, but it will be scalable to other SoCs too with less effort.

Great.

but I don't want to make everybody pull in that dependency.

Sooner or later, we need to add that dependency as otherwise how can we enable OEMs to build open boot stack in the same build environment.

When it's decided that the open boot stack is a default option for any of the targets, we can flip it.

As I said above, we should really be offering a choice for OEMs to build open boot stacks. And I don't understand when you would feel it's the right time to flip. You need to really understand; the open boot firmware stack is an essential feature of any open source Yocto BSP layer which people expect to be available by default.

As I wrote, I don't understand, what we are arguing here. Please move your changes under dynamic-layers/meta-arm-bsp/ and add meta-arm-bsp to LAYERRECOMMENDS. I'm not asking you to drop the changes. I'm asking you to allow people to use meta-qcom without pulling in extra layers if they don't need them.

As I wrote, I don't understand, what we are arguing here.

I think here the main point of argument is to keep meta-arm layer in the dependency list of meta-qcom since we need to reuse the BSP recipes for TF-A, OP-TEE and edk2. Let others also chime in about what they think here. I think I have made my arguments here.

Please move your changes under dynamic-layers/meta-arm-bsp/ and add meta-arm-bsp to LAYERRECOMMENDS.

The TF-A, OP-TEE and edk2 changes belong to the Qcom BSP layer and not to the Arm BSP layer. I will reiterate the example for meta-ti here.

Please move your changes under dynamic-layers/meta-arm-bsp/ and add meta-arm-bsp to LAYERRECOMMENDS.

The TF-A, OP-TEE and edk2 changes belong to the Qcom BSP layer and not to the Arm BSP layer. I will reiterate the example for meta-ti here.

meta-qcom/dynamic-layers/meta-arm-bsp/. This is a standard way of making recipes / appends depend on another layer without making it a layer dependency. See https://github.com/openembedded/meta-openembedded/tree/master/meta-oe/dynamic-layers

lumag · 2025-11-07T11:04:11Z

recipes-bsp/trusted-firmware-a/trusted-firmware-a-qcm6490.inc

@@ -0,0 +1,9 @@
+SRC_URI += "https://github.com/coreboot/qc_blobs/raw/refs/heads/master/sc7280/qtiseclib/libqtisec.a;name=qtiseclib"


What is the licence for the blob? Does it change the licence of the generated binary?

The license for this blob can be found here: https://github.com/coreboot/qc_blobs/blob/master/sc7280/qtiseclib/LICENSE.

Does it change the licence of the generated binary?

AFAIK, it doesn't change the overall TF-A project license but rather it is required for the binary components to be compliant with the TF-A license terms, see here: https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.html#binary-components

Still the licence should be included in SBOM, etc., so it should be properly annotated.
Also we have to comply to the licensing terms. E.g.:

(iii) redistribution of the Redistributable Binary Code must include the .txt file setting forth the terms and condition of this Agreement;

lumag · 2025-11-07T11:06:49Z

recipes-bsp/trusted-firmware-a/trusted-firmware-a-qcom.inc

+DEPENDS += "qtestsign-native"
+
+MACHINE_TFA_QCOM_REQUIRE ?= ""
+MACHINE_TFA_QCOM_REQUIRE:qcm6490 = "trusted-firmware-a-qcm6490.inc"


Will it work on other qcm6490-based machines (e.g. IDP, Tachyon or RubkPi)?

Yeah, the TF-A/OP-TEE port is specific to the SoC. However, we need to make sure that the OEM hardware is running a QLI based boot firmware release where we can replace boot chain components with open-source ones.

BTW, I have been waiting to get my hands-on with one of these boards as well to run open boot stack.

lumag · 2025-11-07T11:10:06Z

recipes-bsp/trusted-firmware-a/trusted-firmware-a-qcm6490.inc

+TFA_SPD = "opteed"
 EXTRA_OEMAKE:append = " \
    QTISECLIB_PATH=${UNPACKDIR}/libqtisec.a \
+    BL32=${RECIPE_SYSROOT}/${nonarch_base_libdir}/firmware/tee-raw.bin \


If you change the order of the commits, you won't have to change the file that you have just added.

This commit adds OP-TEE support to the TF-A recipe added by previous commit. So, I am not sure what do you meant by reordering commits here.

Add OP-TEE as a recipe

Add TF-A, which uses OP-TEE among other dependencies

lumag · 2025-11-07T11:11:01Z

recipes-security/optee/optee-os-qcom.inc

@@ -0,0 +1,3 @@
+SRCBRANCH = "qcom-next"


lumag · 2025-11-07T11:30:57Z

conf/machine/qcs6490-rb3gen2-core-kit.conf

 MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += " \
    packagegroup-rb3gen2-firmware \
    packagegroup-rb3gen2-hexagon-dsp-binaries \
+    packagegroup-optee \


Please keep the list sorted

lumag · 2025-11-07T11:32:06Z

conf/machine/qcs6490-rb3gen2-core-kit.conf


+EXTRA_IMAGEDEPENDS += "${@bb.utils.contains('MACHINE_FEATURES', 'tfa', 'trusted-firmware-a', '', d)}"
+PREFERRED_PROVIDER_virtual/bootloader = "${@bb.utils.contains('MACHINE_FEATURES','u-boot','u-boot','',d)}"
+TFA_UBOOT:pn-trusted-firmware-a = "${@bb.utils.contains('MACHINE_FEATURES','u-boot','1','0',d)}"


It feels strange at a first glance that machine configuration (which should also define MACHINE_FEATURES) also depends on them. Please add a comment here, how is it expected to be enabled.

lumag · 2025-11-07T11:33:06Z

ci/base.yml

+    url: https://git.yoctoproject.org/meta-arm
+    layers:
+      meta-arm:
+      meta-arm-toolchain:


So, building has beek broken for all previous commits. That's not nice

That's a fair point, I will move this diff to first patch instead.

lumag · 2025-11-07T11:39:23Z

ci/open-boot-firmware.yml

+
+local_conf_header:
+  firmware: |
+    MACHINE_FEATURES:qcm6490:append = " tfa optee u-boot"


I don't know if it's a functional difference or not.. but we usually put the :append or :prepend first in the list of overrides.

It is: foo:soc:append appends to foo:soc, which then override full foo value. foo:append:soc: makes foo:append work only on soc, which then appends to the existing foo variable without redefining it completely.

I also don't like the idea of changing MACHINE_FEATURES here. I'd prefer if we have enabled MACHINE_FEATURES for all machines that support TF-A and then used COMBINED_FEATURES in order to determine whether to use a normal boot flow or a TF-A based one.

lumag · 2025-11-07T11:41:33Z

.github/actions/compile/action.yml

  distro_name:
    required: true
  kernel_yaml:
    required: true


At this point due to QTI signature requirement, the LAVA boot test for RB3Gen2
can't be enabled.

What does it mean? Can users build and deploy TF-A firmware? If not, this is just a dead code.

Currently the developers within Qualcomm are able to generate QTI signed TF-A BL2 and deploy the TF-A firmware. So, it's definitely not a dead code.

For developers outside Qualcomm, we are expecting in the next QLI proprietary firmware blobs release (especially XBL_SEC), the QTI signature requirement for TF-A BL2 to be dropped. Then we should just be able to use qtestsign for that too.

Currently the developers within Qualcomm are able to generate QTI signed TF-A BL2 and deploy the TF-A firmware. So, it's definitely not a dead code.

It is dead until one can use it to generate a fully working solution. If it requires extra signing step, it is of very limited use.

If it requires extra signing step, it is of very limited use.

Sure, it's a temporary extra step until we enable the OEM only signed TZ image. But still, it's a good enough first step for people working within Qualcomm to collaborate while making the open boot firmware stack a reality on Qcom silicon.

ndechesne · 2025-11-07T14:09:11Z

.github/workflows/build-yocto.yml

+            firmware:
+                type: additional
+                dirname: "+open-boot-firmware"
+                yamlfile: ":ci/open-boot-firmware.yml"


the yamlfile is unused. does not sound right.

Ah, I will fix it.

ndechesne · 2025-11-07T14:12:37Z

.github/workflows/build-yocto.yml

          distro_name: ${{matrix.distro.name}}
          kernel_yaml: ${{matrix.kernel.yamlfile}}
          kernel_dirname: ${{matrix.kernel.dirname}}
+          firmware_dirname: ${{matrix.firmware.dirname}}


what I meant in my other comment is that instead of adding more and more config here (e.g. machine, distro, kernel, firmware, ...) I would prefer to have machine, distro and 'variants'

e.g.

- machine: qcs6490-rb3gen2-core-kit distro: name: qcom-distro yamlfile: ':ci/qcom-distro.yml' firmware: type: additional dirname: "+open-boot-firmware" yamlfile: ":ci/open-boot-firmware.yml"

could be

- machine: qcs6490-rb3gen2-core-kit distro: name: qcom-distro yamlfile: ':ci/qcom-distro.yml' variants: type: additional dirname: "+open-boot-firmware" yamlfile: ":ci/open-boot-firmware.yml"

so, combining a custom kernel and custom firmware:

- machine: qcs6490-rb3gen2-core-kit distro: name: qcom-distro yamlfile: ':ci/qcom-distro.yml' variants: type: additional dirname: "+linux-yocto-lts+open-boot-firmware" yamlfile: ":ci/linux-yocto-lts.yml:ci/open-boot-firmware.yml"

Sounds reasonable, I will use this format.

nrclark · 2025-11-25T17:44:38Z

Just wanted to leave a comment here - I'm very glad to see this develop. GM and many of Qualcomm's other customers would strongly prefer a TF-A+OP-TEE+U-boot stack over the current proprietary stack. You would make my day if you could get the automotive group to adopt it for Lemans and Nord.

One extra item to note: if you don't have one already, you should consider setting up a uboot config that can be loaded with Sahara. That would allow customers to get away from Firehose, XBL, and flatbuilds in favor of more cross-platform solutions inside of uboot.

b49020 requested review from lumag, mwasilew, ndechesne, ricardosalveti, sbanerjee-quic and vkraleti as code owners October 30, 2025 05:38

b49020 requested review from idlethread and ldts October 30, 2025 05:39

b49020 force-pushed the rb3gen2-open-boot-fw branch 2 times, most recently from 9104459 to 17e9dc2 Compare October 30, 2025 06:22

ndechesne reviewed Oct 30, 2025

View reviewed changes

ci/open-boot-firmware.yml Outdated Show resolved Hide resolved

ricardosalveti reviewed Oct 30, 2025

View reviewed changes

recipes-security/optee/optee-test-qcm6490.inc Show resolved Hide resolved

ricardosalveti reviewed Oct 30, 2025

View reviewed changes

ci/open-boot-firmware.yml Outdated Show resolved Hide resolved

quaresmajose reviewed Oct 30, 2025

View reviewed changes

recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend Show resolved Hide resolved

recipes-security/optee/optee-os-tadevkit_%.bbappend Show resolved Hide resolved

recipes-security/optee/optee-os_%.bbappend Show resolved Hide resolved

b49020 force-pushed the rb3gen2-open-boot-fw branch from 17e9dc2 to 3474150 Compare October 31, 2025 12:17

quaresmajose reviewed Oct 31, 2025

View reviewed changes

ci/yocto-check-layer.sh Outdated Show resolved Hide resolved

b49020 force-pushed the rb3gen2-open-boot-fw branch 5 times, most recently from 972dc21 to be39af5 Compare November 4, 2025 06:15

layer.conf: add meta-arm to LAYERDEPENDS

074bc4f

Open boot firmware recipes for TF-A and OP-TEE comes from meta-arm, so lets add an explicit dependency on meta-arm. Signed-off-by: Sumit Garg <[email protected]>

b49020 added 6 commits November 6, 2025 10:36

recipes-security: Add OP-TEE recipes override for RB3Gen2

d25d38f

Add OP-TEE recipes override for RB3Gen2 leveraging the base recipes from meta-arm. Also, enable TF-A build to consume OP-TEE OS as the BL32 image. Signed-off-by: Sumit Garg <[email protected]>

qcs6490-rb3gen2: Add U-Boot support for RB3Gen2

aa97c88

U-Boot is an option for BL33 payload with TF-A, so let's add the corresponding RB3Gen2 U-Boot recipe support. Along with that let's limit RB1 changes to the corresponding machine. Signed-off-by: Sumit Garg <[email protected]>

qcs6490-rb3gen2: Add support for open firmware machine features

beff201

Add support for open boot firmware based on TF-A, OP-TEE and U-Boot specific machine features for RB3Gen2. Signed-off-by: Sumit Garg <[email protected]>

github/workflows: Extend CI to compile open boot firmware for RB3Gen2

2376dc9

At this point due to QTI signature requirement, the LAVA boot test for RB3Gen2 can't be enabled. However, lets add the CI build test with open boot firmware. Signed-off-by: Sumit Garg <[email protected]>

b49020 force-pushed the rb3gen2-open-boot-fw branch from be39af5 to 2376dc9 Compare November 6, 2025 05:07

ndechesne reviewed Nov 7, 2025

View reviewed changes

lumag requested changes Nov 7, 2025

View reviewed changes

ndechesne reviewed Nov 7, 2025

View reviewed changes

		@@ -0,0 +1,9 @@
		SRC_URI += "https://github.com/coreboot/qc_blobs/raw/refs/heads/master/sc7280/qtiseclib/libqtisec.a;name=qtiseclib"

Rb3gen2: Add support for Open Boot firmware (TF-A, OP-TEE and U-Boot) build #1172

Are you sure you want to change the base?

Rb3gen2: Add support for Open Boot firmware (TF-A, OP-TEE and U-Boot) build #1172

Uh oh!

Conversation

b49020 commented Oct 30, 2025

Uh oh!

b49020 commented Oct 30, 2025

Uh oh!

koenkooi commented Oct 30, 2025

Uh oh!

ndechesne commented Oct 30, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

b49020 commented Oct 31, 2025

Uh oh!

Uh oh!

b49020 commented Nov 4, 2025

Uh oh!

quaresmajose commented Nov 4, 2025

Uh oh!

quaresmajose commented Nov 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ricardosalveti commented Nov 4, 2025

Uh oh!

b49020 commented Nov 6, 2025

Uh oh!

github-actions bot commented Nov 6, 2025

Test run workflow

Test jobs for commit 2376dc9

Uh oh!

b49020 commented Nov 7, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

b49020 Nov 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

b49020 Nov 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

quaresmajose commented Nov 4, 2025 •

edited

Loading

Test jobs for commit `2376dc9`

b49020 Nov 7, 2025 •

edited

Loading

b49020 Nov 7, 2025 •

edited

Loading