AARCH64引导流程（Boot Process）阶段详解

AARCH64引导流程深度解析：从理论到实践的完整路径

在现代计算架构中，AARCH64已不再只是移动设备的专属标签。从数据中心的服务器芯片到边缘AI终端，再到汽车电子控制单元，它正以前所未有的速度重构底层硬件生态。而在这背后，一个稳定、安全且高效的 引导流程（Boot Process） 成为了系统可靠运行的生命线。

你有没有想过，当你按下电源键那一刻，那不到一秒的时间里，处理器究竟经历了什么？为什么有些设备“秒开”，而另一些却要等待好几秒？又或者，在物联网时代频繁曝出的安全漏洞中，有多少其实是源于启动链路上某个微小环节的疏忽？

今天我们就来揭开这层神秘面纱——深入剖析AARCH64平台从复位向量跳转到操作系统接管全过程的技术细节。这不是一篇简单的技术手册，而是一次工程师视角下的真实探索之旅。准备好了吗？🚀

---

权限金字塔：EL0–EL3 异常级别的权力游戏

AARCH64的世界里，没有绝对自由。每一条指令的执行都受到严格的身份审查。这个身份体系就是 Exception Levels（EL） ——四个层级构成的权限金字塔。

想象一下：EL0 是普通用户，只能使用分配给他的工具；EL1 是操作系统内核，可以管理进程和内存；EL2 居于虚拟化世界之上，掌控多个操作系统的调度；而 EL3，则是整个系统的“守护神”，拥有对所有资源的最终解释权。

// 示例：在EL3配置返回目标状态
SCTLR_EL3 = 0x80000000; // 启用MMU与分支预测等核心功能

这种分层设计不仅仅是性能优化的结果，更是安全架构的基石。引导过程必须从最高特权级 EL3 开始，逐步向下移交控制权。任何试图越级加载的行为都会被硬件直接拦截。

有趣的是，很多初学者会误以为“越高越好”——于是把所有代码都放在 EL3 执行。但事实恰恰相反！长期运行高权限代码意味着更大的攻击面。正确的做法是： 只在必要时使用高权限，完成任务后立即降权 。

就像你不会让银行行长亲自去点钞一样 😅。

---

安全双世界：TrustZone 如何实现物理共存、逻辑隔离

如果说 EL 模型定义了纵向权限，那么 ARM TrustZone 技术则构建了横向的安全边界。它将系统划分为两个独立运行的“宇宙”：

• 安全世界（Secure World） ：用于处理敏感数据，如指纹识别、支付密钥、DRM 内容解码；
• 非安全世界（Non-secure World） ：运行常规应用和操作系统。

这两个世界共享同一套物理硬件（CPU、内存、外设），但通过 NS 位（Non-Secure Bit）进行逻辑隔离。当 NS=0 时进入安全世界，NS=1 则为非安全世界。

寄存器	功能说明
SCR_EL3.NS	0=进入安全世界，1=进入非安全世界
SCR_EL3.ST	控制安全定时器访问权限

关键在于， 切换世界不是随意的跳转，而是需要经过授权的“通道” 。最常见的就是 SMC（Secure Monitor Call）指令。你可以把它理解成一道带安检门的走廊——只有持有正确凭证的人才能通行。

举个例子：你在手机上打开支付宝扫码付款，App 本身运行在非安全世界，但它需要调用 TEE（可信执行环境）中的支付模块完成签名。这时就会触发一次 SMC 调用，CPU 切换至安全世界执行签名逻辑，完成后自动返回。

⚠️ 小贴士：如果你在开发过程中发现 SMC 调用失败或卡死，先检查 SCR_EL3 是否允许 NS 切换，再确认中断路由设置是否正确。这类问题往往不是代码 bug，而是寄存器配置遗漏导致的“隐形墙”。

---

复位之后的第一步：谁最先醒来？

系统上电或复位后，CPU 并不知道该做什么。它的第一反应是从一个预设地址取指执行——这就是所谓的 复位向量（Reset Vector） 。

这个地址通常是 0x0000_0000 或 0xFFFF_0000 ，具体由 SoC 厂商决定。此时 CPU 处于 EL3h 模式，MMU 关闭，缓存未启用，所有通用寄存器值不确定。换句话说，它处于一种“裸机”状态。

接下来会发生什么呢？让我们看一段典型的汇编启动代码：

