ARM64与x64启动流程对比：系统移植深度剖析

ARM64与x64启动流程对比：从加电到内核的系统移植实战解析

你有没有遇到过这样的情况：把一个在 x86_64 上跑得好好的 Linux 系统镜像，直接烧录到一块新的 ARM64 开发板上，结果——黑屏、串口无输出、CPU卡死？别急，这并不是硬件坏了，而是你跳过了最关键的一环：理解不同架构底层启动机制的根本差异。

随着苹果M系列芯片横扫桌面市场、AWS Graviton 和 Ampere Altra 在云服务器中快速普及，ARM64 已不再是“仅限手机”的代名词。越来越多的开发者需要面对这样一个现实：我们写的操作系统代码，必须能在两种截然不同的世界里安全落地。

本文不讲空泛理论，也不堆砌术语，而是带你一步步拆解从 CPU 上电那一刻起，ARM64 与 x64 到底走了怎样两条完全不同的路。你会发现，那些看似微小的设计选择——比如用设备树还是ACPI、是否有多级异常等级——最终决定了整个系统的可移植性边界。

固件起点：当 CPU 复位后，第一行代码从哪来？

一切都要从电源按下那一刻说起。

x64：BIOS/UEFI 掌控全局

在传统的 x86_64 平台上，CPU 复位后会自动跳转到内存地址0xFFFFFFF0—— 这是一个映射到主板 ROM 的固定位置。这里存放的就是BIOS 或 UEFI 固件。

UEFI（Unified Extensible Firmware Interface）是现代 PC 的标准固件接口。它不像老式 BIOS 那样只是个简单的初始化程序，而更像是一个轻量级操作系统：

• 提供图形界面、文件系统访问（FAT32）、网络协议栈；
• 支持模块化驱动加载；
• 使用ACPI 表描述硬件拓扑（CPU核心数、内存布局、中断控制器类型等）；
• 可以直接读取硬盘上的EFI\BOOT\BOOTX64.EFI文件并执行。

这意味着，在 x64 上，引导过程高度标准化。只要你遵循 UEFI 规范，哪怕换主板也能基本无缝运行。

// 示例：UEFI 应用入口（C语言） EFI_STATUS efi_main(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) { Print(L"Hello from UEFI!\n"); // 加载内核镜像、设置启动参数... return EFI_SUCCESS; }

这套机制成熟、稳定，但也带来了“PC 中心主义”的局限：所有硬件都得符合 PC 架构预期，比如必须有 PCI 总线、必须支持 ACPI。

ARM64：BootROM + 多阶段信任链启动

而在典型的 ARM64 SoC（如 Rockchip RK3588、NXP i.MX8、Ampere eMAG）中，事情完全不同。

CPU 上电后，并不会去访问外部 Flash 或 EEPROM，而是直接执行固化在芯片内部的一段只读代码 ——BootROM。这段代码由芯片厂商写死，不可修改，它的任务非常明确：

1. 初始化最基本的时钟和串口（为了能打印 debug 信息）；
2. 尝试从预设路径（SPI NOR、eMMC、USB、UART）加载第一阶段引导镜像（BL1）；
3. 对 BL1 进行签名验证（防篡改）；
4. 成功则跳转执行，失败则进入 ROM USB 模式等待刷机。

这个设计的核心思想是：安全始于硅片。即使后续软件被攻破，只要 BootROM 是可信的，整个系统就有恢复的基础。

接下来就是著名的Trusted Boot Chain（可信启动链），典型流程如下：

BootROM → BL1 (ATF) → BL2 → BL31 (SPD) → BL32 (TEE OS) → BL33 (U-Boot/Linux)

每一级都要对下一级进行完整性校验，形成一条“信任链”。其中最关键的组件是ARM Trusted Firmware (ATF)，它运行在最高特权等级 EL3，负责建立安全环境、管理异常切换、支持 PSCI 电源控制等。

⚠️ 注意：这里的“BL”不是 BootLoader 的缩写那么简单，而是代表了明确的安全职责划分。例如 BL31 是 Secure Payload Dispatcher，专门处理从非安全世界发起的 SMC 调用。

这种分层结构虽然复杂，但为 TrustZone 安全隔离提供了坚实基础。相比之下，x64 上要实现类似功能，还得依赖 Intel SGX 或 AMD SEV 这类附加技术。

权限模型的本质区别：Ring 还是 Exception Level？

很多人以为 x64 的 Ring0 和 arm64 的 EL1 是一回事。其实不然。它们背后反映的是两种完全不同的权限哲学。

x64：四层保护环（Rings 0–3）

x86 架构定义了四个特权级别：

• Ring 0：内核态，可访问所有资源；
• Ring 1 & 2：极少使用，部分操作系统曾用于驱动隔离；
• Ring 3：用户态，应用程序运行于此。

