高通板卡部署备忘：Yocto 元数据、镜像构建与定制查询手册

阅读范围与版本

这份笔记从 Qualcomm Linux 功能 出发，结合同一本指南的概述、用户定制、调试，以及 Yocto 官方文档整理。目标是：以后拿到一块高通板，知道要查哪份配置、改哪一层、编译什么，以及拿什么证据判断部署是否正确。

尤其注意：官网概述在这一本指南中允许 QCM6490／QCS6490 名称交替出现，这不是所有硬件都兼容的承诺。SoC 相同也不代表载板、摄像头 mezzanine、存储布局或设备树相同。平台说明

按问题直接查询

1. 元数据是构建说明书，不是生成出来的业务数据

在 Yocto 语境里，metadata 是用来描述“如何构建软件与系统”的输入：下载地址、版本、补丁、依赖、编译任务、安装路径、打包规则以及硬件／发行版配置。

一个简化的关系是：

repo manifest：把哪些仓库的哪些版本同步到哪里
    ↓
metadata layers：配方、类、配置、补丁
    + 上游源码／本地源码／预编译固件
    ↓
BitBake：解析变量和依赖 → 生成任务图 → 执行任务／复用缓存
    ↓
软件包 → rootfs／内核／设备树／固件打包 → 镜像集合
    └→ SDK：给应用开发者使用的匹配工具链和 sysroot

这也解释了一个常见疑问：repo sync 完成后，为什么 bitbake 还在下载？前者主要同步 manifest 中的构建仓库；配方里的 SRC_URI 还可能指向其他源码、压缩包和预编译固件，后者在 do_fetch 阶段获取。Yocto 4.0.18：构建概念

1.1 分清元数据层与仓库清单

因此，“构建高通元数据”更准确地说，是使用高通及社区提供的元数据，构建面向指定硬件的系统镜像。不要看到 meta- 就认为目录内都是可执行源代码，更不要认为每个子系统固件都能在公开 Yocto 工作区中从源代码重建。

2. 从哪个 layer 开始找：职责比名字更重要

下面按官网列出的职责重新分组，而不是把目录结构原样抄一遍。

这是该版指南的层集合，不保证任意 release 的默认 manifest 都启用了每一层。meta-openembedded 也不能简单理解为“交叉编译器本身”；它主要扩展 OE-Core 之外的软件元数据。高通：元数据层概述

2.1 下载了一个 layer，为什么没有效果？

至少要走完三个关卡：

1. 找得到：该目录存在，且有 conf/layer.conf。
2. 被解析：进入最终 BBLAYERS，兼容当前 Yocto 系列及其他依赖层。
3. 被选择：其中的 recipe／配置影响了当前 target，相关软件包真的进入镜像依赖链。

高通这一代模板把层分成 BASELAYERS、BSPLAYERS、EXTRALAYERS，最后组合成 BBLAYERS。前面几个是模板的组织方式，最终有效的 BBLAYERS 才是关键证据。

在已初始化的 Linux 构建 shell 内查询：

bitbake-layers show-layers
bitbake-layers show-recipes
bitbake-layers show-appends
bitbake -e qcom-multimedia-image | grep '^BBLAYERS='

这里的 qcom-multimedia-image 是官网目标示例；如果选择了自定义镜像，查询时也要使用自己的 target。高通：新增层排错、Yocto：创建与启用 layer

3. .bb、packagegroup、image：不是一回事

3.1 文件类型速查

require 找不到文件会报错，include 找不到不一定终止；inherit 处理类。把文本放在某个目录下，不代表 BitBake 会自动采用它。BitBake 2.0：语法与操作符

3.2 一份 recipe 可以产生多个 package

例如一个程序配方可能拆出运行包、开发头文件包、调试符号包。bitbake robot-hello 是构建配方；IMAGE_INSTALL／RDEPENDS 中通常填写软件包名，两者有时同名，但不能永远等同。

