3. Boot ROM（PBL）深入
PBL（Primary Boot Loader）是固化在骁龙 SoC 内部 ROM 中的第一段可执行代码，上电复位后由硬件直接从 ROM 基址取指运行。它不依赖任何外部存储，因此是整条启动链中唯一“绝对可信”的环节。理解 PBL 的关键，不是把它当成一段普通程序，而是把它看成“硬件状态机 + 安全策略执行器 + 启动介质选择器”三者的结合体。本节围绕执行流程、启动设备枚举、镜像认证头解析、错误码与串口日志四个维度展开。
一、AArch64 与 Hexagon 上的执行分工
骁龙 SoC 内部并非只有一颗 CPU。以典型的 SM8550 为例，芯片内包含 Kryo CPU 集群（AArch64）、Hexagon DSP、Adreno GPU、以及负责电源与时钟的 Always-On 子系统。PBL 的执行是分阶段的：复位后最先运行的是固化在 ROM 中的一段 AArch64 代码，它负责最基础的时钟初始化、PLL 锁定、DDR 训练前的准备，以及安全启动根密钥的加载。随后，PBL 会通过内部 IPC 通道唤醒 Hexagon 子系统，把一部分与传感器、音频、低功耗唤醒相关的初始化任务交给 Hexagon 侧的 ROM 代码执行。
需要强调的是，Hexagon 上的 PBL 代码并不是“第二份 PBL”，而是同一套 ROM 镜像中针对 Hexagon 指令集编译的独立入口。两者共享同一份认证策略和启动介质描述表，但执行路径不同：AArch64 侧负责主启动流程与 XBL 加载，Hexagon 侧主要负责子系统自检与安全域隔离。如果 Hexagon 侧自检失败，AArch64 侧通常会收到一个 IPC 错误码，并决定是否继续启动或进入紧急下载模式（EDL）。
二、启动设备枚举：顺序、超时与回退
PBL 在完成基础时钟初始化后，会按照 SoC 内部熔丝（Fuse）和 GPIO 引脚状态决定的顺序枚举启动设备。典型顺序为：eMMC/UFS → SD 卡 → USB（EDL）→ PCIe/NVMe → UART 下载。这个顺序不是随意排列的，而是由“启动介质优先级”和“安全策略”共同决定。例如，当熔丝中配置了“强制 EDL”位时，PBL 会跳过 eMMC 和 SD，直接进入 USB EDL 模式，等待主机端 QFIL 或 QDL 工具下发镜像。
枚举过程中有两个关键参数：探测超时和重试次数。以 UFS 为例，PBL 会先发送 UFS 链路启动命令（DME Link Startup），等待设备返回 UniPro 就绪信号。如果 100ms 内未收到响应，PBL 会重试最多 3 次；若仍失败，则标记该介质为“不可用”，继续枚举下一项。这个超时值在 ROM 代码中是硬编码的，但可以通过熔丝配置进行有限调整。实际调试中，如果 eMMC 焊接不良或供电异常，串口日志会看到类似 BOOT_DEVICE_UFS_TIMEOUT 的提示，随后 PBL 自动回退到 USB EDL。
三、镜像认证头解析：从 Magic 到签名验证
当 PBL 选定启动介质后，它会从该介质的固定偏移处读取镜像认证头（Auth Header）。以 XBL 镜像为例，认证头通常位于镜像起始位置，包含以下字段：Magic Number（如 0x58424C31，即 “XBL1”）、头部版本号、镜像总长度、签名算法标识、RSA/ECDSA 公钥哈希、SHA-256 摘要、以及签名数据本身。PBL 的解析流程是严格顺序的：先校验 Magic 和版本号，再校验镜像长度是否超出介质容量，然后计算镜像体的 SHA-256 摘要，最后用熔丝中烧录的根公钥验证签名。
这里有一个容易忽略的细节：PBL 在计算摘要时，并不是对整个镜像文件做哈希，而是对“认证头之后、签名之前”的有效载荷区域做哈希。签名数据本身不参与摘要计算。如果摘要不匹配，PBL 会立即停止启动，并输出 AUTH_FAIL_HASH_MISMATCH；如果签名验证失败，则输出 AUTH_FAIL_SIG_INVALID。这两个错误码在串口日志中的表现不同，前者通常伴随镜像长度异常，后者则更多指向密钥不匹配或镜像被篡改。
四、错误码与串口日志特征
PBL 的串口日志是排查启动问题的第一手资料。默认情况下，PBL 会通过 UART 以 115200 波特率输出精简日志，格式通常为 [PBL] <错误码> <附加信息>。常见错误码及其含义如下表所示：
| 错误码 | 含义 | 典型串口日志片段 | 可能原因 |
|---|---|---|---|
BOOT_DEVICE_UFS_TIMEOUT |
UFS 链路启动超时 | [PBL] 0x8001 UFS link timeout |
UFS 供电异常、焊接不良、时钟未锁定 |
AUTH_FAIL_HASH_MISMATCH |
镜像摘要不匹配 | [PBL] 0x9002 hash mismatch at 0x0 |
镜像损坏、烧录偏移错误、长度字段被篡改 |
AUTH_FAIL_SIG_INVALID |
签名验证失败 | [PBL] 0x9003 sig invalid |
根公钥不匹配、镜像未签名、熔丝配置错误 |
EDL_FORCED |
强制进入 EDL 模式 | [PBL] 0xA001 forced EDL |
熔丝强制 EDL 位被烧录、GPIO 组合触发 |
DDR_TRAINING_FAIL |
DDR 训练失败 | [PBL] 0x7001 DDR training fail |
DDR 颗粒不匹配、时序参数错误、供电不稳 |
需要特别说明的是，PBL 的日志输出并非总是完整可读。在安全启动使能且熔丝配置为“禁止调试输出”时，PBL 可能只输出一个极简的十六进制错误码，甚至完全不输出。此时需要借助 JTAG 或 EDL 模式下的内存转储来定位问题。例如，在 EDL 模式下，可以通过 QDL 工具读取 0x146BF00 附近的 PBL 日志缓冲区，获取更详细的错误上下文。
五、从 PBL 到 XBL 的交接条件
PBL 完成镜像认证后，并不会直接跳转到 XBL 的入口地址。它需要先完成三件事：第一，将 XBL 镜像从启动介质搬运到 DDR 中的指定加载地址（例如 0x80000000）；第二，配置 MMU 和异常向量表，为 AArch64 运行环境做准备；第三，通过 SCM（Secure Channel Manager）调用将控制权移交给 XBL 的入口点。如果 DDR 训练失败或搬运过程中发生校验错误，PBL 会停留在当前状态并输出 DDR_TRAINING_FAIL 或 IMAGE_LOAD_FAIL，不会进入 XBL。
理解 PBL 的另一个关键点是：它不解析设备树，也不加载内核。PBL 的唯一目标是“找到并验证下一阶段镜像，然后安全地交出控制权”。所有与硬件描述、内核参数、文件系统相关的工作，都留给 XBL 和后续的 ABL 完成。因此，当启动卡在 PBL 阶段时，排查方向应集中在启动介质、镜像完整性、签名密钥和 DDR 训练上，而不是内核或设备树配置。