# Migrate features to Qualcomm Linux 2.0 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](https://docs.qualcomm.com/doc/80-80022-27/topic/modifying_partition_layout.html). ## 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 \ " Copy to clipboard 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 \ " Copy to clipboard 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 \ " Copy to clipboard 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 \ " Copy to clipboard 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 \ " Copy to clipboard 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 \ " Copy to clipboard ### 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](https://docs.qualcomm.com/doc/80-80022-150/topic/migrate-features.html#section-qcom-dtb-md). 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"; }; }; Copy to clipboard 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,-<...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, and DDR size) - 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](https://github.com/qualcomm-linux/qcom-dtb-metadata/blob/main/Documentation.md) describes base DTB+overlays. Runtime overlay parameters (for example, `CamX` and `EL2KVM`) 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,` > - References to FDT: `fdt-.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](https://github.com/qualcomm-linux/qcom-dtb-metadata/blob/main/Documentation.md) 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](https://github.com/qualcomm-linux/qcom-dtb-metadata/blob/main/Documentation.md). ------- Copy to clipboard #### Add a QCS9100 board variant To add a QCS9100 board variant to `qcom-dtb-metadata`, do the following: 1. Pick the tokens you want to use for the variant (board rev, storage, and memory) using the suggested pattern in the repo. 2. 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. 3. Add `FIT_DTB_COMPATIBLE["key"]` entries in `conf/machine/include/fit-dtb-compatible.inc`. 4. Build the FIT image with the updated metadata DTB using the build commands. 5. Flash the `.qcomflash/` directory for the machine where these FIT changes are expected. 6. 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-` 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](https://softwarecenter.qualcomm.com). 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`. ### Recipes and related software components not supported 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.dtsi`


`qcm6490-camera-sensor-rb3.dtsi` | `qcs6490-camera.dtsi`


`qcs6490-rb3gen2-camera-sensor.dtsi` | | QCS9075 | `qcs9075-camera-iq-9075-evk.dtsi`


`qcs9075-camera-sensor-iq-9075-evk.dtsi` | `lemans-camera.dtsi`


`lemans-camera-sensor.dtsi` | | QCS8275 | `qcs8275-camera-iq-8275-evk.dtsi`


`qcs8275-camera-sensor-iq-8275-evk.dtsi` | `monaco-camera.dtsi`


`monaco-camera-sensor.dtsi` | | QCS615 | Not applicable | `talos-camera.dtsi`