robot-hello_1.0.bb
    ├─ do_compile / do_install：编译并装入打包暂存区
    └─ do_package：依据 PACKAGES、FILES 拆包
          ├─ robot-hello
          ├─ robot-hello-dbg（是否有内容取决于构建）
          └─ ...

packagegroup-myrobot
    └─ RDEPENDS → robot-hello、其他运行依赖

myrobot-image
    └─ IMAGE_INSTALL → packagegroup-myrobot

单独配方构建成功，不会自动修改所有 rootfs。 必须让目标镜像选择对应软件包，再重新生成该镜像，并核对包清单。Yocto：编写配方

3.3 高通镜像选择表

文档中的参考 minimal 配置含 debug-tweaks、调试工具和可选 ADB 等开发功能。以后面向产品交付，需要另外审查账号、认证、调试接口、签名和服务暴露面；“minimal”只描述选择目标，不能代替安全验收。高通：镜像与软件包组

4. 常用变量：先辨认它控制哪一层

对具体目标看最终展开值，而不是只看自己编辑的那一行：

bitbake -e qcom-multimedia-image | grep -E '^(MACHINE|DISTRO|DISTRO_FEATURES|IMAGE_INSTALL|TMPDIR|DEPLOY_DIR_IMAGE)='
bitbake -e virtual/kernel | grep -E '^(PN|PV|SRCREV|KERNEL_DEVICETREE)='

bitbake -e 输出中的变量历史注释也有助于追踪“最后是谁改了值”。不要随意将整份环境转储上传公共仓库，它可能包含内部源地址或私有构建配置。Yocto 变量表

4.1 覆盖语法最容易掉坑的地方

Kirkstone 使用冒号形式的 overrides。迁移旧教程的 _append／_remove 前，应先核对所用 BitBake 版本，不要盲目混写。

两个最常用的例子：

# 在镜像 recipe 的 bbappend 中添加运行包
IMAGE_INSTALL:append = " robot-hello"

# 在某个 bbappend 中添加本层的本地资源搜索路径
FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI:append = " file://my-change.patch"

第二个例子的 := 保留当前 append 文件对应的目录，结尾冒号分隔路径。.bbappend 文件名也必须匹配目标，例如上游从 foo_1.0.bb 升级到 foo_2.0.bb，原来的 foo_1.0.bbappend 不会自动迁移。

BBFILE_PRIORITY 影响多个层提供同名配方时的优先关系，但不是“数值高就覆盖任何变量、任何 .conf、任何 class”的总开关。发生冲突时，结合 provider／version 选择、overrides、解析规则和 show-appends 排查。Yocto：层优先级与 append、BitBake：覆盖语法

5. 从 manifest 到镜像：先锁版本，再初始化

5.1 先记录五个选择

开始前至少明确：板卡／载板、BSP release、manifest 文件、MACHINE、DISTRO／image 组合。不能从不同时间的网页中各取一个“看起来能用”的值拼起来。

官方编译指南还区分了获取路径：

本次读到的未注册用户工作流标注 2024-08-07，其 Linux 示例要求 Ubuntu 22.04、16 GB RAM、300 GB 可用磁盘、超过 32 GB 的 swap，并提示虚拟机编译较慢。这些是该历史流程的容量与环境参考，不是后续所有 BSP 的统一最低要求；同时运行多个构建还需另估资源。它使用预编译专有输入，不能理解成“未注册也可以获取所有专有源码”。官方工作流与主机要求

官方仓库入口为 qcom-manifest。本次访问也会遇到迁移后的 qualcomm-linux 组织链接；记录实际仓库地址与 commit，避免只保留旧组织名。

这次实际读到的资料有三个不同层次：

例如，1.0 Ver.1.4 manifest 中，poky 固定为 54af8c5e80ebf63707ef4e51cc9d374f716da603，meta-qcom-hwe 固定为 b33ec567fa7f4af85e86cd24de10c7e5e519a7cb，meta-qcom-distro 固定为 df08769a3044a33e903696acf2733d3b8babe20b。它还把 distro 仓库的 set_bb_env.sh 通过 linkfile 暴露成根目录 setup-environment。这说明 manifest 不只是一个版本名，还定义整个工作区如何拼装。

