Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 7 commits into
base: master
Choose a base branch
from
Open

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

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
074bc4f
layer.conf: add meta-arm to LAYERDEPENDS
b49020 Oct 30, 2025
297f464
recipes-bsp: Add trusted-firmware-a support for RB3Gen2
b49020 Oct 29, 2025
d25d38f
recipes-security: Add OP-TEE recipes override for RB3Gen2
b49020 Oct 29, 2025
aa97c88
qcs6490-rb3gen2: Add U-Boot support for RB3Gen2
b49020 Oct 29, 2025
beff201
qcs6490-rb3gen2: Add support for open firmware machine features
b49020 Oct 31, 2025
5b04d7e
CI: Add KAS yaml file to build open boot firmware stack
b49020 Oct 30, 2025
2376dc9
github/workflows: Extend CI to compile open boot firmware for RB3Gen2
b49020 Oct 30, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 4 additions & 1 deletion ci/yocto-check-layer.sh
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,7 +34,10 @@ CMD="$CMD meta-qcom"
# Disable auto layer discovery
CMD="$CMD --no-auto"
# Layers to process for dependencies
CMD="$CMD --dependency $WORK_DIR/oe-core/meta"
CMD="$CMD --dependency \
$WORK_DIR/oe-core/meta \
$WORK_DIR/meta-arm/meta-arm \
$WORK_DIR/meta-arm/meta-arm-toolchain"
# Disable automatic testing of dependencies
CMD="$CMD --no-auto-dependency"
# Set machines to all machines defined in this BSP layer
Expand Down
2 changes: 1 addition & 1 deletion conf/layer.conf
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ BBFILE_COLLECTIONS += "qcom"
BBFILE_PATTERN_qcom := "^${LAYERDIR}/"
BBFILE_PRIORITY_qcom = "6"

LAYERDEPENDS_qcom = "core"
LAYERDEPENDS_qcom = "core meta-arm"
Copy link
Contributor

@lumag lumag Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

@b49020 b49020 Nov 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@lumag lumag Nov 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

@b49020 b49020 Nov 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@lumag lumag Nov 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@lumag lumag Nov 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

@b49020 b49020 Nov 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@lumag lumag Nov 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

@b49020 b49020 Nov 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@lumag lumag Nov 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

LAYERRECOMMENDS_qcom = "openembedded-layer"
LAYERSERIES_COMPAT_qcom = "whinlatter"

Expand Down