将功能迁移到 Qualcomm Linux 2.0 - Qualcomm Dragonwing Documentation

Qualcomm Linux 2.0 引入了影响平台架构和运行时行为的系统级更改。要将功能从 Qualcomm Linux 1.0 迁移到 Qualcomm Linux 2.0，请考虑以下主要更新和改进。

分区布局

Qualcomm Linux 2.0 支持一种更新后的分区布局管理方法。作为 Qualcomm Linux 2.0 支持的 meta-qcom 层的一部分，分区布局不再打包在 boot-binaries 归档中的 partition.xml，而是维护在 qcom-ptool 仓库中，并在构建 machine 时在 meta-qcom 中使用。 meta-qcom/conf/machine/iq-9075-evk.conf 中的 QCOM_PARTITION_FILES_SUBDIR 配置变量会选择相应的平台目录，例如 platforms/iq-9075-evk/ufs/partitions.conf，此输入被传递给 ptool 配方（qcom-ptool_git.bb）以生成最终的分区布局。有关如何管理分区布局的说明，请参阅 Qualcomm Linux Yocto Guide。

容器与编排更新

启用 Docker 和 Docker-compose 的流程已得到简化。qcom-multimedia-image 镜像现在包含来自 meta-virtualization 层的上游 packagegroup-container，而不再使用 Qualcomm 定义的容器 packagegroup。Docker 所需的所有内核依赖项已在 Qualcomm 内核树中启用，因此您无需运行兼容性脚本或修改内核配置。 Kubernetes 的启用方式已重新设计，并与多媒体镜像解耦。Kubernetes 现在不再通过 packagegroup-qcom-k8s 启用，而是通过构建一个名为 qcom-container-orchestration-image 的全新专用镜像来启用。该配方位于 meta-qcom-distro/recipes-products/images/qcom-container-orchestration-image.bb。新镜像使用来自 meta-virtualization layer 的上游 Kubernetes 和容器编排软件包。

迁移设备树和设备树 overlay

Qualcomm Linux 1.0 支持级联式（concatenated）multi-DTB，而 Qualcomm Linux 2.0 支持基于 FIT 的 multi-DTB。 Qualcomm Linux 1.0 将 machine 配置中列出的所有 DTB 依次追加，以生成组合 DTB。生成的虚拟文件分配表（VFAT）镜像 dtb.bin 包含该组合 DTB 镜像。dtb.bin 镜像被刷写到 Qualcomm 开发套件上的专用分区 dtb。统一可扩展固件接口（UEFI）解析 dtb 分区中的组合 DTB，并为硬件选择匹配的 DTB。 Qualcomm Linux 2.0 使用 KERNEL_DEVICETREE 变量中列出的所有 DTB 和 DTBO 文件生成 FIT 镜像。FIT 要求为各配置定义相应的 compatible 字符串。例如，对于 conf/machine/rb3gen2-core-kit.conf 中的 qcom/qcs6490-rb3gen2.dtb DTB，在 conf/machine/include/fit-dtb-compatible.inc 中为该 DTB 定义了 compatible qcom,qcs6490-iot，如下所示：

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

同样，为 qcom/qcs9100-ride.dtb 定义了 compatible qcom,qcs9100-qam，如下所示：

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

这些示例展示了如何在 Qualcomm Linux 2.0 中为 DTB 定义 compatible 字符串。请对您设备的 DTB 应用相同的方法。如果某个 compatible 字符串映射到 DTB 与 DTBO 的组合，您可以在 conf/machine/include/fit-dtb-compatible.inc 中相应地定义 FIT_DTB_COMPATIBLE。例如，compatible 字符串 qcom,qcs5430-iot-subtype2 映射到 qcs6490-rb3gen2.dtb 和 qcs6490-rb3gen2-vision-mezzanine.dtbo。示例如下：

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

您必须将 Qualcomm Linux 1.0 中的级联式 DTB 和构建时 DTB overlay 支持迁移到 Qualcomm Linux 2.0 中基于 FIT 的 multi-DTB 和启动时 DTB overlay。Qualcomm Linux 2.0 不要求您区分 base 和 custom DTB 组。在 Qualcomm Linux 1.0 中，DTB 和 DTB overlay 的管理方式如以下代码片段所示。KERNEL_TECH_DTBOS[dtb-name] 中列出的 DTB overlay 会在构建时与 dtb-name 合并，所有这些合并后的 DTB 会前后级联以生成组合 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 \
    "

