3. BootROM阶段与埋点：CPU初始行为、固化代码执行，可埋点的位置与限制
BootROM阶段，说白了就是手机按下电源键后，CPU干的头几件事。这时候芯片内部有一小块只读的固化代码，叫BootROM，它比任何代码都先跑。我当年第一次接触bootloader时，觉得这层离应用层太远，埋点没啥意义。后来被线上玄学问题教育了几次……嗯，从那以后我彻底改了。
这一章，我们就来扒一扒BootROM里到底能埋什么、怎么埋、以及那些让你抓狂的限制。
3.1 BootROM的核心使命
CPU上电瞬间，寄存器是全乱的。BootROM的代码固化在SoC内部，厂家出厂就写死了。它的工作就几件：
- 初始化CPU自身：时钟、MMU（通常是关闭的）、缓存（可能也关着）
- 从指定的启动设备加载第一段代码（比如eMMC的BL1分区，或UFS的BootLun）
- 验证这段代码的签名（如果SoC安全启动打开了）
- 跳转到加载的代码继续执行
这里你想想看，所有代码在RAM都还没正经初始化的时候跑，能埋点吗？能，但极其有限。
3.2 可埋点的位置
我个人习惯把BootROM阶段的埋点机会分成三个“坑位”：
| 位置 | 说明 | 埋点可行性 |
|---|---|---|
| BootROM入口（Reset Vector） | CPU跳到这里开始执行，通常是个跳转指令 | 厂家预置，用户无法改动 |
| 启动设备探测阶段 | BootROM逐个尝试启动设备（eMMC、UFS、UART等） | 部分SoC提供硬件寄存器可读状态 |
| 安全验证阶段 | 校验下一级镜像的数字签名 | 可以通过GPIO或共享内存写日志（极简） |
| 跳转前一刻 | BootROM即将跳转到BL1前，最后写一些状态寄存器 | 可以写入硬件“boot reason”寄存器 |
我在项目中遇到过某平台重启异常，就是靠读取BootROM阶段写的一个硬件计数器才定位到的。当时线上反馈说“偶尔开不了机”，我们从头到尾追了两个月，最后发现是BootROM在枚举启动设备时，因为某个UFS信号不稳定卡死了。但这个信息，普通日志根本看不到。后面我们让芯片厂在BootROM里加了一小段代码，每次枚举设备前都把当前设备编号写到一个保留的GPIO上，我们再拿逻辑分析仪去抓——这才抓到真凶。
3.3 埋点的限制
为什么我说“极其有限”？因为BootROM阶段你面对的不是Linux，不是Android，甚至不是C runtime。几个硬伤：
- 没有内存控制器初始化：堆栈不可用，局部变量都难搞，更别提printf了。
- 没有时钟树：有时连UART都点不亮，因为UART模块的时钟还关着。
- 不支持中断：CPU在BootROM里通常是关中断的，你不能依赖timer中断做打点。
- 代码只读：BootROM是ROM，你没法往里插桩。唯一能做的是在跳转前写硬件寄存器。
- 存储空间有限：SoC内部SRAM可能只有几十KB，留给“额外日志”的余地几乎为零。
3.4 可行的埋点方式
既然不能写代码插桩，那怎么埋？其实思路是“用硬件资源做最原始的信号上报”。我归纳了三种常见做法：
- GPIO toggling：在BootROM的关键步骤前后，让芯片设计预留一些GPIO，BootROM代码中直接写GPIO寄存器拉高拉低。外部用逻辑分析仪或示波器抓。时间精度很高，但只能表示“到了”或“没到”。
- 硬件计数器：SoC内部做个简单的计时器（比如基于内部RCO），BootROM开始执行时清零，每完成一个阶段写入当前计数值到一个只读寄存器。后续软件（如BL1）可以把这个值读出来，作为BootROM阶段的耗时指标。
- 共享内存小区域：如果SoC有一小块“always on”的SRAM（不随CPU复位丢失），可以把关键状态写进去。哪怕BootROM阶段堆栈不能用，你依然可以对固定地址赋值——这通常是汇编几行代码的事。
我建议，在做产品规划时，提前和SoC厂商沟通：问清楚他们是否提供了上述机制。如果没有，那BootROM埋点就只能靠外部设备了。老实说，90%的Android设备在BootROM阶段是完全没有埋点的，因为成本太高，改动韧体需要重新流片。但作为性能优化专家，我们不能因为没有埋点就放弃分析。这些知识，是你在遇到“冷启动卡在开机动画前”这类问题时必须拿出来的底牌。
3.5 BootROM阶段埋点总结
我们来看一张图，把BootROM阶段的流程和可埋点的位置串起来：
从上图你能看到，BootROM阶段一共就5步。可埋点的位置都集中在“步骤执行标记”和“状态寄存器”上。说白了，你没法问“这里花了多少毫秒”，只能问“这一步到底有没有走到”。
3.6 避坑指南
最后，我把这几年踩过的坑总结一下。你记住这几条，至少能少走几个月弯路：
- 不要指望在BootROM阶段打印日志。UART初始化往往是BL1才做的事情。你非要打，就得和芯片厂确认BootROM里是否预置了UART输出代码。很多平台为了安全，默认关闭所有对外输出。
- GPIO toggling 要选对引脚。如果选了上电默认有内部上下拉的GPIO，你能抓到的波形可能被干扰。我曾经遇到一个案子，GPIO被内部弱上拉拉到高，结果BootROM结束后才把它拉低，整个时序全反了。
- 硬件计数器要确认是否受reset影响。有些SoC的计时器在CPU复位时也会被清零，那你测到的就是“从Reset到跳转”的整个时间，没法分阶段。最好选那种“只读不自动清”的计数器，然后在BL1启动后再读。
- 共享内存区域必须避开BootROM使用的空间。BootROM自己也有一段运行用的SRAM，你往里面写数据，搞不好直接把启动过程搞崩了。一定要和SoC FAE确认哪些地址是“保留给用户埋点”的。
嗯，BootROM阶段的埋点就这些。虽然限制很多，但一旦你能拿到这个阶段的信号，分析冷启动的头几十毫秒就不再是玄学。后面几个阶段会逐渐放开，埋点手段也会丰富起来。不过我们先把眼前这关吃透，后续就会顺手很多。