Migrate features to Qualcomm Linux 2.0 - Qualcomm Dragonwing Documentation

Qualcomm Linux 2.0 introduces system-level changes that affect platform architecture and runtime behavior. Consider the following key updates and improvements to migrate features from Qualcomm Linux 1.0 to Qualcomm Linux 2.0.

Partition layout

Qualcomm Linux 2.0 supports an updated method to manage the partition layout. As part of the meta-qcom layer supported in Qualcomm Linux 2.0, instead of packaging partition.xml in the boot-binaries archive, the partition layout is maintained in the qcom-ptool repository and used in meta-qcom when the machine is built. The QCOM_PARTITION_FILES_SUBDIR configuration variable in meta-qcom/conf/machine/iq-9075-evk.conf selects the appropriate platform directory, for example platforms/iq-9075-evk/ufs/partitions.conf, and this input is passed to the ptool recipe (qcom-ptool_git.bb) to produce the final partition layout. For instructions on how to manage the partition layout, see Qualcomm Linux Yocto Guide.

Containers and orchestration updates

Enabling Docker and Docker-compose have been streamlined. The qcom-multimedia-image image now includes the upstream packagegroup-container from the meta-virtualization layer instead of using a Qualcomm-defined container packagegroup. All kernel dependencies required for Docker are already enabled in the Qualcomm kernel tree, so you don’t need to run compatibility scripts or modify the kernel configurations. Enabling Kubernetes has been redesigned and decoupled from the multimedia image. Instead of packagegroup-qcom-k8s, Kubernetes is now enabled by building a new dedicated image called qcom-container-orchestration-image. This recipe is located at meta-qcom-distro/recipes-products/images/qcom-container-orchestration-image.bb. The new image uses upstream Kubernetes and container orchestration packages from meta-virtualization layer.

Migrate device tree and device tree overlay

Qualcomm Linux 1.0 supports concatenated multi-DTB, whereas Qualcomm Linux 2.0 supports FIT-based multi-DTB. Qualcomm Linux 1.0 appends all DTBs listed in the machine configuration one after the other to generate a combined DTB. The generated virtual file allocation table (VFAT) image, dtb.bin, contains the combined DTB image. The dtb.bin image is flashed to a dedicated partition, dtb, present on the Qualcomm development kits. Unified Extensible Firmware Interface (UEFI) parses the combined DTB present in the dtb partition and selects a matching DTB for the hardware. Qualcomm Linux 2.0 generates a FIT image with all the DTB and DTBO files listed in the KERNEL_DEVICETREE variable. FIT requires a compatible string to be defined corresponding to the configurations. For example, for the qcom/qcs6490-rb3gen2.dtb DTB in conf/machine/rb3gen2-core-kit.conf, a compatible qcom,qcs6490-iot corresponding to this DTB is defined in conf/machine/include/fit-dtb-compatible.inc, as follows:

FIT_DTB_COMPATIBLE[qcs6490-rb3gen2] = " \
   qcom,qcs5430-iot \
   qcom,qcs6490-iot \
"

Similarly, a compatible qcom,qcs9100-qam is defined for qcom/qcs9100-ride.dtb, as follows:

 FIT_DTB_COMPATIBLE[qcs9100-ride] = " \
    qcom,qcs9100-qam \
    qcom,qcs9100v2-qam \
"

These examples show how a compatible string is defined for a DTB in Qualcomm Linux 2.0. Apply the same method to the DTB for your device. If a compatible string maps to a DTB and DTBO combination, you can define FIT_DTB_COMPATIBLE accordingly in conf/machine/include/fit-dtb-compatible.inc. For example, the compatible string qcom,qcs5430-iot-subtype2 maps to qcs6490-rb3gen2.dtb and qcs6490-rb3gen2-vision-mezzanine.dtbo. An example is as follows:

FIT_DTB_COMPATIBLE[qcs6490-rb3gen2+qcs6490-rb3gen2-vision-mezzanine] = " \
   qcom,qcs5430-iot-subtype2 \
   qcom,qcs6490-iot-subtype2 \
"

You must migrate the concatenated DTB and build‑time DTB overlay support from Qualcomm Linux 1.0 to a FIT‑based multi‑DTB and boot‑time DTB overlay in Qualcomm Linux 2.0. Qualcomm Linux 2.0 does not require you to differentiate between base and custom DTB groups. In Qualcomm Linux 1.0, the DTB and DTB overlay are managed as shown in the following code snippet. The DTB overlays listed in KERNEL_TECH_DTBOS[dtb-name] are merged with dtb-name at build time and all such merged DTBs are concatenated back to back to generate a combined DTB.

# This DT currently exist only as patches against linux-qcom-base recipe.
KERNEL_DEVICETREE:pn-linux-qcom-base = " \
                      qcom/qcs6490-rb3gen2.dtb \
                      "

KERNEL_DEVICETREE:pn-linux-qcom-custom = " \
                      qcom/qcs6490-addons-rb3gen2.dtb \
                      "