aarch64_reset_handler:
    mov sp, #0x10000       // 设置栈指针至SRAM
    b   bl1_main           // 跳转至C语言主函数

短短两行代码，却是通往高级语言世界的桥梁。其中最关键的动作是 设置栈指针（SP） 。没有栈，就无法进行函数调用、局部变量存储，甚至连 C 环境都无法建立。

💡 经验之谈：我曾经在一个项目中遇到 BL1 阶段崩溃的问题，调试了半天才发现是因为链接脚本中 .stack 段定义错误，导致 SP 指向了一块不可写的内存区域。所以一定要确保你的 SRAM 地址范围和大小与硬件手册完全一致！

---

分阶段信任链：BL1 → BL2 → BL3 的接力赛

现代 AARCH64 系统的启动绝不是一蹴而就的。它采用多阶段引导机制，形成一条环环相扣的“信任链”。每一阶段验证下一个镜像的完整性，确保整个启动过程不被篡改。

主流实现遵循 ARM Trusted Firmware（ATF）框架，主要分为三个阶段：

阶段	运行 EL	主要职责	存储位置
BL1	EL3	最小化初始化，建立栈空间	ROM/SRAM
BL2	EL3	加载并验证后续镜像	SRAM/DDR
BL3	EL3/EL1	提供运行时服务，启动 OS	DDR

听起来像是标准教科书内容？别急，我们换个角度思考： 为什么非要分成这么多阶段？不能一步到位吗？

当然可以——如果你不在乎安全性、可维护性和跨平台兼容性的话 😬。

实际上，这种分层结构带来了三大优势：

1. 风险隔离 ：早期阶段只做最基本的操作，减少潜在攻击面；
2. 灵活扩展 ：高层阶段可通过配置适配不同 SoC；
3. 可验证性强 ：每个阶段都可以独立签名和校验，形成完整的 Chain of Trust。

更进一步地，BL3 还会被细分为：
- BL31 ：EL3 Runtime Software，提供 PSCI、SMC 处理等服务；
- BL32 ：Secure OS，如 OP-TEE；
- BL33 ：Non-secure Bootloader，通常是 U-Boot 或 Linux Kernel。

它们之间的交接依赖一套标准接口，比如 ep_info 结构体传递入口信息，FIP（Firmware Image Package）格式封装多阶段镜像。

---

BL1：信任起点的设计哲学

作为整个引导链的起点，BL1 扮演着“信任根（Root of Trust）”的角色。它必须固化在只读存储器中（如 ROM 或受保护 Flash），不能被动态修改。

由于 DDR 尚未初始化，BL1 只能使用片上 SRAM，通常不超过几十 KB。这就要求其实现高度精简，仅包含必要功能：复位处理、CPU 状态配置、栈空间建立以及跳转至 BL2。

复位处理与初始 CPU 状态配置

当处理器复位时，硬件自动跳转至复位向量。此时 CPU 处于 EL3h 模式，但 MMU 和 Cache 都是关闭的。BL1 的首要任务就是安装异常向量表并设置初始状态。

以下是一段典型汇编代码：

.section ".text.reset_handler", "ax"
.global aarch64_reset_handler

aarch64_reset_handler:
    /* 关闭MMU、Cache和对齐检查 */
    mrs     x0, SCTLR_EL3
    bic     x0, x0, #(1 << 0)      /* 清除M位：关闭MMU */
    bic     x0, x0, #(1 << 2)      /* 清除C位：关闭Data Cache */
    bic     x0, x0, #(1 << 13)     /* 清除A位：关闭Alignment check */
    orr     x0, x0, #(1 << 12)     /* 设置I位：启用Instruction Cache */
    msr     SCTLR_EL3, x0

    /* 设置SPSR_EL3：异常返回时的目标状态 */
    mov     x0, #0x3c0             /* IRQ/FIQ掩码 + M[3:0]=0b1101 (EL3h) */
    msr     SPSR_EL3, x0

    /* 设置ELR_EL3：异常返回地址指向_cstartup */
    adr     x0, _cstartup
    msr     ELR_EL3, x0

    /* 跳转至C语言主函数 */
    eret

逐行分析：

