> ## Documentation Index > Fetch the complete documentation index at: https://dragonwingdocs-staging.qualcomm.com/llms.txt > Use this file to discover all available pages before exploring further. # 将功能迁移到 Qualcomm Linux 2.0 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` 仓库中,并在构建机器时供 `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 指南](https://dragonwingdocs.qualcomm.com/Key-Documents/Yocto-Guide/modify-partition-layout)。 ## **容器和编排更新** 启用 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 和容器编排软件包。 ## **迁移设备树和设备树覆盖** Qualcomm Linux 1.0 支持串联式多 DTB,而 Qualcomm Linux 2.0 支持基于 FIT 的多 DTB。 Qualcomm Linux 1.0 将机器配置中列出的所有 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 字符串。单个 DTB 可以映射到多个 compatible 字符串。例如,对于 `conf/machine/rb3gen2-core-kit.conf` 中的 `qcom/qcs6490-rb3gen2.dtb` DTB,与该 DTB 对应的 compatible 字符串 `qcom,qcs5430-iot` 和 `qcom,qcs6490-iot` 在 `conf/machine/include/fit-dtb-compatible.inc` 中定义如下: ```text theme={null} FIT_DTB_COMPATIBLE[qcs6490-rb3gen2] = " \ qcom,qcs5430-iot \ qcom,qcs6490-iot \ " ``` 同样,为 `qcom/qcs9100-ride.dtb` 定义了 compatible `qcom,qcs9100-qam`,如下所示: ```text theme={null} 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`。示例如下: ```text theme={null} FIT_DTB_COMPATIBLE[qcs6490-rb3gen2+qcs6490-rb3gen2-vision-mezzanine] = " \ qcom,qcs5430-iot-subtype2 \ qcom,qcs6490-iot-subtype2 \ " ``` 您必须将 Qualcomm Linux 1.0 中的串联式 DTB 和构建时 DTB 覆盖支持迁移到 Qualcomm Linux 2.0 中基于 FIT 的多 DTB 和启动时 DTB 覆盖。Qualcomm Linux 2.0 不要求您区分 base 和 custom DTB 组。 在 Qualcomm Linux 1.0 中,DTB 和 DTB 覆盖的管理方式如以下代码片段所示。`KERNEL_TECH_DTBOS[dtb-name]` 中列出的 DTB 覆盖在构建时与 `dtb-name` 合并,所有此类合并后的 DTB 首尾相连串联,生成组合 DTB。 ```text theme={null} # 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 覆盖的管理方式如以下代码片段所示。`KERNEL_DEVICETREE` 和 `LINUX_QCOM_KERNEL_DEVICETREE` 中列出的 DTB 和 DTB 覆盖被打包到生成的 FIT 镜像的 `image` 部分。 ```text theme={null} 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` 中所列的配置: ```text theme={null} 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 元数据](https://dragonwingdocs.qualcomm.com/Key-Documents/Migration-Guide/migrate-features-to-qualcomm-linux-2-0#qualcomm-dtb-metadata-overview)。 典型配置如下: ```text theme={null} 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 覆盖。 | | 解析、匹配和选择方法 | 定制的、特定于平台的 UEFI 代码,固件扫描 blob,匹配 SoC/开发板 ID,使用硬编码逻辑 | UEFI 中的通用 FIT 解析器。UEFI 枚举 FIT 节点,并将 FIT 节点中的 compatible 字符串与由元数据组成的字符串进行匹配。 | | 偏移量处理 | 定制的偏移量计算,用于从组合 DT blob 中识别单个 DT blob;依赖顺序和大小 | 基于节点的选择,与大小和顺序无关 | | DT 覆盖支持 | 无 | 通过 FIT 原生支持 DTB 覆盖 | | 添加新 DTB | 需要固件感知和验证 | 无需固件更改 | | 标准对齐 | 否,下游逻辑 | 与上游对齐(U‑Boot、Linux 和 UEFI) | ### **Qualcomm DTB 元数据概述** Qualcomm DTB 元数据是一个公开的 GitHub 项目,提供以下内容: * 基于 FIT 的 DTB 打包/选择规范。 * `qcom-metadata.dts` 源文件,它被编译为元数据 DTB,供固件用于将硬件标识符匹配到 FIT 配置。 Qualcomm DTB 元数据包含以下内容: * 元数据定义源文件(`qcom-metadata.dts`),它将允许的 compatible 字符串后缀标记分组到节点中,例如 `soc`、`soc-sku`、`board`、`board-subtype-*`、`softsku` 和 `oem`。 * 参考 FIT ITS 模板(例如 `qcom-fitimage.its` 和 `qcom-next-fitimage.its`),其中每个配置声明以下内容: > * 一个 compatible `qcom,-<...suffixes...>` 字符串 > * 要按顺序应用的基础 DTB 和可选覆盖 固件使用 `qcom-dtb-metadata` 读取以下内容: * 硬件 ID(芯片 ID/版本、CDT 板卡数据、检测到的存储、DDR 大小等) * 编译后的元数据 DTB * FIT 配置,以选择其 compatible 标记与元数据定义及硬件报告相匹配的配置 #### **使用** `qcom-dtb-metadata` **的好处** `qcom-dtb-metadata` 仓库是一种与上游对齐、被广泛接受的机制(FIT),用于在单个发布版本必须支持多种 SoC/开发板时支持动态设备树选择。相比多 DTB 解决方案,`qcom-dtb-metadata` 仓库的好处如下: * 标准容器和结构化选择 * FIT 是一种成熟且广泛使用的格式。它支持在单个镜像中包含多个配置。 * 该设计强制要求 compatible 字符串后缀必须在元数据中定义,防止在未更新规范的情况下使用不明标记。 * 构建时验证以防止不匹配 * 执行构建时检查,以检测 FIT compatible 后缀与元数据定义之间的差异。 * 与多 DTB+DTBO 工作流兼容 * Qualcomm DTB 元数据[文档](https://github.com/qualcomm-linux/qcom-dtb-metadata/blob/main/Documentation.md)描述了基础 DTB+覆盖。即运行时覆盖参数(例如 `CamX` 和 `EL2KVM`),由于它们是运行时控制而非元数据定义的,因此检查脚本会对其进行特殊处理。 * Qualcomm 固件集成细节 * 当前的 Qualcomm UEFI 固件仅支持外部 FIT。 * mkimage -E -B 8(外部数据 + 8 字节对齐) * 硬编码的文件名要求:`qclinux_fit.img` #### **FIT 配置和元数据配对条目** FIT 配置条目是 ITS 中的一个配置,包含以下内容: > * Compatible:`qcom,` > * 对 FDT 的引用:`fdt-.dtb`(以及可选的覆盖) 元数据条目描述每个标记的含义。compatible 字符串中使用的标记必须作为子节点存在于相应的元数据组节点之下。Qualcomm DTB 元数据[文档](https://github.com/qualcomm-linux/qcom-dtb-metadata/blob/main/Documentation.md)定义了固件比较的组和位字段。例如: > * `soc` → `msm-id`:\,带有芯片 ID/版本的位解释。 > * `soc-sku` → `msm-id`:其中某些位表示封装 ID/代工厂 ID。 > * `board` → `board-id`:带有类型、主版本和次版本的位定义。 > * `board-subtype-*` → `board-subtype`:根据子类型类别(外设子类型、存储类型或内存大小)使用不同的位片段。 > * `oem` → `oem-id` > * `softsku` → `softsku-id` #### **推荐的标记顺序(模式)** 您可以按照 [Qualcomm DTB 元数据文档](https://github.com/qualcomm-linux/qcom-dtb-metadata/blob/main/Documentation.md)中描述的规范模式来提高可读性。 ```text theme={null} ------- ``` #### **添加 QCS9100 板卡变体** 要向 `qcom-dtb-metadata` 添加 QCS9100 板卡变体,请执行以下操作: 1. 使用仓库中建议的模式,选择您要用于该变体的标记(板卡修订版、存储、内存等)。 2. 对于您要在 compatible 字符串中使用的每个标记,确保在正确的组(`soc`、`board`、`board-subtype-*` 等)下存在相应的子节点。如果引入了新后缀,请将其添加到元数据中的相关节点下。 3. 在 `conf/machine/include/fit-dtb-compatible.inc` 中添加 `FIT_DTB_COMPATIBLE["key"]` 条目。 4. 使用构建命令,通过更新后的元数据 DTB 构建 FIT 镜像。 5. 为预期应用这些 FIT 更改的机器烧录 `.qcomflash/` 目录。 6. 启动时,验证日志中显示新添加的 compatible。UEFI 启动日志会打印以下内容: * `ParseFitDt`:BoardParam 日志行中的配置,其组成部分构成您添加的 compatible * `FitLoadDtbFromFdt`:您映射到您的 compatible 的配置 `fdt-` ## **固件管理中的变更** Qualcomm Linux 1.0 在 `meta-qcom-hwe` 中支持固件配方。`meta-qcom-hwe/recipes-firmware/firmware` 固件配方从 [Qualcomm® Software Center](https://softwarecenter.qualcomm.com/) 获取固件二进制文件。 Qualcomm Linux 2.0 使用来自 `oe-core` 中 `linux-firmware` 配方的上游固件。由 `oe-core` 中的 `linux-firmware` 配方定义的软件包被包含在 `meta-qcom` 的机器配置文件中。 ## **不受支持的配方和相关软件组件** 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 节点进行探测,这需要为不同的音频使用场景维护多个 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 中,摄像头设备树更改已集成到树内内核中。`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 中,摄像头设备树更改已集成到树内内核中,位于内核源码的 `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` | **注意** 将摄像头子系统 SoC 设备树与摄像头传感器设备树组合,即可创建 overlay 摄像头 DTBO。 摄像头被覆盖到基础之上。下表列出了摄像头 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 | \${WORKSPACE}/build-qcom-wayland/workspace/sources/cameradlkm/qcom/ opensource/camera-kernel/camera-kt/ | | 2 | \${WORKSPACE}/build/workspace/sources/camx-dlkm/camera-kt/ | | | QCS9075

