跳到主要内容

U-Boot 升级与维护

U-Boot 一旦进入产品，就不只是“能启动”那么简单。你还要考虑如何升级、如何回滚、如何保护环境变量、如何定位现场问题，以及如何避免一次升级把设备变成无法恢复的状态。

产品中的 U-Boot 应该尽量少变，但不能完全不维护。安全漏洞、硬件版本变化、启动介质变化、升级策略变化，都可能要求你更新启动链。关键是：升级方案必须可恢复、可追踪、可验证。

1. 为什么升级 U-Boot 风险高​

U-Boot 位于启动链前段。一旦它损坏，Linux 可能根本起不来，远程修复也就无从谈起。升级 U-Boot 比升级普通应用程序风险更高。

升级前必须确认：

  • 新镜像适配当前硬件版本。
  • 烧录偏移正确。
  • 电源中断时有恢复方案。
  • 旧版本可回滚。
  • environment 与新版兼容。

2. 版本兼容性​

升级 U-Boot 不只是替换一个二进制。你要确认新版与这些内容兼容：

  • 启动镜像格式。
  • environment 变量名和脚本。
  • 分区布局。
  • FIT 配置名称。
  • kernel 和 DTB 路径。
  • recovery 入口。
  • A/B 状态变量。

如果新版 U-Boot 改了变量名，旧 environment 仍然保留，可能导致系统执行旧脚本。产品中常见做法是维护一个 environment 版本号，启动时发现版本不匹配就迁移或恢复默认值。

3. 维护 environment​

环境变量经常保存启动命令、网络参数、升级状态和板级信息。维护策略包括：

  • 给关键变量设置默认值。
  • 避免把临时调试变量永久保存。
  • 对升级状态变量做冗余或校验。
  • 记录变量版本，必要时迁移。
注意

env save 会写持久化存储。产品中应明确 environment 存储位置、大小、冗余策略和损坏恢复方式。

一个简单的变量版本思路：

env_version=3
bootcmd=run boot_production
boot_targets=mmc0 usb0 pxe

当 U-Boot 发现持久化 environment 中的 env_version 低于当前版本，可以选择恢复默认环境或执行迁移脚本。具体实现取决于产品需求。

4. 升级方式​

常见方式包括：

  • Linux 用户空间写入 U-Boot 分区。
  • U-Boot 通过 TFTP/USB/MMC 加载新镜像并写入。
  • 厂商 recovery 工具升级。
  • 整机 OTA 系统统一管理。

越靠前的固件，越应该保守升级。能不现场升级 U-Boot，就不要频繁升级 U-Boot。

不同升级方式的风险不同：

方式优点风险
Linux 用户空间写入容易集成 OTA断电可能损坏启动链
U-Boot 自己写入可在 Linux 不可用时恢复命令危险，交互复杂
厂商 recovery恢复能力强依赖工具和物理接入
A/B 固件分区可回滚占用空间，状态机复杂

5. 版本与日志​

产品 U-Boot 应能输出足够的信息：

  • U-Boot 版本。
  • Git commit 或构建号。
  • 板级版本。
  • 启动介质。
  • 当前启动 slot。
  • 失败原因或回滚原因。

这些信息能显著降低现场排障成本。

建议在启动日志中能看到：

U-Boot version:
board revision:
build commit:
boot device:
active slot:
rollback reason:

这些字段不一定都由 U-Boot 自动提供，有些需要板级代码或环境变量配合。

6. 升级前检查清单​

  • 新镜像已在同硬件版本上验证。
  • 有断电测试结果。
  • 有回滚路径。
  • environment 兼容性已验证。
  • recovery 镜像仍然可用。
  • 升级过程有日志。
  • 失败状态不会无限重启。

7. 现场维护策略​

现场设备的维护目标是减少不可恢复故障。建议：

  • 不把临时调试环境变量保存到生产设备。
  • 避免让用户随意进入 U-Boot console。
  • 为关键启动失败记录原因。
  • 设计 watchdog 和 bootcount。
  • 保留一个可恢复系统或恢复介质。

本章小结​

U-Boot 维护的关键词是“可恢复”。任何升级方案都要优先回答：失败后设备如何回到可启动状态。

思考与练习​

  1. 列出升级 U-Boot 前必须验证的 5 个条件。
  2. 解释 environment 版本号有什么用。
  3. 说明为什么 U-Boot 升级比普通应用升级风险更高。