• mrs x0, SCTLR_EL3 ：读取当前 EL3 下的系统控制寄存器。
• bic x0, x0, #(1 << 0) ：清除 M bit，即关闭 MMU，确保后续访存使用物理地址。
• bic x0, x0, #(1 << 2) ：关闭数据缓存，避免脏数据干扰。
• orr x0, x0, #(1 << 12) ：启用指令缓存以提高性能。
• msr SCTLR_EL3, x0 ：写回更新后的值。
• mov x0, #0x3c0 ：构造 SPSR 值，屏蔽中断，设定异常返回后进入 EL3h 模式。
• adr x0, _cstartup ：获取 C 入口地址。
• eret ：异常返回指令，触发跳转至 _cstartup ，正式进入 C 环境。

🧠 工程师笔记：这里有个常见误区——有人认为应该尽早开启 MMU。但实际上，在页表尚未准备好之前开启 MMU 会导致地址转换失败，引发异常甚至死机。所以“先关后开”才是正道！

片上 SRAM 初始化与栈空间建立

在没有外部内存的情况下，BL1 必须显式设置栈指针。假设 SRAM 起始于 0x08000000 ，大小为 128KB，则可将栈顶设为 0x08020000 。

void __attribute__((noreturn)) _cstartup(void)
{
    // 设置栈指针到SRAM顶部
    __asm__ volatile (
        "ldr x0, =0x08020000\n\t"
        "mov sp, x0"
        ::: "x0", "memory"
    );

    // 初始化 .bss 段
    extern char __bss_start__, __bss_end__;
    char *bss = &__bss_start__;
    while (bss < &__bss_end__)
        *bss++ = 0;

    // 调用BL1主函数
    bl1_main();
}

注意几点：
- .bss 段必须清零，否则全局变量可能含有随机值；
- volatile 防止编译器优化掉关键语句；
- 栈设置必须在任何函数调用前完成。

一旦栈建立成功，就可以调用复杂函数进行时钟、看门狗、串口等基础外设配置了。

安全监控模式的初步设置

虽然完整的安全切换逻辑由 BL31 实现，但 BL1 需要预先配置相关寄存器，例如 SCR_EL3。

void configure_secure_monitor(void)
{
    uint64_t scr;

    __asm__ volatile("mrs %0, SCR_EL3" : "=r"(scr));

    scr |= (1 << 0);       // NS bit: 允许切换到Non-secure state
    scr |= (1 << 4);       // IRQ bit: 路由IRQ到当前安全状态
    scr |= (1 << 3);       // FIQ bit: 路由FIQ到当前安全状态
    scr |= (1 << 10);      // ST bit: 允许安全定时器访问

    __asm__ volatile("msr SCR_EL3, %0" :: "r"(scr));
}

这些配置为后续 BL2 加载非安全镜像、BL31 注册 SMC 处理程序提供了前提条件。若此处配置错误，可能导致 SMC 调用失败或中断劫持漏洞。

---

BL2：调度中心的智慧与责任

如果说 BL1 是“打地基”的工人，那 BL2 就是“项目经理”——负责统筹资源、协调各方、确保项目顺利推进。

它运行在 EL3，但已经可以使用更大内存（通常已初始化 DDR），并能调用更复杂的驱动程序。其主要职责包括：

• 初始化外部存储控制器（eMMC、SPI-NAND、USB）
• 从 Flash 中读取 FIP 镜像包
• 解析设备树（DTB）
• 验证并加载 BL31、BL32、BL33
• 规划内存布局并移交控制权

外部存储器驱动初始化

以 eMMC 为例，初始化流程如下：

int emmc_init(void)
{
    gpio_set_mode(EMMC_CLK_PIN, OUTPUT);
    gpio_set_mode(EMMC_CMD_PIN, ALT_FUNC_2);
    gpio_set_mode(EMMC_DAT0_PIN, ALT_FUNC_2);
    clock_enable(EMMC_CLOCK);

    send_cmd(0, 0); // GO_IDLE_STATE
    if (get_response() != R1_IDLE_STATE) return -1;

    do {
        send_cmd(1, OCR_3V3_SUPPLY);
    } while (!(get_response() & R1_READY));

    send_cmd(9, RCA << 16);
    parse_csd(get_response_buffer());

    send_app_cmd(RCA);
    send_cmd(ACMD6, BUS_WIDTH_4);

    return 0;
}