上述 XML 文件本身仍通过分支 URL 引用；实际部署时也要记录 manifest 仓库的 commit，并保存 repo manifest -r 结果。不要把“XML 内部固定了 revision”误认为“引用 XML 的分支 URL 永远不变”。Kirkstone 分支 README

以下仅示意同步命令的形式，变量没有默认值，不可整段当成已确认板型的部署脚本：

# 在已满足该 release 要求的 Linux 构建主机、独立工作区内
# 先为这些变量填入经过核对的值
: "${QCOM_MANIFEST_BRANCH:?填写匹配 BSP 的 manifest 分支}"
: "${QCOM_MANIFEST_FILE:?填写具体 release XML 文件名}"

repo init -u https://github.com/quic-yocto/qcom-manifest \
  -b "$QCOM_MANIFEST_BRANCH" -m "$QCOM_MANIFEST_FILE"
repo sync

不要在现有网站仓库运行这些命令。宿主架构、Ubuntu 版本、磁盘空间、依赖和注册许可要求以对应 Qualcomm Linux 编译指南 为准。手头有一个 Ubuntu 22.04 容器，不等于已经有经过验证的高通 BSP 构建环境。

5.2 setup-environment 不是普通可执行程序

官网该代示例是：

# 在同步完成的 BSP 根目录；以下 machine 只是 2024 指南示例
export SHELL=/bin/bash
MACHINE=qcm6490 DISTRO=qcom-wayland source setup-environment

必须在兼容的 Bash shell 中运行。source 会改变当前 shell的环境和工作目录；改成 bash setup-environment，子进程退出后通常不能保留所需环境。export SHELL=/bin/bash 也不会把正在运行的 zsh 变成 Bash，需要先真正进入 Bash。

不同 release 的机器命名已经变化。只要源码里的 .conf 不支持当前 MACHINE，就应回到 release 文档，而不是改个近似名字反复尝试。

5.3 配置可能被重新生成

高通环境脚本不应直接套用“上游 oe-init-build-env 一定保留已有配置”的印象。本次成功读取的 Kirkstone 分支脚本 有两条路径：

因此，按已读分支脚本恢复环境的形式是：

# 在 BSP 工作区根目录；先备份并确认该目录的配置齐全
source setup-environment build-qcom-wayland

复用分支不会重新生成层列表，临时传入 EXTRALAYERS 也不等于自动加入新层；需要核对实际 BBLAYERS。这是本次读到的分支实现，不冒充所有 release 的保证；部署前仍须核对 manifest 固定 revision 对应的脚本。

操作原则：

• 首次初始化后记录 pwd 和生成的 conf/ 内容。
• 再次进入环境前，先看固定 release 的脚本是否支持显式传入已有 build 目录并复用配置。
• auto.conf 若标注为自动生成，就不要把它作为持久定制入口。
• 长期修改放在自己的 layer／受版本控制的配置模板中；对工作区配置保留差异和备份。
• 初始化后再次核对 MACHINE、DISTRO、BBLAYERS，不要只看终端提示符。

5.4 编译与产物确认

在已选择并确认的 build 环境中，文档示例构建：

bitbake qcom-multimedia-image

该代文档的典型输出为：

<workspace>/build-qcom-wayland/
  conf/
  tmp-glibc/
    work/...
    deploy/
      images/<machine>/<image-name>/
      sdk/...

真正找路径时优先查 TMPDIR、DEPLOY_DIR_IMAGE 和部署类。高通 image-qcom-deploy.bbclass 还会组织 <image-name> 子目录。构建成功后要确认文件、大小、哈希和对应的 release，而不是只看最后一行 succeeded。

6. 加自己的代码：维护一个小 layer

