固件 OTA 与双分区 / A-B 更新架构 · 技术探讨

更新这个词被用得太随意了 —— 本文把它拆成传输、写入、切换三件互不相同的事，分别讲清它们的原子性关口、判据与回滚手段。面向嵌入式存储与固件工程参考。 ｜ 编制日期 2026-10-14 ｜ 版本号 Rev 1.0

前言

做固件的人迟早会遇到同一个噩梦：设备在现场更新到一半断电了，从此再也起不来。事后复盘时，往往发现所有「该做的」都做了 —— 用了 TLS 通道、做了分块校验、写了重试逻辑 —— 唯独没有回答一个问题：假如现在这一刻掉电，上电后第一段代码会读到什么？

这个问题问的已经不是传输，而是可信性：系统在任何时刻被切断电源，重新上电时都必须落在一个可以被明确判定的状态里 —— 要么明确地跑旧版本，要么明确地跑新版本，要么明确地进入恢复流程；绝不能出现「看情况，取决于运气」。

与第 2 章配合的这个视角，也划清了本文与《嵌入式启动介质与启动架构》篇的边界：那篇回答「谁负责把第一段代码读起来」，本文回答「当读到的东西是坏的、或者刚刚被换过一轮的时候，谁负责改判、按什么凭据改判」。

结论： OTA 的核心不是把新固件传下去，而是保证更新过程中的任何一次中断都不会把设备变成砖。 做法是：把它拆成传输、写入、切换三件彼此独立的事，分别为它们建一道原子性关口 —— 传输关口允许任意次失败且零代价；写入关口保证「旧镜像在任何一个断电时刻都仍然完整」； 切换关口由一个持久化的、可被下一段代码读懂的状态来决定「现在跑哪一份」，并且任何没能在确认窗口内证明自己活着的新版本都必须能自动退回。

读者路径

• 做方案评审 / 选型：第 1 章建立框架，第 3 章与第 11 章给结论，可直接用于决策。
• 写 Bootloader / Loader：第 2 章划清层级责任，第 4 章是本文技术密度最高的部分（落盘顺序、尝试计数、回滚判据）。
• 做镜像与服务端：第 5 章讲格式与分块，第 6 章讲签名、信任链与防回滚。
• 做 MCU 侧：第 7 章（介质约束）加第 8 章；做 Linux 侧：第 9 章。
• 处理现场问题：第 10 章与附录 C的排查手册可直接对照使用。

1. 为什么 OTA 是一个可信性问题而不是传输问题

这一章给出全文的分析框架。结论先行：把 OTA 当成传输问题的团队，会把绝大部分精力花在代价最低的那一段上，而在代价最高的那一段裸奔。

1.1 OTA 失败的三种代价

「更新失败了」是一句信息量极低的描述。同样是失败，发生在还没有开始写的那一刻，和发生在已经把旧镜像的前 4 KB 擦掉的那一刻，是两种完全不同的事件。要讨论设计，先把代价量化。

工程上把 OTA 失败的代价分三类，它们的数量级相差好几个数量级，这决定了资源应该怎么分配：

这里值得强调的是第三种代价常被漏掉。很多团队的防御清单里只有「不能变砖」，却没有「不能悄悄退回到有漏洞的旧版本」和「不能让人往里投放任意固件」。这两条属于更新机制自身的Trustworthy，与传输是否可靠无关 —— 用最结实的 TLS 通道送一个被降级签名的旧固件，攻击照样成立。第 6 章会把这条展开。

1.2 「传下去」与「变得可用」是两个独立问题

把「更新」这个词拆开，它其实包含三件性质完全不同的工作：

1. 传输：把服务端产出的字节串，通过某个通道（蜂窝、以太网、串口、本地总线、离线 USB）搬到设备端的一块暂存区。
2. 写入：把暂存区里的字节串，按某种顺序写进某个非易失的目标位置，并且在这个过程中不动正在运行的那一套代码。
3. 切换：在某个明确的时刻，让下一次上电（或下一次跳转）跑到新的那一套代码上去，并且为「它跑不起来」准备退路。

关键区别在于失败的可重试性：传输失败，重试的代价只是时间和流量，设备的状态完全没有被修改；写入与切换失败，设备的非易失状态已经被修改了，重试未必能把状态还原到修改之前。

这张表里最需要记住的是第三行：只有传输阶段的失败是「零副作用」的。写入与切换一旦开始，设备的持久状态就已经在被修改，此后的一切设计目标就变成了「让每个中间状态都可判定」。