在 Qualcomm Linux 2.0 中，DTB 和 DTB overlay 的管理方式如以下代码片段所示。KERNEL_DEVICETREE 和 LINUX_QCOM_KERNEL_DEVICETREE 中列出的 DTB 和 DTB overlay 会打包在生成的 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 \
                      "

FIT 镜像的 configurations 部分会按照 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 \
    "

Qualcomm Linux 2.0 中的 UEFI 增强功能

Qualcomm Linux 2.0 中的 UEFI 增强功能支持基于 FIT 的 DTB 和 DTBO 管理。 UEFI 通过匹配 compatible 字符串，为其正在引导的平台选择合适的 DTB 或 DTB + DTBO 组合。为了派生这些 compatible 字符串，UEFI 会解析存储在 FIT 镜像中的元数据 blob。UEFI 将派生出的 compatible 字符串与配置中定义的字符串进行匹配。有关元数据的更多信息，请参阅 Qualcomm DTB 元数据。典型配置如下：

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";
   };
};

下表比较了 Qualcomm Linux 1.0 与 Qualcomm Linux 2.0 中的 UEFI： 表：Qualcomm Linux 1.0 与 Qualcomm Linux 2.0 中的 UEFI 对比

方面	Qualcomm 1.0 中的 UEFI 功能	Qualcomm 2.0 中的 UEFI 功能
UEFI 处理的对象	级联式 DTB，即由多个 DT blob 组合而成的 blob。	结构化标准容器，基于 FIT 的 DTB 和 DTB overlay。
解析、匹配和选择方法	定制的、平台特定的 UEFI 代码，固件扫描 blob，匹配 SoC/board ID，使用硬编码逻辑	UEFI 中的通用 FIT 解析器。UEFI 枚举 FIT 节点，并将 FIT 节点中的 compatible 字符串与由元数据组成的字符串进行匹配。
偏移量处理	定制的偏移量计算，以从组合 DT blob 中识别各个 DT blob；依赖顺序和大小	基于节点的选择，与大小和顺序无关
DT overlay 支持	否	通过 FIT 提供原生 DTB overlay 支持
添加新 DTB	需要固件感知和验证	无需固件更改
标准对齐	否，下游逻辑	与上游对齐（U‑Boot、Linux 和 UEFI）

Qualcomm DTB 元数据概述

Qualcomm DTB 元数据是一个公开的 GitHub 项目，提供以下内容：

基于 FIT 的 DTB 打包/选择规范。
qcom-metadata.dts 源文件，编译为固件使用的元数据 DTB，用于将硬件标识符匹配到某个 FIT 配置。

Qualcomm DTB 元数据包含以下内容：

元数据定义源文件（qcom-metadata.dts），它将允许的 compatible 字符串后缀标记（token）分组到多个节点中，如 soc、soc-sku、board、board-subtype-*、softsku 和 oem。
参考 FIT ITS 模板（例如 qcom-fitimage.its 和 qcom-next-fitimage.its），其中每个配置声明以下内容：
- compatible qcom,<soc>-<...suffixes...> 字符串
- 要按顺序应用的基础 DTB 和可选 overlay

固件使用 qcom-dtb-metadata 读取以下内容：

硬件 ID（芯片 ID/版本、CDT 板卡数据、检测到的存储、DDR 大小等）
编译后的元数据 DTB
FIT 配置，以选择其 compatible 标记与元数据定义和硬件上报内容相匹配的配置

使用 `qcom-dtb-metadata` 的优势

qcom-dtb-metadata 仓库是一种与上游对齐、被广泛接受的机制（FIT），用于在单个发布版本必须支持多种 SoC/板卡时支持动态设备树选择。与 multi-DTB 解决方案相比，qcom-dtb-metadata 仓库的优势如下：

