从上电到内核：深入ARM64启动链的实战解析
你有没有遇到过这样的场景？板子通电后串口只打出“Starting kernel…”，然后就彻底沉默了。或者系统偶尔能启动，但换一张SD卡就不行——这种“玄学”问题的背后，往往藏在启动流程的底层细节中。
在x64世界里，BIOS/UEFI像一位全能管家，默默把操作系统托举起来。但在ARM64平台，事情完全不同。这里没有“一键启动”的魔法，取而代之的是一个层层递进、环环相扣的信任链条。理解这条链路，不仅是调试启动失败的关键，更是构建安全系统的基石。
今天，我们就以一线开发者的视角，带你走完从复位向量到Linux内核加载的全过程。不讲空话，只聚焦真实项目中必须掌握的核心机制和避坑要点。
启动第一站：BL1 —— 安全世界的守门人
系统一上电，CPU的第一步是跳转到复位向量地址。这个地址通常指向SoC内部固化的BootROM代码。它非常小，功能也有限：检测时钟、初始化基本RAM，然后从外部存储（如eMMC或SPI Flash）加载第一个可执行程序——这就是BL1。
BL1到底做什么？
别被“Stage 1”这个名字骗了，BL1可不是简单的跳板。它是整个启动链的信任根（Root of Trust），运行在最高特权等级EL3，拥有对所有硬件资源的完全控制权。
它的任务清单很明确：
- 初始化栈指针（SP），否则连函数调用都做不到
- 配置异常向量表，为后续错误处理打基础
- 打开串口输出，没有日志等于盲人摸象
- 加载并验证下一阶段镜像（BL2）
- 最后干净利落地跳转过去
⚠️ 注意：BL1必须极快完成工作。很多SoC内置看门狗定时器，默认几百毫秒超时就会强制复位。如果你在BL1里加太多初始化逻辑，系统可能永远出不来。
关键代码长什么样？
下面这段简化后的代码，来自ARM Trusted Firmware（TF-A），展示了BL1主流程的真实面貌：
void bl1_main(void) { bl1_early_platform_setup(); // 设置CPU、内存控制器等 exception_init(); // 异常向量就位 console_init(CONFIG_BL1_UART_BASE, 115200); // 日志通道打通 NOTICE("BL1: Starting execution\n"); // 获取BL2镜像信息（位置、大小、入口地址） image_info_t *bl2_image = bl1_plat_get_bl2_image_info(); // 从Flash加载BL2，并做CRC或签名校验 if (load_image(bl2_image) != 0) { ERROR("Failed to load BL2\n"); panic(); // 卡死在这里，绝不继续 } // 准备跳转参数 entry_point_info_t *next = bl1_plat_get_next_boot_ep_info(NT_FW); jump_to_next_image(next); // 永久移交控制权 }看到panic()没有返回吗？这是设计使然。一旦BL2加载失败，说明系统完整性已被破坏，宁可停机也不能冒险执行不可信代码。
这也是ARM64安全启动的核心思想：每一阶段都必须验证下一阶段的合法性，形成一条不可篡改的“信任链”。
第二道关卡：BL2 —— 固件调度中心
BL2接过控制权后，真正的多组件协调才开始上演。
如果说BL1只是“加载一个文件”，那BL2就是“指挥一场交响乐”。它要从一个叫FIP（Firmware Image Package）的容器中，提取出多个关键镜像：
| 镜像 | 名称 | 功能 |
|---|---|---|
| BL31 | Runtime Firmware | EL3运行时服务，负责安全切换 |
| BL32 | Secure OS | 如OP-TEE，运行在安全世界 |
| BL33 | Non-Secure Bootloader | 通常是U-Boot，最终加载Linux |
为什么需要这么复杂？
想象一下智能手机的启动过程：
1. 系统要运行Android（非安全世界）
2. 同时还要保护指纹支付、DRM内容（安全世界）
3. 两者之间要有严格隔离，互不干扰
这就引出了ARM的TrustZone技术——通过硬件支持的“双世界架构”，实现安全与性能兼顾。而BL2正是这个架构的搭建者。
实战中的典型流程
int bl2_load_images(void) { // 1. 先加载BL31（运行时固件） image_info_t *bl31_img = bl2_plat_get_bl31_image_info(); load_image(bl31_img); // 2. 加载BL32（TEE操作系统） image_info_t *bl32_img = bl2_plat_get_bl32_image_info(); if (bl32_img) { auth_verify_image(bl32_img); // 校验签名！ load_image(bl32_img); } // 3. 加载BL33（U-Boot） image_info_t *bl33_img = bl2_plat_get_bl33_image_info(); auth_verify_image(bl33_img); // 再次校验 load_image(bl33_img); return 0; }注意两次auth_verify_image()调用。这意味着即使攻击者替换了U-Boot，只要私钥没泄露，签名验证就会失败，机器直接卡死。这就是Android Verified Boot（AVB）的基础。
此外，BL2还负责规划内存布局。比如为OP-TEE预留一段DRAM，告诉U-Boot：“这块内存别碰，我留着做安全计算。”
权限交接的艺术：BL31与异常等级切换
当BL2完成所有镜像加载后，它不会直接跳去U-Boot。相反，它会先跳入BL31，由这位“权限调度员”来完成最后的安全交接。
ARM64的异常等级是什么？
你可以把 EL3 ~ EL0 看作四个权限层级：
- EL3：安全监控，掌控一切
- EL2：虚拟化层，KVM就跑在这儿
- EL1：Linux内核所在之地
- EL0：普通应用程序
每下降一级，权限就越受限。这种设计让系统既能高效运行应用，又能防止恶意程序越权访问硬件。
如何从EL3降到EL1？
这才是真正的技术难点。处理器不能简单地“跳”到低等级，必须通过特定指令触发状态迁移。
核心操作如下：
// 在BL31中设置目标状态 mov x0, #0x80080000 // U-Boot入口地址 msr ELR_EL3, x0 // 存入异常返回地址 mov x0, #(0 << 8) // 目标异常等级 EL1h orr x0, x0, #(1 << 0) // N-bit=1，进入非安全世界 msr SPSR_EL3, x0 // 保存PSTATE状态 mov x0, #(1 << 0) // SCR.NS = 1，切换为非安全状态 msr SCR_EL3, x0 eret // 返回！此时CPU降级至EL1并进入非安全世界ERET是关键。它不是普通的跳转，而是模拟一次“异常返回”，从而合法地降低异常等级。如果没有正确配置SPSR_EL3和ELR_EL3，CPU会在降级时触发异常，导致系统崩溃。
这也是为什么你在U-Boot日志开头经常看到一句：
Entering Kernel at 0x80080000...因为它确实是被“异常返回”进来的。
最后一棒：U-Boot如何把Kernel扶上马
终于到了传统意义上的“Bootloader”——U-Boot（作为BL33）。它已经运行在非安全世界的EL1，接下来的任务是为Linux内核铺平道路。
三大准备工作缺一不可
1. 设备树（Device Tree）准备
x64靠ACPI描述硬件，ARM64则依赖设备树Blob（DTB）。U-Boot需要加载正确的.dtb文件，并可能动态修改：
setenv bootargs "console=ttyAMA0,115200 root=/dev/mmcblk0p2" fdt addr 0x83000000 fdt open_and_resize fdt property /memory reg <0x80000000 0x40000000> // 声明可用内存 booti 0x80080000 - 0x83000000如果设备树里的UART地址写错了，哪怕内核成功启动，你也看不到任何输出。
2. 内核加载与解压
现代内核通常是压缩过的Image.gz，U-Boot需将其解压到指定位置：
load mmc 0:1 0x80000000 Image.gz gunzip 0x80080000 0x4000000 0x80000000 // 解压到0x80080000注意：解压地址不能覆盖正在运行的U-Boot代码区！
3. 参数传递与跳转
AArch64规定了标准的内核入口参数传递方式：
| 寄存器 | 内容 |
|---|---|
x0 | 内核入口地址 |
x1 | 保留为0 |
x2 | 设备树物理地址 |
x3 | 保留 |
然后执行：
br x0 // 跳入内核从此，控制权正式交给Linux。
常见启动故障排查指南
再完整的理论也抵不过一次实际调试。以下是我在项目中最常遇到的几个“坑”及应对方法：
❌ 卡在 “Starting kernel…” 之后
- ✅ 检查设备树兼容性：
compatible字段是否匹配当前SoC？ - ✅ 查看内存节点：
/memory/reg是否准确反映了DDR大小和基址？ - ✅ 确认串口配置：时钟频率、寄存器偏移是否与硬件一致？
建议做法：先用最小化DTB测试，逐步添加节点定位问题。
❌ 内核panic提示“Unable to mount root fs”
- ✅ 检查
bootargs中的root=参数是否指向正确的分区？ - ✅ 是否启用了initramfs？若无，则需确保根文件系统设备已就绪。
❌ 系统随机重启
- ✅ 检查BL1/BL2是否有看门狗未关闭？
- ✅ 是否因电源不稳定导致Brown-out Reset？
工具推荐：使用JTAG调试器连接OpenOCD，观察确切崩溃点。
写在最后：为何这套机制越来越重要？
ARM64的分阶段启动模型看似繁琐，实则是为现代计算需求量身定制的解决方案。
随着物联网设备普及、自动驾驶兴起、云原生边缘计算落地，我们不能再接受“裸奔式”的系统启动。每一次开机，都应是一次可验证、可审计、可追溯的安全旅程。
而BL1→BL2→BL31→Kernel这条链条，正是这场旅程的路线图。它不仅支撑起手机、服务器、工控设备的稳定运行，也为RISC-V等新兴架构提供了宝贵的设计范本。
当你下次面对一片漆黑的终端屏幕时，请记住：那不是终点，而是你深入系统底层的起点。
如果你正在开发定制固件、移植操作系统，或研究可信执行环境，欢迎在评论区分享你的经验和挑战。我们一起把这条路走得更清楚。
