嵌入式Linux OTA更新第1部分：基础与实现

更新需求

嵌入式Linux产品离开实验室进入现场后，如何接收更新成为关键设计决策。

虽完美应用似免疫变更，现实是软件必然积累Bug，联网或互联设备常需安全补丁。即使理论完美固件也须容纳第三方库漏洞。

考虑Heartbleed漏洞(CVE-2014-0160)暴露OpenSSL加密库。该缺陷影响约三分之二网站，至今无数嵌入式Linux设备仍携带未修补OpenSSL构建，面临被利用风险。

基于块 vs 基于文件更新

Linux更新机制大致分块更新和文件更新。块更新单次原子操作覆盖整个分区或块设备；文件更新替换单个文件或包——类似桌面/服务器发行版“apt-get upgrade”。

嵌入式Linux偏好块更新，因整个文件系统通常由单一构建管线产出、产品存储空间固定。单步更新整个分区也简化回滚：保留前一镜像副本直到新镜像验证通过。

设备不应处于不可用状态，尤其掉电或写入失败中途。常规缓解是维护次级分区，主镜像启动失败时接管。

图1. 失败恢复 – 回退选项 (来源：ByteSnap)

两常见模式：

救援分区策略 – 引导加载程序启动小救援镜像，更新完成后启动主固件。允许主分区占用大部分存储，但需两次重启(进救援、再进主)。
双根文件系统策略 – 并存两完整根文件系统。引导加载程序启动时在两者间切换。更新时覆盖非活动镜像，仅需一次重启。此法单镜像可用空间减半，但恢复更快、零停机。

存储充足时，双根文件系统法通常推荐，因其简单性和性能。主镜像大且备用空间有限时，救援法有用。

注意引导加载程序通常在此设置中不可变。更新引导加载程序需额外引导加载程序分区和板级管理控制器(BMC)编排切换——增加硬件复杂度和成本。

图2. 失败恢复 – 板级管理控制器 (来源：ByteSnap)

因BMC增硬件和固件，多数设计师倾向让引导加载程序尽可能小且可靠，使其永不需OTA更新。

U-Boot存储非易失性环境，可从Linux查询、启动时操作。这些变量适合编码活动分区、追踪启动成功、编排故障转移逻辑。

典型模式含：

将此状态存储在U-Boot中，引导加载程序可在新镜像连续失败配置次数时自动回滚前一镜像。

图3. U-Boot环境变量 (来源：ByteSnap)

嵌入式