# Additional dtbo to overylay on top of kernel devicetree files
KERNEL_TECH_DTBOS[qcs6490-addons-rb3gen2] = " \
    qcm6490-graphics.dtbo qcm6490-wlan-rb3.dtbo \
    qcm6490-video.dtbo qcm6490-wlan-upstream.dtbo \
    qcm6490-camera-rb3.dtbo \
    "

In Qualcomm Linux 2.0, the DTB and DTB overlay are managed as shown in the following code snippet. The DTB and DTB overlay listed in KERNEL_DEVICETREE and LINUX_QCOM_KERNEL_DEVICETREE are packed in the image section of the generated FIT image.

KERNEL_DEVICETREE ?= " \
                      qcom/qcs6490-rb3gen2.dtb \
                      qcom/qcs6490-rb3gen2-industrial-mezzanine.dtbo \
                      qcom/qcs6490-rb3gen2-vision-mezzanine.dtbo \
                      "

# These DTs aren't upstreamed and currently exist only in linux-qcom kernels
LINUX_QCOM_KERNEL_DEVICETREE ?= " \
                      qcom/qcs6490-rb3gen2-vision-mezzanine-camx.dtbo \
                      "

The configurations section of the FIT image generates configuration as listed by FIT_DTB_COMPATIBLE:

FIT_DTB_COMPATIBLE[qcs6490-rb3gen2] = " \
    qcom,qcs5430-iot \
    qcom,qcs6490-iot \
    "
FIT_DTB_COMPATIBLE[qcs6490-rb3gen2+qcs6490-rb3gen2-industrial-mezzanine] = " \
    qcom,qcs5430-iot-subtype9 \
    qcom,qcs6490-iot-subtype9 \
    "
FIT_DTB_COMPATIBLE[qcs6490-rb3gen2+qcs6490-rb3gen2-vision-mezzanine] = " \
    qcom,qcs5430-iot-subtype2 \
    qcom,qcs6490-iot-subtype2 \
    "
FIT_DTB_COMPATIBLE[qcs6490-rb3gen2+qcs6490-rb3gen2-vision-mezzanine-camx] = " \
    qcom,qcs6490-iot-camx \
    qcom,qcs6490-iot-subtype2-camx \
    "

UEFI enhancements in Qualcomm Linux 2.0

UEFI enhancements in Qualcomm Linux 2.0 support FIT‑based DTB and DTBO management. UEFI selects the appropriate DTB or DTB + DTBO combination for the platform it’s booting by matching the compatible string. To derive these compatible strings, UEFI parses a metadata blob stored in the FIT image. UEFI matches the derived compatible string with the strings defined in the configurations. For more information on metadata, see Qualcomm DTB metadata. Typical configurations are as follows:

configurations {
   conf-1 {
         description = "FDT Blob";
         fdt = "fdt-qcs6490-rb3gen2.dtb";
         compatible = "qcom,qcs6490-iot";
   };
   conf-2 {
         description = "FDT Blob";
         fdt = "fdt-qcs6490-rb3gen2.dtb", "fdt-qcs6490-rb3gen2-industrial-mezzanine.dtbo";
         compatible = "qcom,qcs6490-iot-subtype9";
   };
   conf-3 {
         description = "FDT Blob";
         fdt = "fdt-qcs6490-rb3gen2.dtb", "fdt-qcs6490-rb3gen2-vision-mezzanine.dtbo";
         compatible = "qcom,qcs6490-iot-subtype2";
   };
};

The following table compares UEFI in Qualcomm Linux 1.0 with Qualcomm Linux 2.0: Table: UEFI in Qualcomm Linux 1.0 vs. Qualcomm Linux 2.0

Aspect	UEFI feature in Qualcomm 1.0	UEFI feature in Qualcomm 2.0
What UEFI handles	Concatenated DTB, a combined blob of multiple DT blobs.	Structured standard container FIT-based DTB and DTB overlays.
Parsing, matching, and selection methods	Custom, platform‑specific UEFI code, firmware scans blob, matches SoC/board ID, uses hard coded logic	Generic FIT parser in UEFI. UEFI enumerates FIT nodes and matches the compatible strings in the FIT node with the string composed from the metadata.
Offset handling	Customized offset calculation to identify individual DT blobs from the combined DT blob; dependency on order and size	Node‑based selection, size- and order-independent
DT overlay support	No	Native DTB overlay support through FIT
Adding a new DTB	Requires firmware awareness and validation	No firmware changes required
Standards alignment	No, downstream logic	Upstream‑aligned (U‑Boot, Linux, and UEFI)

Qualcomm DTB metadata overview

The Qualcomm DTB metadata is a public GitHub project that provides the following:

A specification for FIT-based DTB packaging/selection.
The qcom-metadata.dts source that’s compiled into a metadata DTB used by the firmware to match hardware identifiers to a FIT configuration.

The Qualcomm DTB metadata contains the following:

A metadata definition source (qcom-metadata.dts) that groups allowable compatible-string suffix tokens into nodes, such as soc, soc-sku, board, board-subtype-*, softsku, and oem.
A reference FIT ITS template (for example, qcom-fitimage.its and qcom-next-fitimage.its), where each configuration declares the following:
- A compatible qcom,<soc>-<...suffixes...> string
- The base DTB and optional overlays to apply in order

The firmware uses qcom-dtb-metadata to read the following:

The hardware IDs (chip ID/version, CDT board data, detected storage, DDR size, and so on)
The compiled metadata DTB
The FIT configurations to select a configuration whose compatible tokens match what the metadata defines and what the hardware reports

Benefits of using `qcom-dtb-metadata`

The qcom-dtb-metadata repo is an upstream-aligned, widely-accepted mechanism (FIT) to support dynamic device tree selection when a single release must support many SoCs/boards. The benefits of the qcom-dtb-metadata repo over multi-DTB solutions are as follows:

Standard container and structured selection
- FIT is an established and a widely-used format. It supports multiple configurations in a single image.
- The design enforces compatible-string suffixes to be defined in the metadata, preventing mystery tokens from being used, without a specification update.
Build-time validation to prevent mismatches
- Build-time checks are done to detect disparity between FIT-compatible suffixes and metadata definitions.
Works with multi-DTB+DTBO workflows
- The Qualcomm DTB metadata documentation describes base DTB+overlays. That is, runtime overlay parameters (for example, CamX and EL2KVM) that are treated specially by check scripts because they’re runtime-controlled rather than metadata-defined.
Qualcomm firmware integration details
- The current Qualcomm UEFI firmware supports external FIT only.
  - mkimage -E -B 8 (external data + 8-byte alignment)
  - Hard-coded file name expectation: qclinux_fit.img

FIT configuration and metadata pairing entries

The FIT configuration entry is a configuration in the ITS, which contains the following:

Compatible: qcom,<tokens...>

References to FDT: fdt-<board>.dtb (and optional overlays)

The metadata entry describes what each token means. Tokens used in the compatible string must exist as subnodes under the appropriate metadata group node. The Qualcomm DTB metadata documentation defines the groups and the bit fields that the firmware compares. For example:

soc → msm-id: <chip-id chip-version> with bit interpretations for chip ID/version.

soc-sku → msm-id: where certain bits represent the package ID/foundry ID.

board → board-id: with bit definitions for type, major, and minor.

board-subtype-* → board-subtype: with different bit slices depending on the subtype category (peripheral subtype, storage type, or memory size).

oem → oem-id

softsku → softsku-id

Recommended token order (pattern)

You can improve readability by following the Canonical pattern described in the Qualcomm DTB metadata documentation.

<soc>-<soc-sku>-<board>-<board-subtype-peripheral-subtype>-<board-subtype-storage-type>-<board-subtype-memory-size>-<softsku>-<oem>

Add a QCS9100 board variant

To add a QCS9100 board variant to qcom-dtb-metadata, do the following:

Pick the tokens you want to use for the variant (board rev, storage, memory, and so on) using the suggested pattern in the repo.
For every token you want to use in the compatible string, ensure there’s a corresponding subnode under the right group (soc, board, board-subtype-*, and so on). If a new suffix is introduced, add it to the metadata under the relevant node.
Add FIT_DTB_COMPATIBLE["key"] entries in conf/machine/include/fit-dtb-compatible.inc.
Build the FIT image with the updated metadata DTB using the build commands.
Flash the .qcomflash/ directory for the machine where these FIT changes are expected.
On bootup, verify that the logs show the newly added compatible. The UEFI boot logs print the following:
- ParseFitDt: Configuration from the BoardParam log line with parts that create the compatible you added
- FitLoadDtbFromFdt: Configuration fdt-<DTB> that you’ve mapped to your compatible

Changes in firmware management

Qualcomm Linux 1.0 supports firmware recipes in meta-qcom-hwe. The meta-qcom-hwe/recipes-firmware/firmware firmware recipes fetch firmware binaries from the Qualcomm® Software Center. Qualcomm Linux 2.0 uses the upstream firmware from the linux-firmware recipe in oe-core. The packages, as defined by the linux-firmware recipe in oe-core, are included in the machine configuration files in meta-qcom. The following recipes and software components in Qualcomm Linux 1.0 aren’t supported in Qualcomm Linux 2.0:

property-vault_1.0.bb

syslog-plumber_1.0.bb

Changes in Audio

Changes in OpenEmbedded metadata layer organization for audio are as follows: In Qualcomm Linux 1.0, AudioReach-related recipes were a part of meta-qcom-hwe. In Qualcomm Linux 2.0, they’re a part of the meta-audioreach OpenEmbedded layer. The recipe changes are as follows:

