3. 启动流程总览
理解 TRAVEO 的启动过程，关键不是记住“先跑 BootROM 再跑 Flash Boot”这种口号，而是建立一条从复位向量到用户 main() 的完整链路视图：谁先执行、谁校验谁、谁把控制权交给谁、每一步失败会落到哪里。TRAVEO T2G 系列（以 CYT4BF 这类双核 Cortex-M7 + HSM 的器件为例）的启动是一条多阶段、带安全校验的链式过程，任何一环的配置或校验结果都会改变后续走向。
一、复位后的第一段代码：BootROM
上电复位（POR）或外部复位释放后，Cortex-M7 内核从固定的复位向量取指，但 TRAVEO 的复位向量并不直接指向用户 Flash，而是先进入芯片内部固化的 BootROM。BootROM 是掩膜在芯片里的只读代码，出厂即固定，用户无法修改，它承担三件事：
- 基础初始化：建立最小可运行环境，包括时钟源选择（通常先用内部 IMO 高速时钟起振）、必要的外设复位释放、SRAM 的基本可用性检查。
- 启动模式判定：读取 SFlash（Supervisory Flash）中的启动配置区（如 TOC2、启动模式字），判断本次是正常 Flash Boot、还是进入调试/DFU/系统调用等特殊模式。
- 安全策略入口：根据 eFuse 与 SFlash 中的生命周期（Lifecycle）状态、安全启动使能位，决定是否要求后续镜像必须通过签名校验。
BootROM 阶段通常只有几百微秒到几毫秒量级，但它决定了整条链路的“规则”。如果 SFlash 中的启动配置被擦除或损坏，BootROM 会回退到默认行为，常见表现是进入 DFU 或直接停在 BootROM 等待，而不是跳转到应用。
二、Flash Boot：从 SFlash 到用户镜像
BootROM 判定为正常启动后，会把控制权交给 Flash Boot 逻辑。这一阶段的核心是“找到并验证用户镜像”。TRAVEO 的用户程序通常由两部分组成：位于 Flash 起始区域的 Bootloader / Flash Boot 代码，以及紧随其后的 应用镜像（App）。Flash Boot 需要完成：
- 读取 SFlash 中的 TOC（Table of Contents）条目，获取应用镜像的起始地址、长度、入口地址和校验信息。
- 若安全启动使能，则对应用镜像做完整性校验（CRC）与真实性校验（基于 ECDSA 的签名验证，公钥哈希存放在 SFlash 或 eFuse 中）。
- 校验通过后，配置应用所需的向量表偏移（VTOR），跳转到应用复位处理函数。
这里有一个工程上极易踩坑的点：向量表偏移必须与链接脚本、TOC 中记录的地址三者一致。如果应用被链接到 0x1000_0000 之后的偏移，但 TOC 仍指向默认地址，跳转后取到的就是错误的中断向量，表现为“能跑几条指令然后 HardFault”。
三、HSM 启动与双核协同
在带 HSM（Hardware Security Module）的 TRAVEO 器件中，HSM 是一个独立的 Cortex-M0+ 安全核，拥有自己的 ROM、RAM 和 Flash 区域。上电后 HSM 与主核（CM7）的启动是并行但有序的：HSM 先完成自身固件加载与自检，随后主核的 BootROM 在需要安全服务（如签名验证、密钥派生）时通过 IPC 与 HSM 通信。也就是说，安全启动的“验签”动作往往由 HSM 执行或协助，主核等待其结果。
这带来一个直接后果：HSM 固件缺失或版本不匹配时，安全启动会失败，主核可能停在 BootROM 或进入错误处理。因此刷写时 HSM 固件（HSM 的 SFlash 配置与 HSM 代码区）必须与主核镜像配套更新，不能只刷 App。
四、安全启动策略选择
TRAVEO 的安全启动不是“开/关”二值，而是按生命周期和校验强度分层。常见策略可归纳为下表（参数为示例性说明，具体以器件 TRM 与 SFlash 映射为准）：
| 策略 | 校验内容 | 典型生命周期 | 启动时间影响 |
|---|---|---|---|
| 无安全启动 | 仅 CRC 或不做校验 | Development | 最短 |
| CRC 完整性 | 镜像 CRC32 | Development / Production | +数 ms |
| 签名验证 | ECDSA P-256 验签 + CRC | Production / Secure | +数十 ms |
| 安全 + 加密镜像 | 验签 + 解密后校验 | Secure | 最高 |
策略一旦在 Secure 生命周期下被 eFuse 锁定，就无法回退到无校验模式。因此量产前必须在 Development 阶段把启动策略、密钥哈希、TOC 布局全部验证完毕，再烧写生命周期位。
五、启动时间预算
整车 ECU 对启动时间有硬性要求（例如 CAN 唤醒后 100 ms 内必须能响应报文）。TRAVEO 的启动时间可粗略拆分为：BootROM 固定开销 + Flash Boot 校验开销 + HSM 通信开销 + 应用自身初始化。其中签名验证是最大变量：以 ECDSA P-256 验签为例，在 80 MHz 下软件实现约需 20~40 ms，若由 HSM 硬件加速可压缩到几毫秒。工程上常用做法是：
- 把不依赖安全校验的外设初始化（如 CAN 控制器基础配置）提前到 Flash Boot 阶段完成，让通信“先活起来”。
- 对时间敏感的中断服务在应用早期就绪，避免等全部初始化完成才开放接收。
- 用 GPIO 翻转或 DWT 计数器在启动各阶段打点，实测而非估算。
六、完整链路一图看清
下图把上述阶段串成一条从复位到应用跳转的链路，并标出各阶段的关键判定与失败分支。注意图中“校验失败”并非终点，而是可能回落到 DFU 或错误处理，具体取决于启动配置。
把这张链路图记牢，后续排查启动问题时就能快速定位：是 BootROM 没读到配置，还是 Flash Boot 找不到 TOC，还是验签失败，还是 VTOR 设错。每一段的失败现象和日志特征都不同，而它们的分界点，正是上面这条链路。