1. 课程导入
固件升级看似只是“把新版本烧进去”，但在真实工程中，它是一条横跨硬件、驱动、协议、系统、安全与运维的完整链路。一次失败的升级，轻则设备变砖返修，重则批量事故、现场停摆。本课程的目标，是把零散的升级经验整理成一套可复用的工程手册：从需求定义、镜像制作、传输协议、校验回滚，到灰度发布、现场排障与复盘归档，形成端到端的标准动作。
学习目标：完成本课程后，你应能独立设计一条固件升级链路，写出可执行的升级方案文档，定位升级失败的关键环节，并建立可追溯的版本与回滚机制。
一、核心价值：为什么升级需要“工程化”
固件升级的本质，是在不可靠的现场环境中，把可信的新镜像安全地写入可能随时断电的设备，并保证失败后设备仍可恢复。它同时受四类约束：
- 可靠性约束：断电、断网、Flash 坏块、内存不足都可能中断升级。
- 安全性约束：镜像需签名验签，防止被篡改或降级攻击。
- 兼容性约束：硬件版本、Bootloader 版本、分区表必须匹配。
- 可运维约束：升级要能灰度、能暂停、能回滚、能审计。
把这四类约束落到流程里，就是本课程所说的“手册工程”。它不是一份文档，而是一组可执行的检查项、脚本与判定条件。
二、整体框架：五层升级体系
下图给出固件升级全流程的工程框架。自下而上分别是硬件与存储层、引导与分区层、传输与协议层、安全与校验层、发布与运维层。每一层都有明确的输入、输出与失败处理策略，上层依赖下层的稳定能力。
三、实战路线图：从镜像到设备的七个阶段
把框架落到操作层面，一次完整升级可拆为七个阶段。每个阶段都有明确的“进入条件”和“退出条件”，任一条件不满足就应停止并回退，而不是继续冒险。
| 阶段 | 关键动作 | 退出条件 |
|---|---|---|
| 1 需求与版本定义 | 确定目标版本、硬件范围、升级窗口 | 版本号与兼容矩阵确认 |
| 2 镜像构建 | 编译、裁剪、生成签名镜像 | 镜像哈希与签名通过 |
| 3 传输通道准备 | 选择 UART/USB/OTA，配置分包参数 | 链路连通、速率稳定 |
| 4 写入与校验 | 擦除、写入、逐包校验 | 整镜像校验一致 |
| 5 启动切换 | 置启动标志、复位、Bootloader 选择分区 | 新固件正常启动 |
| 6 灰度与监控 | 分批下发、采集成功率与异常日志 | 灰度指标达标 |
| 7 归档与复盘 | 记录版本、设备清单、失败样本 | 手册更新完成 |
四、典型场景：一次 OTA 升级的失败复盘
某现场设备通过 4G OTA 升级，约 3% 设备升级后无法启动。排查发现：这些设备在写入新分区时遭遇瞬时断网，传输层虽做了重传，但未校验“整镜像完整性”，Bootloader 仅检查了分区头就切换启动，导致运行了不完整镜像。
[升级日志片段]
recv pkt 1024/2048 ... timeout, retry 3
recv pkt 2048/2048 done
verify header: OK
verify image : SKIPPED <-- 缺失整镜像校验
set boot flag: B
reboot
[启动失败] image crc mismatch, no fallback
误区：只校验“包头”或“分包 CRC”，不等于校验“整镜像”。正确做法是写入完成后对整镜像做一次 SHA-256 或 CRC32 全量校验，校验失败必须清除启动标志并回退到旧分区。
复盘后补充三条手册规则：其一，传输层必须支持断点续传与整镜像校验；其二，Bootloader 启动前必须验证镜像签名与长度；其三，A/B 分区必须保留可回滚的旧镜像，且回滚动作要记录日志。
五、本课程的学习方法
- 按链路学：不要孤立记命令，要理解每个动作在五层框架中的位置。
- 按失败学：每学一个环节，先问“它可能怎么失败，失败后如何恢复”。
- 按手册写：把每节的检查项整理进自己的升级手册，形成可执行清单。
- 按数据验：升级成功率、回滚率、平均耗时，是判断方案好坏的硬指标。
建议准备一份“升级检查表”，至少包含：版本兼容矩阵、镜像哈希、传输参数、校验方式、回滚条件、灰度比例、监控指标、归档路径。后续章节会逐项填充这张表。
固件升级的难点不在“写进去”，而在“写进去之后仍然可控”。掌握这套框架与路线图，你就拥有了把一次升级从“碰运气”变成“可复现工程”的基础。