启动流程基础：处理器复位后的第一条指令、复位向量与异常向量表、启动模式选择
各位同学，今天我们来聊聊芯片上电那一刻到底发生了什么。很多人觉得启动就是“按下开关，系统跑起来”，但作为做安全芯片的人，我得说——启动过程是整个信任链的起点，这里出问题，后面全是白搭。
我做过好几个项目的安全启动方案，踩过不少坑。今天就把处理器复位后那点事儿，掰开了讲清楚。
复位后的第一条指令：CPU 睁开眼看到的第一行代码
处理器复位时，内部寄存器会被强制初始化到一个已知状态。PC（程序计数器）会被赋一个固定值——这个值就是复位向量。
举个例子，ARM Cortex-M 系列复位后从 0x00000000 加载栈指针，从 0x00000004 加载 PC 初始值。而 ARM Cortex-A 系列则直接从 0x00000000 或 0xFFFF0000 取指（取决于异常向量表配置）。
说白了，CPU 一睁眼看到的地址是硬件写死的。这个地址指向的存储介质，必须是非易失性的、可信的——通常是 Boot ROM。
关键点：复位向量指向的存储介质，决定了信任根的物理载体。Boot ROM 是只读的，出厂后不可更改，天然具备防篡改能力。
我在一个 IoT 芯片项目中，遇到过客户想把复位向量指向 SPI Flash。我直接否决了——Flash 可以被物理替换或篡改，信任根必须放在 ROM 里。这是底线。
复位向量与异常向量表：一张跳转表决定了系统生死
复位向量只是异常向量表中的一个条目。完整的异常向量表包括：
| 向量偏移 | 异常类型 | 触发条件 |
|---|---|---|
| 0x00 | 复位 (Reset) | 上电或外部复位引脚触发 |
| 0x04 | 未定义指令 | CPU 遇到无法识别的指令码 |
| 0x08 | 软件中断 (SWI/SVC) | 执行 SVC 指令主动触发 |
| 0x0C | 预取中止 | 取指令时发生故障 |
| 0x10 | 数据中止 | 数据访问时发生故障 |
| 0x14 | 保留 | — |
| 0x18 | IRQ (中断请求) | 外设中断 |
| 0x1C | FIQ (快速中断请求) | 高速中断 |
这张表必须放在复位向量指定的基地址上。我习惯在启动代码开头这样安排：
; ARM Cortex-M 启动向量表示例
__Vectors DCD __initial_sp ; 0x00: 栈顶指针
DCD Reset_Handler ; 0x04: 复位处理函数
DCD NMI_Handler ; 0x08: NMI
DCD HardFault_Handler ; 0x0C: 硬错误
DCD MemManage_Handler ; 0x10: 内存管理错误
DCD BusFault_Handler ; 0x14: 总线错误
DCD UsageFault_Handler ; 0x18: 用法错误
; ... 后续向量省略你想想看，如果攻击者能篡改这个向量表，他就能把任何异常重定向到恶意代码。所以安全芯片的异常向量表必须放在 Boot ROM 里，并且要加硬件保护锁。
我曾经在一个项目中，发现芯片复位后向量表被意外重映射到了 SRAM。原因是 Boot ROM 代码里有个 bug，在初始化 MMU 之前就修改了向量基地址寄存器。结果系统一触发异常就直接跑飞了。排查了整整两天才找到根因。
教训：向量表重映射必须在 MMU/Cache 初始化之后，并且要确保目标内存区域已经正确映射且可执行。
启动模式选择：芯片怎么知道自己该从哪儿启动？
现代 SoC 通常支持多种启动介质：Boot ROM、NAND Flash、eMMC、SD 卡、UART、USB 等。芯片怎么选？靠的是启动模式引脚（Boot Mode Pins）。
一般流程是这样的：
- 复位释放后，硬件采样 Boot Mode 引脚电平
- 根据采样值查表，确定启动设备
- Boot ROM 代码读取该设备的启动头（Boot Header）
- 验证签名或完整性后，跳转到下一级代码
我画了一张流程图，帮你理清这个逻辑：
这张图里，左侧是 Boot ROM 启动路径——这是安全芯片的首选。右侧是外部存储启动路径，需要额外的签名验证。
Boot Mode 的硬件实现细节
不同厂商的实现各有千秋。我列个对比表：
| 厂商 | Boot Mode 引脚数 | 典型启动介质 | 特点 |
|---|---|---|---|
| NXP i.MX | 4 (BOOT_MODE[3:0]) | QSPI, NAND, eMMC, SD, USB | 支持串行下载模式，方便工厂烧录 |
| TI AM335x | 5 (SYSBOOT[4:0]) | NAND, MMC, SPI, UART, USB | 支持 NOR 启动，兼容老设计 |
| STM32MP1 | 3 (BOOT[2:0]) | Flash, SD, UART, USB | 支持工程模式，可强制进入 DFU |
我建议：在产品设计阶段，就把 Boot Mode 引脚通过电阻上拉/下拉固定到 Boot ROM 启动。量产时再通过 OTP 或 eFuse 锁定启动模式，防止攻击者通过修改引脚电平来切换启动介质。
避坑指南：Boot ROM 初始化中的常见陷阱
做了这么多年芯片安全，我总结了几条血泪教训：
- 时钟配置必须在访问外设之前完成——我见过有人先初始化 UART，结果时钟没配，UART 模块根本没工作，调试信息全丢了。
- Boot ROM 代码必须位置无关——因为 ROM 地址是固定的，但跳转到 RAM 后代码可能重定位。用绝对地址跳转会直接崩掉。
- 异常向量表要加校验和——有些攻击者会尝试注入错误向量。我习惯在向量表末尾放一个 CRC32，Boot ROM 启动时先校验再使能中断。
- Boot Mode 引脚采样有毛刺风险——复位释放瞬间，引脚电平可能不稳定。硬件上要加去抖电路，软件上建议连续采样三次取多数值。
我曾经遇到一个案例：某款芯片在低温环境下，Boot Mode 引脚采样错误，导致本该从 eMMC 启动的系统从 UART 启动了。结果生产线上的烧录程序一直报错，排查了三天才发现是引脚电平在低温下漂移了 0.2V，刚好跨过阈值。
解决方案：在 Boot ROM 代码里增加 Boot Mode 引脚的重采样机制——如果检测到启动设备无效，重新采样一次引脚状态。同时硬件上把阈值电压设计成带迟滞的比较器。
嗯，启动流程这块内容不少，但核心就三件事：复位向量指向哪、异常向量表怎么保护、Boot Mode 怎么选。这三件事决定了信任根能不能立得住。
下次你们做芯片选型或写启动代码时，记得回头看看今天讲的这些细节。一个可靠的启动流程，是后面所有安全机制的基础。