嵌入式启动介质与启动架构

从 BootROM → XIP 直跑 → bootloader / loader → 操作系统这条链出发，讲清四类启动介质该怎么排 —— 一份跨 MCU 与 Cortex-A 两类平台的通用基础篇 ｜ 编制日期 2026-10-14 ｜ 版本号 Rev 1.0

报告总结

嵌入式项目里，「启动介质选哪一颗」这个问题几乎总是被简化成一道容量题：代码装不下就换大一档的器件。但真正决定方案的从来不是容量，而是四件更靠前的事——启动时刻的行为是否确定、介质本身会不会失效率、成本落在哪一段、出了问题能不能维护。

这份文档要做三件事：

• 把启动链拆成可对齐口径的四段：复位与取指、ROM 初始化、介质初始化、加载与移交。每一段谁做、做什么、占多少时间，都给可套用的模板。
• 把四类介质放进同一套语言里对齐：片内 BootROM、SPI NOR、SPI NAND / SD NAND、eMMC / UFS，分别讲清它们「启动友好」在哪里、代价在哪里。
• 给一个能落到具体场景的排序框架：不用容量排序，用启动确定性、失效率、成本、可维护性四维排序，并给出五类典型产品的推荐级别总表与自查清单。

覆盖 MCU 与 Cortex-A 两类平台：前者关心代码容量与极简确定性，后者关心容量、分区与 OTA 原子性。两者共用同一套分层模型，只是每一层的权重不同。

结论： 启动介质不是按容量选的，是按启动确定性 + 失效率 + 成本 + 可维护性四个维度排的。 容量只决定「装不装得下」，而这四个维度决定「这设备能不能上线」—— SPI NOR 在小容量高确定性场景仍是首选，NAND 类介质必须配套一块 NOR 才敢用来做引导，eMMC / UFS 是大容量与 OTA 原子性的必选项而非可选项。 先把「谁做第一段引导代码」这件事定下来，再谈容量与价格。

读者路径

• 要做选型决策：直接看第 8 章（四个维度 + 场景排序 + 自查 8 问）与附录 B（四介质对照总表）。
• 要理解启动链本身：按 1 → 2 → 3 章顺序读，这是从复位到操作系统接管的完整因果链。
• 做 Cortex-A / Linux 平台：第 4、6、7 章 + 第 9 章（bootloader 与 loader 切分、安全启动信任链）。
• 做 MCU / 裸机或 RTOS 平台：第 2、3、5 章 + 第 10 章（启动加速），重点看 XIP 与省时手段。
• 现场排启动故障：第 11 章（三段定位法 + 12 条以上失败清单 + 案例复盘），可当手册翻。
• 要落地时间预算与验证用例：附录 C 两个模板直接套用。

1. 启动链的四个阶段

启动不是一件事，而是一条被切成四段的链。把这四段的口径统一之后，后面所有介质之间的比较才有意义——否则「启动只要 80 ms」和「启动要 2 s」很可能说的是完全不同的两段。

上图是全文的骨架，后面每一章都在细化其中某一段或某一类介质：第 2、3 章讲第一段与第二段的做法（BootROM 与 XIP / 拷贝），第 4~7 章按四类介质分别展开，第 8 章把它们放进同一套排序框架，第 9~11 章处理移交、加速与排障。

1.1 从复位到第一行指令：复位向量与初始栈指针

设备上电或复位释放之后，处理器做的第一件事不是「运行你的代码」，而是从固定位置取一条指令。这个固定位置就是复位向量，通常指向一段极短的入口代码。紧跟着它的还有一件事：装载初始栈指针，让后续的函数调用有地方可退。

这两步是整条链上唯一「不可协商」的部分，它们决定了三件事：

• 入口位置的确定性。介质上的内容可以被换、被改、被擦坏，但复位向量的位置不能变——所以启动镜像必须放在一个固定偏移处，而不是「随便找个空位」。
• 栈的有效性。栈指针必须落在真实可写的 RAM 里。BootROM 自带的 RAM 通常很小，很多深层调用链必须靠自己尽早把栈搬走。
• 失败的可观测性。如果连这一步都过不去，后面所有日志手段都是空的——这也是「无输出」这类故障最难定位的原因。

1.2 阶段划分：ROM 初始化 → 介质初始化 → 加载 → 移交