中断通过IDT（Interrupt Descriptor Table）分发，系统调用通过syscall/sysret快速切换。

优点是简单直观，缺点也很明显：缺乏原生安全扩展能力。你想做个安全支付应用？对不起，除非启用虚拟化或 SGX，否则只能靠软件沙箱。

而且，现代 Linux 实际只用了 Ring 0 和 Ring 3，中间两层几乎成了历史包袱。

ARM64：EL0–EL3 异常等级模型

arm64 的异常等级不是为了兼容旧软件而设计的，而是为现代计算需求重新规划的结果：

每个等级有自己的寄存器视图（如SP_EL1,VBAR_EL2）、异常向量表和 MMU 配置。切换时需显式保存上下文状态。

举个例子：当你在 Android 手机上进行指纹识别时，普通系统（Linux）运行在 Non-secure World 的 EL1，而指纹加密运算则发生在 Secure World 的 EL1 —— 两者物理共存于同一颗 CPU 上，但逻辑隔离，这就是TrustZone的威力。

再看一段实际代码：

// 设置 EL1 异常向量表基址 mov x0, #0x80000 msr vbar_el1, x0 isb

这条指令告诉处理器：“以后发生中断或异常时，请跳到0x80000地址去找处理函数”。注意，这是针对 EL1 的设置，如果你在 EL3 上还要单独配置vbar_el3。

相比之下，x64 只有一个全局 IDTR 寄存器，没有这种细粒度控制。

引导加载器：GRUB vs 多阶段协作

到了 bootloader 层，差异更加显著。

x64：GRUB 主导一切

在 x64 上，GRUB 几乎是事实标准。它分为两个阶段：

• Stage 1：写入 MBR（主引导记录），负责加载 Stage 2；
• Stage 2：功能完整，支持多种文件系统（ext4、btrfs）、脚本解析、菜单选择、模块动态加载。

你可以轻松编辑/boot/grub/grub.cfg来定制启动项：

menuentry 'Linux' { linux /boot/vmlinuz root=/dev/sda1 ro quiet initrd /boot/initrd.img }

GRUB 直接加载内核镜像，填充boot_params结构体，然后跳转执行。整个过程一气呵成，调试方便。

ARM64：U-Boot 只是链条的最后一环

但在 arm64 上，U-Boot 往往只是 BL33 —— 即整个信任链的最后一环。

前面还有 ATF 负责完成关键初始化工作：

• 建立 EL3 到 EL1 的跳转路径；
• 配置 GIC（通用中断控制器）；
• 启动其他 CPU 核心；
• 准备传递给 U-Boot 的参数块。

最终通过eret指令降级到 EL1，将控制权交给 U-Boot。

来看一段关键跳转代码：

