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
14 changes: 10 additions & 4 deletions .github/actions/compile/action.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,8 @@ inputs:
required: true
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.

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.

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.

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.

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.

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.

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.

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.

kernel_dirname:
required: true
firmware_dirname:
Copy link
Contributor

@ndechesne ndechesne Nov 7, 2025

Choose a reason for hiding this comment

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

having a new machine would simplify the CI config here.

Copy link
Member Author

@b49020 b49020 Nov 7, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

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.

Copy link
Contributor

@ndechesne ndechesne Nov 7, 2025

Choose a reason for hiding this comment

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

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?

Copy link
Member Author

@b49020 b49020 Nov 7, 2025

Choose a reason for hiding this comment

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

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.

required: true
cache_dir:
required: true
kas:
Expand Down Expand Up @@ -61,14 +63,14 @@ runs:

- uses: actions/upload-artifact@v4
with:
name: buildchart-${{ inputs.distro_name }}${{ inputs.kernel_dirname }}-${{ inputs.machine }}
name: buildchart-${{ inputs.distro_name }}${{ inputs.kernel_dirname }}${{ inputs.firmware_dirname }}-${{ inputs.machine }}
path: |
buildchart.svg
buildchart-world.svg

- uses: actions/upload-artifact@v4
with:
name: kas-build-${{ inputs.distro_name }}${{ inputs.kernel_dirname }}-${{ inputs.machine }}
name: kas-build-${{ inputs.distro_name }}${{ inputs.kernel_dirname }}${{ inputs.firmware_dirname }}-${{ inputs.machine }}
path: kas-build.yml

- name: Stage build artifacts for publishing
Expand All @@ -78,7 +80,7 @@ runs:
# expects file to be relative to our PWD. deploy_dir is outside
# that, so we move things around:
deploy_dir=../kas/build/tmp/deploy/images/${{inputs.machine}}
uploads_dir=./uploads/${{ inputs.distro_name }}${{ inputs.kernel_dirname }}/${{ inputs.machine }}
uploads_dir=./uploads/${{ inputs.distro_name }}${{ inputs.kernel_dirname }}${{ inputs.firmware_dirname }}/${{ inputs.machine }}
mkdir -p $uploads_dir
find $deploy_dir/ -maxdepth 1 -type f -exec cp {} $uploads_dir/ \;
find $deploy_dir/ -maxdepth 1 -type l \( -name boot-*.img -o -name *.rootfs.ext4.gz -o -name *.rootfs.qcomflash.tar.gz \) -exec cp -d {} $uploads_dir/ \;
Expand All @@ -105,7 +107,11 @@ runs:
if [ -n "${KERNEL_DIRNAME}" ]; then
KERNEL_DIRNAME="_${KERNEL_DIRNAME}"
fi
BUILDNAME="${{ inputs.machine }}_${{ inputs.distro_name }}${KERNEL_DIRNAME}"
FIRMWARE_DIRNAME="${{ inputs.firmware_dirname }}"
if [ -n "${FIRMWARE_DIRNAME}" ]; then
FIRMWARE_DIRNAME="_${FIRMWARE_DIRNAME}"
fi
BUILDNAME="${{ inputs.machine }}_${{ inputs.distro_name }}${KERNEL_DIRNAME}${FIRMWARE_DIRNAME}"
FILENAME="build-url_${BUILDNAME}"
echo "${{ steps.upload_artifacts.outputs.url }}" > "${FILENAME}"
echo "filename=${FILENAME}" >> $GITHUB_OUTPUT
Expand Down
10 changes: 10 additions & 0 deletions .github/workflows/build-yocto.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -94,6 +94,7 @@ jobs:
distro_name: ${{matrix.distro.name}}
kernel_yaml: ${{matrix.kernel.yamlfile}}
kernel_dirname: ${{matrix.kernel.dirname}}
firmware_dirname: ${{matrix.firmware.dirname}}
cache_dir: ${CACHE_DIR}
kas: ${KAS_CONTAINER}

Expand Down Expand Up @@ -144,6 +145,14 @@ jobs:
type: additional
dirname: "+linux-yocto-lts"
yamlfile: ":ci/linux-yocto-lts.yml"
- 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"
Copy link
Contributor

@ndechesne ndechesne Nov 7, 2025

Choose a reason for hiding this comment

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

the yamlfile is unused. does not sound right.

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.

Ah, I will fix it.

exclude:
# Incompatible builds
- machine: qcom-armv7a
Expand All @@ -162,6 +171,7 @@ jobs:
distro_name: ${{matrix.distro.name}}
kernel_yaml: ${{matrix.kernel.yamlfile}}
kernel_dirname: ${{matrix.kernel.dirname}}
firmware_dirname: ${{matrix.firmware.dirname}}
Copy link
Contributor

@ndechesne ndechesne Nov 7, 2025

Choose a reason for hiding this comment

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

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"

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.

Sounds reasonable, I will use this format.

cache_dir: ${CACHE_DIR}
kas: ${KAS_CONTAINER}

Expand Down
Loading