AudioReach 1.0 recipes use the qcom-* naming convention, while AudioReach 2.0 recipes use audioreach-*. For example, qcom-args in AudioReach 1.0 is now audioreach-graphservices in AudioReach 2.0.
The audio package name has changed from packagegroup-qcom-audio to packagegroup-audioreach.
An additional recipe, audioreach-kernel, has been added for downstream drivers.

Changes in device tree and driver

Qualcomm Linux 1.0 relied on multiple, configuration-specific DT audio nodes. Qualcomm Linux 2.0 introduces a single, unified DT audio configuration reused across all audio setups.

Changes in audio device tree handling

In Qualcomm Linux 1.0, separate DT audio nodes were maintained per custom audio configuration. The overlay audio drivers were probed based on individual DT nodes, which required maintaining multiple DT variants for different audio use cases. In Qualcomm Linux 2.0, a single common DT audio node is used for all configurations. The same node is re-used to probe and bind overlay audio drivers, eliminating redundancy and reducing DT complexity.

Changes in device tree in Qualcomm Linux 2.0

Explicit platform binding is used per digital audio interface (DAI) link. Each DAI link under the sound node now explicitly defines its platform Qualcomm Hexagon Q6 DSP (Q6) audio processing manager (APM). A new Q6 APM DAI container has been added. A Q6 APM DAI container node is also added under the GPR node, which provides a centralized DAI definition for audio routing.

Device tree nodes removed in Qualcomm Linux 2.0

The following nodes are removed as they’re no longer required with the unified DT and overlay probing model:

spf-core
audio-pkt
spf-core-platform
- msm-audio-mem
- msm-audio-mem-cma

Changes in the overlay drivers

Overlay drivers are now probed using a shared DT audio node. Configuration‑specific DT variants aren’t required. The removed nodes aren’t needed for overlay probing in the new architecture.

Changes in Audioreach userspace source organization

AudioReach sources are now fetched from the AudioReach/meta-audioreach GitHub project. There are no changes to the userspace API.

Changes in camera

Consider the following changes in camera for upgrading from Qualcomm Linux 1.0 to Qualcomm Linux 2.0.

Changes in camera in the OpenEmbedded layers

The following table lists the camera dynamically-loadable kernel module (DLKM) changes in the OpenEmbedded layers: Table: Camera DLKM changes

Qualcomm Linux 1.0 layers	Qualcomm Linux 2.0 layers
`meta-qcom-hwe/ recipes-multimedia/cameradlkm/cameradlkm_1.0.bb`	`meta-qcom/recipes-multimedia/camx/camx-dlkm_git.bb`

The following table lists the camera device tree changes in the OpenEmbedded layers: Table: Camera DTB changes

Qualcomm Linux 1.0 layers	Qualcomm Linux 2.0 layers
`meta-qcom-hwe/recipes-multimedia/cameradtb/cameradtb_1.0.bb`	In Qualcomm Linux 2.0, camera device tree changes are integrated into the in‑tree kernel. `meta-qcom/recipes-kernel/linux/linux-qcom_6.18.bb`

The following table lists the camera firmware changes in the OpenEmbedded layers: Table: Camera firmware changes

SoC	Qualcomm Linux 1.0 layers	Qualcomm Linux 2.0 layers
QCS6490	`meta-qcom-hwe/recipes-multimedia/camx/camxlib-kt_1.0.qcom.bb`	`meta-qcom /recipes-bsp/firmware/camxfirmware-kodiak_1.0.7.bb`
QCS9075 QCS8275	`meta-qcom-hwe/recipes-multimedia/camx/camxlib_1.0.qcom.bb`	`meta-qcom /recipes-bsp/firmware/camxfirmware-lemans_1.0.7.bb`
QCS615	Not applicable	`meta-qcom /recipes-bsp/firmware/camxfirmware-talos_1.0.0.bb`

The following table lists the CamX userspace changes in the OpenEmbedded layers: Table: CamX userspace changes

SoC	Qualcomm Linux 1.0 layers	Qualcomm Linux 2.0 layers
QCS6490	`meta-qcom-hwe/recipes-multimedia/camx/camxapi-kt_1.0.qcom.bb` `meta-qcom-hwe/recipes-multimedia/camx/ chicdk-autogen-kt_1.0.qcom.bb` `meta-qcom-hwe/recipes-multimedia/camx/camxlib-kt_1.0.qcom.bb` `meta-qcom-hwe/recipes-multimedia/camx/camx-kt_1.0.qcom.bb` `meta-qcom-hwe/recipes-multimedia/camx/chicdk-kt_1.0.qcom.bb`	`meta-qcom /dynamic-layers/openembedded-layer/recipes-multimedia/camx/camxlib-kodiak_1.0.11.bb`
QCS9075 QCS8275	`meta-qcom-hwe/recipes-multimedia/camx/camxapi_1.0.qcom.bb` `meta-qcom-hwe/recipes-multimedia/camx/camxcommon_1.0.qcom.bb` `meta-qcom-hwe/recipes-multimedia/camx/ camx-autogen_1.0.qcom.bb` `meta-qcom-hwe/recipes-multimedia/camx/ chicdk-autogen_1.0.qcom.bb` `meta-qcom-hwe/recipes-multimedia/camx/camxlib_1.0.qcom.bb` `meta-qcom-hwe/recipes-multimedia/camx/camx_1.0.qcom.bb` `meta-qcom-hwe/recipes-multimedia/camx/chicdk_1.0.qcom.bb`	`meta-qcom /dynamic-layers/openembedded-layer/recipes-multimedia/camx/camxlib-lemans_1.0.12.bb`
QCS615	Not applicable	`meta-qcom /dynamic-layers/openembedded-layer/recipes-multimedia/camx/camxlib-talos_1.0.2.bb`
COMMON	Not applicable	`meta-qcom /recipes-multimedia/camx/camxcommon-headers_1.0.1.bb`

