📚 课程目录第4章升级包制作与管理

4. 升级包制作与管理

在OTA测试与升级脚本联调中，升级包是贯穿始终的核心交付物。它既是固件团队构建产出的“货物”，也是测试团队验证升级逻辑的“输入”，更是设备端升级脚本解析、校验、写入、回滚的“依据”。一个设计良好的升级包，应当同时满足可识别、可校验、可追溯、可增量、可回滚五项要求。本节围绕固件打包、差分升级、签名验签、版本管理、元数据描述与存储策略六个关键环节展开，帮助读者建立从构建到落盘的完整认知。

一、固件打包：从镜像到可分发单元

固件打包不是简单地把bin文件压缩成zip。它需要把多个分区镜像、元数据、签名、校验信息按照设备端可解析的格式组织成一个升级包。常见结构包括包头、分区表、镜像数据区、签名区和尾部校验区。包头通常包含魔数、包格式版本、目标设备型号、目标版本号、包长度等字段；分区表描述每个分区的名称、偏移、长度、写入地址和校验方式。

打包工具一般由构建系统调用，输入是编译产物和配置清单，输出是带签名的升级包。以下是一个典型的打包命令示例：

ota_pack \
  --model=GW-200 \
  --version=1.4.2 \
  --from-version=1.4.1 \
  --bootloader=bl.bin \
  --kernel=kernel.img \
  --rootfs=rootfs.squashfs \
  --app=app.bin \
  --meta=meta.json \
  --sign-key=private.pem \
  --output=gw200_1.4.1_to_1.4.2.ota

打包阶段要特别关注分区对齐、镜像顺序和长度字段。设备端升级脚本通常按分区表顺序写入，如果偏移或长度错误，轻则升级失败，重则破坏bootloader导致设备变砖。

二、差分升级：减小包体与传输成本

全量包体积大，在弱网或流量受限场景下体验差。差分升级通过对比旧版本与新版本镜像，生成补丁文件，设备端在升级时用旧镜像加补丁重建新镜像。常见算法有bsdiff、hdiffpatch、xdelta等。差分升级的关键在于基准版本必须精确匹配，否则补丁无法应用。

差分升级的流程可以概括为：构建系统保留历史版本镜像，打包工具根据from-version选择基准镜像，生成差分包并写入元数据中的base_version和patch_algorithm字段。设备端升级脚本先校验当前版本是否等于base_version，再读取旧分区数据，应用补丁，计算新镜像哈希，最后写入目标分区。

差分升级的误区：只校验补丁签名，不校验基准镜像哈希。如果设备当前镜像被篡改或损坏，补丁应用后可能生成错误镜像。正确做法是同时校验基准镜像哈希和补丁签名。

三、签名验签：保证来源可信与完整性

签名验签是升级包安全的第一道防线。制作阶段使用私钥对升级包摘要进行签名，设备端使用预置公钥验签。常用方案是RSA-2048或ECDSA-P256配合SHA-256。签名对象可以是整个包，也可以是包头加镜像数据区，签名本身放在包尾或独立签名区。

验签流程通常包括：读取公钥、解析签名区、计算摘要、验证签名、校验镜像哈希。任何一步失败都应终止升级并记录错误码。测试联调时，要重点验证公钥不匹配、签名被篡改、包被截断三种异常场景。

# 设备端验签日志示例
[OTA] verify signature: start
[OTA] pubkey id: GW200-PROD-01
[OTA] digest algo: sha256
[OTA] signature verify: OK
[OTA] image hash check: OK
[OTA] verify signature: PASS

四、版本管理与元数据描述

版本管理要解决“谁是谁的升级路径”问题。建议采用语义化版本号，并在元数据中明确model、version、from_version、min_bootloader、build_time、changelog等字段。元数据通常以JSON描述，打包时嵌入包内，同时可单独发布到升级服务器供设备查询。

元数据中的依赖关系非常重要。例如新固件要求bootloader不低于某版本，若设备当前bootloader过低，升级脚本应拒绝升级并提示先升级bootloader。以下是一个元数据示例：

{
  "model": "GW-200",
  "version": "1.4.2",
  "from_version": "1.4.1",
  "package_type": "diff",
  "base_version": "1.4.1",
  "patch_algorithm": "hdiffpatch",
  "min_bootloader": "2.1.0",
  "signature": "RSA2048-SHA256",
  "images": [
    {"name": "kernel", "offset": 4096, "size": 8388608, "sha256": "a1b2..."},
    {"name": "rootfs", "offset": 8392704, "size": 33554432, "sha256": "c3d4..."}
  ],
  "build_time": "2025-03-18T10:22:00Z"
}

五、存储策略与升级包生命周期

升级包在设备端和服务器端都需要存储策略。设备端通常采用A/B双分区或独立ota分区暂存升级包，写入前要检查剩余空间、擦除块对齐和坏块管理。服务器端则要保留历史版本、差分包和全量包，并支持按model、version、from_version检索。

存储位置	存放内容	关键约束	清理策略
设备端ota分区	当前待升级包	空间≥包体+校验区，擦除块对齐	升级完成后擦除
设备端备份分区	旧版本镜像	支持回滚，保留至少一个版本	新版本稳定后释放
升级服务器	全量包、差分包、元数据	按model/version索引，签名可验证	保留最近N个版本
构建产物库	历史镜像、补丁、签名私钥	权限隔离，私钥不落普通磁盘	按发布周期归档

六、联调复盘：升级包制作常见问题

在OTA测试与升级脚本联调中，升级包相关问题占比很高。常见误区包括：元数据版本号与包内镜像版本不一致；差分包基准版本选择错误；签名私钥与设备公钥不匹配；分区偏移未按擦除块对齐；包尾校验区被截断。建议在打包流水线中加入自动校验步骤，包括元数据字段完整性检查、镜像哈希比对、签名验签自测和包长度校验。

联调时可以先在PC端用升级脚本模拟器解析升级包，确认包头、分区表、签名区和元数据都能正确读取，再烧录到设备验证。这样能把“包制作问题”和“设备端升级问题”快速分离。

总结来看，升级包制作与管理不是单一工具问题，而是构建、安全、版本、存储、设备端解析多方协同的工程问题。把打包规范、差分基准、签名验签、元数据字段和存储策略固定下来，并在联调前用模拟器做包解析自测，可以显著降低OTA升级失败率，也能让升级脚本的异常分支测试更有针对性。