官网通过直接编辑高通 layer 展示定制点；长期维护时，我更倾向于保留 vendor 基线，用自己的 layer 放应用、配置、patch 和 .bbappend。这样 BSP 升级后可以清楚比较自己的增量。

下面是原创教学结构，未执行 BitBake 编译，不包含任何高通闭源代码：

layers/meta-myrobot/
  conf/layer.conf
  recipes-demo/robot-hello/
    robot-hello_1.0.bb
    files/hello.c
  recipes-products/images/
    qcom-multimedia-image.bbappend

在已经初始化、确认路径正确的 build 目录中，可以使用 Yocto 的创建工具生成 layer 骨架，再启用它：

# 假定 build 与 layers 是 BSP 根目录的同级子目录
bitbake-layers create-layer ../layers/meta-myrobot
bitbake-layers add-layer ../layers/meta-myrobot
bitbake-layers show-layers

命令会创建／修改文件；只应在自己的 BSP 工作区执行一次。如果目录已存在，先检查而不是覆盖。创建工具还可能生成示例 recipe；正式维护时整理为所需结构，并保留 layer 的 README、许可证与兼容系列声明。

6.1 应用、配方和镜像，三处各做一件事

hello.c 的教学内容：

/* SPDX-License-Identifier: MIT */
#include <stdio.h>

int main(void) {
    puts("robot-hello: application packaging check");
    return 0;
}

robot-hello_1.0.bb 的结构：

SUMMARY = "Small application packaging exercise"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"

SRC_URI = "file://hello.c"
S = "${WORKDIR}"

do_compile() {
    ${CC} ${CPPFLAGS} ${CFLAGS} ${S}/hello.c ${LDFLAGS} -o robot-hello
}

do_install() {
    install -d ${D}${bindir}
    install -m 0755 robot-hello ${D}${bindir}/robot-hello
}

这个本地单文件示例使用 Kirkstone 的 WORKDIR 布局。示例校验值已对照 Poky Kirkstone 的公共 MIT 文件 计算核对；实际项目要声明真实许可证并检查文件校验值，不能给专有代码随便贴 MIT。${CC} 和相关 flags 来自目标工具链；${D} 是打包暂存根目录，不能删掉它把文件安装到构建主机。

随后在 qcom-multimedia-image.bbappend 中写：

IMAGE_INSTALL:append = " robot-hello"

最后分别确认“配方可构建”和“镜像会安装”：

bitbake robot-hello
bitbake-layers show-appends
bitbake -e qcom-multimedia-image | grep '^IMAGE_INSTALL='
bitbake qcom-multimedia-image

核对生成镜像的 package manifest，确认包含 robot-hello；以后上板再执行它确认目标架构、动态库和安装路径。本文没有把这些预期动作写成实测成功日志。Yocto：新配方

6.2 加服务、加依赖、裁剪功能时怎么扩展

注意，原始 image 最终可能不仅靠 IMAGE_INSTALL，还使用 CORE_IMAGE_* 和 packagegroup 等机制；删除某一处引用后，应看最终包清单，不把编辑成功当成裁剪成功。

7. 任务与缓存：每条命令究竟做什么

典型源码配方可以按下面的链条理解，实际 DAG 会包含依赖和额外任务：

do_fetch → do_unpack → do_patch → do_configure → do_compile
  → do_install → do_package → do_package_write_*
  → 镜像依赖装配 do_rootfs → do_image* → 部署相关任务

qprebuilt 一类配方可能使用预编译输入，并不按普通源码程序那样完成编译。任务列表和 bitbake -e 的最终函数才是证据。

缓存不是简单判断“文件夹存在就不再编译”。任务签名与输入变化决定重建／复用；直接改 tmp*/work 下临时展开源码，可能被重新解包覆盖，也可能没有按希望触发重建。

7.1 定位日志，不手猜路径

bitbake -e robot-hello | grep -E '^(WORKDIR|S|B|T)='