这张图是全文的骨架。左侧那一列无论失败多少次都不留痕迹；右侧那一列从第一个字节写进闪存开始，设备就有可能被断电，而每一次断电都会留下一个需要被解读的中间状态。

1.3 更新过程的三个原子性关口

「原子性」用在嵌入式更新里，含义与数据库事务并不完全相同。这里把它定义为一个可判定性要求：

更新在任意时刻被中断后，重新上电的那段代码必须能够回答两个问题：现在这个状态属于哪一类？接下来该做什么？如果答案依赖于「运气」或者「写得快不快」，这套方案就没有原子性。

要满足这个要求，只需要盯住三个关口。每个关口都有明确的跨越动作、成功判据和中断后果：

1.4 与启动介质篇的分工：谁负责读起第一段代码

本系列里还有一篇《嵌入式启动介质与启动架构》，它和本文看的是同一条芯片上电到应用跑起来的过程，但角度完全不同。混读容易串线，这里先划清边界：

一句话概括分工：那边负责「读起来」，这边负责「读到的东西换了、或者坏了的时候，改由谁裁决」。

这里有一个容易踩的坑值得单独点出来 —— 有些人把所有期望寄托在不可更新的那一层（BootROM 或掩膜固化的第一级引导）上，希望它来做版本判决、降级保护和回滚。这不成立，原因很简单：不可更新就意味着它对「版本」的理解永远停留在出厂那一天。版本单调性、密钥轮换、新引入的镜像格式，它一概看不懂。把判决逻辑写死在不可更新的层里，等于在出厂的那一刻给整个产品线判了刑。

1.5 本文主线与读者路径

全文的主线是一条：说清楚「任何时候断电，设备为什么一定还能起来」。后续各章按这条主线推进：

关于数值：本文刻意不写寄存器地址、位域、操作码数值与厂商商业数据。所有涉及具体数值的地方（时间、擦写次数、容量开销）都只给量级与关系，落地时请以正式 datasheet / 规范为准。

2. 启动链视角：更新能挂在哪些环节

要讨论更新安全，必须先把「从复位到应用跑起来」这段路拆成层，然后问每一层同一个问题：它能不能被现场改写？写坏了能不能退回来？

2.1 从 ROM Boot 到应用的分层

不同芯片、不同 SoC 的分层名称各不相同（ROM / SPL / SBL / 二级 Loader / bootloader / 应用），但抽象结构是稳定的：每一层负责把机器收拾到一个「能拿下一层」的状态，然后把控制权交出去。更新的绝大部分工作发生在最后两三层。

这张表里最值得注意的不是某一层的职责，而是层与层之间的交接面要尽可能窄。理想情况下，上一层只需要知道「下一层放在哪里、多大、头部长什么样、从哪里开始执行」这四件事，其余一概不问。交接面越窄，就越容易做校验，也越容易在未来替换某一层的实现。

2.2 不可更新的第一级能兜住什么

BootROM 与掩膜固化的第一级引导有一个共同点：它们的行为在产品生命周期内是不可变的。这个性质带来一个极强的推论 —— 它们所有的能力都是出厂那一刻的快照，无法吸收后来出现的任何新需求。

因此，正确的设计思路是给它们做减法：把能做的事情做到最小且足够健壮，把不能做的事情明确地不承担，留给可以更新的下一层。

2.3 可更新的第二级 Loader

第二级 Loader 处在一个尴尬的位置：它是整个更新机制的执行者，同时它自己也是一个需要被更新的固件。它负责校验别的镜像，那谁校验它？它负责在应用挂的时候回滚，那它自己挂了怎么办？

这个问题没有免费的答案，只有三种各有代价的解法：

无论选哪一种，有三条纪律是共通的：

• Loader 必须验证它要加载的东西，不能把信任交给「上一次似乎成功了」。
• Loader 自身的更新必须走与业务镜像同样严格（通常更严格）的流程，因为它是最不能被写坏的那一份。
• Loader 必须能在「自己刚刚被更新过，但应用还没起来」这个状态下被识别 —— 也就是说，Loader 的更新也必须有「待确认」语义，只不过它的确认者通常是紧接着的一次成功启动。

2.4 应用镜像的位置与启动判决

