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
Board support package (BSP) layers: `meta-qcom`, `meta-qcom-hwe`, `meta-qcom-qim-product-sdk`, and `meta-qcom-realtime` Reference distro layer: `meta-qcom-distro` Optional BSP layer for registered users: `meta-qcom-extras`	BSP layer: `meta-qcom` Reference distro layer: `meta-qcom-distro` Optional BSP layer for registered users: `meta-qcom-extras`

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 provides all BSP recipes for Qualcomm Linux 2.0. It is compatible with the Yocto Project Wrynose and Master releases.
`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_<you-layer> "qcom-hwe"`
`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_<you-layer> "qti-qim-product-sdk"`
`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_<you-layer> "qcom-realtime"`
`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`.

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 <config.yml> does the following:
- Clones the layer repositories
- Sets up the environment
- Starts the BitBake <image>
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-multimedia-image.yml` includes upstream sources. `qcom-distro.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
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.
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`.
Build the image.	Runs `bitbake <target>` 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.

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

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

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

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=<machine>` in `local.conf`.
distro	Indicates the distribution to be built. Equivalent to setting `DISTRO=<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 <target>` 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/<machine-name>.yml:meta-qcom/ci/<distro-name>.yml

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/<machine-name>.yml:meta-qcom/ci/<distro-name>.yml

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

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

For more information, see KAS documentation. To migrate you 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.yml
meta-qcom/blob/master/ci/qcom-distro-multimedia-image.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 Note To set up your Yocto Project build environment, see Yocto Project Reference Manual. To run a KAS-based build, do the following:

To install the KAS tool, run the following command:
sudo pip3 install kas

To clone the meta-vendor-example layer, run the following command:

git clone https://github.com/qualcomm-linux/meta-vendor-example.git

To build using the KAS configuration for one of the supported boards, run the following command:
kas build meta-vendor-example/ci/qcs9100-ride-sx.yml:meta-vendor-example/ci/qcom-distro.yml

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 <manifest-release-tag>.xml
repo sync

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
BitBake is manually invoked for building images.
bitbake <image-recipe>

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 <manifest-release-tag>.xml && repo sync`.	Uses `repo init -u https://github.com/qualcomm-linux/qcom-manifest -m <manifest-release-tag>.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 is 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:$:qcom-base-bsp:qcm6490= “libcamera v4l-utils media-ctl yavta” 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:$:qcom-custom-bsp:qcs9100 = “camxcommon camxlib camx chicdk cameradlkm” 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:$:append:qcom-custom-distro = ”\ packagegroup-qcom-fastcv \ packagegroup-qcom-graphics \ packagegroup-qcom-iot-base-utils \ packagegroup-qcom-video \ “ 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 \ “

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 upstreamed 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.
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. 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

Table: Changes in image recipes
Qualcomm Linux Version	Image recipes	Code snippet
1	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:$ = ”\ gstreamer1.0 \ gstreamer1.0-plugins-base \ gstreamer1.0-plugins-good \ gstreamer1.0-plugins-bad \ gstreamer1.0-rtsp-server \ tensorflow-lite \ RDEPENDS:$:append:qcom-custom-distro = ”\ packagegroup-qcom-fastcv \ packagegroup-qcom-graphics \ packagegroup-qcom-iot-base-utils \ packagegroup-qcom-video \ “ Here, the qcom-custom-distro override is used to conditionally include packagegroups. When you run BitBake <image> 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	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 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 \ “ 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 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.

Introduction

Architecture

Key Documents

Technologies

System

Release Notes

Changes in the OpenEmbedded layers and the build system

Changes in OpenEmbedded layers

Changes in Qualcomm Linux 2.0 build system

KAS overview

Sample KAS configuration file

base.yml

machine.yml

distro.yml

Run builds using KAS-based build system

Set up CI with KAS using a sample repository

Qualcomm Linux 2.0 repo-manifest workflow

Build steps comparison

Changes in overrides

Changes in machine configuration

Changes in BitBake variables

Changes in Linux recipes

Changes in image recipes

Changes in reference distro configurations

​Changes in OpenEmbedded layers

​Changes in Qualcomm Linux 2.0 build system

​KAS overview

​Sample KAS configuration file

​base.yml

​machine.yml

​distro.yml

​Run builds using KAS-based build system

​Set up CI with KAS using a sample repository

​Qualcomm Linux 2.0 repo-manifest workflow

​Build steps comparison

​Changes in overrides

​Changes in machine configuration

​Changes in BitBake variables

​Changes in Linux recipes

​Changes in image recipes

​Changes in reference distro configurations

Changes in OpenEmbedded layers

Changes in Qualcomm Linux 2.0 build system

KAS overview

Sample KAS configuration file

base.yml

machine.yml

distro.yml

Run builds using KAS-based build system

Set up CI with KAS using a sample repository

Qualcomm Linux 2.0 repo-manifest workflow

Build steps comparison

Changes in overrides

Changes in machine configuration

Changes in BitBake variables

Changes in Linux recipes

Changes in image recipes

Changes in reference distro configurations