标准容器和结构化选择
- FIT 是一种成熟且被广泛使用的格式。它支持在单个镜像中包含多个配置。
- 该设计强制要求 compatible 字符串后缀在元数据中定义，防止在未更新规范的情况下使用来历不明的标记。
构建时验证以防止不匹配
- 通过构建时检查来检测 FIT compatible 后缀与元数据定义之间的差异。
与 multi-DTB+DTBO 工作流兼容
- Qualcomm DTB 元数据文档描述了基础 DTB+overlay。也就是说，运行时 overlay 参数（例如 CamX 和 EL2KVM）由检查脚本特殊处理，因为它们由运行时控制而非元数据定义。
Qualcomm 固件集成细节
- 当前的 Qualcomm UEFI 固件仅支持外部 FIT。
  - mkimage -E -B 8（外部数据 + 8 字节对齐）
  - 硬编码的文件名要求：qclinux_fit.img

FIT 配置和元数据配对条目

FIT 配置条目是 ITS 中的一个配置，包含以下内容：

Compatible：qcom,<tokens...>

对 FDT 的引用：fdt-<board>.dtb（以及可选的 overlay）

元数据条目描述了每个标记的含义。compatible 字符串中使用的标记必须以子节点的形式存在于相应的元数据组节点之下。Qualcomm DTB 元数据文档定义了固件比较的组和位字段。例如：

soc → msm-id：<chip-id chip-version>，包含芯片 ID/版本的位解释。

soc-sku → msm-id：其中某些位表示封装 ID/代工厂 ID。

board → board-id：包含类型（type）、主版本（major）和次版本（minor）的位定义。

board-subtype-* → board-subtype：根据子类型类别（外设子类型、存储类型或内存大小）使用不同的位段。

oem → oem-id

softsku → softsku-id

添加 QCS9100 板卡变体

要向 qcom-dtb-metadata 添加 QCS9100 板卡变体，请执行以下操作：

按照仓库中建议的模式，选择您要为该变体使用的标记（板卡版本、存储、内存等）。
对于您要在 compatible 字符串中使用的每个标记，确保在正确的组（soc、board、board-subtype-* 等）下存在对应的子节点。如果引入了新的后缀，请将其添加到元数据中的相关节点下。
在 conf/machine/include/fit-dtb-compatible.inc 中添加 FIT_DTB_COMPATIBLE["key"] 条目。
使用构建命令，用更新后的元数据 DTB 构建 FIT 镜像。
为期望应用这些 FIT 更改的 machine 刷写 .qcomflash/ 目录。
启动时，验证日志中是否显示新添加的 compatible。UEFI 启动日志会打印以下内容：
- ParseFitDt：来自 BoardParam 日志行的配置，其组成部分构成了您添加的 compatible
- FitLoadDtbFromFdt：您已映射到您的 compatible 的配置 fdt-<DTB>

固件管理的更改

Qualcomm Linux 1.0 支持 meta-qcom-hwe 中的固件配方。meta-qcom-hwe/recipes-firmware/firmware 固件配方从 Qualcomm® Software Center 获取固件二进制文件。 Qualcomm Linux 2.0 使用来自 oe-core 中 linux-firmware 配方的上游固件。由 oe-core 中 linux-firmware 配方定义的软件包被包含在 meta-qcom 的 machine 配置文件中。

不再支持的配方和相关软件组件

Qualcomm Linux 1.0 中的以下配方和软件组件在 Qualcomm Linux 2.0 中不受支持：

property-vault_1.0.bb

syslog-plumber_1.0.bb

音频的更改

音频在 OpenEmbedded 元数据层组织方面的更改如下：在 Qualcomm Linux 1.0 中，与 AudioReach 相关的配方是 meta-qcom-hwe 的一部分。在 Qualcomm Linux 2.0 中，它们是 meta-audioreach OpenEmbedded 层的一部分。配方更改如下：

AudioReach 1.0 的配方使用 qcom-* 命名约定，而 AudioReach 2.0 的配方使用 audioreach-*。例如，AudioReach 1.0 中的 qcom-args 现在在 AudioReach 2.0 中为 audioreach-graphservices。
音频软件包名称已从 packagegroup-qcom-audio 更改为 packagegroup-audioreach。
为下游驱动程序新增了一个配方 audioreach-kernel。

设备树和驱动程序的更改

Qualcomm Linux 1.0 依赖多个特定于配置的 DT 音频节点。 Qualcomm Linux 2.0 引入了一个单一、统一的 DT 音频配置，可在所有音频设置中复用。

音频设备树处理的更改