QCS8275

QCS615 | 1 | \${WORKSPACE}/build-qcom-wayland/workspace/sources/cameradlkm/qcom/ opensource/camera-kernel/camera/ | | 2 | \${WORKSPACE}/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 中运行以下命令: ```text theme={null} echo -n "camx" > /var/data efivar -n 882f8c2b-9646-435f-8de5-f208ff80c1bd-VendorDtbOverlays -w -f /var/data sync reboot ``` 有关更多信息,请参阅[使用 overlay 配置派生镜像配方](https://dragonwingdocs.qualcomm.com/Key-Documents/Migration-Guide/use-overlay-configurations-to-derive-image-recipes)。 ## **显示中的变更** 显示的 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 调速器过渡到用于 GPU 动态时钟和电压调节(DCVS)的 Simple On‑Demand 调速器 * 更新内核图形支持层(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](https://github.com/qualcomm-linux/meta-qcom/blob/master/recipes-graphics/kgsl-dlkm/kgsl-dlkm_1.0.14.bb)。 ### **固件处理中的变更** 在 Qualcomm Linux 1.0 中,固件二进制文件作为 Adreno 图形配方的一部分发布。 在 Qualcomm Linux 2.0 中,固件不随 Adreno 图形栈一起发布。您必须从 [Linux 固件仓库](https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/qcom)获取。 **注意** 确保在创建根文件系统期间存在相应的 Qualcomm 固件文件。 **注意** 固件打包和部署必须独立于图形配方进行处理。 ### **Overlay 启用** GLVND 用于用户空间图形栈。它为以下内容提供厂商中立的调度: * OpenGL * EGL * GLX GLVND 在应用与厂商特定图形库之间引入了一个加载器层。 #### **链接和运行时行为变更** 启用 GLVND 后,应用不再直接链接到厂商特定的 EGL/GLES 库。它们改为链接 GLVND 库。厂商库在运行时被动态选择和加载。 #### **安装的组件** 在 Qualcomm Linux 2.0 中,图形安装以下组件: * GLVND 核心库 * 仅厂商特定的 EGL/GLES 加载器库 厂商选择通过可安装客户端驱动(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 厂商实现: ```text theme={null} 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`。 ```text theme={null} 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 调速器过渡** GPU DCVS 调速器实现经历了重大修改: * Qualcomm Linux 1.0 使用 Adreno TZ 调速器。 * Qualcomm Linux 2.0 过渡到上游 Simple On-Demand 调速器。 影响如下: * 性能:Simple On-Demand 调速器提供改进的性能效率。 * 功耗:作为性能提升的权衡,您可能会看到功耗略有增加。 ## **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 使用标准化的、与机器无关的方法来编译示例应用。它将开发环境从特定于目标的工具链转变为构建工具独立安装程序,使构建工具与特定设备镜像解耦。Qualcomm Linux 2.0 使用 RPM 打包而非 OPKG,因为它与标准打包机制对齐,并提供更强的软件包和依赖管理。 **注意** 除打包更新外,迁移到 Qualcomm Linux 2.0 不需要对现有示例应用进行任何额外更改。 下表列出了 Qualcomm Linux 1.0 与 Qualcomm Linux 2.0 中示例应用支持的关键差异: **表:示例应用比较** | **方面** | **Qualcomm Linux 1.0** | **Qualcomm Linux 2.0** | | :----------------: | :----------------------------------------------------------------------------------------------------------------------------------------------------------------: | :-----------------------------------------------------------------------------------------------------------------------------------------: | | SDK 类型 | 特定于机器的 eSDK | 适用于所有机器的单一 eSDK | | eSDK 脚本 | `qcom-wayland-x86_64-qcom-multimedia-image-armv8-2a--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`。 | | 应用可安装软件包的路径 | `/tmp/deploy/ipk/armv8-2a/` | `/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/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`
| 有关更多信息,请参阅: * [下载并安装 eSDK](https://docs.qualcomm.com/doc/80-80021-51/topic/install-sdk.html#download-and-install-esdk) * [使用 Qualcomm IM SDK 自定义现有示例应用](https://docs.qualcomm.com/doc/80-80021-51/topic/customize-sample-applications.html) ## **视频中的变更** 视频的 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_.bb` * 视频设备树配置已从早期的 overlay DT 迁移到主线内核中已提供的 DT。 * Qualcomm Linux 1.0:`qcom-videodtb_1.0.bb` * Qualcomm Linux 2.0:DT 是主线内核 DT 的一部分。