# Changes in the OpenEmbedded layers and the build system Consider changes in the OpenEmbedded layers, build system, BitBake variables, recipes, and distros to migrate from Qualcomm Linux 1.0 to Qualcomm Linux 2.0. ## Changes in OpenEmbedded layers Qualcomm Linux uses OpenEmbedded layers to deliver technology components and reference distributions. The following table lists the changes in the OpenEmbedded layers between Qualcomm Linux 1.0 and Qualcomm Linux 2.0: Table: Changes in OpenEmbedded layers | Qualcomm Linux 1.0 layers | Qualcomm Linux 2.0 layers | | --- | --- | | | | The following table lists the changes made to the Qualcomm-authored OpenEmbedded layers, which are a part of Qualcomm Linux 2.0: Table: Changes in Qualcomm-authored OpenEmbedded layers | OpenEmbedded layer in Qualcomm Linux 1.0 | Corresponding OpenEmbedded layer in Qualcomm Linux 2.0 | Summary of changes in Qualcomm Linux 2.0 | Migration notes | | --- | --- | --- | --- | | `meta-qcom` | `meta-qcom` | For Qualcomm Linux 2.0, this layer provides all BSP recipes that Qualcomm has authored. | This layer is compatible with Yocto whinlatter and master. | | `meta-qcom-distro` | `meta-qcom-distro` | This layer provides reference distribution images for Qualcomm Linux. | For Qualcomm Linux 2.0, the key image recipes supported are `qcom-multimedia-image` and `qcom-multimedia-proprietary-image`. | | `meta-qcom-hwe` | `meta-qcom` | The `meta-qcom-hwe` layer isn’t supported in Qualcomm Linux 2.0. The BSP recipes from this layer are now part of `meta-qcom`. | If your integration layer has a dependency placed on this layer, remove the dependency as `meta-qcom` provides all the OpenEmbedded features in Qualcomm Linux 2.0. To remove the dependency, remove `qcom-hwe` from `layer.conf` of your OpenEmbedded layer:


LAYERDEPENDS_ "qcom-hwe"
Copy to clipboard