在 Qualcomm Linux 1.0 中，每个自定义音频配置都维护单独的 DT 音频节点。overlay 音频驱动程序基于各个 DT 节点进行探测（probe），这要求为不同的音频用例维护多个 DT 变体。在 Qualcomm Linux 2.0 中，所有配置都使用单一的通用 DT 音频节点。该节点被复用于探测和绑定 overlay 音频驱动程序，消除了冗余并降低了 DT 复杂性。

Qualcomm Linux 2.0 中设备树的更改

每个数字音频接口（DAI）链路使用显式平台绑定。sound 节点下的每个 DAI 链路现在都显式定义其平台 Qualcomm Hexagon Q6 DSP（Q6）音频处理管理器（APM）。新增了一个 Q6 APM DAI 容器。GPR 节点下也添加了一个 Q6 APM DAI 容器节点，为音频路由提供集中式的 DAI 定义。

Qualcomm Linux 2.0 中移除的设备树节点

以下节点已被移除，因为在统一 DT 和 overlay 探测模型下不再需要它们：

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

Overlay 驱动程序的更改

Overlay 驱动程序现在使用共享的 DT 音频节点进行探测。不再需要特定于配置的 DT 变体。在新架构中，overlay 探测不需要那些已移除的节点。

Audioreach 用户空间源代码组织的更改

AudioReach 源代码现在从 AudioReach/meta-audioreach GitHub 项目获取。用户空间 API 没有变化。

摄像头的更改

从 Qualcomm Linux 1.0 升级到 Qualcomm Linux 2.0 时，请考虑以下摄像头方面的更改。

OpenEmbedded 层中摄像头的更改

下表列出了 OpenEmbedded 层中摄像头动态可加载内核模块（DLKM）的更改： 表：摄像头 DLKM 更改

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

下表列出了 OpenEmbedded 层中摄像头设备树的更改： 表：摄像头 DTB 更改

Qualcomm Linux 1.0 层	Qualcomm Linux 2.0 层
`meta-qcom-hwe/recipes-multimedia/cameradtb/cameradtb_1.0.bb`	在 Qualcomm Linux 2.0 中，摄像头设备树更改已集成到内核树内（in-tree）。`meta-qcom/recipes-kernel/linux/linux-qcom_6.18.bb`

下表列出了 OpenEmbedded 层中摄像头固件的更改： 表：摄像头固件更改

SoC	Qualcomm Linux 1.0 层	Qualcomm Linux 2.0 层
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	不适用	`meta-qcom /recipes-bsp/firmware/camxfirmware-talos_1.0.0.bb`

下表列出了 OpenEmbedded 层中 CamX 用户空间的更改： 表：CamX 用户空间更改

SoC	Qualcomm Linux 1.0 层	Qualcomm Linux 2.0 层
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	不适用	`meta-qcom /dynamic-layers/openembedded-layer/recipes-multimedia/camx/camxlib-talos_1.0.2.bb`
COMMON	不适用	`meta-qcom /recipes-multimedia/camx/camxcommon-headers_1.0.1.bb`

注意 Qualcomm Linux 2.0 中未启用 meta-qcom-extras 配方。

摄像头设备树从 Qualcomm Linux 1.0 迁移到 Qualcomm Linux 2.0

在 Qualcomm Linux 2.0 中，摄像头设备树更改已集成到内核树内（in-tree），位于内核源码中的 arch/arm64/boot/dts/qcom/。这些更改作为 Qualcomm Linux 2.0 中 linux-qcom 配方的一部分被包含。下表列出了各目标特定的摄像头设备树源文件。对于每个目标，DT 源文件先包含摄像头 SoC，然后是摄像头传感器。 表：目标特定的摄像头设备树源文件

目标	Qualcomm Linux 1.0 摄像头子系统 SoC DT 和摄像头传感器设备树 DT	Qualcomm Linux 2.0 摄像头子系统 SoC DT 和摄像头传感器设备树 DT
QCS6490	`qcm6490-camera-rb3.dtsiqcm6490-camera-sensor-rb3.dtsi`	`qcs6490-camera.dtsiqcs6490-rb3gen2-camera-sensor.dtsi`
QCS9075	`qcs9075-camera-iq-9075-evk.dtsiqcs9075-camera-sensor-iq-9075-evk.dtsi`	`lemans-camera.dtsilemans-camera-sensor.dtsi`
QCS8275	`qcs8275-camera-iq-8275-evk.dtsiqcs8275-camera-sensor-iq-8275-evk.dtsi`	`monaco-camera.dtsimonaco-camera-sensor.dtsi`
QCS615	不适用	`talos-camera.dtsitalos-camera-sensor.dtsi`