Note The meta-qcom-extras recipes are not enabled in Qualcomm Linux 2.0.

Camera device tree migration from Qualcomm Linux 1.0 to Qualcomm Linux 2.0

In Qualcomm Linux 2.0, the camera device tree changes are integrated into the in‑tree kernel, which are located in arch/arm64/boot/dts/qcom/ within the kernel source. These changes are included as part of the linux-qcom recipe in Qualcomm Linux 2.0. The following table lists the target-specific camera device tree source files. For each target, the DT sources include the camera SoC first, followed by the camera sensor. Table: Target-specific camera device tree source files

Target	Qualcomm Linux 1.0 camera subsystem SoC DT and camera sensor device tree DT	Qualcomm Linux 2.0 camera subsystem SoC DT and camera sensor device tree DT
QCS6490	`qcm6490-camera-rb3.dtsiqcm6490-camera-sensor-rb3.dtsi`	`qcs6490-camera.dtsiqcs6490-rb3gen2-camera-sensor.dtsi`
QCS9075	`qcs9075-camera-iq-9075-evk.dtsiqcs9075-camera-sensor-iq-9075-evk.dtsi`	`lemans-camera.dtsilemans-camera-sensor.dtsi`
QCS8275	`qcs8275-camera-iq-8275-evk.dtsiqcs8275-camera-sensor-iq-8275-evk.dtsi`	`monaco-camera.dtsimonaco-camera-sensor.dtsi`
QCS615	Not applicable	`talos-camera.dtsitalos-camera-sensor.dtsi`

Note An overlay camera DTBO is created by combining the camera subsystem SoC device tree with the camera sensor device tree. The camera is overlaid on the base. The following table lists the camera overlay. For each target, the DT binary includes the base DT, followed by the camera overlay DTBO: Table: Base DTB and camera overlay DTBO

Target	Qualcomm Linux 1.0 base DTB and camera overlay DTBO	Qualcomm Linux 2.0 base DTB and camera overlay DTBO
QCS6490	`qcs6490-rb3gen2.dtb` `qcm6490-camera-rb3.dtbo`	`qcs6490-rb3gen2.dtb` `qcs6490-rb3gen2-vision-mezzanine-camx.dtbo`
QCS9075	`qcs9075-ride-r3.dtb` `qcs9075-ride-sx-camera.dtbo`	`lemans-evk.dtb` `lemans-evk-camx.dtbo`
QCS8275	`qcs8275-iq-8275-evk.dtb` `qcs8275-addons-iq-8275-evk.dtb`	`monaco-evk.dtb` `monaco-evk-camx.dtbo`
QCS615	Not applicable	`talos-evk.dtb` `talos-evk-camx.dtbo`

BitBake command to compile the camera DTS

The following table lists the BitBake command to compile the camera DTS: Table: Camera device tree compilation command

Qualcomm Linux 1.0	Qualcomm Linux 2.0
`bitbake cameradtb`	`bitbake linux-qcom`

Camera DLKM migration from Qualcomm Linux 1.0 to 2.0

The camera DLKM recipe name and source path have changed in Qualcomm Linux 2.0. In Qualcomm Linux 1.0, the recipe name is cameradlkm. It has been renamed to camx-dlkm in Qualcomm Linux 2.0, and the source path has been changed. The following table lists the command to modify the camera DLKM source: Table: Command to modify camera DLKM source

Qualcomm Linux 1.0	Qualcomm Linux 2.0
`devtool modify cameradlkm`	`devtool modify camx-dlkm`

The following table lists the locations for the camera DLKM source code, based on the target platform:

Table: Target-specific camera DLKM source code location
Target	Qualcomm Linux version	Source code location
QCS6490	1	$/build-qcom-wayland/workspace/sources/cameradlkm/qcom/ opensource/camera-kernel/camera-kt/
2	$/build/workspace/sources/camx-dlkm/camera-kt/
QCS9075 QCS8275 QCS615	1	$/build-qcom-wayland/workspace/sources/cameradlkm/qcom/ opensource/camera-kernel/camera/
2	$/build/workspace/sources/camx-dlkm/camera/