For more information, see [Changes in Qualcomm® Intelligent Multimedia (IM) SDK](https://docs.qualcomm.com/doc/80-80022-150/topic/migrate-features.html#qim-sdk). | | `meta-qcom-qim-product-sdk` | `meta-qcom` | The `meta-qcom-qim-product-sdk` layer isn’t supported in Qualcomm Linux 2.0. The recipes present earlier in this layer have been migrated to `meta-qcom`. | If your integration layer has a dependency placed on this layer, remove the dependency
as `meta-qcom` provides the OpenEmbedded features in Qualcomm Linux 2.0.
To remove the dependency, remove `qti-qim-product-sdk-` from `layer.conf` of your OpenEmbedded layer:


LAYERDEPENDS_ "qti-qim-product-sdk"
Copy to clipboard | | `meta-qcom-realtime` | `meta-qcom` | The `meta-qcom-realtime` layer isn’t supported in Qualcomm Linux 2.0. The real-time Linux recipes are now part of `meta-qcom`. | If your integration layer has a dependency placed on this layer, remove the dependency
as `meta-qcom` provides all the OpenEmbedded features in Qualcomm Linux 2.0.
To remove the dependency, remove `qcom-realtime` from `layer.conf` of your OpenEmbedded layer:


LAYERDEPENDS_ "qcom-realtime"
Copy to clipboard | ## Changes in Qualcomm Linux 2.0 build system Consider the following key differences between the traditional Qualcomm Linux 1.0 repo-manifest Yocto build workflow and the Qualcomm Linux 2.0 Configuration Automation System (KAS)-based workflow. ### KAS overview Qualcomm Linux supports KAS-based build execution. KAS is an open-source tool for BitBake-based projects. It simplifies the process of configuring and launching OpenEmbedded builds using a YAML configuration file. KAS automates the following, making it suitable for both developers and continuous integration/continuous deployment (CI/CD) usage: > > > - Cloning and checking out of necessary layer Git repositories > - Generating the required BitBake configuration files, such as `local.conf` and `bblayers.conf`, based on the YAML input > - Reducing the number of steps required to set up a workspace by executing the standard BitBake process. For example, `kas build ` does the following: > > > > > > > > > - Clones the layer repositories > > - Sets up the environment > > - Starts the BitBake `` > - Providing a wrapper kas-container, which can run the build process in Docker The following table compares the Repo tool and KAS on parameters, such as machine selection, distribution selection, and BSP flavor: Table: Repo tool vs KAS comparison | **Parameter** | **Repo-manifest workflow** | **KAS workflow** | | --- | --- | --- | | Machine selection | Controlled through the `MACHINE` environment variable. | Defined in the `machine.yml` configuration file. | | Distribution selection | Controlled through the `DISTRO` environment variable. | Defined in the `distro.yml` configuration file. | | BSP flavor | Controlled explicitly using `QCOM_SELECTED_BSP` (either `base` or `custom`).



>
>
>

    >

  • base includes upstream sources.


    • >

  • custom includes Qualcomm-proprietary packages.


    • >
| No direct equivalent to `QCOM_SELECTED_BSP`. The BSP flavor is implicitly chosen by selecting the appropriate distro configuration file:



>
>
>

    >

  • qcom-distro.yml includes upstream sources.


    • >

  • qcom-distro-prop-image.yml includes Qualcomm-proprietary packages.


    • >
| The following table compares the workflows at a high-level between the Repo tool and KAS: Table: High-level workflow comparison: Repo tool vs. KAS | Step | Repo-manifest workflow | KAS workflow | | --- | --- | --- | |

  1. Sync layers.


| Uses `repo init` + `repo sync` to fetch meta layers based on a manifest file | `kas checkout` fetches all layers defined in the KAS configuration files. | |

  1. Configure the build environment.


| Runs `setup-environment` to generate `local.conf` and `bblayers.conf`, based on `MACHINE`, `DISTRO`, and `QCOM_SELECTED_BSP` | `kas build` generates `local.conf` and `bblayers.conf`, based on `machine.yml` and `distro.yml`. | |

  1. Build the image.


| Runs `bitbake ` to build the image | `kas build` automatically runs `bitbake` to build the target configured in `distro.yml`. | ### Sample KAS configuration file The following example illustrates sample KAS configuration files found in `meta-qcom` and explains how each section maps to the repo-manifest workflow concepts and how KAS interprets them. For more information about the configuration file format, see [KAS documentation](https://kas.readthedocs.io/en/latest/userguide/project-configuration.html). #### base.yml The `base.yml` file documents the base configuration used by all build combinations. header: version: 14 distro: poky-altcfg defaults: repos: branch: master repos: meta-qcom: oe-core: url: https://github.com/openembedded/openembedded-core layers: meta: bitbake: url: https://github.com/openembedded/bitbake layers: .: disabled meta-yocto: url: https://git.yoctoproject.org/meta-yocto layers: meta-poky: local_conf_header: base: | CONF_VERSION = "2" INHERIT += "buildstats-summary" INHERIT += "buildhistory" INHERIT += "rm_work" diskmon: | BB_DISKMON_DIRS ??= "\ STOPTASKS,${TMPDIR},1G,100K \ STOPTASKS,${DL_DIR},1G,100K \ STOPTASKS,${SSTATE_DIR},1G,100K \ STOPTASKS,/tmp,100M,100K \ HALT,${TMPDIR},100M,1K \ HALT,${DL_DIR},100M,1K \ HALT,${SSTATE_DIR},100M,1K \ HALT,/tmp,10M,1K" clo-mirrors: | MIRRORS:append = " \ git://github.com git://git.codelinaro.org/clo/yocto-mirrors/github/ \ git://.*/.*/ git://git.codelinaro.org/clo/yocto-mirrors/ \ https://.*/.*/ https://artifacts.codelinaro.org/codelinaro-le/ \ " cmdline: | KERNEL_CMDLINE_EXTRA:append = " qcom_scm.download_mode=1" qcomflash: | IMAGE_CLASSES += "image_types_qcom" IMAGE_FSTYPES += "qcomflash" extra: | DISTRO_FEATURES:append = " efi pni-names" EXTRA_IMAGE_FEATURES = "allow-empty-password empty-root-password allow-root-login" IMAGE_ROOTFS_EXTRA_SPACE = "307200" WATCHDOG_RUNTIME_SEC:pn-systemd = "30" uninative: | INHERIT:remove = "uninative" machine: unset target: - core-image-base Copy to clipboard #### machine.yml The `machine.yml` file documents machine-specific configuration. This file generally extends the `base.yml` configuration. header: version: 14 includes: - ci/base.yml machine: qcs8300-ride-sx Copy to clipboard #### distro.yml The `distro.yml` file documents distribution-specific configuration and the targets to be built. header: version: 14 distro: qcom-distro repos: meta-qcom-distro: url: https://github.com/qualcomm-linux/meta-qcom-distro branch: main meta-openembedded: url: https://github.com/openembedded/meta-openembedded layers: meta-filesystems: meta-gnome: meta-multimedia: meta-networking: meta-oe: meta-python: meta-xfce: meta-virtualization: url: https://git.yoctoproject.org/git/meta-virtualization branch: master meta-audioreach: url: https://github.com/AudioReach/meta-audioreach branch: master meta-selinux: branch: master url: https://git.yoctoproject.org/meta-selinux meta-updater: branch: master url: https://github.com/uptane/meta-updater local_conf_header: virtualization: SKIP_META_VIRT_SANITY_CHECK = "1" target: - qcom-multimedia-image Copy to clipboard The following table lists the KAS file structure: Table: KAS file structure | Section | Description | | --- | --- | | machine | Machine name used in the build.
Equivalent to setting `MACHINE=` in `local.conf`. | | distro | Indicates the distribution to be built.
Equivalent to setting `DISTRO=` in `local.conf`. | | repos | Defines all Yocto/OE meta layers to fetch.
Each repository entry includes URL, branch, commit (optional), and a list of layers used from that repo.
It corresponds directly to the meta layer <project> elements in the repo-manifest. | | local\_conf\_header | Appends fragments to the `local.conf` generated .
Equivalent to what `setup-environment` injects into `local.conf` in the repo-manifest workflow. | | target | Specifies the images to build.
Equivalent to running `bitbake ` in the repo-manifest workflow. | ### Run builds using KAS-based build system When using KAS, clone the repository containing the KAS YAML files and then build using one of the following methods: - Run the KAS build command - Start a KAS shell and then run BitBake To run a build using the KAS build command, run the following command: git clone https://github.com/qualcomm-linux/meta-qcom.git kas build meta-qcom/ci/.yml:meta-qcom/ci/.yml Copy to clipboard To start a KAS shell and then run BitBake, run the following command: git clone https://github.com/qualcomm-linux/meta-qcom.git kas shell meta-qcom/ci/.yml:meta-qcom/ci/.yml Copy to clipboard The output is as follows: 2026-02-13 10:36:33 - INFO - kas 4.7 started 2026-02-13 10:36:33 - INFO - Using /local/mnt/workspace/sbanerje/QSBT/meta-qcom as root for repository meta-qcom 2026-02-13 10:36:33 - INFO - Repository oe-core already contains master as commit 2026-02-13 10:36:33 - INFO - Repository bitbake already contains master as commit 2026-02-13 10:36:33 - INFO - Repository meta-yocto already contains master as commit 2026-02-13 10:36:33 - INFO - Repository meta-qcom-distro already contains main as commit 2026-02-13 10:36:33 - INFO - Repository meta-openembedded already contains master as commit 2026-02-13 10:36:33 - INFO - Repository meta-virtualization already contains master as commit 2026-02-13 10:36:33 - INFO - Repository meta-audioreach already contains master as commit 2026-02-13 10:36:33 - INFO - Repository meta-selinux already contains master as commit 2026-02-13 10:36:33 - INFO - Repository meta-updater already contains master as commit 2026-02-13 10:36:33 - INFO - Repository oe-core checked out to 983cb2171e53564bc9dd188136439f3e2ad9e188 2026-02-13 10:36:33 - INFO - Repository bitbake checked out to c16e7ba2088dcd119e93bad6cf22d9026ec1736b 2026-02-13 10:36:33 - INFO - Repository meta-yocto checked out to c23c19e0b300812bad314f1d0a901965315271ae 2026-02-13 10:36:33 - INFO - Repository meta-qcom-distro checked out to c902dc1e60f2aea45cf69879830e9bb062613f07 2026-02-13 10:36:33 - INFO - Repository meta-openembedded checked out to 3e3f0eac0f599e92442d8c6c0000eb961d8c4170 2026-02-13 10:36:33 - INFO - Repository meta-virtualization checked out to 28d26fd95397bf575e65fcca0cbb302b1e9bc7ff 2026-02-13 10:36:33 - INFO - Repository meta-audioreach checked out to 44c7cd7a46012d9b0d2595b7110f4a10dee41da0 2026-02-13 10:36:33 - INFO - Repository meta-selinux checked out to 54d455a48ef4a86615ccbfde68ad742b05433d3d 2026-02-13 10:36:33 - INFO - Repository meta-updater checked out to 835ad81bdb30326c542b5740cacad0e68ad8a8e2 2026-02-13 10:36:33 - INFO - To start the default build, run: bitbake -c build qcom-multimedia-image qcom-multimedia-proprietary-image qcom-container-orchestration-image Copy to clipboard To start the build for `qcom-multimedia-image`, run the following command from the KAS shell that appears after the preceding output: bitbake qcom-multimedia-image Copy to clipboard For more information, see [KAS documentation](https://kas.readthedocs.io/en/1.0/). To migrate OpenEmbedded layer to the KAS-based build as supported by Qualcomm Linux 2.0, create KAS CI files for the machine by referring to the following machine files: - `meta-qcom/ci/rb3gen2-core-kit.yml` - `meta-qcom/ci/qcm6490.yml` - `meta-qcom/ci/base.yml` Similarly, create KAS CI files for distro by referring to the following files: - `meta-qcom/ci/qcom-distro-prop-image.yml` - `meta-qcom/blob/master/ci/qcom-distro.yml` #### Set up CI with KAS using a sample repository To set up CI with KAS, use the following sample repo: [https://github.com/qualcomm-linux/meta-vendor-example](https://github.com/qualcomm-linux/meta-vendor-example) Note To set up your Yocto Project build environment, see [Yocto Project Reference Manual](https://docs.yoctoproject.org/ref-manual/index.html). To run a KAS-based build, do the following: 1. To install the KAS tool, run the following command: sudo pip3 install kas Copy to clipboard 2. To clone the `meta-vendor` layer, run the following command: git clone https://github.com/qualcomm-linux-stg/meta-vendor.git Copy to clipboard 3. To build using the KAS configuration for one of the supported boards, run the following command: kas build meta-vendor/ci/qcs9100-ride-sx.yml:meta-vendor/ci/qcom-distro.yml Copy to clipboard ### Qualcomm Linux 2.0 repo-manifest workflow A repo-manifest-based workflow is provided for Qualcomm Linux 2.0. The high-level changes in Qualcomm Linux 2.0 are as follows: - A repo is used for syncing meta layers from a manifest. > > > repo init -u https://github.com/qualcomm-linux/qcom-manifest -m .xml > repo sync > Copy to clipboard - The setup environment is used for generating the BitBake configuration. In Qualcomm Linux 2.0, the BitBake configuration is generated based on the `machine.yml` and `distro.yml` configuration files. Hence, the setup environment takes these configuration files as input. > > > source setup-environment --machine meta-qcom/ci/qcs9100-ride-sx.yml --distro meta-qcom/ci/qcom-distro.yml > Copy to clipboard - BitBake is manually invoked for building images. > > > bitbake > Copy to clipboard ### Build steps comparison The following table lists the key differences in build steps between Qualcomm Linux 1.0 and Qualcomm Linux 2.0: Table: Build steps comparison | Step | Qualcomm Linux 1.0 | Qualcomm Linux 2.0 | | --- | --- | --- | | Sync (no changes) | Uses `repo init -u https://github.com/qualcomm-linux/qcom-manifest -m .xml && repo sync`. | Uses `repo init -u https://github.com/qualcomm-linux/qcom-manifest -m .xml && repo sync`. | | Configure | Uses `MACHINE=qcs9100-ride-sx DISTRO=qcom-distro source setup-environment`. | Uses `source setup-environment --machine meta-qcom/ci/qcs9100-ride-sx.yml --distro meta-qcom/ci/qcom-distro.yml`. | | BitBake build (no changes) | Uses the BitBake <recipe>. | Uses the BitBake <recipe>. | ## Changes in overrides Qualcomm Linux 1.0 supports the `qcom-base-bsp` and `qcom-custom-bsp` overrides. It uses these overrides to do the following: - Use separate kernel trees for `qcom-base-bsp` and `qcom-custom-bsp` - Include different sets of recipe packages in the `rootfs` image - Include different sets of device tree binaries in `DTB.bin` These overrides aren’t supported in Qualcomm Linux 2.0. The following table lists the recipes supported in Qualcomm Linux 2.0: | `qcom-multimedia-image` | `qcom-multimedia-proprietary-image` | | --- | --- | | The `qcom-multimedia-image` recipe adds upstream packages to the `rootfs` generated. | The `qcom-multimedia-proprietary-image` recipe adds Qualcomm value-added packages to the `rootfs` generated. | For Qualcomm Linux 2.0, overrides aren’t used for the following reasons: > > > - Same kernel tree and kernel binary are used when > `qcom-multimedia-image` and `qcom-multimedia-proprietary-image` are built. > - Same device tree binary and device tree binary overlay are packed in the flattened image tree (FIT) image > generated when `qcom-multimedia-image` and `qcom-multimedia-proprietary-image` are built. Note If you’re using the `qcom-base-bsp` and `qcom-custom-bsp` overrides, discontinue using them in Qualcomm Linux 2.0. To migrate changes that use overrides in Qualcomm Linux 1.0, modify the implementation to use overrides, based on the following examples: Table: Overrides migration examples | Aspect | Override in Qualcomm Linux 1.0 | Qualcomm Linux 2.0 migration example | | --- | --- | --- | | MACHINEOVERRIDE | `qcom-base-bsp` | For any conditional inclusion that uses `qcom-base-bsp` in Qualcomm Linux 1.0 `meta-qcom-hwe`, it’s moved to `qcom-multimedia-image` in Qualcomm Linux 2.0.
For example, in Qualcomm Linux 1.0, the `meta-qcom-hwe/recipes-products/packagegroups/packagegroup-qcom-camera.bb` override is used as follows:


RDEPENDS:${PN}:qcom-base-bsp:qcm6490= "libcamera v4l-utils media-ctl yavta"
Copy to clipboard


In Qualcomm Linux 2.0, it’s moved to `recipes-products/packagegroups/packagegroup-qcom-test-pkgs.bb`, which is included in `recipes-products/images/qcom-multimedia-image.bb`; that is, the image that includes upstream components. | | MACHINEOVERRIDE | `qcom-custom-bsp` | For any conditional inclusion that uses `qcom-custom-bsp` in Qualcomm Linux 1.0 `meta-qcom-hwe`, it’s moved to `qcom-multimedia-proprietary-image` in Qualcomm Linux 2.0.
For example, in Qualcomm Linux 1.0, the `meta-qcom-hwe/recipes-products/packagegroups/packagegroup-qcom-camera.bb` override is used as follows:


RDEPENDS:${PN}:qcom-custom-bsp:qcs9100 = "camxcommon camxlib camx chicdk cameradlkm"
Copy to clipboard


In Qualcomm Linux 2.0, it’s moved to `recipes-products/images/qcom-multimedia-proprietary-image.bb`, that is, the image that includes Qualcomm software components. | | DISTROOVERRIDE | `qcom-custom-distro` | For any conditional inclusion that uses `qcom-custom-distro` in Qualcomm Linux 1.0 `meta-qcom-distro`, it’s moved to `qcom-multimedia-proprietary-image` in Qualcomm Linux 2.0.
For example, in Qualcomm Linux 1.0, the `meta-qcom-distro/recipes-products/packagegroups/packagegroup-qcom-multimedia.bb` override is used as follows:


RDEPENDS:${PN}:append:qcom-custom-distro = "\
packagegroup-qcom-fastcv \
packagegroup-qcom-graphics \
packagegroup-qcom-iot-base-utils \
packagegroup-qcom-video \
"
Copy to clipboard


In Qualcomm Linux 2.0, it’s moved to `recipes-products/images/qcom-multimedia-proprietary-image.bb`:



>
>
> CORE_IMAGE_BASE_INSTALL += " \
> camx-dlkm \
> camx-kodiak \
> camx-lemans \
> camx-nhx \
> camx-talos \
> iris-video-dlkm \
> kgsl-dlkm \
> libdiag-bin \
> qcom-adreno \
> qcom-sensors-binaries \
> "
> Copy to clipboard | ## Changes in machine configuration The following table lists the changes in the machine configuration names between Qualcomm Linux 1.0 and Qualcomm Linux 2.0: Table: Machine configuration updates | Machine name
in Qualcomm Linux 1.0 | Machine name
in Qualcomm Linux 2.0 | | --- | --- | | `qcs8275-iq-8275-evk.conf` | `iq-8275-evk.conf` | | `qcs9075-iq-9075-evk.conf` | `iq-9075-evk.conf` | | `qcs6490-rb3gen2-core-kit.conf` | `rb3gen2-core-kit.conf` | ## Changes in BitBake variables The following table lists the BitBake variables used in the machine configuration for Qualcomm Linux 1.0 and Qualcomm Linux 2.0: > > > Table: BitBake variables in Qualcomm Linux 1.0 and Qualcomm Linux 2.0 > > > | Qualcomm Linux 1.0 BitBake variables | Qualcomm Linux 2.0 BitBake variables | > | --- | --- | > | Uses `KERNEL_DEVICETREE` with the `qcom-base-bsp` and `qcom-custom-bsp` overrides. | Uses `KERNEL_DEVICETREE` for upstream device trees (DTs), and `LINUX_QCOM_KERNEL_DEVICETREE` for DTs that aren’t upstream and exist only in the `linux-qcom` kernels. | > | Uses `KERNEL_TECH_DTBOS` to overlay the device tree blob for overlay (DTBO) on the kernel device tree at build time. | The build-time overlays support isn’t required anymore as Qualcomm Linux 2.0 supports multi-DTB FIT images. For more information, see [Qualcomm Linux Yocto Guide](https://docs.qualcomm.com/doc/80-80022-27/topic/configure_and_secure_boot_with_systemd_boot_and_uki.html#multi-dtb-support). | > | Uses `DBG_CMDLINE` and `KERNEL_CMDLINE_EXTRA` in the `inc` file, which is added in the machine file. | Uses machine-specific kernel command-line. | > | Adds modules using `MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS`. | Adds modules using `packagegroup-qcom-boot-essential`. | ## Changes in Linux recipes Qualcomm Linux 2.0 supports a single kernel recipe and its corresponding real-time variant. The following table lists the Linux kernel recipe changes between Qualcomm Linux 1.0 and Qualcomm Linux 2.0: Table: Linux kernel recipe changes | Linux recipe in Qualcomm Linux 1.0 | Linux recipe in Qualcomm Linux 2.0 | | --- | --- | | `meta-qcom-hwe/recipes-kernel/linux/linux-qcom-base_6.6.bb` | `meta-qcom/recipes-kernel/linux/linux-qcom_6.18.bb` | | `meta-qcom-hwe/recipes-kernel/linux/linux-qcom-custom_6.6.bb` | `meta-qcom/recipes-kernel/linux/linux-qcom_6.18.bb` | | `meta-qcom-realtime/recipes-kernel/linux/linux-qcom-base-rt_6.6.bb` | `meta-qcom/recipes-kernel/linux/linux-qcom-rt_6.18.bb` | | `meta-qcom-realtime/recipes-kernel/linux/linux-qcom-custom-rt_6.6.bb` | `meta-qcom/recipes-kernel/linux/linux-qcom-rt_6.18.bb` | Note For Qualcomm Linux 2.0, only a single kernel tree is fetched from [qcom-next](https://github.com/qualcomm-linux/kernel/tree/qcom-next). This kernel tree is built for both the images: - `qcom-multimedia-image` provides a `rootfs` with the upstream stack. - `qcom-multimedia-proprietary-image` provides a `rootfs` with the Qualcomm-maintained components. ## Changes in image recipes The `meta-qcom-distro` layer supports all the image recipes used in Qualcomm Linux. Qualcomm Linux 2.0 introduces changes to how the image recipes are managed and organized, and no longer uses BitBake overrides in image recipes. The following table lists the image recipes defined in the `meta-qcom-distro open-embedded` layer. The naming convention of these image recipes and their evolution from Qualcomm Linux 1.0 has changed. For example: - The image recipes no longer use `DISTROOVERRIDES` to distinguish between package inclusion in the image. - `qcom-multimedia-proprietary-image` adds Qualcomm software components. Table: Changes in image recipes | Qualcomm Linux Version | Image recipes | Code snippet | | --- | --- | --- | | 1.0 | `qcom-multimedia-image` with use of bitbake OVERRIDES `qcom-custom-distro` | The following example shows the use of override in `packagegroup-qcom-multimedia`, which is included in `qcom-multimedia-image`:


RDEPENDS:${PN} = "\
gstreamer1.0 \
gstreamer1.0-plugins-base \
gstreamer1.0-plugins-good \
gstreamer1.0-plugins-bad \
gstreamer1.0-rtsp-server \
tensorflow-lite \

RDEPENDS:${PN}:append:qcom-custom-distro = "\
packagegroup-qcom-fastcv \
packagegroup-qcom-graphics \
packagegroup-qcom-iot-base-utils \
packagegroup-qcom-video \
"
Copy to clipboard


Here, the `qcom-custom-distro` override is used to conditionally include packagegroups. When you run `BitBake ` in a Qualcomm Linux 1.0 workspace, depending on whether the build environment is set up with `custom` or `base` override,
the `rootfs` content generated by `qcom-multimedia-image` changes. | | 2.0 | `qcom-multimedia-image` and `qcom-multimedia-proprietary-image` | If the `qcom-multimedia-proprietary-image` image is inspected, it requires `qcom-multimedia-image` and adds Qualcomm-maintained technology stacks on it.


require qcom-multimedia-image.bb
Copy to clipboard


CORE_IMAGE_BASE_INSTALL += " \
camx-dlkm \
camx-kodiak \
camx-lemans \
camx-nhx \
camx-talos \
iris-video-dlkm \
kgsl-dlkm \
libdiag-bin \
qcom-adreno \
qcom-sensors-binaries \
"
Copy to clipboard


The separated organization of image recipes shows how Qualcomm-maintained components are added to the `qcom-multimedia-proprietary-image` image. | ## Changes in reference distro configurations Qualcomm Linux 2.0 introduces changes in reference distro configurations. In Qualcomm Linux 1.0, the reference distros for `qcom-wayland` are in the [distro](https://github.com/qualcomm-linux/meta-qcom-distro/tree/scarthgap/conf/distro) folder. The following table lists the reference distros in Qualcomm Linux 2.0: Table: Qualcomm Linux 2.0 reference distros | Qualcomm Linux 2.0 reference distro | Description | | --- | --- | | `qcom-distro-sota` | Enables the OSTree framework for OS updates. If you’re using `qcom-wayland` in Qualcomm Linux 1.0, use this distro in Qualcomm Linux 2.0. | | `qcom-distro-catchall` | Enables the OSTree framework for OS updates and SELinux. If you’re using `qcom-wayland` with SELinux enabled in Qualcomm Linux 1.0, use this distro in Qualcomm Linux 2.0. | | `qcom-distro-selinux` | Enables the SELinux framework for security; doesn’t enable OSTree. | | `qcom-distro` | Enables package management on device; the default packaging style enabled in RPM Package Manager (RPM) with DNF front-end. | Last Published: May 12, 2026 [Previous Topic Qualcomm Linux 2.0 migration overview](https://docs.qualcomm.com/bundle/publicresource/80-80022-150/topics/migrate_overview.md) [Next Topic Changes in the Qualcomm Linux kernel](https://docs.qualcomm.com/bundle/publicresource/80-80022-150/topics/migrate-qualcomm-linux-kernel.md)