U-Boot 移植验收：启动介质、环境变量与恢复

U-Boot 移植应作为一套启动与恢复系统来验收，而不只是确认能进入命令行。移植成果必须选择预期启动源、加载正确的软件组合、处理无效持久状态，并在主镜像无法启动时提供有文档可依的恢复方式。

本文清单面向在嵌入式 Linux 启动链中使用 U-Boot 的产品。命令、存储后端、早期加载器和安全功能会随 U-Boot 版本及板级配置变化。示例属于验收设计，不表示某一欧蓓特电路板已通过这些测试。

1. 明确移植实际包含哪些内容

列出 SoC ROM、SPL 或厂商首级加载器、DDR 初始化组件、可信固件、U-Boot 主程序及 Linux 交接环节。为每个组件指定负责人和版本。如果需要专有 DDR 二进制，应说明允许的分发方式，以及它支持的确切板级内存配置。

定义支持的硬件版本和启动介质。“支持 eMMC 和 SD”并没有说明 SD 是仅用于开发、自动回退，还是获准的现场恢复通道。写清启动绑带、可移除介质和软件设置如何相互影响。验收计划应区分 ROM 对启动介质的选择，与 U-Boot 后续对内核或启动流程的选择。

约定是否包括安全启动、签名升级、防回滚和控制台限制。这些功能需要端到端设计；一个 U-Boot 构建选项不足以建立完整信任链。

2. 使用相互冲突的输入测试介质策略

为每种支持介质记录控制器标识、编号、分区图、镜像偏移和支持的文件系统。在启动日志中记录实际检测到的设备。不要假定 U-Boot 设备编号与 Linux 设备名始终一一对应。

分别测试只有正常介质、只有恢复介质、两者同时存在，以及两者均不含有效应用的情形。检查优先级时，使用两个具有明显标识差异的测试构建，否则从错误介质启动也可能看起来成功。分别确认冷启动和热复位后的行为。

使用 U-Boot Standard Boot 的系统，应记录启用的启动设备、启动方法和预期搜索策略。这是可配置框架，并不保证每种构建都支持所有介质或格式。参见所选版本的 U-Boot Standard Boot 文档。

如果板级构建包含以下命令，可以用它们进行只读信息采集。设备选择和详细存储检查仍取决于具体电路板。

version
bdinfo
printenv bootcmd bootargs bootdelay
mmc list

将输出与发布记录一起保存。不要复制其他电路板的擦除、写入或环境复位命令，错误偏移可能破坏唯一可启动副本。

3. 将环境变量作为受控接口

记录持久环境的存放位置、大小、是否冗余、擦除单元约束及其与分区图的关系。区分编译内置默认值、当前加载值和已经保存到非易失存储的值。U-Boot 中，在内存里修改环境值与保存它是不同操作，参见 环境变量文档。

将变量分为启动策略、开发便利设置和单台设备身份。恢复出厂设置不应意外复制或删除唯一身份、校准或生产配置数据。定义现场人员可修改的设置，以及不支持的值如何被拒绝或恢复。

在可恢复测试设备上，测试环境缺失、完整性校验无效和环境更新中断。预期结果应说明选择哪套默认值或冗余副本，以及操作人员如何识别。只有所选后端和更新顺序确实支持预期断电行为时，冗余存储才有帮助。

还要测试从旧版有效环境迁移。新二进制仍可能加载旧启动命令，从而悄悄绕过新默认值。应把环境模式或迁移策略纳入发布流程，而不是假定重新烧录 U-Boot 会重置持久状态。

4. 验证完整 Linux 交接

把内核、设备树、可选 initramfs 和根文件系统身份关联维护。确认加载地址彼此不重叠，也不侵占保留固件内存或解压所需空间。应使用允许的最大镜像重复测试，而不只是小型开发镜像。

检查最终内核命令行是否选择预期根文件系统和控制台。确认传递给 Linux 的板级身份和内存信息。成功交接必须达到产品定义的应用就绪条件；仅出现早期内核信息，不能验证文件系统或应用镜像。

对于签名镜像设计，应在具备台架恢复计划的情况下，测试有效授权镜像及对受保护内容的主动修改。U-Boot 验证启动文档介绍了信任链中的签名验证。校验和用于检测意外损坏，不能替代身份认证，而签名本身也不等于防回滚。

5. 定义失败计数和有意义的成功信号

启动尝试计数必须与存储后端和复位行为匹配。明确哪些故障会增加计数、何时持久化、何时清零。U-Boot 启动计数文档说明了启动次数限制和替代启动行为，包括实现相关的持久化细节。应在确切构建中验证，而不是假定存在某个变量名就保证相应功能。

只有必需的健康检查通过后，才清除升级尝试状态。过早以 init 进程启动作为成功标志，可能在控制应用仍无法打开设备时就把镜像判为正常。反过来，要求访问不可用外部服务器的健康检查，也可能让本地健康系统回滚。应围绕产品需求定义成功边界，区分本地就绪与可选网络可用性。

选择有界恢复策略：已知正常槽位、专用恢复镜像或有文档的维修路径。避免无限重启循环不断破坏证据、消耗持久存储寿命，却始终不能让设备恢复可用。

6. 执行明确的故障矩阵

• 内核缺失：启动路径报告可识别原因，并进入约定回退方式。
• DTB 错误或损坏：在设计支持验证的情况下拒绝不兼容发布组合，或进入可恢复的失败路径。
• 根文件系统不可用：系统不能仅因为内核已启动，就错误地标记升级成功。
• 升级中断：在每个约定中断点，仍存在已知正常镜像或恢复方法。
• 网络不可用：开发网络启动尝试和生产回退都具有明确时限。
• 恢复操作：授权人员在最终外壳和线缆布局下能够进入恢复模式。

除非全部介质丢失明确属于范围，且外部恢复已验证，否则不要一次覆盖全部冗余副本。记录样本数量、中断位置和观察结果。通过选定中断测试，不能证明能承受任意时刻断电。

7. 交付足以恢复电路板的信息

验收包应包括源码版本、defconfig 与补丁、构建工具、打包镜像及哈希、存储布局、环境策略、测试证据和逐步恢复说明。说明哪些恢复步骤需要物理访问、厂商工具或单独维护的签名服务。切勿把私有签名密钥放进普通发布归档。

欧蓓特的 RK3528 Linux 网络网关项目方案明确讨论了恢复访问以及电源和 OTG 分离的注意事项。它是相关范围示例，并不代表本文所有 U-Boot 机制都已在该方案中实现。移植审查可参阅 固件与 BSP 诊断服务，并准备当前启动日志、存储图及恢复步骤。