注意 overlay 摄像头 DTBO 是通过将摄像头子系统 SoC 设备树与摄像头传感器设备树组合而创建的。摄像头以 overlay 方式叠加在基础（base）之上。下表列出了摄像头 overlay。对于每个目标，DT 二进制文件包含基础 DT，随后是摄像头 overlay DTBO： 表：基础 DTB 和摄像头 overlay DTBO

目标	Qualcomm Linux 1.0 基础 DTB 和摄像头 overlay DTBO	Qualcomm Linux 2.0 基础 DTB 和摄像头 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	不适用	`talos-evk.dtb` `talos-evk-camx.dtbo`

用于编译摄像头 DTS 的 BitBake 命令

下表列出了用于编译摄像头 DTS 的 BitBake 命令： 表：摄像头设备树编译命令

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

摄像头 DLKM 从 Qualcomm Linux 1.0 迁移到 2.0

摄像头 DLKM 的配方名称和源代码路径在 Qualcomm Linux 2.0 中已更改。在 Qualcomm Linux 1.0 中，配方名称为 cameradlkm。在 Qualcomm Linux 2.0 中，它已重命名为 camx-dlkm，并且源代码路径也已更改。下表列出了修改摄像头 DLKM 源代码的命令： 表：修改摄像头 DLKM 源代码的命令

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

下表列出了基于目标平台的摄像头 DLKM 源代码位置：

表：目标特定的摄像头 DLKM 源代码位置
目标	Qualcomm Linux 版本	源代码位置
QCS6490	1	$/build-qcom-wayland/workspace/sources/cameradlkm/qcom/ opensource/camera-kernel/camera-kt/
2	$/build/workspace/sources/camx-dlkm/camera-kt/
QCS9075 QCS8275 QCS615	1	$/build-qcom-wayland/workspace/sources/cameradlkm/qcom/ opensource/camera-kernel/camera/
2	$/build/workspace/sources/camx-dlkm/camera/

下表列出了用于编译摄像头 DLKM 源代码的 BitBake 命令：

摄像头 DLKM 编译命令
Qualcomm Linux 1.0	Qualcomm Linux 2.0
bitbake cameradlkm	bitbake camx-dlkm

CamX 用户空间源代码组织的更改

在 Qualcomm Linux 2.0 中，CamX 用户空间二进制文件通过 meta qcom 配方提供。CamX 用户空间源代码位于 meta qcom extras 中，目前尚未在 Qualcomm Linux 2.0 主线中启用。

启用摄像头功能

Qualcomm Linux 2.0 的 qcom-multimedia-proprietary-image 默认安装下游摄像头软件包，但不启用摄像头功能。要为 qcom-multimedia-proprietary-image 启用摄像头功能，请在设备 shell 中运行以下命令：

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

有关更多信息，请参阅使用 overlay 配置派生镜像配方。

显示的更改

显示在 OpenEmbedded 元数据层组织方面的更改如下：在 Qualcomm Linux 1.0 中，用于 Yocto 的 GBM 后端使用 meta-qcom-hwe 中单独的镜像源仓库。meta-qcom-hwe OpenEmbedded 层使用 msm_be.bb 配方，该配方获取 Mesa 22.04 并为后端应用补丁。编译由基于图形驱动程序的 packagegroup 启用。在 Qualcomm Linux 2.0 中，msm-gbm-backend.bb 配方在 meta-qcom 中处理 GBM 后端，从 CodeLinaro 获取源代码。它在编译时添加了从 qcom-adreno 到 msm-gbm-backend 的运行时依赖。

图形的更改

升级到 Qualcomm Linux 2.0 时，请考虑 KMD 和用户模式驱动程序（UMD）组件中图形所需的以下更改。 KMD 中进行了以下更改：

统一的设备树架构
从 Qualcomm^® Adreno^™ GPU TZ governor 过渡到用于 GPU 动态时钟和电压调节（DCVS）的 Simple On‑Demand governor
内核图形支持层（KGSL）驱动程序分发工作流的更新

UMD 中进行了以下更改：

