2. BootROM 与启动模式：SoC 上电后的第一行代码

当 Android 设备按下电源键的瞬间，SoC（System on Chip）内部最先执行的既不是 Linux 内核，也不是 Bootloader，而是一段固化在芯片内部 ROM 中的微小程序——BootROM。BootROM 是 SoC 上电后第一条指令的所在地，它负责完成最底层的硬件初始化，并根据外部引脚状态决定设备的启动模式。本章将深入分析 BootROM 的执行流程、启动模式选择机制，以及工程调试中的关键观察点。

2.1 BootROM 的物理位置与不可变性

BootROM 是一段只读的掩膜 ROM（Mask ROM），在芯片流片时就已经固化，用户无法修改。其典型特性如下：

属性 说明
存储介质 芯片内部掩膜 ROM（Mask ROM）
容量 通常 32KB ~ 256KB（视 SoC 厂商而定）
可修改性 不可修改（流片后固定）
执行地址 SoC 复位向量指向的固定物理地址（如 0x00000000 或 0xFFFF0000）
主要职责 最小硬件初始化、启动模式检测、加载下一级启动代码（如 PBL/SBL）
工程提示： 由于 BootROM 不可修改，芯片厂商在流片前必须确保其逻辑完全正确。任何 BootROM 级别的漏洞（如高通 2019 年的 "BootROM 漏洞"）都会导致设备永久性安全风险，通常只能通过硬件召回或熔丝（eFuse）修复。

2.2 BootROM 执行流程详解

BootROM 的执行流程可以划分为 5 个关键阶段，每个阶段都有明确的硬件操作和状态检查点。下面通过 SVG 流程图展示完整的执行路径：

BootROM 执行流程图 1. 上电复位（POR） 2. 最小硬件初始化 时钟 PLL · 内部 SRAM · 堆栈指针 3. 启动模式采样 读取 BOOT_MODE[3:0] 引脚电平 4a. 下载模式（Download Mode） USB/UART 等待主机命令 4b. 正常启动（Normal Boot） 从存储介质加载 PBL/SBL 5a. 下载协议处理 Fastboot / DFU / BROM 协议 5b. 加载 PBL（Primary Boot Loader） 从 eMMC / UFS / SPI Flash 读取 注：启动模式采样通常在复位释放后的几十个时钟周期内完成，采样结果锁存到内部寄存器

2.3 启动模式选择机制

BootROM 通过读取 SoC 特定 GPIO 引脚（通常称为 BOOT_MODE[3:0] 或 BOOT_CFG）的复位电平来判断启动模式。这些引脚在芯片复位期间被采样，采样结果决定了 BootROM 后续的行为分支。

2.3.1 常见启动模式分类

模式名称 典型引脚电平 行为描述 工程用途
正常启动 BOOT_MODE[3:0] = 0000 从预设存储介质（eMMC/UFS/SPI）加载 PBL 产品量产后的标准启动路径
下载模式 BOOT_MODE[3:0] = 0001 初始化 USB/UART 外设，等待主机下发命令 刷机、烧录固件、恢复变砖设备
串口下载 BOOT_MODE[3:0] = 0010 通过 UART 接收启动代码（低速调试用） 早期开发板调试、BootROM 调试
恢复模式 BOOT_MODE[3:0] = 0011 加载 Recovery 分区中的最小系统 系统更新、工厂测试
测试模式 BOOT_MODE[3:0] = 1111 进入芯片级测试（DFT/扫描链） 芯片出厂测试、硬件验证
调试警告： 在工程样机阶段，如果发现设备无法进入下载模式，首先应使用万用表或示波器测量 BOOT_MODE 引脚的复位电平。常见问题包括：外部上拉/下拉电阻焊接错误、引脚虚焊、或 PMIC 复位时序导致采样窗口偏移。

2.4 下载模式深入分析

下载模式是嵌入式开发和调试中最常使用的启动模式。BootROM 在该模式下会初始化一个通信外设（通常是 USB Device 或 UART），然后等待主机发送特定协议的命令。不同 SoC 厂商的下载协议各有差异：

  • 高通（Qualcomm）： 使用 EDL（Emergency Download） 模式，通过 USB 传输 programmer.elf 到内部 SRAM 执行。
  • 联发科（MediaTek）： 使用 BROM（BootROM） 协议，通过 UART 或 USB 接收 preloader.bin。
  • 三星（Exynos）： 使用 Download Mode，通过 USB 接收 fwbl1.bin。
  • 海思（HiSilicon）： 使用 Fastboot 协议变体，通过 USB 进行镜像烧录。

