Skip to main content
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 layersQualcomm 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.0Corresponding OpenEmbedded layer in Qualcomm Linux 2.0Summary of changes in Qualcomm Linux 2.0Migration notes
meta-qcommeta-qcomFor 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-hwemeta-qcomThe 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-sdkmeta-qcomThe 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-realtimemeta-qcomThe 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-distrometa-qcom-distroThis 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
ParameterRepo-manifest workflowKAS workflow
Machine selectionControlled through the MACHINE environment variable.Defined in the machine.yml configuration file.
Distribution selectionControlled through the DISTRO environment variable.Defined in the distro.yml configuration file.
BSP flavorControlled 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
StepRepo-manifest workflowKAS workflow
  1. Sync layers.
Uses repo init + repo sync to fetch meta layers based on a manifest filekas 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_BSPkas build generates local.conf and bblayers.conf, based on machine.yml and distro.yml.
  1. Build the image.
Runs bitbake <target> to build the imagekas 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
SectionDescription
machineMachine name used in the build. Equivalent to setting MACHINE=<machine> in local.conf.
distroIndicates the distribution to be built. Equivalent to setting DISTRO=<distro> in local.conf.
reposDefines 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_headerAppends fragments to the local.conf generated . Equivalent to what setup-environment injects into local.conf in the repo-manifest workflow.
targetSpecifies 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:
  1. To install the KAS tool, run the following command: 
    sudo pip3 install kas
  2. To clone the meta-vendor-example layer, run the following command: 
    git clone https://github.com/qualcomm-linux/meta-vendor-example.git
  3. 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
StepQualcomm Linux 1.0Qualcomm 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.
ConfigureUses 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-imageqcom-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
    AspectOverride in Qualcomm Linux 1.0Qualcomm Linux 2.0 migration example
    MACHINEOVERRIDEqcom-base-bspFor 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.
    MACHINEOVERRIDEqcom-custom-bspFor 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.
    DISTROOVERRIDEqcom-custom-distroFor 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.0Machine name in Qualcomm Linux 2.0
qcs8275-iq-8275-evk.confiq-8275-evk.conf
qcs9075-iq-9075-evk.confiq-9075-evk.conf
qcs6490-rb3gen2-core-kit.confrb3gen2-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 variablesQualcomm 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.0Linux recipe in Qualcomm Linux 2.0
meta-qcom-hwe/recipes-kernel/linux/linux-qcom-base_6.6.bbmeta-qcom/recipes-kernel/linux/linux-qcom_6.18.bb
meta-qcom-hwe/recipes-kernel/linux/linux-qcom-custom_6.6.bbmeta-qcom/recipes-kernel/linux/linux-qcom_6.18.bb
meta-qcom-realtime/recipes-kernel/linux/linux-qcom-base-rt_6.6.bbmeta-qcom/recipes-kernel/linux/linux-qcom-rt_6.18.bb
meta-qcom-realtime/recipes-kernel/linux/linux-qcom-custom-rt_6.6.bbmeta-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 VersionImage recipesCode snippet
1qcom-multimedia-image with use of bitbake OVERRIDES qcom-custom-distroThe 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.
2qcom-multimedia-image and qcom-multimedia-proprietary-imageIf 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 distroDescription
qcom-distro-sotaEnables 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-catchallEnables 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-selinuxEnables the SELinux framework for security; doesn’t enable OSTree.
qcom-distroEnables package management on device; the default packaging style enabled in RPM Package Manager (RPM) with DNF front-end.