The following table lists the BitBake command to compile the camera DLKM sources:

Camera DLKM compilation command
Qualcomm Linux 1.0	Qualcomm Linux 2.0
bitbake cameradlkm	bitbake camx-dlkm

Changes in CamX userspace source organization

In Qualcomm Linux 2.0, the CamX userspace binary is shipped using the meta qcom recipe. The CamX userspace sources reside in meta qcom extras, which is currently not enabled in the Qualcomm Linux 2.0 mainline.

Enable camera functionality

Qualcomm Linux 2.0 qcom-multimedia-proprietary-image installs the downstream camera packages by default, but doesn’t enable the camera functionality. To enable the camera functionality for qcom-multimedia-proprietary-image, run the following command in the device shell:

echo -n "camx" > /var/data
efivar -n 882f8c2b-9646-435f-8de5-f208ff80c1bd-VendorDtbOverlays -w -f /var/data
sync
reboot

For more information, see Use overlay configurations to derive image recipes.

Changes in display

Changes in OpenEmbedded metadata layer organization for display are as follows: In Qualcomm Linux 1.0, the GBM backend for Yocto uses a separate mirrored source repository in meta-qcom-hwe. The meta-qcom-hwe OpenEmbedded layer uses the msm_be.bb recipe, which fetches Mesa 22.04 and applies a patch for the backend. The compilation is enabled from packagegroup based on the graphics driver. In Qualcomm Linux 2.0, the msm-gbm-backend.bb recipe handles the GBM backend in meta-qcom, which fetches the source from CodeLinaro. It’s compiled with runtime dependency added from qcom-adreno to msm-gbm-backend.

Changes in graphics

When upgrading to Qualcomm Linux 2.0, consider the following changes required for graphics in the KMD and the user mode driver (UMD) components. The following changes were made in KMD:

Unified device tree architecture
Transition from the Qualcomm^® Adreno^™ GPU TZ governor to the Simple On‑Demand governor for GPU dynamic clock and voltage scaling (DCVS)
Updates to the kernel graphics support layer (KGSL) driver distribution workflow

The following changes were made in UMD:

Restructured OpenEmbedded metadata layer
Reorganized recipe
Revised header usage
Updated firmware handling
Integration of OpenGL Vendor-Neutral Dispatch (GLVND) to provide a vendor‑neutral user‑space interface

These modifications provide the following benefits in Qualcomm Linux 2.0:

Simplified maintenance
Alignment with upstream Yocto practices
Streamlined graphics stack

Changes in OpenEmbedded metadata layer organization for graphics are as follows:

Reorganized metadata layer

In Qualcomm Linux 2.0, the graphics-related OE metadata is consolidated. The graphics recipes previously located in meta-qcom-hwe are now moved to meta-qcom. The benefits are as follows:

Easier maintenance
Single source of truth for graphics build artifacts
Alignment with the upstream Yocto layer structure

Updated Adreno recipe

The Adreno graphics recipe is now located at meta-qcom/recipes-graphics/adreno/. Update your build configurations to reference recipes from meta-qcom instead of meta-qcom-hwe.

Removal of exported graphics userspace headers

Vendor graphics recipes no longer export the following headers:

EGL
OpenGL/OpenGL ES
OpenCL

The new header consumption model is as follows:

EGL, OpenGL, and OpenGL ES: Provided by GLVND include paths
OpenCL: Provided by the OpenCL loader
Adreno-specific OpenCL extension: Only cl_ext_qcom.h is provided by the Adreno package

The benefits are as follows:

Consistent API interface across vendors
Improved application portability
Reduced vendor-specific coupling

The impact on applications is as follows:

Applications must be updated to include paths to rely on GLVND and OpenCL loader headers
Direct dependency on vendor-exported headers is no longer supported

The following table lists the APIs and the respective header sources: Table: APIs and header sources in Qualcomm Linux 2.0

API	Header source in Qualcomm Linux 2.0
EGL	GLVND
OpenGL/OpenGL ES	GLVND
OpenCL	OpenCL loader
Adreno OpenCL extensions	`cl_ext_qcom.h` (Adreno package)

Updated KGSL recipe

The distribution and fetching mechanism for the KGSL driver has been updated in Qualcomm Linux 2.0. The source code is now managed through a read-only development model on GitHub. The repository details are as follows:

Source repository: github.com/qualcomm-linux/kgsl
Branch: gfx-kernel.le.0.0
Development model: Private, closed

For integration, the KGSL recipe fetches source code directly from the repository. The recipe is located at kgsl-dlkm_git.bb.

Changes in firmware handling

In Qualcomm Linux 1.0, the firmware binaries were shipped as part of the Adreno graphics recipe. In Qualcomm Linux 2.0, the firmware isn’t shipped with the Adreno graphics stack. You must obtain it from the Linux firmware repository. Note Ensure that the appropriate Qualcomm firmware files are present during root file system creation. Note Firmware packaging and deployment must be handled independently of graphics recipes.

