RK3588 固件怎么升级？OTA、A/B 分区与差分方案
RK3588 固件升级方案按场景选：产线与返修走本地 SD 卡/U 盘或量产工具，现场小批量走网络手动触发，大规模在线才上 OTA 平台化。机制是 A/B 双分区、原子切换与完整性校验，再配灰度发布。
RK3588 固件升级有哪些方案？怎么按场景选？
方案没有优劣，只有匹配度。判断顺序：先看设备数量与分布，再看是否允许停机，再看失败代价。
| 场景 | 推荐方案 | 主要代价 | 关键风险 |
|---|---|---|---|
| 产线烧录与售后返修 | 本地 SD 卡/U 盘或量产烧录工具 | 需现场人工操作，人力成本高 | 误触覆盖、版本错乱 |
| 现场小批量（几十台内） | 网络手动触发升级 | 需逐台确认，响应慢 | 版本基线不统一 |
| 大规模在线（数百台以上） | OTA 平台化 + 灰度发布 | 需搭建服务端与监控 | 失败面放大、带宽与并发压力 |
| 紧急修复单个缺陷 | 差分包定点升级 | 生成与校验链路复杂 | 基线不匹配导致校验失败 |
量产工具适合芯片级首次烧录，SD 卡/U 盘适合无网络或返修场景，网络手动触发用于试产与现场排障，OTA 平台化是规模化后的必然选择。设备超过数百台或分布在多地，就应尽快转向 OTA 平台化，逐台上门升级的时间与差旅成本会迅速失控。RK3588 的启动方式与分区表以原厂官方规格书与核心板厂商文档为准，不同平台的烧录工具与镜像格式并不通用。
整包升级与差分升级怎么选？
两种形态的差异在体积、速度与链路复杂度：
- 整包升级：下发完整镜像，实现简单、对版本基线无要求；代价是包体大、下载慢，对带宽与存储要求高。
- 差分升级：只下发新旧版差异，包体常见为整包的一到两成，下载快、省流量；代价是对基线要求严格，包体必须与设备当前版本精确匹配，生成与校验链路复杂度明显上升。
选择可量化：单台整包 1~2GB、全网上千台时，整包总流量与时间成本高，差分包收益明显；设备仅几十台且网络良好时，整包更省事。差分方案要额外解决三件事：基线管理（为每个历史版本预生成差分包）、回退兼容（跨版本跳升可能没有差分链）、校验强度（还原后必须重新做完整性与签名校验）。常见做法是「整包为主、差分为辅」。
A/B 双分区是怎么工作的？
A/B 把存储划分为两套可启动槽位，升级写入非活动槽位、重启后切换，关键收益是任何时刻都保留一个可用系统。工程上关注四点：
- 分区规划：bootloader、boot、system/rootfs、vendor 等关键分区成对存在，用户数据分区共享。
- 空间代价：双份系统分区使存储占用接近翻倍，eMMC 容量规划要算进去。
- 切换与回滚触发：升级后首次启动置为「试运行」，若在设定启动次数或时间内未收到确认，bootloader 自动回滚旧槽位。
- bootloader 侧标记：槽位标记、试运行计数与确认状态要存在升级不会覆盖的位置，否则判断会失效。
常见的坑是只做双分区却没做回滚判定：新系统能启动但业务异常，设备会停在坏版本上。回滚判定建议用双条件——系统健康标志加业务自检结果，任一不通过就回滚。
升级流程怎么设计？六个步骤与失败处理
一次可靠升级可拆成六步，每步都要定义失败动作：
- 版本校验：比对当前与目标版本，确认升级路径合法；失败则中止并回报原因。
- 下载：分块下载，支持断点续传与限速；失败按退避策略重试。
- 完整性校验：校验哈希与签名；失败则删除重下，绝不写入存储。
- 写入非活动分区：擦除、写入、读回比对；失败则清理该槽位，活动系统不受影响。
- 重启试运行：切换启动标志并重启；启动失败由 bootloader 兜底回滚。
- 提交或回滚：业务自检通过后提交并清除试运行标记；未通过则回滚并上报。
贯穿六步的原则是「永不原地写活动分区」：在活动分区写入时一次掉电就可能让设备无法启动。签名与校验的机制细节属于安全范畴，可参考同系列安全加固文章。
升级期间断电怎么办？
现场常见故障不是网络问题，而是升级中断电或掉电重启。防护分三层：
- 双备份区：用 A/B 分区保证任何时候都有一套完整可启动系统。
- 原子切换：把「切换生效」做成一次不可分的标记写，只有旧版或新版生效，没有中间态。
- 避免活动分区原地写：只写非活动分区；配置等易变数据放独立存储并备份。
建议给写入加超时与重试计数，并记录掉电时间点，便于判断设备停在哪一步；有掉电检测能力时可在电压跌落时暂停升级并安全落盘。断电保护效果须以实测确认：在写入过程中反复制造掉电，看设备能否稳定回到某一可用版本。
灰度发布与常见坑怎么处理？
大规模升级须先灰度再放量：先小批量试点（覆盖不同硬件版本与环境），观测失败率与关键指标（启动成功率、可用性、重启次数），达标后按 5%~10%、30%、全量逐步放量，全程保留一键回退。失败率超阈值立即暂停。
常见的坑集中在几处：配置被覆盖（配置文件放在系统分区而非独立配置分区）、SD 卡/U 盘升级被误触（本地升级需明确触发条件与防呆设计）、版本号未递增（回滚判断与版本比较失效）、混合版本设备跨版本跳升（差分链断裂或路径未测试）。Android 与 Linux 发行版机制不同：Android 通常有官方 A/B 与只读系统分区，Linux 更依赖自建分区与包管理，回滚与校验链路需团队自建。具体实现与分区结构以平台官方规格书为准。
常见问题
- Q1：RK3588 设备一定要用 A/B 双分区吗？不必强制，但无法现场干预的在线设备强烈建议。单分区升级掉电可能无法启动，A/B 用一份额外存储换取可回滚能力，通常值得。
- Q2：差分包和整包怎么配合使用？日常升级用差分包省流量，整包作为兜底；跨版本跳升或差分链缺失时改发整包，差分还原后必须重新做完整性与签名校验。
- Q3：升级断电后设备会变砖吗？遵循「不原地写活动分区 + 原子切换 + 试运行确认」，掉电通常只中断升级，设备应能回到旧版本继续运行，需实测确认。
- Q4：灰度发布的比例怎么定？先取覆盖各硬件版本的少量设备，观测一个业务周期后从 5%~10% 起放量，指标达标才继续，异常立即暂停回退。