重构的 OpenEmbedded 元数据层
重新组织的配方
修订后的头文件使用方式
更新的固件处理
集成 OpenGL Vendor-Neutral Dispatch (GLVND)，以提供厂商中立的用户空间接口

这些修改在 Qualcomm Linux 2.0 中带来以下好处：

简化维护
与上游 Yocto 实践对齐
精简的图形栈

图形在 OpenEmbedded 元数据层组织方面的更改如下：

重新组织的元数据层

在 Qualcomm Linux 2.0 中，与图形相关的 OE 元数据得到了整合。之前位于 meta-qcom-hwe 中的图形配方现已移至 meta-qcom。好处如下：

更易于维护
图形构建产物的单一可信来源
与上游 Yocto 层结构对齐

更新后的 Adreno 配方

Adreno 图形配方现在位于 meta-qcom/recipes-graphics/adreno/。请更新您的构建配置，改为引用 meta-qcom 中的配方，而非 meta-qcom-hwe。

移除导出的图形用户空间头文件

厂商图形配方不再导出以下头文件：

EGL
OpenGL/OpenGL ES
OpenCL

新的头文件使用模型如下：

EGL、OpenGL 和 OpenGL ES：由 GLVND include 路径提供
OpenCL：由 OpenCL loader 提供
Adreno 特有的 OpenCL 扩展：仅 cl_ext_qcom.h 由 Adreno 软件包提供

好处如下：

跨厂商一致的 API 接口
提升应用程序可移植性
减少特定于厂商的耦合

对应用程序的影响如下：

应用程序必须更新 include 路径，以依赖 GLVND 和 OpenCL loader 头文件
不再支持直接依赖厂商导出的头文件

下表列出了各 API 及其相应的头文件来源： 表：Qualcomm Linux 2.0 中的 API 和头文件来源

API	Qualcomm Linux 2.0 中的头文件来源
EGL	GLVND
OpenGL/OpenGL ES	GLVND
OpenCL	OpenCL loader
Adreno OpenCL 扩展	`cl_ext_qcom.h`（Adreno 软件包）

更新后的 KGSL 配方

KGSL 驱动程序的分发和获取机制在 Qualcomm Linux 2.0 中已更新。源代码现在通过 GitHub 上的只读开发模型进行管理。仓库详情如下：

源仓库：github.com/qualcomm-linux/kgsl
分支：gfx-kernel.le.0.0
开发模型：私有、封闭

在集成方面，KGSL 配方直接从仓库获取源代码。该配方位于 kgsl-dlkm_git.bb。

固件处理的更改

在 Qualcomm Linux 1.0 中，固件二进制文件作为 Adreno 图形配方的一部分提供。在 Qualcomm Linux 2.0 中，固件不再随 Adreno 图形栈一起提供。您必须从 Linux 固件仓库获取。注意请确保在创建根文件系统时存在相应的 Qualcomm 固件文件。注意固件的打包和部署必须独立于图形配方进行处理。

Overlay 启用

用户空间图形栈使用 GLVND。它为以下项目提供厂商中立的分派（dispatch）：

OpenGL
EGL
GLX

GLVND 在应用程序和厂商特定的图形库之间引入了一个 loader 层。

链接和运行时行为的更改

启用 GLVND 后，应用程序不再直接链接到厂商特定的 EGL/GLES 库，而是链接到 GLVND 库。厂商库在运行时被动态选择和加载。

安装的组件

在 Qualcomm Linux 2.0 中，图形部分安装以下组件：

GLVND 核心库
仅厂商特定的 EGL/GLES loader 库

厂商选择通过可安装客户端驱动程序（ICD）JSON 文件控制。

Adreno ICD

Adreno 提供 10_EGL_adreno.json ICD 文件。GLVND 使用该文件在运行时选择 Adreno 厂商实现。

应用程序级别的影响

由于 GLVND 存在于应用程序和厂商库之间，应用程序级别的影响如下：

应用程序必须使用 eglGetProcAddress() 获取扩展 API。
静态链接到厂商特定符号的方式不再有效。
厂商库选择在运行时根据 ICD 优先级进行。

环境变量和 overlay 行为

GLVND 环境控制

可以使用环境变量控制和调试 GLVND 的行为。

通过环境变量选择厂商