把启动链切成四段的理由不是「好看」，而是这四段的责任方不同、可改动程度不同、时间量级不同。分清责任方，才能在出问题时知道该找谁；分清可改动程度，才能判断哪些环节值得投入优化。

四段之间有两条经常被忽略的隐性契约：一是交接格式——上一段交给下一段的是什么（一段内存镜像，还是「一个可跳的地址」），这段约定决定了后面能不能灵活替换实现；二是失败语义——下一段失败时，上一段是重试、跳过、还是回退。没有这两条，启动链一旦在中间出错就只能从头重来，现场定位成本极高。

1.3 各阶段的时间预算拆解

做启动优化之前，先把时间拆到段。下面的预算表是通用骨架，具体数值必须实测填入——本文给出的是「哪一段大概占多少」的量级判断，用来决定优化投在哪一段最划算。

1.4 启动时间的定义边界与测量口径

「启动时间」至少有四种不同的口径，不同口径之间可以差一个数量级。对外沟通前必须先声明用的是哪一种，否则很容易被拿去做错误的对比。

最后一行值得单独强调：启动时间的最大值往往比平均值更值得关注。用户能接受「偶尔慢一点」，不能接受「偶尔开不了机」。因此验收指标建议同时给出平均、P99 与最大三个数，并把「连续冷启动若干次全部成功」写成明确的通过准则。

1.5 一张完整启动链流程图

把前面四段合起来看，加上「失败怎么回来」这条横线，就是一张完整的启动链。图中时间占比是示意，用来说明「加载段通常是最大的一块可动空间」；每段的详细做法分别在第 2、3、5~7 章展开，移交与安全在第 9 章，排障在第 11 章。

四段之间的衔接还有一条容易忽略的主线：每一段交给下一段时，都必须已经成立一组前提，也必须事先定义好失败时的动作。复位交给 ROM 初始化时，供电与时钟源必须已稳定，失败则等待或复位；ROM 交给介质初始化时，串口必须可用，失败则打印诊断后停住；介质初始化交给加载时，镜像头必须可解析，失败则重读或转诊断模式；加载交给移交时，校验必须通过，失败则重试若干次后回退；移交交给操作系统时，版本判定必须完成，失败则回退或进恢复模式。没有这条主线，启动链一旦在中间出错就只能从头重来，现场定位成本极高。

2. BootROM：固化在硅片里的那一段代码

BootROM 是整条启动链里唯一「改不了」的一段。它的容量以 KB 计，代码量以最小可用为设计目标，能力以「刚好够用」为准。理解它的边界，就理解了后面三类介质存在的理由。

2.1 BootROM 的职责边界与它必须做的最小集合

BootROM 的设计目标只有一句：用最小的代码，把系统带到「可以读外部介质」的状态，然后把控制权交出去。为了做到这一点，它必须做且只做这几件事：

• 建立最小运行环境：栈、少量 RAM、必要的时钟。ROM 自带的 RAM 通常很小，深调用链要靠自己尽快搬走。
• 留一条能说话的通路：串口或调试口。这是现场唯一能拿到「卡在哪一步」的手段，没有它的 BootROM 在量产后等于黑盒。
• 让启动介质可读：把引脚复用改对、时序参数设对、器件识别出来。这一步的难度决定了 BootROM 能不能支持大容量介质。
• 移交：把一段「位置已知的可执行内容」交给下一段，并且约定好失败时怎么办。

2.2 掩膜固化 vs 预烧录 Flash 内的引导代码：取舍

「引导代码放在哪里」实际上有两条路：固化进硅片（掩膜）或预烧进外部 Flash 的固定偏移。两者不互斥，实际产品常常是「ROM 一小段 + Flash 一段」的两级结构。选择哪条，看四个维度：

2.3 BootROM 的局限：不可变更、容量小、认证能力弱

上一节的表格已经列出了具体表现，这里把三条局限的根因与后果讲透，因为它们直接决定了第 4 章的选型结论。

这三个局限互相强化，最终形成一个很难挣脱的局面：不可变更让现场发现的 BUG 只能等下一颗料、产线不良品无法现场救活；容量小让它无法容纳完整介质初始化、完整校验与复杂人机交互，只能把识别与校验拆到一级去做；认证能力弱则因为存放密钥需要非易失且不可读的存储，导致真正的签名验证难以实现——应对方式是让信任根只保存公钥或公钥哈希，对称材料外置加密存储。此外还有一条常被忽略的局限：调试受限，ROM 内无法用常规手段观测内部状态，失效分析只能靠猜，因此必须在设计时就预留诊断输出与失败标志位。