「应用镜像放在哪里」看似是个地址问题，实际上是个元数据驱动问题。硬编码绝对地址的好处是简单，代价是：一旦分区布局调整，整个启动链都要跟着改，而分区布局恰恰是产品演进过程中最容易变的东西之一。

更稳的模型是：槽位是逻辑概念，物理位置由分区表给出，当前该跑哪个槽由持久化元数据给出。判决的执行者（第二级 Loader）只做三件事：读元数据 → 选候选 → 验证候选。

这里有一个关键的顺序问题常被搞反：是先「判决」再「校验」，还是先「校验」再「判决」？

正确的答案是先读元数据选出一个候选，再对候选做校验，校验不通过就换下一个候选。原因是：元数据本身很小、校验很快、而且可以有冗余；而逐个校验所有候选镜像的代价太大（尤其是要验签名的时候）。把元数据作为「先看哪里」的索引，把真正的重验证留给被选中的那一个，既能保证安全性，也把启动时间压了下来。

这条结论还有一个隐含要求：元数据自身必须是可校验的，否则「元数据说 A 槽坏了」这句话本身可能是字节翻转的产物。第 4 章会把元数据的冗余、校验与落盘顺序展开。

2.5 各环节的可写性与回滚能力对照

把前面几节合并成一个可以贴在评审会上的结论表：

3. 分区方案：单区、双区与 A/B

分区方案回答的是一个非常具体的问题：当我要写新镜像的那一刻，正在运行的那个镜像放在哪里、它会不会被这次写入碰到。

3.1 单区就地更新的三种失败模式

单区方案（就地更新 / in-place update）的定义很简单：整个介质上只有一份应用镜像，更新就是把新的字节覆盖到旧的字节上面去。它的优点是几乎不占额外空间，实现也最短 —— 一个发送端、一个写介质的循环、一个跳转地址。

它的缺点同样简单：从「擦除命令生效」到「新镜像写完并通过校验」之间，介质上不存在任何一份完整的、可启动的应用镜像。这段时间里只要断电，设备的凭据就断了。

需要区分的是三种后果完全不同的失败模式：

模式①最直观，也最让人警觉；真正阴险的是模式②和模式③。模式②的问题在于「看似成功」—— 如果只检查「写入返回 OK」而不做回读和摘要比对，设备会把一个半新半旧的镜像当成好东西来启动。模式③的问题则在于它根本不存在退路：即使新版本明显跑不稳，也没有另一份可以回去。

3.2 双区（A/B）的切换模型

双区（A/B，也常写作双槽、slot A / slot B）的核心思想只有一句：任何时刻都只有一份镜像在被运行，而写入永远只发生在当前不运行的那一份上。

这句话的威力在于它把一个复杂的顺序问题变成了一个简单的归属问题：既然正在跑的那一槽不会被碰，那么「更新写到一半断电」这件事在语义上就不可能破坏正在运行的系统。剩下要回答的只有两个小问题：新写的这一份什么时候生效，以及它如果不争气怎么退回来。

注意表里第四行：切换本身几乎不搬任何东西。这正是双区方案在工程上可行的原因 —— 真正耗时的部分（擦除、写入、回读校验）全都发生在「不急着生效」的阶段，而真正决定生死的那个动作只是一个很小的写操作。

这个性质带来一个重要推论：如果切换动作本身做不到原子且可靠，那么前面搬了多少字节都不会让设备更安全。所以第 4 章要专门讨论这「很小的一步」。

3.3 双区的容量代价与「两份都放不下」

双区不是免费的。它最直接的成本是一句简单的算术：假设介质总容量减去引导区、元数据区、数据区之后，剩下来的可用空间是 S，那么双区方案下单个应用镜像可用的上限约为 S 的一半。镜像尺寸稍一膨胀，就会撞上这堵墙。

需要强调：这里的「约一半」说的是关系，不是精确数字。真实开销还要算上擦除块的对齐损耗、坏块预留、旧布局切换期的浪费，以及更新机制自身（例如第二份元数据槽）所占的地皮。具体请以正式 datasheet 与实际布局为准。

3.4 恢复分区与工厂分区

「恢复分区」和「工厂分区」这两个词经常被混用，但它们承担的职责不同，混用会导致保护策略搞错：

这里最容易被忽略的是最后一行。更新机制再完美，也架不住一次分区表错误把序列号与校准区擦掉 —— 那类数据一旦丢了，设备即便还能启动也已经不再是原来那台设备。

