1. ARM64平台的特殊性与启动挑战
在嵌入式系统和移动设备领域，ARM64架构已经成为绝对主流。与传统的x86体系不同，ARM64平台的启动流程有着独特的硬件交互方式和阶段划分。我第一次在树莓派4B上移植Linux时，就深刻体会到理解完整启动链的重要性——当时因为忽略了TrustZone初始化阶段，导致系统在U-Boot阶段反复重启。
ARM64架构的启动流程之所以复杂，主要源于三个特性：多级异常等级（EL0-EL3）、丰富的协处理器配置选项，以及强制要求的内存管理单元（MMU）早期启用。这些特性使得从冷启动到用户空间的每一步都需要精心设计。
2. 冷启动阶段：从复位向量到BL1
2.1 硬件复位后的第一条指令
当按下开发板的电源键时，所有CPU核心都会从复位向量地址（通常是0x00000000或0xFFFF0000）开始执行。在主流ARM64 SoC如瑞芯微RK3566上，这个地址通常映射到芯片内部的Boot ROM。这个只有几十KB的ROM里固化着厂商提供的最初级启动代码。
关键细节：部分SoC允许通过熔丝位修改复位向量地址，这在安全启动场景下非常有用。
2.2 Boot ROM的核心任务
Boot ROM会依次完成以下工作：
- 初始化关键时钟和DRAM控制器
- 扫描预定义的存储介质（eMMC、SD卡、SPI Flash等）
- 加载并验证第一阶段引导加载程序（通常称为BL1）
以全志H616芯片为例，其Boot ROM会优先检查SD卡0扇区是否存在合法的eGON头部（全志特有的签名标记），若不存在则转向eMMC搜索。
3. 引导加载程序阶段：从BL1到U-Boot
3.1 ARM Trusted Firmware的作用
现代ARM64系统普遍采用ARM Trusted Firmware（ATF）作为BL1的实现。以NXP i.MX8MM为例，其启动流程如下：
bash复制BL1 (ATF) → BL2 (ATF) → BL31 (ATF运行时服务) → BL32 (OP-TEE) → BL33 (U-Boot)
每个阶段都有明确的职责划分：
- BL1：初始化安全环境
- BL2：加载后续镜像并验证
- BL31：提供PSCI等运行时服务
- BL32：可选的安全操作系统（如OP-TEE）
3.2 U-Boot的定制与移植
当控制权转移到U-Boot时，系统已经具备完整的内存访问能力。在RK3588开发板上移植U-Boot时，需要特别注意：
- 设备树文件的兼容性：
dts复制/ {
compatible = "rockchip,rk3588";
#address-cells = <2>;
#size-cells = <2>;
};
- 内存控制器配置：
c复制static struct dram_info dram_info = {
.base = 0x0,
.size = 0x80000000, // 2GB内存
};
- 启动命令环境设置：
bash复制setenv bootargs "console=ttyFIQ0 root=/dev/mmcblk1p8"
setenv bootcmd "load mmc 1:1 0x10000000 Image; booti 0x10000000"
4. Linux内核启动流程解析
4.1 内核镜像格式与加载
ARM64内核通常采用Image格式（非压缩）或Image.gz（压缩）。以树莓派为例，其启动过程会经历：
- 头部校验：检查magic number "ARM\x64"
- 重定位：将内核移动到指定物理地址
- 解压（如适用）：使用LZ4或GZIP算法
4.2 早期汇编阶段关键步骤
在内核入口点（通常是stext符号），会依次执行：
assembly复制stext:
bl preserve_boot_args // 保存启动参数
bl el2_setup // 配置异常等级
bl set_cpu_boot_mode_flag
bl __create_page_tables // 创建初始页表
bl __cpu_setup // 配置处理器
b __primary_switch // 开启MMU并跳转到C代码
这个阶段最易出错的点是页表配置。我曾遇到因1GB大页配置不当导致的内核崩溃，解决方法是在设备树中明确内存区域：
dts复制memory@80000000 {
device_type = "memory";
reg = <0x00000000 0x80000000 0x0 0x80000000>;
};
5. 内核初始化到用户空间
5.1 start_kernel的初始化序列
当进入C语言环境后，内核会依次初始化：
- 陷阱处理（trap_init）
- 内存管理（mm_init）
- 调度器（sched_init）
- 设备树解析（unflatten_device_tree）
特别值得注意的是console_init的时机选择。过早初始化可能导致日志丢失，过晚则无法调试早期问题。
5.2 用户空间启动过程
从内核到用户空间的过渡涉及：
- 内核线程kthreadd创建
- 初始化ramdisk执行/init
- 切换到systemd或init进程
在嵌入式系统中，常见的启动优化手段包括：
- 并行初始化（CONFIG_ASYNC_INIT）
- 延迟初始化（CONFIG_DEFERRED_INITCALLS）
- 热插拔优化（CONFIG_HOTPLUG_CPU）
6. 调试技巧与常见问题
6.1 早期启动问题定位
当系统卡在U-Boot阶段时，可以：
- 检查串口输出电平（3.3V vs 1.8V）
- 验证设备树地址是否正确传递
- 确认内存配置参数
bash复制=> md.l 0x40000000 10 // 查看内存内容
=> fdt addr 0x83000000 // 设置设备树地址
6.2 内核panic解决方案
遇到内核崩溃时，首先检查：
- 异常等级是否正确降级（EL2→EL1）
- 页表映射是否完整
- 设备树兼容性字符串
c复制early_printk("Current EL: %d\n", get_current_el());
7. 性能优化实践
7.1 启动时间测量
使用示波器测量关键节点：
- BL1到BL2：通常<200ms
- U-Boot加载：500ms-2s
- 内核解压：取决于压缩算法
bash复制dmesg | grep "clocksource" # 查看时间源精度
7.2 压缩算法选择对比
实测数据（RK3399平台）：
| 算法 | 压缩率 | 解压时间 | 总启动时间 |
|---|---|---|---|
| LZ4 | 35% | 0.8s | 3.2s |
| GZIP | 28% | 1.5s | 3.9s |
| ZSTD | 32% | 1.1s | 3.5s |
在存储空间充足的情况下，LZ4通常是首选方案。
8. 安全启动实现
8.1 信任链构建
现代ARM64系统通常采用以下安全方案：
- Boot ROM验证BL1签名（RSA-PSS）
- BL1验证BL2/BL31（SHA256哈希）
- BL2验证内核和initramfs
在i.MX8QM上配置HAB的典型命令：
bash复制hab_csf -t 0x1000 -k key.pem -c csf.txt -i u-boot.imx
8.2 安全存储实践
使用SoC的OTP区域存储密钥时要注意：
- 分阶段烧写（先写使能位，再写数据）
- 保留备份区域
- 监控温度（高温可能导致烧写失败）
c复制static void program_otp(uint32_t *data)
{
writel(0x1, OTP_CTRL); // 使能编程模式
for (int i = 0; i < 8; i++) {
writel(data[i], OTP_DATA + i*4);
}
writel(0x2, OTP_CTRL); // 触发烧写
}
在RK3568平台上调试安全启动时，我发现一个关键细节：当启用安全启动后，JTAG调试接口会被自动禁用。此时需要通过串口配合efuse读写命令来恢复设备：
bash复制rkdeveloptool efuse read > efuse.bin
# 修改efuse.bin中的安全配置位
rkdeveloptool efuse write efuse.bin
这种深度集成的安全特性既是ARM64的优势，也给开发者带来了新的挑战。建议在开发阶段保留恢复模式，量产时再完全锁定设备。