把这四条放在一起看，结论其实很直接：BootROM 是一个「兜底 + 引导」的角色，不是一个「运行」的角色。任何需要版本迭代、需要复杂协议、需要承载业务逻辑的功能，都不应该放在 ROM 里。这条判断准则比任何具体容量数字都可靠。

2.4 BootROM 常见失败模式与现场排查

BootROM 层面的失败有个共同特点：因为这段代码不可改，所以现场遇到时几乎没有软件手段可以救。因此这一层的工作重心是预防而不是修复。下面按现象归类，给出首查项。

2.5 BootROM 与外部 Flash 引导代码的衔接协议思路

两级结构的核心是那个「交接」。交接协议不需要多复杂，但必须把三件事定义清楚：交的是什么、失败了怎么办、怎么知道上一段做完了。

1. 交的是一段确定位置的镜像：约定镜像头在介质的固定偏移，头里至少有长度、目标加载地址、校验信息。ROM 只负责把头部与正文读到并校验，不解析任何复杂格式。
2. 失败语义要先定好：头部无效或校验不通过时，是重试、跳到备用位置、还是进入一个最小诊断模式。这一条决定了现场是「起不来但能说话」还是「彻底黑盒」。
3. 要有可观测的交接记录：至少保留「当前停在哪一级、失败原因是哪一类」的状态。这些状态既用于现场的串口输出，也用于第 11 章讲的故障快照。

3. XIP 直跑与拷贝运行的分野

这是启动链上一个真正的分叉点。同样是「从 Flash 里取代码执行」，可以完全不碰 RAM，也可以先老老实实搬一遍。两者的代价结构完全不同，适用条件也完全不同。

3.1 XIP 的原理与前提：可随机访问的接口

XIP（Execute In Place，原地执行）的做法只有一句话：把一段外部存储映射到处理器地址空间里的一个固定窗口，取指时硬件自动去读那块存储。程序计数器指向这个窗口内的地址，CPU 以为自己在读内存，实际上每次取指都变成了一次外部读。

它成立的前提有三条，缺一条就不成立：

• 接口必须支持随机访问。给一个地址就要能在合理时间内返回对应的数据，而不能要求「必须从头顺序读」。这是 NOR 天然具备、NAND 天然不具备的差别。
• 读时延必须足够确定。取指对时延抖动比数据访问更敏感——一次不确定的等待会让 CPU 的流水线频繁停顿，表现为「代码跑得慢但说不清为什么」。
• 不需要修改内容。XIP 期间介质里的内容是当作指令读的，不能是压缩包、加密包或需要运行时重定位的格式。这条常被忽略：如果镜像需要解压或解密，就不可能纯 XIP。

3.2 拷贝运行的流程与代价

拷贝运行是最普适的方式：任何能读出字节的介质都能用，代价是多花一段搬运时间和一块 RAM。

典型流程是四步：

1. 确定源地址与长度：从镜像头读出加载地址与长度，并检查目标区域是否可用。
2. 搬运：按块或按页把内容读进 RAM 缓冲区。这一步可以边读边校验，把校验开销和搬运重叠掉。
3. 校验：整段搬完后确认校验通过，再决定是否跳转。中途失败应回到重试计数，而不是带着半个镜像往下走。
4. 重定位与跳转：若代码含绝对地址，需要做重定位；然后跳到 RAM 里的入口。

拷贝的真实代价有三笔：搬运占用的启动时间、被占用的 RAM、以及RAM 布局被镜像大小绑架。第三笔最容易被忽略——一旦代码膨胀到 RAM 放不下，就得回头改架构，这在大内存 Linux 平台上尤其常见（此时解法是把内核分段加载，而不是整块进 RAM）。

3.3 XIP 对介质的要求：读延迟确定、无需 ECC 重算、可映射到地址空间

把上面的前提展开成下面四条可核查的判据。这四条里任意一条不满足，XIP 就会从「省时间」变成「浪费时间」甚至「跑不起来」。

3.4 混合模式：XIP 启动 + 拷贝到 RAM 运行

实际产品里最常见的不是二选一，而是混合：用 XIP 把「小而关键」的第一段代码跑起来，再由它把「大而不急」的部分拷到 RAM 执行。典型分工是：