重点在于：
- CMD1 循环直到设备报告“ready”，防止超时失败；
- ACMD6 启用 4 线传输，提升读取速度；
- 成功后即可调用 emmc_read() 实现块读取。

有了这个能力，BL2 才能加载存储在 eMMC 分区中的 FIP 包。

镜像验证与解密机制

为了防止恶意固件注入，BL2 必须对加载的 BL3 镜像进行签名校验。常用方案基于 RSA+SHA256：

bool authenticate_image(void *img, size_t len, void *sig)
{
    uint8_t digest[32];
    uint8_t pub_key_modulus[256] = { /* 固化公钥模数 */ };
    uint8_t pub_key_exp[3] = {1, 0, 1}; // e=65537

    sha256_compute(img, len, digest);

    return rsa_verify(pub_key_modulus, pub_key_exp,
                     sig, 256,
                     digest, 32);
}

如果验证失败怎么办？简单粗暴的做法是停机，但更好的方式是触发“安全熔断”机制，比如锁定 JTAG 接口、禁用调试模式，防止攻击者进一步探测。

此外，部分场景还需支持 AES-GCM 解密，密钥来源于 HUK（Hardware Unique Key）派生。

内存布局规划与设备树加载

BL2 还需解析 DTB，提取内存映射、CPU 拓扑、串口节点等信息，用于指导 BL3 的加载地址分配。

struct mem_region {
    uint64_t start;
    uint64_t size;
};

void load_device_tree(void)
{
    void *dtb_base = find_dtb_in_storage();
    const void *node;

    node = fdt_path(dtb_base, "/memory");
    if (node) {
        struct mem_region *mem = parse_reg_prop(node, "reg");
        ddr_start = mem->start;
        ddr_size  = mem->size;
    }

    node = fdt_path(dtb_base, "/chosen");
    bootargs = fdt_getprop(node, "bootargs", NULL);
}

以下是 BL2 阶段的关键资源配置示例：

资源类型	示例地址	来源方式
FIP镜像	0x08080000	eMMC LBA 0x1000
设备树（DTB）	0x08100000	FIP中UUID_NAMED_RESOURCE_DT
BL31入口	0x08200000	FIP中BL31_IMAGE_PACKAGE
公钥证书	0x08300000	OTP镜像解压后加载

完成后，调用 run_image() 函数，通过 eret 跳转至 BL31 入口点。

---

BL3：迈向操作系统的最后一步

BL3 阶段标志着引导流程接近尾声。主要包括：

• BL31 ：EL3 Runtime Software，处理 SMC、PSCI、电源管理；
• BL32 ：Secure OS，如 OP-TEE；
• BL33 ：Non-secure Bootloader，如 U-Boot 或 Linux Kernel。

BL31 的加载与控制权移交

void bl2_to_bl31(struct entry_point_info *bl31_ep)
{
    disable_interrupts();

    write_spsr_el3(SPSR_64(MODE_EL3, MODE_SP_ELX, DISABLE_ALL_EXCEPTIONS));
    write_elr_el3(bl31_ep->pc);

    register_t x0 = (register_t)bl31_ep->args[0].u.regval;
    register_t x1 = (register_t)bl31_ep->args[1].u.regval;

    __asm__ volatile(
        "mov x0, %x0\n\t"
        "mov x1, %x1\n\t"
        "eret"
        :: "r"(x0), "r"(x1)
    );
}

ERET 执行后，处理器跳转至 BL31，不再返回 BL2，完成控制权移交。

BL32 与 BL33 的协同启动

void bl31_main(void)
{
    psci_setup();

    if (bl32_ep && bl32_ep->pc)
        el3_enter_next_image(bl32_ep);  // 切换至EL1 Secure

    el3_enter_next_image(bl33_ep);      // 切换至EL2/EL1 Non-secure
}

其中 el3_enter_next_image() 会动态调整 SCR_EL3 中的 NS 位与 RW 位，决定目标执行状态。

至此，整个引导链完成，系统进入操作系统接管阶段。

---

ATF 实战：如何构建自己的可信固件

ARM Trusted Firmware（ATF）是目前最广泛使用的开源可信固件参考实现。它不仅提供了标准化引导框架，还集成了 TrustZone、PSCI、多核启动等核心功能。

目录结构一览

├── bl1/
├── bl2/
├── bl31/
├── drivers/
├── include/
├── lib/
├── plat/
├── services/
└── tools/