一条实用规则：凡是不能被重新生成的数据，都必须放在更新流程永远不会写入的区域，并且独立冗余。「我们不会去写那里」这种口头承诺不构成保护，必须是布局上写不到、或者硬件上写不动。

3.5 分区表自身如何更新

分区表是一个很特殊的对象：它描述的正是「别的更新该怎么落盘」这件事本身。如果分区表自身的更新不安全，那么再好的镜像更新流程也建立在一个可能随时被改写的基础上。

常见做法按安全程度从低到高排列：

3.6 分区方案对照

把三种主要方案放在一起对照：

4. 切换机制：什么时候新固件才算生效

这一章是全文技术密度最高的部分。前面所有搬字节的工作，最后都要落到「新固件到底在哪一瞬间算数」这个点上；而这个点本身，是全过程中唯一必须做得绝对可靠的一步。

4.1 切换点的三个候选

「什么时候新固件才算生效」这个问题有几个天然的候选答案。它们的差别看起来只是措辞不同，实际决定了整套方案的失败代价：

关键区别在于可重复性。候选①依赖的是一个稍纵即逝的事件，断电之后没有人知道它发生过没有；候选②依赖的是一个持续过程的中间时刻，本身就定义不清；只有候选③把「当前跑哪一份」变成了一个写在非易失载体上、每次上电都会被读取、读完就能作出决定的状态。

换句话说：生效不是一个事件，而是一个持久状态被下一次启动读到。

4.2 启动标志与尝试计数

要让「当前生效的活动 slot」这个状态能被可靠地读出，至少需要两个持久化变量：

• 待确认标记（pending / trial flag）：表示「下一次上电要走一次可能是新的路径」。它区分了「稳定运行的常规启动」与「刚刚改判过的一次尝试」。
• 尝试计数（attempt counter / rollback index）：表示「这条路已经失败过几次」。它是防止系统陷入无限重启的唯一手段。

这两个变量都必须写在断电后会保留的地方，而且必须能被原子地更新。把它们放在内存里、或者放在会随内核重启而重建的地方，是这一类设计里最常见也最致命的错误 —— 断电之后那里什么都不剩。

4.3 回滚触发的判据

有了尝试计数，接下来要回答的是：什么叫做「这次没通过」？这个问题没有唯一答案，它取决于产品能容忍什么，也取决于做可行性权衡时的取舍。这里给出常见的几种判据与它们的副作用：

一条重要的设计原则：判据应当「宁可迟钝，不要冲动」。冲动地回滚会把「偶发的、本来能自愈的问题」升级成「一次完整的服务中断」，而且一旦开始回滚，往往在很短的时间内连续波及整批次设备。判据越激进，誤杀率越高，这在第 10 章讨论批量更新时会变得更严重。

4.4 元数据的落盘顺序

这是本章最核心的一节。前面说过，闪存的擦写本身不是原子的：擦了不一定写完，写了不一定写完头部，写完头部不一定写完指向。我们能做的最有力的事情，不是去消除这些中间状态（做不到），而是把它们的发生顺序安排成「任何一种中间状态都能被判定」。

核心规律：先写「没有它也能活」的东西，后写「唯一的那个开关」。切换开关必须是整个过程中最后一个落盘的字节。

把这张图读成一句话：越往后的一步，它的失败代价越高，所以它必须写得越小、越靠后。第③步是整个更新过程中唯一在语义上不可替代的一步 —— 在它之前，任何中断都只是「白干一场」；在它之后，一切由尝试计数负责。

由此还可以推出几条实用的纪律：

• 镜像体先写，头部最后写。头部是这段字节串的「自我描述」，它的存在与否就是这支镜像是否成立的唯一凭据。
• 槽元数据（这一槽的存在与健康状况）先于全局指向。先让世界知道「这份东西存在且完整」，再让判决者考虑要不要用它。
• 永远不要试图「同时」更新两件东西。没有同时，只有顺序；凡是以为在同时更新的地方，实际都是在赌运气。
• 任何写完之后都必须回读校验。写入返回成功只是说命令被接受，不代表字节落到位了。

4.5 元数据自身的冗余与校验

元数据有一个残酷的属性：它比它描述的对象更值得关心。一个槽里的镜像坏了，判决者还能去挑另一个槽；元数据坏了，判决者连「有哪几个槽」都不知道。

4.6 失败注入测试要点

更新机制的正确性无法靠正常路径的测试来证明，只能靠刻意的失败注入。以下是必须覆盖的项目：