在输出的任务日志目录查看 log.do_fetch、log.do_configure、log.do_compile、log.do_install、log.do_package_qa 等；实际失败在哪个 task，就先检查该 task 的日志。run.do_* 还可帮助理解实际执行命令，具体后缀以目录中内容为准。

7.2 devtool 用于开发，完成后要保存回 layer

以官网已有的 Weston 目标为例，在适用 BSP 内：

devtool modify weston
# 编辑 devtool 报告的源代码目录，记录修改并按工作流提交补丁
devtool build weston
devtool build-image qcom-multimedia-image

长期保存时，再按该版 devtool finish --help 将修改归入自己的 layer，并核对生成的补丁／append。workspace/sources 是开发工作区，不是最终可移植构建说明书。不要在尚未保存改动时随意 reset 或清理工作区。

官网用户定制的 QDL 段落出现“修改 QDL 却 devtool build weston”，Weston 段落也出现 pulseaudio 输出路径，明显存在拷贝痕迹。修改哪个 recipe，就围绕该 recipe 验证，不能照抄示例中的不一致名称。 QDL 还区分 target 与 qdl-native 等宿主构建变体，要先明确需要的是刷机主机上的工具。高通：用户定制

8. 内核、设备树和 RT：硬件支持的三条线

8.1 内核与配置入口

该版指南使用 6.6 LTS 的 linux-kernel-qcom 配方；实时扩展由 meta-qcom-realtime 的 linux-kernel-qcom-rt 提供。文档中的核心配置包括：

DEBUG_BUILD、PERFORMANCE_BUILD 是该 BSP 定义的控制项，不是通用 Yocto 开关。官网说明 DEBUG_BUILD=1 优先；性能启动模式可能移除 UART console。首次 bring-up 时丢掉串口输出，会让定位启动失败更困难。

8.2 DTB 和 DTBO 为什么还要跟 package 依赖配合

KERNEL_DEVICETREE 选择基础 DTB；该 BSP 的 KERNEL_TECH_DTBOS 为指定基础设备树关联技术模块 overlay。生成 DTBO 的包还需要进入相应依赖，例如 MACHINE_EXTRA_RDEPENDS。

因此“在变量里填了一个 .dtbo 文件名”并不保证文件已经被构建并进入镜像。还要检查：源文件／配方是否存在、依赖是否生效、打包产物是否存在、启动时是否选中了适配实际载板的设备树。

这也是不能只凭 MACHINE=qcm6490 就判断 camera mezzanine 可用的原因。该代平台支持组合多个 DTB，UEFI 依据硬件选择对应项；基础板与视觉扩展板的选择要匹配。

本次也读到了上述旧 manifest 固定的 qcm6490.conf（b33ec567…）：KERNEL_DEVICETREE 同时列出 QCS5430 不同变体与 QCS6490 RB3 Gen 2 的基础板、video／vision mezzanine 等 DTB；KERNEL_TECH_DTBOS[...] 按基础板条目关联 overlay，MACHINE_EXTRA_RDEPENDS 再拉入 firmware packagegroup 与 graphics／display／camera／WLAN／BT 设备树包。这是“同一个 machine 文件覆盖多个具体设备树目标”的实际例子，不是各载板可以混用镜像的保证。

8.3 模块签名与实时性

指南说明 BSP 强制模块签名，并通过 qmodule.bbclass 处理部分树外模块签名。自编模块加载失败时，应检查内核版本／配置、vermagic、签名和信任链，不要首先关闭强制校验。

同理，加入 meta-qcom-realtime 只解决 RT 内核构建的一部分。对机器人控制，应实测调度延迟、驱动和中断行为、负载下的周期抖动与 deadline miss；它不是一条让整机自动满足硬实时的开关。高通：内核、RT 与设备树

9. 输出文件怎么认：rootfs 不等于整机固件

9.1 三种固件输入