当存在多个厂商或 overlay 时，GLVND 使用 __EGL_VENDOR_LIBRARY_FILENAMES 变量。该变量显式指定 GLVND 必须使用哪些 ICD 文件。例如，以下命令强制 GLVND 在运行时选择 Adreno 厂商实现：

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

为内核模块启用 overlay

要启用 overlay 配置，需要调整一个特定的模块参数。skip_gpu DRM 模块参数在标准配置（Config #1）中默认为 0。对于 overlay 支持（Config #2），该参数被设置为 1，随后加载 msm_kgsl 模块。在 Config #2 中，overlay 通过 asoc-blacklist.conf 启用。文件路径为 /etc/modprobe.d/asoc-blacklist.conf。

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

上游和统一设备树

在 Qualcomm Linux 2.0 中，KGSL 驱动程序已升级以支持上游设备树。因此，上游设备树现在同时兼容 DRM 和 KGSL 驱动程序。与 Qualcomm Linux 1.0 不同，这种统一消除了为 DRM 和 KGSL 分别维护 Base 和 Custom DT 的需要。主要更改如下：

配方弃用：在向 meta-qcom 2.0 过渡的过程中，不再需要 Qualcomm Linux 1.0 中用于维护下游 DT 的独立配方（qcom-graphicsdevicetree_git.bb）。
统一维护：这一转变通过消除单独 DT 维护工作流的需求，简化了开发流程。

GPU DCVS governor 过渡

GPU DCVS governor 的实现经历了重大修改：

Qualcomm Linux 1.0 使用 Adreno TZ governor。
Qualcomm Linux 2.0 过渡到上游的 Simple On-Demand governor。

影响如下：

性能：Simple On-Demand governor 提供更高的性能效率。
功耗：作为性能提升的权衡，功耗可能略有增加。

Qualcomm^® Intelligent Multimedia (IM) SDK 的更改

Qualcomm IM SDK 在 OpenEmbedded 元数据层组织方面的更改如下。

GStreamer 插件配方

在 Qualcomm Linux 1.0 中，每个 GStreamer 插件都有一个配方文件。在 Qualcomm Linux 2.0 中，它们被整合如下：

单一配方 gst-plugins-imsdk_git.bb 现在负责所有 GStreamer 插件的编译。
配方虽已统一，但每个插件仍会生成独立的软件包。这确保您仍然可以按需仅安装特定的插件软件包，而无需使用全部插件。

在 Qualcomm Linux 1.0 中，插件以构建产物形式提供，您需要使用安装脚本进行安装。在 Qualcomm Linux 2.0 中，刷写构建后，插件已打包在镜像中，无需单独安装。

摄像头服务配方更新

camera-server.bb 已重命名为 camera-service.bb。更新后的配方现在从 GitHub 获取源代码，与上游最佳实践保持一致。该配方生成多个子软件包，例如 client、common 和目标特定的库。因此，qtiqmmfsrc GStreamer 插件仅依赖 client 软件包，而非整个服务。这种模块化使其能够与其他层和组件进行更清晰的集成。

`qcom-multimedia-image` 中包含的插件

qcom-multimedia-image 包含所有标准 GStreamer 插件，但以下依赖专有库的插件除外：

qtimlqnn
qtimlsnpe
qtismartvencbin
qtiqmmfsrc

`qcom-multimedia-proprietary-image` 中包含的插件

专有镜像包含所有插件，包括专有插件。这确保了在需要专有依赖项可用的开发、调试和产品构建中提供完整功能。

已弃用的 QIM 插件

以下下游插件在 Qualcomm Linux 2.0 中已弃用：

qtimlvclassification
qtimlvdetection
qtimlvpose
qtimlvsuperresolution
qtimlvsegmentation
qtimlaclassification

qtiqmmfsrc 插件属性基于 SoC 从摄像头元数据中填充，而不是使用固定的硬编码值。

示例应用程序的更改

Qualcomm Linux 2.0 采用标准化、与 machine 无关的方式来编译示例应用程序。它将开发环境从目标特定的工具链转变为构建工具独立安装程序（standalone installer），使构建工具与特定设备镜像解耦。Qualcomm Linux 2.0 使用 RPM 打包而非 OPKG，因为 RPM 与标准打包机制对齐，并提供更强的软件包和依赖管理。注意除打包更新外，迁移到 Qualcomm Linux 2.0 不需要对现有示例应用程序进行任何其他更改。下表列出了 Qualcomm Linux 1.0 和 Qualcomm Linux 2.0 中示例应用程序支持的主要区别： 表：示例应用程序对比

