Add machine support for the Thundercomm RUBIK Pi 3 #41
Open
EmbeddedAndroid wants to merge 5 commits into
Open
Conversation
EmbeddedAndroid
requested review from
ndechesne and
ricardosalveti
as code owners
Author
|
Boot log: |
EmbeddedAndroid
changed the title
| flashing the pre-built Ubuntu whole-disk image). All other LUNs come from \ | ||
| boot-assets verbatim, including the Rubik Pi 3 CDT." | ||
|
|
||
| LICENSE = "CLOSED" |
Collaborator
There was a problem hiding this comment.
Unfortunately closed is just enable bitbake to build the recipe, but it has no legal meaning, opened rubikpi-ai/boot-assets#1 as it seems to be missing upstream.
| QCDIR="${IMGDEPLOYDIR}/${IMAGE_NAME}.qcomflash" | ||
| SRC="${DEPLOY_DIR_IMAGE}/${QCOM_BOOT_FILES_SUBDIR}" | ||
| added=0 | ||
| for img in "$SRC"/*.img; do |
Collaborator
There was a problem hiding this comment.
We should be able to extend https://github.com/qualcomm-linux/meta-qcom/blob/master/classes-recipe/image_types_qcom.bbclass#L99 to also copy *.img files, mind a pr for that in meta-qcom instead?
Author
There was a problem hiding this comment.
Collaborator
|
Also add the machine to our workflow machine list at https://github.com/qualcomm-linux/meta-qcom-3rdparty/blob/main/.github/workflows/build-yocto.yml#L101, then it will also be built by github. |
This was referenced May 13, 2026
Add a board-specific boot firmware recipe for the Thundercomm RUBIK Pi 3 (QCS6490). This follows the same pattern as firmware-qcom-boot-qrb2210-arduino-imola: fetch the prebuilt, Qualcomm-signed boot binaries from the board vendor and deploy them under QCOM_BOOT_FILES_SUBDIR for consumption by the qcomflash image type. Sources from https://github.com/rubikpi-ai/boot-assets (pinned via SRCREV): - SoC boot firmware: XBL, UEFI, TZ, HYP, AOP, devcfg, qupv3fw, cpucp, multi_image, shrm, imagefv, uefi_sec, XblRamdump, tools.fv - Rubik Pi 3-specific LUN 6 payloads: rubikpi_config.img, devcfg_full.img, rubikpi_dtso.img, splash.img - Per-LUN partition layout for LUNs 1..6: rawprogram*.xml, patch*.xml, gpt_main*.bin, gpt_backup*.bin - Board CDT: RubikPi3_CDT.bin LUN 0 in boot-assets is geared at flashing a single whole-disk Ubuntu image and is not suitable for the Yocto per-partition flow. A Yocto-friendly LUN 0 layout (efi + rootfs) is shipped with this recipe as static files under files/, and installed alongside the LUNs 1..6 layout from boot-assets. The qcomflash class' deploy_partition_files() globs for gpt_both*.bin without nullglob protection; boot-assets ships gpt_main / gpt_backup but not gpt_both, so the recipe synthesises gpt_both<N>.bin per LUN by concatenating the matching main + backup pair. The qdl flow itself only references gpt_main / gpt_backup via rawprogram XMLs, so the synthesised gpt_both bins are install-step placeholders. Signed-off-by: Tyler Baker <tyler.baker@oss.qualcomm.com>
Add a board-specific firmware packagegroup for the Thundercomm RUBIK Pi 3 (QCS6490), modelled on packagegroup-radxa-dragon-q6a. Firmware packages pulled into rootfs: - GPU: Adreno A660 (conditional on opencl/opengl/vulkan) - QUP serial engine: qcm6490-qupv3fw - Video encoder/decoder: VPU - Audio DSP: qcs6490-thundercomm-rubikpi3-audio - Compute DSP: qcs6490-compute (SoC-level; no board-specific compute blob is published for RUBIK Pi 3 in linux-firmware) Wifi (brcmfmac43456) and Bluetooth (BCM4345C5) firmware are not yet packaged in upstream linux-firmware so they are intentionally omitted; the system boots to a usable console without them. Signed-off-by: Tyler Baker <tyler.baker@oss.qualcomm.com>
Author
|
CI is failing as we now need qualcomm-linux/qcom-ptool#115 and qualcomm-linux/meta-qcom#2172. I've tested this change locally which builds and boots. |
lumag
pushed a commit
to qualcomm-linux/meta-qcom
that referenced
this pull request
May 13, 2026
The boot-firmware deploy loop in create_qcomflash_pkg only picks up a fixed set of file patterns (*.elf, *.mbn*, *.melf*, *.fv, named *.bin families, etc.). Boards whose LUN payloads are deployed as raw *.img files therefore never make it into the qcomflash tarball, even though the firmware recipe deploys them into QCOM_BOOT_FILES_SUBDIR. In particular, the Thundercomm RUBIK Pi 3 has LUN 6 partitions backed by rubikpi_config.img, devcfg_full.img, rubikpi_dtso.img and splash.img. Without this whitelist entry these files are silently dropped from the bundle and the resulting flashable image is incomplete; this was previously being worked around in a downstream bbappend on core-image-base, which is the wrong layer. Add *.img to the find expression at the same precedence as the other plain extension globs. The change is purely additive: existing targets that do not deploy any *.img files into QCOM_BOOT_FILES_SUBDIR see no behavioural change, and the exclusions inside the \( ... \) ELF group are unaffected. Link: qualcomm-linux/meta-qcom-3rdparty#41 (comment) Signed-off-by: Tyler Baker <tyler.baker@oss.qualcomm.com>
lumag
added a commit
to qualcomm-linux/meta-qcom
that referenced
this pull request
May 13, 2026
## Summary The boot-firmware deploy loop in `create_qcomflash_pkg` (`classes-recipe/image_types_qcom.bbclass`) globs `QCOM_BOOT_FILES_SUBDIR` for a fixed set of file patterns (`*.elf`, `*.mbn*`, `*.melf*`, `*.fv`, named `*.bin` families, etc.) and copies the matches into the qcomflash tarball. Boards whose LUN payloads are deployed as raw `*.img` files are therefore silently dropped from the bundle, even though the firmware recipe correctly deploys them into `QCOM_BOOT_FILES_SUBDIR`. This trips up the Thundercomm RUBIK Pi 3 in particular, where LUN 6 holds `rubikpi_config.img`, `devcfg_full.img`, `rubikpi_dtso.img` and `splash.img`. Future boards that ship raw image partitions will hit the same gap. Add `-o -name '*.img'` to the `find` expression, at the same precedence as the other plain extension globs. The `\( -name '*.elf' ! -name 'abl2esp*.elf' ... \)` group with its exclusions is untouched. The change is purely additive. Targets that do not deploy any `*.img` files into `QCOM_BOOT_FILES_SUBDIR` see no behavioural change, no existing pattern is removed, and no existing file is newly excluded. This addresses review feedback on qualcomm-linux/meta-qcom-3rdparty#41 (qualcomm-linux/meta-qcom-3rdparty#41 (comment)) requesting that the fix land here in `meta-qcom` rather than as a downstream `core-image-base` bbappend.
Add machine configuration for the Thundercomm RUBIK Pi 3 development board, which is based on the Qualcomm QCS6490 SoC and ships with UFS storage. The board follows the standard upstream Qualcomm Linux boot architecture: PBL -> XBL -> UEFI -> systemd-boot UKI -> kernel + dtb -> rootfs XBL and UEFI come from the prebuilt, Qualcomm-signed binaries delivered by firmware-qcom-boot-rubikpi3 (sourced from github.com/rubikpi-ai/boot-assets), which also ships the per-board UFS partition layout for LUNs 1..6 and the Rubik Pi-specific LUN 6 payloads (rubikpi_config, devcfg_full, rubikpi_dtso). LUN 0 uses a Yocto-friendly efi + rootfs layout shipped in the same recipe. The kernel, device tree (qcs6490-thundercomm-rubikpi3.dtb, merged in mainline since Linux 7.0 via commit f055a39f6874 "arm64: dts: qcom: Add qcs6490-rubikpi3 board dts"), ESP (systemd-boot + UKI) and rootfs (ext4) are produced by this build. QCOM_BOOTIMG_ROOTFS keeps the qcom-base.inc default of "PARTLABEL=rootfs", which matches our LUN 0 layout. Key configuration: - PREFERRED_PROVIDER_virtual/kernel = linux-qcom-next - QCOM_BOOT_FIRMWARE = firmware-qcom-boot-rubikpi3 - QCOM_PARTITION_FILES_SUBDIR = "rubikpi3" (flat layout) - QCOM_CDT_FILE = "RubikPi3_CDT" Signed-off-by: Tyler Baker <tyler.baker@oss.qualcomm.com>
Add KAS configuration to build core-image-base for the Thundercomm RUBIK Pi 3, following the same single-line-includes-base.yml pattern used by the radxa-dragon-q6a and uno-q machines. Signed-off-by: Tyler Baker <tyler.baker@oss.qualcomm.com>
Add qcs6490-thundercomm-rubikpi3 to the CI build matrix. Signed-off-by: Tyler Baker <tyler.baker@oss.qualcomm.com>
ricardosalveti
pushed a commit
to ricardosalveti/meta-qcom
that referenced
this pull request
May 13, 2026
The boot-firmware deploy loop in create_qcomflash_pkg only picks up a fixed set of file patterns (*.elf, *.mbn*, *.melf*, *.fv, named *.bin families, etc.). Boards whose LUN payloads are deployed as raw *.img files therefore never make it into the qcomflash tarball, even though the firmware recipe deploys them into QCOM_BOOT_FILES_SUBDIR. In particular, the Thundercomm RUBIK Pi 3 has LUN 6 partitions backed by rubikpi_config.img, devcfg_full.img, rubikpi_dtso.img and splash.img. Without this whitelist entry these files are silently dropped from the bundle and the resulting flashable image is incomplete; this was previously being worked around in a downstream bbappend on core-image-base, which is the wrong layer. Add *.img to the find expression at the same precedence as the other plain extension globs. The change is purely additive: existing targets that do not deploy any *.img files into QCOM_BOOT_FILES_SUBDIR see no behavioural change, and the exclusions inside the \( ... \) ELF group are unaffected. Link: qualcomm-linux/meta-qcom-3rdparty#41 (comment) Signed-off-by: Tyler Baker <tyler.baker@oss.qualcomm.com> (cherry picked from commit 39762c0)
Author
|
Once qualcomm-linux/meta-qcom#2183 is merged, CI should go green. |
lumag
requested changes
May 13, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add machine support for the Thundercomm RUBIK Pi 3 (
qcs6490-thundercomm-rubikpi3), a QCS6490-based maker board.The board's device tree was merged upstream in
f055a39f6874("arm64: dts: qcom: Add qcs6490-rubikpi3 board dts", first released in Linux 7.0) and the Qualcomm-signed boot binaries are published by Thundercomm
at https://github.com/rubikpi-ai/boot-assets. This PR wires both into meta-qcom-3rdparty so a complete OS image can be built and flashed via
qdlwithno out-of-tree pieces beyond Thundercomm's signed CDT/UEFI blobs.
The Rubik Pi 3-specific LUN 6 partitions (
rubikpi_con,devcfg_full,dtb_con) and their backing.imgpayloads come fromrubikpi-ai/boot-assets;without them UEFI fails its early platform probe.