• XIP 区：复位向量、中断向量表、时钟与内存初始化、介质初始化、镜像头解析。这些加起来通常只有几 KB，但必须在最快路径上跑完。
• 拷贝区：主应用、图形资源、需要解密的模块、模型权重。这些大块内容在启动后慢慢搬，搬完再启用。

这个混合模式的四个区段可以这样划分：XIP 区放向量表、时钟与内存初始化、介质初始化——体量小、在关键路径上，必须最快完成；校验区做镜像头与首段校验，用直接执行加少量栈空间即可，因为跳转前必须确认正确而成本很低；拷贝区放主应用与大数据段，体量大、执行期需要高速与确定，必须搬进 RAM；延后区放日志、网络、外设驱动，它们不属于「可用」的必要条件，可以放到启动完成之后再初始化。

混合模式的关键设计点是「在哪里切换」。切换点之前不能依赖任何未初始化的东西，包括 RAM 里未清零的区域、外部设备、甚至栈上的返回值。一个实用的做法是把切换点做成一次显式的、带日志与失败回退的跳转，让它成为一个可观测的事件——这也是第 11 章做故障快照时最有价值的一个时间锚点。

3.5 五种启动方式的对比矩阵

把常见的五种方式放进同一张表，就能看清各自的适用边界。矩阵的价值不在于「哪个最好」，而在于每种方式放弃了什么。

4. 第一类介质：片内 BootROM 与 eMCP 类内置

第一类介质的共同点是：启动代码和介质都在芯片内部，外部总线上没有任何启动器件。这一类方案启动确定性最好、成本最省，代价是容量极小、几乎不可变更。

4.1 纯 BootROM 方案的启动时序与代码容量约束

纯 BootROM 方案的启动链只有三步：取向量、建最小环境、跳转到固定地址。它的时间短到几乎可以忽略，真正的约束是代码容量。

ROM 容量以 KB 计，且面积直接对应成本。经验上 ROM 里放不下复杂的东西：完整的介质识别、完整的镜像校验、复杂的中断管理、任何需要较大表格的逻辑——这些都会迅速把体积推上去。所以纯 BootROM 方案里的主程序通常是「极小的固定代码 + 尽可能少的逻辑」，真正的功能在别处（可能是不可编程的应用专用逻辑，也可能是固化在另一片 ROM 里）。

时间上，取向量与装载栈在百微秒以内量级，最小环境初始化在百微秒到毫秒量级，校验固定镜像在毫秒量级，跳转本身是微秒量级。真正需要分配预算的不是这些动作，而是「校验」这一段——它随镜像大小与算法复杂度线性增长，是纯 BootROM 方案里唯一可能变慢的地方。

4.2 eMCP / uMCP 这类把控制器与 Flash 合封的价值：省掉外部介质初始化

eMCP、uMCP 这类器件把存储控制器与 Flash 阵列合封装在同一颗芯片里，对主板而言它看起来就像一颗「带控制器的存储器」——不需要外挂控制器，也不需要复杂的裸介质时序驱动。

它对启动链的价值体现在一个具体的地方：第二阶段「介质初始化」被显著压缩。控制器已经在片内完成上电自检与初始化，主机侧只需要按标准协议发命令，不必自己写一套介质驱动。

把合封器件与外挂方案逐项对比：控制器位置上外挂方案需要主机自己驱动，合封器件片内自带；主机侧代码量上外挂 NOR 最小、外挂 NAND 最大、合封器件居中；上电初始化上外挂 NOR 简单，外挂 NAND 需要强制状态读与参数下发，合封器件由控制器内部完成；启动确定性上外挂 NOR 最好、外挂 NAND 最差；现场可修复性上外挂方案可以换芯片，合封器件焊死在板上，通常要整板返修；适用容量段上外挂 NOR 面向小容量、外挂 NAND 面向小到中容量、合封器件面向中容量。

4.3 内置控制器带来的启动简化与代价

把「内置控制器」这件事的收益与代价摊开看，收益集中在启动链的第二阶段，代价则集中在灵活性与可修复性两个维度。

4.4 适用边界：不可现场升级 Flash 内容本身时怎么办

这是第一类介质最常被问到的问题。答案取决于「不可升级」的到底是哪一部分——这一点必须先分清，否则方案会做错。