方面	Qualcomm Linux 1.0	Qualcomm Linux 2.0
SDK 类型	machine 特定的 eSDK	适用于所有 machine 的单一 eSDK
eSDK 脚本	`qcom-wayland-x86_64-qcom-multimedia-image-armv8-2a-<machine>-toolchain-ext-1.7-Ver.1.1.sh`	`qcom-distro-aarch64-qcom-multimedia-proprietary-image-armv8a-qcom-armv8a-toolchain-ext-2.0.sh`
安装更新后应用程序的命令	生成 `opkg --force-reinstall install.ipk`。	生成 `dnf install.rpm`。
应用程序可安装软件包的路径	`<workspace_root>/tmp/deploy/ipk/armv8-2a/`	`<workspace_root>/tmp/deploy/rpm/armv8a`
下载现有示例应用程序源代码的命令和示例路径	命令：`devtool modify qcom-gst-camera-single-stream-example` 示例路径：`workspace_root>/workspace/sources/qcom-gst-camera-single-stream-example`	命令：`devtool modify gst-plugins-imsdk` 示例路径：`<workspace_root>/workspace/sources/gst-plugins-imsdk/gst-sample-apps`
构建命令示例	`devtool build qcom-gst-camera-single-stream-example` `devtool package qcom-gst-camera-single-stream-example`	`devtool build gst-plugins-imsdk` `devtool package gst-plugins-imsdk`

有关更多信息，请参阅：

视频的更改

视频在 OpenEmbedded 元数据层组织方面的更改如下：

视频驱动程序配方已重命名并从 meta-qcom-hwe 移至 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
视频固件配方已从 meta-qcom-hwe 迁移到标准 Linux 固件配方。
- Qualcomm Linux 1.0：qcom-video-firmware_1.0.bb
- Qualcomm Linux 2.0：OpenEmbedded-core 中的 linux-firmware_<version>.bb
视频设备树配置已从早期的 overlay DT 迁移到主线内核中已有的 DT。
- Qualcomm Linux 1.0：qcom-videodtb_1.0.bb
- Qualcomm Linux 2.0：DT 是主线内核 DT 的一部分。

​分区布局

​容器与编排更新

​迁移设备树和设备树 overlay

​Qualcomm Linux 2.0 中的 UEFI 增强功能

​Qualcomm DTB 元数据概述

​使用 qcom-dtb-metadata 的优势

​FIT 配置和元数据配对条目

​推荐的标记顺序（模式）

​添加 QCS9100 板卡变体

​固件管理的更改

​不再支持的配方和相关软件组件

​音频的更改

​设备树和驱动程序的更改

​音频设备树处理的更改

​Qualcomm Linux 2.0 中设备树的更改

​Qualcomm Linux 2.0 中移除的设备树节点

​Overlay 驱动程序的更改

​Audioreach 用户空间源代码组织的更改

​摄像头的更改

​OpenEmbedded 层中摄像头的更改

​摄像头设备树从 Qualcomm Linux 1.0 迁移到 Qualcomm Linux 2.0

​用于编译摄像头 DTS 的 BitBake 命令

​摄像头 DLKM 从 Qualcomm Linux 1.0 迁移到 2.0

​CamX 用户空间源代码组织的更改

​启用摄像头功能

​显示的更改

​图形的更改

​重新组织的元数据层

​更新后的 Adreno 配方

​移除导出的图形用户空间头文件

​更新后的 KGSL 配方

​固件处理的更改

​Overlay 启用

​链接和运行时行为的更改

​安装的组件

​Adreno ICD

​应用程序级别的影响

​环境变量和 overlay 行为

​GLVND 环境控制

​通过环境变量选择厂商

​为内核模块启用 overlay

​上游和统一设备树

​GPU DCVS governor 过渡

​Qualcomm® Intelligent Multimedia (IM) SDK 的更改

​GStreamer 插件配方

​摄像头服务配方更新

​qcom-multimedia-image 中包含的插件

​qcom-multimedia-proprietary-image 中包含的插件

​已弃用的 QIM 插件

​示例应用程序的更改

​视频的更改