Overlay enablement

GLVND is used for the userspace graphics stack. It provides vendor-neutral dispatching for the following:

OpenGL
EGL
GLX

GLVND introduces a loader layer between applications and vendor-specific graphics libraries.

Linking and runtime behavior changes

With GLVND enabled, applications no longer link directly to vendor-specific EGL/GLES libraries. They link against GLVND libraries instead. Vendor libraries are selected and loaded dynamically at runtime.

Installed components

In Qualcomm Linux 2.0, graphics installs the following components:

GLVND core libraries
Vendor-specific EGL/GLES loader libraries only

Vendor selection is controlled through installable client driver (ICD) JSON files.

Adreno ICD

Adreno provides the 10_EGL_adreno.json ICD file. GLVND uses this file to select the Adreno vendor implementation at runtime.

Application-level impact

As GLVND exists between applications and vendor libraries, the application-level impact is as follows:

Applications must use eglGetProcAddress() to obtain extension APIs.
Static linking to vendor-specific symbols is no longer valid.
Vendor library selection occurs at runtime based on the ICD priority.

Environment variables and overlay behavior

GLVND environment controls

GLVND behavior can be controlled and debugged using environment variables.

Vendor selection through environment variable

When multiple vendors or overlays are present, GLVND uses the __EGL_VENDOR_LIBRARY_FILENAMES variable. This variable explicitly specifies which ICD files GLVND must use. For example, the following forces GLVND to select the Adreno vendor implementation at runtime:

export __EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/10_EGL_adreno.json

Overlay enablement for the kernel module