2.4.1 下载模式下的 BootROM 协议栈

以下是一个典型的下载模式协议栈结构，以高通 EDL 模式为例：

高通 EDL 模式协议栈 Sahara 协议（安全哈希验证与镜像传输） Firehose 协议（分区读写与镜像烧录） USB Bulk Transfer（端点 1 IN / 端点 2 OUT） USB 2.0 / 3.0 物理层（D+/D- 或 SS 差分对）

2.5 正常启动路径：从 BootROM 到 PBL

在正常启动模式下，BootROM 需要从非易失性存储介质中加载下一级启动代码（PBL 或 SBL）。这个过程涉及存储控制器初始化、读取启动头、验证签名等关键步骤。

2.5.1 存储介质优先级与回退机制

BootROM 通常支持多种存储介质，并按照预设优先级依次尝试加载。以下是一个典型的优先级列表：

  1. eMMC Boot Partition 1（最高优先级，通常用于存放 PBL）
  2. eMMC Boot Partition 2（冗余备份）
  3. eMMC User Data Partition（特定偏移位置）
  4. UFS Boot Logical Unit（UFS 设备的专用启动 LUN）
  5. SPI NOR Flash（低容量、高可靠性场景）
  6. NAND Flash（旧设备或低成本方案）
关键观察点： 如果所有存储介质都加载失败，BootROM 会进入一个 死循环（Dead Loop） 或 看门狗复位（Watchdog Reset）。在调试时，如果发现设备反复重启且无法进入下载模式，通常意味着 BootROM 无法从任何介质读取有效的启动头。

2.5.2 启动头（Boot Header）结构

BootROM 在读取存储介质时，首先会检查特定偏移位置的 启动头（Boot Header）。启动头包含了加载下一级代码所需的关键信息：

// 以高通平台为例的 Boot Header 结构
typedef struct {
    uint32_t magic;             // 魔数，用于识别有效启动镜像（如 0x844BDCD1）
    uint32_t image_size;        // 镜像总大小（字节）
    uint32_t load_addr;         // 加载到内存的目标地址
    uint32_t entry_point;       // 入口函数地址
    uint32_t code_offset;       // 代码在镜像中的偏移
    uint32_t checksum;          // 校验和
    uint8_t  signature[256];    // RSA 签名（安全启动时验证）
    uint32_t version;           // 镜像版本号
    uint32_t reserved[8];       // 保留字段
} boot_header_t;

2.6 工程调试要点

在实际的 Android 内核启动调试中，BootROM 阶段是最难观测的，因为此时 DRAM 尚未初始化，无法使用 JTAG/SWD 进行复杂调试。以下是几个实用的调试方法：

调试方法 适用场景 操作要点
GPIO 电平指示 确认 BootROM 是否执行到特定阶段 在 BootROM 代码中预留 GPIO 翻转点，用示波器测量
UART 早期打印 获取 BootROM 执行日志 部分 SoC 支持在 BootROM 中通过 UART 输出调试信息
启动模式引脚测量 确认设备是否进入预期模式 复位后立即测量 BOOT_MODE 引脚电平，对比数据手册
电源轨时序分析 排查 BootROM 因供电不足而卡死 使用多通道示波器同步测量 PMIC 输出与复位信号
JTAG 早期附加 在 BootROM 执行期间暂停 CPU 需要 SoC 支持 JTAG 在复位后立即生效（如 ARM CoreSight）
实战技巧： 在开发板上，可以预先在 BootROM 源码（如果厂商提供）的启动模式采样点之后插入 GPIO 翻转代码。通过观察 GPIO 波形，可以精确判断 BootROM 是否成功采样到预期的启动模式，以及是否进入了正确的执行分支。这是最廉价且可靠的 BootROM 调试手段。

2.7 本章小结

BootROM 是 Android 设备启动流程的起点，其执行逻辑虽然简单，但直接决定了设备能否正常启动或进入调试模式。理解 BootROM 的启动模式选择机制、下载协议栈以及正常启动路径中的存储介质优先级，是进行底层启动调试的基础。在实际工程中，BootROM 阶段的调试手段有限，需要结合 GPIO 指示、UART 日志和电源时序分析来定位问题。

← 上一章 📖 返回目录 下一章 →