`talos-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: | **Target** | **Qualcomm Linux version** | **Source code location** | | --- | --- | --- | |
QCS6490 | 1.0 | `${WORKSPACE}/build-qcom-wayland/workspace/sources/cameradlkm/qcom/ opensource/camera-kernel/camera-kt/` | |
QCS6490 | 2.0 | `${WORKSPACE}/build/workspace/sources/camx-dlkm/camera-kt/` | |
QCS9075


QCS8275


QCS615 | 1.0 | `${WORKSPACE}/build-qcom-wayland/workspace/sources/cameradlkm/qcom/ opensource/camera-kernel/camera/` | |
QCS9075


QCS8275


QCS615 | 2.0 | `${WORKSPACE}/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 Copy to clipboard For more information, see [Use overlay configurations to derive image recipes](https://docs.qualcomm.com/doc/80-80022-150/topic/overlay_configurations.html#configurations). ## Changes in display Changes in OpenEmbedded metadata layer organization for display are as follows: In Qualcomm Linux 1.0, the GBM back-end 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 back end. 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 back-end 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](https://github.com/qualcomm-linux/meta-qcom/blob/master/recipes-graphics/kgsl-dlkm/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](https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/qcom). 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 Copy to clipboard #### Overlay setup 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" Copy to clipboard ### 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 Qualcomm IM SDK GStreamer plugin was provided as an independent BitBake recipe and delivered as a separate installable artifact, requiring additional post-installation scripts. In Qualcomm Linux 2.0, the Qualcomm IM SDK GStreamer integration uses a consolidated Yocto-native model: - Multiple plugins are built from a single source tree. - Plugins are compiled from source. - Each plugin is still packaged independently. - Packages are installed directly into the root filesystem image. - No post-flash installation scripts are required. The new design improves build reproducibility, simplifies image composition, and aligns fully with standard Yocto packaging workflows. #### Common include files - `gst-plugins-imsdk-common.inc`: This is a shared include file used by all Qualcomm IM SDK GStreamer plugin recipes. It centralizes common configuration and avoids duplication across individual recipes. All Qualcomm IM SDK recipes must include this file. - `gst-plugins-imsdk-packaging.inc`: This include file extends standard GStreamer packaging behavior. It ensures fine-grained packaging so that each Qualcomm IM SDK plugin can be installed independently. #### BitBake recipes - `gst-plugins-imsdk-base_0.1.3.bb`: This recipe is for the Qualcomm IM SDK GStreamer base libraries. It’s functions are as follows: > > > > > > > > - Builds core Qualcomm IM SDK libraries shared by all Qualcomm IM SDK plugins > > - Provides headers and shared objects required by both OSS and proprietary plugins > > > > Note > > > Build this recipe before building any Qualcomm IM SDK plugin recipes. - `gst-plugins-imsdk-oss_0.1.3.bb`: This recipe is for open-source Qualcomm IM SDK GStreamer plugins. > > > - The default plugin groups are as follows: > > > > > > > > > - `sw` > > - `tools` > > - `videoproc` > - The key characteristics are as follows: > > > > > > > > > - Depends on `gst-plugins-imsdk-base` > > - Plugin groups are controlled using `PACKAGECONFIG` > > - Each plugin is packaged independently, allowing selective installation. For example, `IMAGE_INSTALL += "gst-plugin-imsdk-videoproc"` - `gst-plugins-imsdk-prop_0.1.3.bb`: This recipe is for proprietary Qualcomm IM SDK GStreamer plugins. > > > - The default plugin groups are as follows: > > > > > > > > > - `qairt`: AI/ML acceleration plugins > > - `smartvencbin`: Smart Video Encoder plugin > > - `qtiqmmfsrc`: Camera source plugin > - The key characteristics are as follows: > > > > > > > > > - Depends on `gst-plugins-imsdk-base` > > - Builds proprietary plugins from the Qualcomm IM SDK source tree > > - Each plugin is packaged as an individual runtime package - `smart-venc-ctrl-algo_1.0.bb`: Recipe for Smart Video Encoder Control algorithm (prebuilt libraries). It provides precompiled control algorithm libraries required by the `smartvencbin` plugin. > > > - The key characteristics are as follows: > > > > > > > > > - Fetches prebuilt binaries from the Qualcomm artifactory > > - Installs libraries into the Yocto sysroot > > > > Example dependency: `RDEPENDS:${PN} += "smart-venc-ctrl-algo"` ### 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 libraries. 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 Note Except for packaging updates, migrating to Qualcomm Linux 2.0 doesn’t require any additional changes to the existing sample applications. Sample applications are now compiled without using the extended SDK (eSDK). Previously, the eSDK provided devtool support and full Yocto build functionality. The Qualcomm Linux 2.0 RC3 release uses a standard SDK, which serves as a lightweight toolchain for cross-compilation. A new `build.sh` helper script is included to simplify the CMake configuration, build, and installation processes. To set up the SDK environment, run `environment-setup-armv8-2a-qcom-linux` directly. The script retains its previous name, but it’s designed for the standard SDK. For more information, see [Create a sample application with the Qualcomm IM SDK](https://docs.qualcomm.com/doc/80-80022-51/topic/content-develop-your-first-application.html). ## 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_.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. Last Published: May 12, 2026 [Previous Topic Migrate to Qualcomm Linux 2.0 using OTA upgrade](https://docs.qualcomm.com/bundle/publicresource/80-80022-150/topics/migrate-using-ota-software.md) [Next Topic Enable and evaluate Qualcomm Linux overlays](https://docs.qualcomm.com/bundle/publicresource/80-80022-150/topics/overlay_overview.md) Source: [https://docs.qualcomm.com/doc/80-80022-150/topic/migrate-features.html](https://docs.qualcomm.com/doc/80-80022-150/topic/migrate-features.html)