2、系统启动的起点：BootROM与引导加载程序（Bootloader）
芯片上电后的第一条指令，到底是谁在执行？
很多人以为Android系统启动是从Linux内核开始的。其实不是。在CPU真正“看见”内核之前，还有一段非常底层的旅程。这段旅程的起点，就是BootROM。
2.1 芯片上电后的第一微秒
当电源键按下，电压稳定后，CPU的复位逻辑会强制将PC指针指向一个固定的物理地址。这个地址，就是BootROM的入口。
BootROM是芯片内部的一块只读存储器，出厂时就已经固化好了。它不可修改，也不可擦除。说白了，它是芯片厂商留给硬件的第一道保险。
我个人习惯把BootROM比作“芯片的出厂设置”。它负责最基础的工作：初始化CPU、设置时钟、配置内存控制器。这些事必须在任何代码运行之前完成。
关键点：BootROM是硬件固化代码，不是操作系统的一部分。它不关心你是Android还是Linux，它只负责把下一级代码加载进来。
我在项目中遇到过一个问题：某款芯片在低温环境下启动失败。排查到最后，发现是BootROM阶段的内存训练时序出了问题。嗯，这种问题你靠软件是修不了的，只能找芯片原厂打补丁。
2.2 引导加载程序（Bootloader）的职责
BootROM执行完毕后，会跳转到Bootloader。Bootloader是芯片上电后第一个可编程的软件组件。
它的核心任务有三个：
- 硬件初始化：设置DDR、存储控制器、显示控制器等
- 启动介质检测：从eMMC、UFS、SD卡等设备中读取启动镜像
- 启动模式选择：决定进入正常系统、恢复模式还是刷机模式
你想想看，Bootloader其实是个“小操作系统”。它有自己的驱动、文件系统支持，甚至还有简单的命令行交互。我见过一些工程师直接在Bootloader里加调试代码，用来验证新板子的硬件是否正常。
2.3 启动模式选择：三种核心模式
Android设备通常支持三种启动模式。它们的选择逻辑，一般在Bootloader的早期阶段完成。
| 模式 | 触发方式 | 用途 |
|---|---|---|
| 正常启动 | 无按键干预 | 加载boot.img，进入Android系统 |
| 恢复模式 | 音量键+电源键组合 | 进入Recovery，执行OTA升级或数据擦除 |
| 刷机模式 | 特定按键或fastboot命令 | 通过USB烧录系统镜像 |
这三种模式的选择，通常是通过读取GPIO电平状态来判断的。比如音量减键按下时，对应的GPIO会被拉低，Bootloader检测到这个状态后，就会跳转到对应的启动分支。
避坑指南：我曾经遇到过一个问题：某款设备的音量键在开机时被误触，导致设备总是进入恢复模式。排查后发现是按键的硬件去抖电路设计不合理。后来我们在Bootloader里加了一段软件去抖逻辑，问题才解决。
2.4 第一条指令的执行流程
我们来梳理一下完整的执行链路：
- 上电复位：CPU从复位向量地址取指，执行BootROM代码
- BootROM初始化：设置CPU模式、关闭看门狗、初始化缓存
- 加载Bootloader：从eMMC的特定分区（如xbl、abl）读取Bootloader到SRAM
- Bootloader执行：初始化DDR、检测启动模式、加载内核
- 跳转到内核：将控制权交给Linux内核
这里有个细节值得注意：BootROM通常只有几十KB大小，而Bootloader可能有几百KB甚至几MB。所以BootROM只能把Bootloader加载到芯片内部的SRAM中，然后再由Bootloader去初始化DDR，最后把内核加载到DDR里。
注意事项：如果Bootloader损坏，设备会变砖。因为BootROM找不到有效的Bootloader，就会进入下载模式或直接死循环。这也是为什么刷机时千万不能断电的原因。
2.5 实际项目中的经验
我记得有一次调试一个启动失败的问题。现象是设备上电后黑屏，没有任何反应。用串口抓日志，发现BootROM已经执行完毕，但Bootloader没有启动。
后来定位到是eMMC的启动分区被意外擦除了。解决办法是用工具通过USB直接烧写Bootloader到eMMC的boot分区。嗯，这种问题在开发阶段很常见，量产阶段反而很少遇到。
另外，我建议你在做底层开发时，一定要保留串口调试接口。没有串口日志，BootROM阶段的错误几乎无法定位。你想想看，这时候连屏幕都没初始化，你靠什么看日志？
2.6 小结
系统启动的起点，不是Linux内核，而是BootROM和Bootloader。它们负责在操作系统运行之前，完成最底层的硬件初始化和启动模式选择。
理解这一层，你才能真正掌握Android系统的启动全流程。下一章，我们会深入Bootloader的内部实现，看看它到底是怎么加载内核的。