默认 meta-qcom-hwe 路径可以获取预编译固件；在拥有相应源码和权限时，meta-qcom-extras 可通过 FWZIP_PATH 接入自行生成的匹配 ZIP。公开 layer 能被 clone，不意味着闭源固件源码和分发许可也自动开放。

9.2 启动与打包关系

启动固件／UEFI
    ↓
EFI 系统分区 efi.bin
    ├─ bootaa64.efi：启动管理器
    └─ uki.efi：kernel + initramfs + cmdline + OS 元数据等

dtb.bin
    └─ 对应硬件的设备树／该 BSP 的组合 DTB

system.img
    └─ 目标 rootfs：库、程序、服务、部分子系统固件

分区描述 → gen_partition → partition.xml → Ptool
    └─ GPT 二进制 + rawprogram XML + patch XML

该代的 uki.bbclass 与 image-efi.bbclass 负责相应封装，image-qcom-deploy.bbclass 组织交付文件。只替换 Linux Image 文件，未必就替换了设备实际启动的 UKI／EFI 分区内容。

9.3 刷写输入是成套契约

prog_firehose_*.elf 是与目标平台相关的刷写 programmer；rawprogram*.xml 描述写入内容和位置；patch*.xml 与 GPT 等负责对应布局调整。它们必须与板型、存储介质、容量、分区方案和安全状态匹配。

文档使用 UFS 示例，不能直接推到 eMMC。也不要从不同版本目录各取一个 programmer、rootfs 和 XML 拼在一起。没有确认这些条件前，本笔记不提供可直接执行的通用刷写命令。高通：固件、分区与 QDL

10. 板上文件系统与服务：为什么“重启还在”和“刷机还在”不同

10.1 rootfs、overlay、persist

“放在 overlay 重启后还在”不等于“更新整个分区后还在”。反过来，旧 overlay 上层文件也可能遮住新 rootfs 中更新后的同名配置；出现“镜像明明改了但运行还是旧内容”，应检查挂载层与升级策略。后一点是基于 overlay 工作方式的部署推论，不是本文已经在板上复现的故障。

目标板只读查询示例：

cat /etc/os-release
uname -m
uname -r
findmnt /
findmnt /etc
findmnt /var
findmnt /opt
findmnt /var/persist
lsblk -o NAME,SIZE,FSTYPE,LABEL,PARTLABEL,MOUNTPOINTS

不同目标镜像可能未安装完整 util-linux 命令，可先用 mount 查看，不要因为工具缺失就假定分区不存在。指南出现的 /dev/sda10、/dev/sda11 只是示例，不应硬编码进部署脚本。

10.2 需要认识的服务

systemctl --failed --no-pager
systemctl status property-vault.service --no-pager
journalctl -b -u property-vault.service --no-pager

getprop／setprop 在本文是高通 property-vault 提供的能力，不应据此推断目标系统就是 Android。持久属性与普通临时属性不同；不要把属性服务当成放密码、密钥的安全存储。高通：文件系统、初始化与属性

11. 后续应用部署：交叉 SDK、原生包和 Docker 各管一层

11.1 “SDK”在这里至少有两种意思

有 QIM layer 不代表已经生成应用交叉 SDK；有交叉工具链也不代表设备上存在对应 NPU／DSP runtime。

应用和第三方 C++ 库需要作为可追溯制品复用时，可继续看 Conan：制品身份、依赖锁定与 Yocto SDK 对接。其中区分 build/host profile、工具链与 sysroot 的配置归属，以及为什么换一个 SDK 路径不一定会改变 Conan 的 package ID。该节仍是待板卡验证的集成方案，不表示本文 BSP 已经接入 Conan。

对支持标准 SDK 的 image，Yocto 通用入口为：

bitbake qcom-multimedia-image -c populate_sdk

安装器通常位于 ${TMPDIR}/deploy/sdk，实际文件名以生成结果为准。不要从别的 BSP 随便拿一个同为 aarch64 的 SDK：glibc、C++ ABI、头文件、驱动用户态接口和库版本都需要匹配。Yocto 4.0.18：获取 SDK