To enable overlay configurations, a specific module parameter is adjusted. The skip_gpu DRM module parameter defaults to 0 in the standard configurations (Config #1). For overlay support (Config #2), this parameter is set to 1, followed by the loading of the msm_kgsl module. The overlay is enabled in Config #2 through asoc-blacklist.conf. The file path is /etc/modprobe.d/asoc-blacklist.conf.

install msm /bin/sh -c "( modprobe --ignore msm skip_gpu=1 && modprobe msm_kgsl ) || modprobe --ignore-install msm"

Upstream and unified device tree

In Qualcomm Linux 2.0, the KGSL driver has been upgraded to support the upstream device tree. Consequently, the upstream device tree is now compatible with both DRM and KGSL drivers. This unification eliminates the requirement for maintaining separate Base and Custom DTs for DRM and KGSL, unlike in Qualcomm Linux 1.0. The key changes are as follows:

Recipe deprecation: The separate recipe used to maintain the downstream DT in Qualcomm Linux 1.0 (qcom-graphicsdevicetree_git.bb) is no longer required in the transition to meta-qcom 2.0.
Unified maintenance: This shift streamlines the development process by removing the need for distinct DT maintenance workflows.

GPU DCVS governor transition

The GPU DCVS governor implementation has undergone a significant modification:

Qualcomm Linux 1.0 uses the Adreno TZ governor.
Qualcomm Linux 2.0 transitions to the upstream Simple On-Demand governor.

The impact is as follows:

Performance: The Simple On-Demand governor offers improved performance efficiency.
Power: You may see a slight increase in power consumption as a trade‑off for performance gains.

Changes in Qualcomm^® Intelligent Multimedia (IM) SDK

Changes in the OpenEmbedded metadata layer organization for Qualcomm IM SDK are as follows.

GStreamer plugin recipes

In Qualcomm Linux 1.0, each GStreamer plugin has a recipe file. In Qualcomm Linux 2.0, they’re consolidated as follows:

A single recipe, gst-plugins-imsdk_git.bb, now handles the compilation of all GStreamer plugins.
The recipe is unified, but each plugin continues to produce an individual package. This ensures that you can still install only the specific plugin package as needed, without using the entire plugin.

In Qualcomm Linux 1.0, plugins came as artifacts and you had to install them using the install script. In Qualcomm Linux 2.0, on flashing the build, plugins are packaged in the image. No separate installation is required.

Camera service recipe updates

camera-server.bb has been renamed to camera-service.bb. The updated recipe now fetches source code from GitHub, aligning with upstream best practices. The recipe generates multiple sub packages, such as, client, common, and target specific libs. Hence, the qtiqmmfsrc GStreamer plugin depends only on the client package instead of the entire service. This modularization enables cleaner integration with other layers and components.

Plugins included in `qcom-multimedia-image`

qcom-multimedia-image includes all standard GStreamer plugins except the following, which depend on proprietary libraries:

qtimlqnn
qtimlsnpe
qtismartvencbin
qtiqmmfsrc

Plugins included in `qcom-multimedia-proprietary-image`

The proprietary image contains all plugins, including the proprietary plugins. This ensures full-feature availability for development, debugging, and product builds that require proprietary dependencies to be available.

Deprecated QIM plugins

The following downstream plugins are deprecated in Qualcomm Linux 2.0:

qtimlvclassification
qtimlvdetection
qtimlvpose
qtimlvsuperresolution
qtimlvsegmentation
qtimlaclassification

The qtiqmmfsrc plugin properties are populated from the camera metadata instead of fixed hardcodings, based on the SoC.

Changes in sample applications

Qualcomm Linux 2.0 uses a standardized, machine-agnostic approach to compiling sample applications. It shifts the development environment from target-specific toolchain to the build tools standalone installer, decoupling build utilities from specific device image. Qualcomm Linux 2.0 uses RPM packaging instead of OPKG as it’s aligned to the standard packaging mechanism and offers a stronger package and dependency management. Note Except for packaging updates, migrating to Qualcomm Linux 2.0 doesn’t require any additional changes to the existing sample applications. The following table lists the key differences between sample application support in Qualcomm Linux 1.0 and Qualcomm Linux 2.0: Table: Sample applications comparison

Aspect	Qualcomm Linux 1.0	Qualcomm Linux 2.0
SDK type	Machine-specific eSDK	Single eSDK applicable to all machines
eSDK script	`qcom-wayland-x86_64-qcom-multimedia-image-armv8-2a-<machine>-toolchain-ext-1.7-Ver.1.1.sh`	`qcom-distro-aarch64-qcom-multimedia-proprietary-image-armv8a-qcom-armv8a-toolchain-ext-2.0.sh`
Command to install the updated application	`opkg --force-reinstall install.ipk` is generated.	`dnf install.rpm` is generated.
Path for application-installable packages	`<workspace_root>/tmp/deploy/ipk/armv8-2a/`	`<workspace_root>/tmp/deploy/rpm/armv8a`
Command and sample path to download the existing sample application sources	Command: `devtool modify qcom-gst-camera-single-stream-example` Sample path: `workspace_root>/workspace/sources/qcom-gst-camera-single-stream-example`	Command: `devtool modify gst-plugins-imsdk` Sample path: `<workspace_root>/workspace/sources/gst-plugins-imsdk/gst-sample-apps`
Build commands examples	`devtool build qcom-gst-camera-single-stream-example` `devtool package qcom-gst-camera-single-stream-example`	`devtool build gst-plugins-imsdk` `devtool package gst-plugins-imsdk`

For more information, see:

Changes in video

Changes in OpenEmbedded metadata layer organization for video are as follows:

The video driver recipe is renamed and moved from meta-qcom-hwe to meta-qcom.
- Qualcomm Linux 1.0: qcom-videodlkm_1.0.bb
- Qualcomm Linux 2.0: recipes-kernel/iris-video-module/iris-video-dlkm_git.bb
The video firmware recipe has been migrated from meta-qcom-hwe to the standard Linux firmware recipe.
- Qualcomm Linux 1.0: qcom-video-firmware_1.0.bb
- Qualcomm Linux 2.0: linux-firmware_<version>.bb as present in OpenEmbedded-core
The video device tree configuration has been migrated from the earlier overlay DT to the DT which is already available in the mainline kernel.
- Qualcomm Linux 1.0: qcom-videodtb_1.0.bb
- Qualcomm Linux 2.0: The DT is a part of the mainline kernel DT.

​Partition layout

​Containers and orchestration updates

​Migrate device tree and device tree overlay

​UEFI enhancements in Qualcomm Linux 2.0

​Qualcomm DTB metadata overview

​Benefits of using qcom-dtb-metadata

​FIT configuration and metadata pairing entries

​Recommended token order (pattern)

​Add a QCS9100 board variant

​Changes in firmware management

​Recipes and related software components not supported

​Changes in Audio

​Changes in device tree and driver

​Changes in audio device tree handling

​Changes in device tree in Qualcomm Linux 2.0

​Device tree nodes removed in Qualcomm Linux 2.0

​Changes in the overlay drivers

​Changes in Audioreach userspace source organization

​Changes in camera

​Changes in camera in the OpenEmbedded layers

​Camera device tree migration from Qualcomm Linux 1.0 to Qualcomm Linux 2.0

​BitBake command to compile the camera DTS

​Camera DLKM migration from Qualcomm Linux 1.0 to 2.0

​Changes in CamX userspace source organization

​Enable camera functionality

​Changes in display

​Changes in graphics

​Reorganized metadata layer

​Updated Adreno recipe

​Removal of exported graphics userspace headers

​Updated KGSL recipe

​Changes in firmware handling

​Overlay enablement

​Linking and runtime behavior changes

​Installed components

​Adreno ICD

​Application-level impact

​Environment variables and overlay behavior

​GLVND environment controls

​Vendor selection through environment variable

​Overlay enablement for the kernel module

​Upstream and unified device tree

​GPU DCVS governor transition

​Changes in Qualcomm® Intelligent Multimedia (IM) SDK

​GStreamer plugin recipes

​Camera service recipe updates

​Plugins included in qcom-multimedia-image

​Plugins included in qcom-multimedia-proprietary-image

​Deprecated QIM plugins

​Changes in sample applications

​Changes in video