void cortex_a53_plat_goto_ns_bl33(struct entry_point_info *bl33_image_info) { write_spsr(el_im_to_spsr(bl33_image_info->h.attr)); write_elr(bl33_image_info->pc); // 设置返回地址 eret(); // 异常返回，进入非安全世界 }

这里的eret不是一般意义上的函数调用，而是一次完整的异常等级下降操作。它会从ELR_EL3寄存器取出目标地址，同时切换 SP 和 PSTATE，进入指定异常等级。

如果你在这一步配置错误（比如没清零 SCTLR 中的 EE 位导致大小端混乱），系统就会无声无息地卡住，连串口都没输出。

内核如何认识硬件？ACPI vs Device Tree

操作系统启动后，第一件事就是搞清楚“我面前有哪些硬件”。

x64：ACPI 统治一切

在 x64 上，这个问题的答案来自ACPI（Advanced Configuration and Power Interface）表。

UEFI 固件会在内存中构建一系列二进制表（如 MADT、DSDT、FADT），描述：

• CPU topology（核心数量、拓扑关系）；
• 内存区域划分；
• 中断路由（IOAPIC、HPET）；
• 电源管理方法（_S3、_S4）；

Linux 内核通过扫描 RSDP（Root System Description Pointer）找到这些表，然后解析 AML 字节码来获取信息。

好处是统一规范，坏处是灵活性差。你想加个新外设？除非 ACPI 表更新，否则内核根本不知道它的存在。

ARM64：设备树灵活适配

arm64 采用Device Tree（设备树）机制。它本质上是一个.dts文本文件，编译成.dtb二进制 blob，由 U-Boot 传给内核。

示例片段：

/dts-v1/; / { model = "Rockchip RK3588 Board"; chosen { bootargs = "root=/dev/mmcblk0p2 rw console=ttyS2,1500000"; }; cpus { cpu@0 { compatible = "arm,cortex-a76"; reg = <0x0>; }; }; memory@0 { device_type = "memory"; reg = <0x0 0x0 0x0 0x80000000>; /* 2GB */ }; };

内核启动时调用early_init_dt_scan()解析 DTB，自动注册 platform_device，匹配of_match_table驱动表。

这种方式极大提升了可移植性：同一份内核镜像，配合不同的 DTB，就能适配上百种开发板。

但也有代价：你需要维护一堆.dts文件，且一旦 DTB 损坏或地址传错，系统将无法启动。

💡 小技巧：在 U-Boot 中可用fdt addr <dtb_phys>和fdt print命令检查设备树是否正确加载。

移植实战：四大常见坑点与应对策略

当你真正动手做系统移植时，以下问题几乎不可避免。

1. 设备驱动绑定失败

现象：网卡、GPIO 控制器找不到，驱动不加载。

原因：x64 使用 PCI 枚举设备，arm64 多用 platform_device + OF_MATCH_TABLE。

解决方案：
- 添加设备树节点；
- 驱动中使用MODULE_DEVICE_TABLE(of, xxx_of_match)；
- 在 probe 函数中通过of_property_read_u32()获取参数。

static const struct of_device_id my_driver_of_match[] = { { .compatible = "vendor,my-device", }, { } }; MODULE_DEVICE_TABLE(of, my_driver_of_match);

2. 中断系统无法响应

x64 使用 APIC，arm64 使用 GIC

GICv2/v3/v4 版本差异大，配置稍有不慎就会导致中断丢失。

对策：
- 确保设备树中正确声明 interrupt-controller 节点；
- 使用标准 IRQ domain 框架；
- 在 early_init 中调用gic_of_init()自动探测。

3. 休眠唤醒失败

x64 依赖 ACPI _S3 方法进行挂起；arm64 依赖 PSCI（Power State Coordination Interface）

若 ATF 未正确实现PSCI_CPU_SUSPEND，调用cpuidle会导致系统宕机。

修复步骤：
- 检查 ATF 是否启用CONFIG_ARM_PSCI_FW；
- 实现psci_cpu_suspend()作为 idle handler；
- 确保所有 CPU core 都能被独立关闭/重启。

4. 安全启动失败

x64 的 Secure Boot 基于 UEFI KEK/PK 签名；arm64 需构建完整的 Chain of Trust

如果 BL2 没签名，BootROM 就不会加载它，整个链条断裂。

解决办法：
- 使用imgtool（TF-A 提供）对各阶段镜像签名；
- 在 SoC OTP 区域烧录公钥哈希；
- 开发阶段可先禁用验证（风险自担）。

如何高效开展跨平台移植？

面对如此复杂的差异，有没有办法简化工作？

当然有。以下是经过验证的最佳实践：

✅ 统一构建系统

使用Buildroot或Yocto Project构建双架构镜像：

# Buildroot 示例 make qemu_x86_64_defconfig # x64 模拟 make qemu_aarch64_virt_defconfig # arm64 模拟 make

一套配置，产出两个平台的根文件系统和内核镜像。

✅ 抽象硬件差异

利用 DTSI（Device Tree Source Include）复用公共配置：

board-common.dtsi ← 公共 CPU、GIC、UART 定义 ↓ board-a.dts ← 包含 board-common.dtsi，添加特定外设 board-b.dts

减少重复劳动，提高一致性。

✅ 日志先行

确保串口 console 在 BL1 阶段就能输出。这是调试的第一生命线。

建议：
- 使用低成本 CP2102 转 USB 串口模块；
- 波特率统一设为 115200；
- 在每阶段开始打印标志字符串（如[BL1] Start...）。

✅ 启用现代特性

尽管增加复杂度，但值得开启：
-KASLR（内核地址空间随机化）提升安全性；
-PIE（Position Independent Executable）支持更灵活加载；
-Early printk + panic 输出堆栈，便于定位崩溃点。

最后的思考：走向融合的未来

有趣的是，这两种原本泾渭分明的架构，正在互相靠近。

一方面，EDK II（UEFI 实现）已被移植到许多 ARM64 服务器平台，甚至支持加载 PE/COFF 格式的 payload；

另一方面，ACPI 也开始出现在部分 arm64 设计中（如微软 SQ1/SQ2 芯片），以便更好地与 Windows 生态整合。

这说明了一个趋势：在高性能领域，标准化的价值正在超越架构本身的偏好。

但对于嵌入式、边缘计算、IoT 等场景，arm64 的设备树+多阶段引导+TrustZone 组合依然具有不可替代的优势。

所以，下次你在做系统移植时，不妨问自己几个问题：

• 我的目标平台，信任根在哪里？
• 硬件信息是由谁提供的？ACPI 还是 DTB？
• 当前运行在哪个异常等级？能否顺利降到 EL1？
• 下一阶段的入口参数是否正确设置了？

这些问题的答案，往往比“换个编译器”重要得多。

如果你也在进行类似的移植项目，欢迎在评论区分享你的经验或踩过的坑。毕竟，底层世界的探险，从来都不是一个人的旅程。