最关键的三个模块是 bl1 、 bl2 和 bl31 ，分别对应不同引导阶段。

构建你的第一个 ATF 镜像

首先配置交叉编译环境：

export CROSS_COMPILE=/opt/gcc-linaro-7.5.0-2019.12-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-
make PLAT=hikey960 RESET_TO_BL2=yes DEBUG=1 LOG_LEVEL=50 all

参数说明：

参数	含义
PLAT	目标平台
RESET_TO_BL2	是否直接从复位向量进入BL2
DEBUG	是否启用调试输出
LOG_LEVEL	日志等级

构建完成后生成 fip.bin ，可通过烧录工具写入设备。

使用 QEMU 快速验证

不想折腾真实硬件？试试 QEMU 吧！

qemu-system-aarch64 \
    -machine virt \
    -cpu cortex-a57 \
    -m 1G \
    -bios build/virt/debug/bl1.bin \
    -device loader,file=u-boot.bin,addr=0x80080000 \
    -nographic \
    -s -S

另开终端连接 GDB：

(gdb) target remote :1234
(gdb) break bl1_main
(gdb) continue

借助反汇编和寄存器查看，能精确定位空指针、非法跳转等问题。

---

安全强化：打造坚不可摧的信任链

安全启动（Secure Boot）机制

核心思想是在每个阶段对下一阶段镜像进行完整性校验，确保只有授权代码才能执行。

PKI 证书链构建

使用 OpenSSL 生成三级证书链：

openssl genrsa -out root.key 2048
openssl req -x509 -new -key root.key -sha256 -days 3650 -subj "/CN=Root CA" -out root.crt
...

信任锚点（根证书哈希）应固化于 ROM 或 eFUSE 中。

自动化签名集成

利用 imgtool 实现自动签名：

imgtool sign --key image_signing.key --image bl33.bin --output signed_bl33.img

在 Makefile 中集成：

$(BUILD_DIR)/fip.bin: $(BUILD_DIR)/bl33.bin
    imgtool sign --key $(KEY_DIR)/image_signing.key $<

---

性能优化：让启动快如闪电 ⚡

多核同步启动优化

传统方式由主核逐一唤醒其他 CPU，存在延迟累积。改用 PSCI CPU_ON 接口：

psci_cpu_on(1, (uint64_t)&secondary_entry_point);

改进后单核启动耗时从 142μs 降至 98μs，提升 31%！

冷启动时间压缩策略

• 减少冗余检测 ：BL1 完成时钟配置后广播状态标志，BL2 检测到即跳过；
• 并行初始化 ：使用中断驱动代替轮询；
• 镜像压缩 ：LZMA 压缩使 Flash 读取次数减少一半，总冷启动时间缩短 25%。

实测数据对比：

配置	加载时间（ms）	总冷启动时间
未压缩	210	480ms
LZMA压缩（62%）	98	360ms

---

实际案例：鲲鹏与树莓派的引导艺术

华为鲲鹏平台定制化引导

• 引入 KSBE 模块，支持国密算法 SM2/SM3；
• 双区 FIP 冗余存储，自动故障切换；
• 专用 DMA 引擎加速镜像加载，带宽达 1.2GB/s；
• 动态调整 PSCI 响应优先级适应 NUMA 拓扑。

树莓派4最小化启动链

编写极简引导程序绕过官方固件：

.section ".text.start"
.global _start
_start:
    mov sp, #0x80000
    mrs x0, mpidr_el1
    and x0, x0, #0xF
    cbz x0, primary_core
    b secondary_wait

primary_core:
    bl uart_init
    bl mmu_enable
    ldr x0, =kernel_entry
    br x0

整个引导过程小于 50ms，适用于实时控制场景。

---

写在最后：引导不只是“开机”

AARCH64 的引导流程远不止“从复位到启动”那么简单。它是软硬件协同设计的典范，是安全与性能博弈的战场，也是工程师智慧的结晶。

每一次成功的启动背后，都是无数细节的精准配合。而每一次失败的尝试，也都藏着值得深挖的经验教训。

希望这篇文章不仅能帮你理解 AARCH64 引导机制，更能激发你对底层系统设计的兴趣与敬畏之心 ❤️。

毕竟，真正的高手，从来不只是会敲命令的人，而是知道每一行代码背后发生了什么的人。✨