11.2 哪种部署方式适合什么阶段

应用容器共享目标板的宿主内核。容器不能替代 BSP 驱动、设备树、子系统固件或签名链。把本站现有 ONNX／MuJoCo Docker 镜像搬过去，也不能自动获得高通 NPU 加速；应分别核对 CPU 架构、实际推理 provider、模型算子、runtime 与驱动匹配。

11.3 官网容器能力说明应怎样使用

该代文档通过 meta-virtualization、packagegroup-container、相关内核配置以及 multimedia packagegroup 集成 Docker／Compose／Kubernetes。它说明这套 BSP 的集成路径，不是当前所有镜像都已开启这些能力。

部署前只读核对：

docker version
docker info
systemctl status docker --no-pager
systemctl status kubelet --no-pager

官网某些示例包含广泛的设备映射、--privileged、忽略 Kubernetes preflight 检查等开发设置。它们不作为本文默认的产品部署策略；后续按所需设备、权限、网络和安全策略最小化配置。Compose v1 的 docker-compose 与插件形式 docker compose 也应按目标实际版本区分。

12. 上板前检查：先留下一份可追溯记录

12.1 部署记录模板

可下载 部署检查表 YAML。这是人工记录模板，不是会执行刷机的配置文件。

repo manifest -r 可用于导出解析后的仓库 revision；但它不会自动保存未提交补丁、外部 SRC_URI 下载物、许可证授权或所有环境配置。应按团队允许的存储范围归档这些证据，不把凭据和专有软件上传公开网站。

12.2 哪些操作必须单独确认

• 刷写／重新分区会写设备存储，可能覆盖系统和数据；先确认串口、恢复模式和对应板卡官方流程。
• persist 不能作为普通缓存删除；备份范围也要考虑校准、设备身份等实际 BSP 数据用途。
• UFS OTP、--finalize-provisioning、熔丝、密钥烧录、Secure Boot 状态变更可能不可逆，不属于普通尝鲜步骤。
• 不把关闭 SELinux、关闭模块签名、启用宽松调试账号当成通用解决方法。
• 看到 USB 05c6:9008 只说明相关下载模式枚举，不证明 programmer、容量和安全状态匹配。

这轮只整理知识，没有连接硬件，也没有执行这些操作。刷写细节必须等实际板型与 BSP release 确认后再形成单独的、可审核的操作单。

12.3 验收不要只停在“能开机”

建议逐层确认：启动／串口 → 系统版本和挂载 → 驱动／设备树 → 固件与服务 → 应用依赖 → 功能输入输出 → 重启持久性 → 长时运行与资源占用 → 更新回滚。

对后续四足控制部署，还应另外记录控制频率、端到端时延、deadline miss、通信中断行为、watchdog 和故障恢复；“成功启动一个 ONNX session”不能替代控制闭环验收。

13. 排错索引：先看证据，再改配置

QDL 与 ModemManager 的具体诊断入口见 高通：调试。如果为了刷机临时停止服务，应记录原状态并在完成后恢复，不能不加区分地永久禁用。

14. 官网旧例子中，不应原样带进部署脚本的内容

这些差异不否定官网提供的架构信息，但提醒我：知识可以按概念整理，命令必须按具体版本验证。

原始资料与相关笔记

• Qualcomm Linux Yocto 指南：概述。
• 用户提供的入口：Qualcomm Linux 功能。
• 同版指南：用户定制、调试。
• Qualcomm Linux 编译指南入口：实际 BSP 构建／刷写应回到对应 release。
• Yocto 4.0.18 文档、BitBake 2.0 语法。
• 本站：Docker：镜像、容器与可复现环境、Linux 进程诊断工具。
• 分类：系统与开发环境 → Linux 与终端。

最后用一句话记：manifest 固定源码入口，layer 组织构建知识，machine 定义硬件目标，distro 定义系统策略，image 决定交付内容；真正部署时还要核对固件、分区、工具链和安全状态。