ARM Trusted Firmware深度解析：架构、安全审计与平台移植实践

ARM Trusted Firmware 深度源码评测：ATF 架构全景梳理、安全固件工程审计与平台移植落地指南

这两年我在嵌入式安全领域摸爬滚打，接触最多、也最绕不开的一个基础组件就是 ARM Trusted Firmware（ATF）。不管是做手机 Secure Boot、平板固件安全升级，还是边缘网关的可信启动链，ATF 几乎都是绕不开的第一道关口。它跑在 Linux 内核之下、硬件之上，负责把 CPU 从 EL3 安全世界带到 EL1 内核世界，同时承担着 PSCI 电源管理、安全监控模式切换、可信启动认证这些底层脏活累活。这篇文章我准备从源码层面拆解 ATF 的架构全景，聊聊做固件工程审计时应该重点盯哪些文件和调用链，最后分享一下我在平台移植过程中的完整落地步骤和踩坑实录。内容主要来自这一年来基于实际项目对 ATF 源码的持续阅读和移植验证，希望能帮到正在做 ARM 底层固件、Secure Boot 方案选型或正准备把 ATF 移植到新板卡上的朋友。

先说明一下，文章里的源码分析基于 TF-A 的 LTS 分支（v2.8 系列），同时我会穿插一些 master 分支上的新特性对比。如果你手头的代码版本不同，行号和宏定义可能会有出入，但核心架构和调用链基本一致。

1. ATF 在 ARM 启动流程中的位置与核心价值

1.1 ATF 解决了什么问题

很多人第一次接触 ATF 时会被它的名字吓到，觉得它是一个庞然大物。其实 ATF 的定位非常聚焦：它是 ARM 平台上"安全世界"的固件参考实现，提供了从片上 ROM 启动到内核运行之间那段真空地带的标准化方案。在 ATF 出现之前，各家 SoC 厂商在 BootROM 之后几乎都是各搞一套，安全监控模式的代码千奇百怪，也没有统一的电源状态协调接口。ATF 的价值在于，它把 EL3 异常等级下的安全监控模式、电源管理、可信启动这些能力做成了一个可复用的标准框架。

用生活类比来理解：如果 Linux 内核是一个公司的业务部门，那 ATF 就是这家公司的保安系统和物业总管。保安系统负责验证每一个进入公司的人是否持有合法工牌（Trusted Boot 认证），物业总管负责在业务部门休息时管理大楼的照明和电力分配（PSCI 电源管理）。业务部门自己在正常工作时间做业务，但上下班开关门、凌晨停电如何恢复，这些都归物业和保安管。

1.2 启动链路全景：BL1、BL2、BL31、BL32、BL33 的接力赛

我在刚开始读 ATF 源码时，最大的困惑是它的启动流程里为什么会有这么多 BL（Boot Loader）阶段。后来跟着代码走了一遍才明白，这其实是一场严格分工的接力赛。

整个启动链路从 SoC 出厂固化的 BootROM 开始：

• BL1：存放在片上 ROM 或一次性可编程存储中，是复位后的第一个可执行代码，负责初始化最小硬件环境，把 BL2 从外部存储加载到 SRAM 并完成安全认证，然后跳转过去。BL1 的代码量最小，但容错要求最高。
• BL2：运行在 EL3 下的可信启动固件，负责初始化 DDR、加载 BL31（和可选的 BL32）到内存，执行镜像签名验证，验证通过后跳转到 BL31。
• BL31：常驻内存的 EL3 运行时固件，包含 Secure Monitor、PSCI 电源管理实现、SMC 调度器，是 ATF 中最核心的"物业总管"。
• BL32：可选的 Trusted OS（如 OP-TEE），运行在 S-EL1，通过 SMC 与 BL31 通信。如果你的产品不需要 TEE，这个阶段可以跳过。
• BL33：就是我们常说的 U-Boot 或 UEFI，运行在 EL2/EL1，最终引导 Linux 内核。

关于 BL31 和 U-Boot 的关系，很多做上层开发的朋友容易混淆。BL31 运行在 EL3，U-Boot 运行在 EL2/EL1，两者的职责完全不同。U-Boot 阶段如果需要做电源管理相关操作，比如 CPU 热插拔、系统挂起唤醒，必须通过 SMC 指令陷入 EL3，由 BL31 里的 PSCI 实现来真正操作硬件寄存器。这也是为什么 ATF 经常和 U-Boot 一起出现在启动代链中——它们在异常等级上是上下级关系。

1.3 异常等级与安全状态模型

理解 ATF 绕不开 ARM 的异常等级模型。ARMv8-A 定义了四个异常等级，从 EL0 到 EL3，数字越大特权越高。系统复位后 CPU 默认进入 EL3，ATF 的 BL1/BL2/BL31 都在这个等级运行。EL2 通常跑虚拟化层（Hypervisor），EL1 跑操作系统内核，EL0 跑用户态应用。

ATF 架构里还有一个非常重要的概念：安全世界（Secure World）和普通世界（Normal World）。这两个世界共享同一套 CPU 物理资源，但通过 TrustZone 技术做了隔离。Linux 运行在普通世界，TEE 运行在安全世界，两个世界之间的切换必须经过 EL3 的 Secure Monitor，也就是 BL31 里的bl31_main和上下文管理模块。每次切换都需要保存和恢复完整的 CPU 上下文，这部分代码在context_mgmt.c里，是 ATF 中极其考验细节的地方。

2. ATF 源码结构全景与关键目录审计

2.1 源码顶层目录速览

我习惯拿到一份源码先看目录结构，因为目录设计通常反映了整个工程的核心模块划分。TF-A 的顶层目录并不复杂，但每个目录的职责非常清晰：

tf-a/ ├── bl1/ # BL1 阶段源码 ├── bl2/ # BL2 阶段源码 ├── bl31/ # BL31 阶段源码 ├── bl32/ # BL32（TEE 入口）相关代码 ├── common/ # 各 BL 阶段共享的通用代码 ├── drivers/ # 驱动：串口、定时器、IO 存储、认证加密等 ├── lib/ # 核心库：el3_runtime、psci、stack_protector 等 ├── plat/ # 平台移植代码，核心工作区 ├── services/ # 运行时服务：SMC 调度、std_svc、trng 等 ├── include/ # 全局头文件 ├── tools/ # 构建与镜像处理工具（cert_create、fiptool 等） ├── makefile # 顶层构建入口 └── docs/ # 设计文档与移植指南

从工程审计的角度看，plat/目录是每次必看的，因为这是芯片厂商和方案商修改最集中的地方。lib/el3_runtime/里的上下文切换代码、lib/psci/里的电源管理框架、services/里的 SMC 调度器则决定了这个信任根实现是否健壮。

2.2 核心库源码审计要点

el3_runtime：这个目录下主要是 AArch64 的异常进入与退出实现，以及上下文管理。context_mgmt.c负责维护安全世界和普通世界的上下文结构体，每一个cpu_context都保存了通用寄存器、系统寄存器、SVE 寄存器状态。在做安全审计时，我重点检查的是上下文切换时是否完整保存了所有相关寄存器，尤其是vbar_el3、sctlr_el3这类影响安全策略的系统寄存器。

psci：PSCI（Power State Coordination Interface）是 ARM 定义的电源管理接口标准。ATF 里的实现分成两层：上层是 PSCI 服务框架，负责解析 SMC 请求、校验参数、分发调用；底层是平台操作函数，比如platform_cpu_pwr_down、platform_cpu_suspend，这些需要移植时在平台代码里实现，或者引入 scpi/sip 等协议与下游的电源管理处理器通信。做移植的朋友可以重点看psci_setup.c里的初始化顺序，以及psci_cpu_on.c的启动流程。

el3_common：这里存放 EL3 阶段共用的初始化代码，包括 cache 使能、MMU 配置、异常向量表设置。BL31 的入口bl31_entrypoint.S就在这里，是整个安全固件运行起来的第一行汇编。我在审计时习惯先看这段汇编，确认启动时 CPU 处于什么状态、需要规避哪些硬件 bug。

2.3 运行时服务与 SMC 调度机制

ATF 启动完成后，主要工作就是响应普通世界的 SMC 请求。所有 SMC 请求进入 EL3 后，都会先经过runtime_svc.c里的分发逻辑。这个逻辑非常精巧：SMC 指令的函数 ID 编码里包含了服务类型、调用类型等信息，ATF 根据这些字段决定将请求转给哪个运行时服务。

标准服务（std_svc）通常处理 PSCI 请求，比如PSCI_CPU_ON、PSCI_CPU_OFF、PSCI_SYSTEM_SUSPEND。SiP（Silicon Provider）服务则留给芯片厂商实现私有功能，比如厂商特有的安全配置、温度读取、AB 分区切换等。

这里有个容易忽略的审计点：SMC 返回值是否对调用者做了合法检查。一个负责任的安全固件，必须在进入具体服务处理前验证调用者位于普通世界还是安全世界、请求的服务 ID 是否被允许。在runtime_svc.c的runtime_svc_init和handle_runtime_svc流程里，这些检查逻辑是否完整决定了整个系统安全边界的强度。

3. 平台移植落地实操：从零适配一块自定义 ARM 板卡

3.1 移植前必须搞清楚的几个问题

很多初学者拿到一块新板子，第一反应是直接照抄参考平台的代码。这个思路没错，但容易翻车。我建议在动手前先回答这三个问题：

• 板卡的 DDR 初始化由谁来负责？如果是 U-Boot 负责 DDR 初始化，ATF 的 BL2 在加载 BL31 时可能还没有 DDR 可用，那就需要在 BL2 阶段将 BL31 加载到 SRAM 里，等 U-Boot 起来后再做一次低功耗驻留。如果是 ATF 的 BL2 负责 DDR 初始化，那么 BL2 中需要集成厂商提供的 DDR 驱动，这通常是最费时的部分。
• 串口控制器的具体型号和寄存器基址是什么？ATF 的早期启动打印离不开串口，你需要确认你的串口芯片是否被drivers/uart下的某个驱动支持，如果用的是 SoC 内部定制串口，可能需要自己写一个简单的字符输出驱动。
• 板卡有没有独立的电源管理控制器（PMC）？如果需要支持 CPU 热插拔和深度睡眠，就要确认如何与 PMC 通信，是 MMIO 寄存器访问，还是通过 SCPI 协议与另一个 M 核处理器通信。

我这次移植用的是一个基于 Cortex-A72 的定制板卡，4 核 CPU，DDR4 内存，串口用的是 SoC 内部的 8250 兼容控制器。目标是把 ATF 跑在 FVP 和 QEMU 环境上验证流程，再对接实际板卡。下面我以这套环境为例，给出从零开始移植的完整路径。

3.2 基于现有参考平台搭出属于你的 plat 目录

ATF 的plat/目录里已经提供了大量参考平台，比如arm/board/fvp、arm/board/juno、qemu、nvidia/tegra、rockchip/rk3399等。选择参考平台时优先选与你的目标 SoC 架构最接近的，可以节省大量工作。我这个项目基于 QEMU 虚拟环境和一块定制的 A72 开发板，参考的是plat/qemu的目录结构。每个平台目录下基本都有这些文件：

plat/<vendor>/<board>/ ├── plat.mk # 平台构建配置，定义需要编译哪些源文件 ├── platform_def.h # 平台宏定义，内存布局、串口地址、GIC 地址等 ├── bl31_plat_setup.c # BL31 阶段平台初始化 ├── bl2_plat_setup.c # BL2 阶段平台初始化 ├── plat_topology.c # CPU 拓扑结构定义（集群、核心、线程） ├── plat_pm.c # 电源管理操作函数 ├── plat_console.c # 控制台输出配置 ├── aarch64/platform_common.c # 共享平台函数 └── include/plat_macros.h # 平台辅助宏

创建一个新平台的 ATM（All-to-Make）最快路径是：先复制一份 qemu 的目录到你自己的厂商目录下，然后逐文件修改。改到能编译通过、能启动，再逐步清掉不需要的代码。

3.3 平台内存布局与platform_def.h配置

platform_def.h是移植最容易出错的地方。它定义了 ATF 各个镜像的加载地址和数据存放地址。我在做第一个移植板时，因为 DDR 地址配置错误，BL31 加载完成跳转后直接跑飞，串口上什么都没有输出，排查了很久。下面是核心宏的说明，以我的板卡为例如下：

#define PLAT_PRIMARY_CPU 0x0 #define PLAT_CLUSTER_COUNT 1 #define PLAT_MAX_CPUS_PER_CLUSTER 4 /* 内存布局 */ #define ARM_TRUSTED_SRAM_BASE 0x04000000 /* SRAM 基址 */ #define ARM_TRUSTED_SRAM_SIZE 0x00040000 /* SRAM 大小 256KB */ #define BL31_BASE 0x04000000 #define BL31_SIZE 0x00040000 #define BL32_BASE 0x04200000 #define BL32_SIZE 0x00040000 /* 串口信息 */ #define PLAT_ARM_UART_BASE 0x09000000 #define PLAT_ARM_UART_CLK_IN_HZ 24000000 #define PLAT_ARM_UART_BAUDRATE 115200 /* GIC 信息 */ #define PLAT_ARM_GICD_BASE 0x2f000000 #define PLAT_ARM_GICC_BASE 0x2c000000

这里的核心逻辑是：SRAM 必须够放下 BL31（以及 BL32 可选），所以 SRAM 的基址和大小要根据芯片手册确定。如果 SRAM 太小，就必须考虑 XIP（片上执行）或加载到 DDR 后运行的模式，但这会牺牲启动早期阶段的安全性。一般 Cortex-A 系列的 SoC 至少会留 256KB 到 1MB 的 SRAM 给 ATF，实测 256KB 跑最小配置的 BL31 已经比较紧凑，如果还要用 TBBR 安全启动和 TRNG 那就得规划仔细。

PLAT_ARM_UART_BASE和时钟频率必须和你的板子实际一致，否则串口打印乱码或者完全没有输出。在最早阶段调不通串口时，我只能靠逻辑分析仪抓波形。

3.4 构建流程与编译命令解析

TF-A 的构建顶层用的是makefile，配合平台目录下的plat.mk。编译一个 AArch64 平台的命令如下：

make CROSS_COMPILE=aarch64-linux-gnu- \ PLAT=qemu \ DEBUG=1 \ LOG_LEVEL=40 \ BL33=./u-boot/u-boot.bin \ ARM_TSP_RAM_LOCATION=tdram \ all fip

几个重要参数说明：

• PLAT=qemu指定平台名，对应plat/qemu/目录。
• DEBUG=1打开调试选项，会保存更多符号信息，日志输出也可以用。产品发布时务必改成DEBUG=0，关掉多余日志。
• LOG_LEVEL=40是日志级别，40 对应LOG_LEVEL_INFO，如果排查问题可以调到 50（VERBOSE），会打出非常详细的 EL3 运行路径。
• BL33=...需要指定 BL33 镜像（U-Boot 或 UEFI），特别是生成fip镜像时必须带上。
• all fip表示编译所有 BL 阶段，并用fiptool打包生成fip.bin，这是烧录到板卡的主镜像。

如果不想每次手动传 BL33，也可以先把BL33路径写到plat/qemu/platform.mk里。

交叉编译工具链的选择值得多说一句。ATF 的交叉编译工具链一般用aarch64-linux-gnu-gcc或arm-none-eabi-gcc（取决于你是否使用 newlib），我个人更推荐aarch64-linux-gnu-gcc，因为 ATF 的某些测试和工具链依赖 Linux 头文件。注意不要用 ARM Compiler 5（AC5）来编译 ATF。AC5 是老旧的 ARMCC 产物，它不会生成 AArch64 代码。网上那些关于arm compiler 5.06u7 下载的内容，基本都是针对裸机 STM32 这类 Cortex-M 平台或老旧的 ARM32 平台的，ATF 的 AArch64 世界完全用不上。在 aarch64 生态里，标准工具链要么是 ARM 官方的aarch64-none-elf-gcc，要么是发行版自带的aarch64-linux-gnu-gcc。如果你在某个资源站搜索 AC5 想拿来编 ATF，属于走错大门了。

3.5 BL31 平台初始化函数详解

BL31 的启动入口在lib/el3_common/aarch64/bl31_entrypoint.S，它完成最底层的基础设置后，跳转到 C 函数bl31_main，然后依次调用平台初始化函数。这里我挑最重要的三个函数剖析一下。

bl31_early_platform_setup是第一个被调用的平台函数，主要做非常早期的硬件准备：

void bl31_early_platform_setup(void *from_bl2, void *plat_params_from_bl2) { /* 从 BL2 传递过来的内存信息不能直接信任，必须做校验 */ assert(from_bl2 == NULL); /* 初始化串口，这是后续所有日志的先决条件 */ console_16550_register(PLAT_ARM_UART_BASE, PLAT_ARM_UART_CLK_IN_HZ, PLAT_ARM_UART_BAUDRATE); /* 配置 GIC 安全中断 */ plat_gic_driver_init(); plat_gic_init(); }

我在移植时踩过一个坑：console_16550_register之后我没有做console_set_scope的配置，结果串口打印一会儿有一会儿没有，后来发现是 Linux 内核起来后console 被重定向了。在 BL31 阶段建议把 console 的作用域设为CONSOLE_FLAG_BOOT和CONSOLE_FLAG_RUNTIME都打开，保证运行期也能看到 PSCI 相关日志。

bl31_plat_arch_setup用来配置 BL31 运行时的 MMU 和内存属性：

void bl31_plat_arch_setup(void) { /* 构建页表，映射 BL31 的代码段、数据段和设备区域 */ mmap_add(bl31_mmap); init_xlat_tables(); enable_mmu_el3(0); }

这个函数正常的流程是用 xlat table 库把设备内存映射为 Device 属性、把普通内存映射为 Normal 属性。如果你的 MMU 配置里把一个只有 Device 属性的外设映射成了普通内存，编译器可能会对寄存器读写做合并或重排，导致硬件行为诡异。这里建议用mmap_add_region单独为每个外设配置类型，而不是用一个大 WHERE 区域覆盖全部地址空间。

bl31_platform_setup是通用的平台初始化收尾点，一般放定时器初始化、安全外设配置、SIP 服务的准备等。这些其实比较简单，主要看你的板级需求。

4. 安全固件工程审计实战：从代码到硬件的信任链构建

4.1 可信启动链（Trusted Board Boot）如何设计与验证

安全固件审计，最核心的就是信任链设计。ARM 的可信启动链（Trusted Board Boot，简称 TBBR）思路非常直白：从 BootROM（被 SoC 出厂固化信任）开始，每一级固件必须验证下一级固件的签名和完整性，通过验证才允许被执行。

LF 整个流程中，平台证书是沿着链式结构逐级签名的。BL1 在片内 ROM 中，它验证 BL2 的镜像，BL2 验证 BL31、BL32、BL33。每级镜像都有对应的数字证书，证书里包含镜像的哈希值、签名和授权信息。ARM 提供了tools/cert_create来生成这些证书，同时提供了tools/fiptool把证书和镜像打包成 FIP。

我在实际项目中验证这套信任链时，发现两个非常有价值的审计点：

第一，BL2 是否强制校验密钥属性。如果你的产品有生产密钥、开发密钥之分，那么 BL2 在验证镜像签名时不能仅仅验证"密钥能解开"，还要验证"密钥是谁的"。在 ATF 里这通过Trusted Key Certificate的场景来管理，如果配置不完整，攻击者完全可以替换成自己的开发密钥签名镜像，绕过整个安全启动。

第二，镜像哈希算法和密钥长度。ARM 默认推荐 RSA-2048，但随着算力提升，很多产品已经切换到 RSA-3072 或 ECC。ATF 在 v2.6 之后也支持 ECC 曲线。如果你要过国密合规，还要自己改造认证算法，ATF 提供了独立的auth_mod框架，把完整性校验、签名验证抽象成模块化接口，重写drivers/auth/mbedtls或加入自己的 crypto engine 驱动都是可行的。

4.2 镜像认证与签名验证的代码路径

ATF 里的认证框架代码主要位于drivers/auth/，你用auth_mod接口注册认证方法和存储方法。启动时，每个 BL 镜像的加载都会经过认证流程，这个过程在bl2_main.c中可以被看到：

static int load_and_auth_image(unsigned int image_id, image_info_t *image_data) { /* 1. IO 层从存储设备读取镜像 */ /* 2. 解析镜像头部，提取元数据 */ /* 3. 调用 auth_mod 验证签名 */ /* 4. 验证通过后返回镜像信息给加载器 */ }

看代码时会发现 ATF 对证书的解析、哈希计算、公钥比较做了非常细致的校验：检查字段长度是否小于负载长度、公钥指数是否为 65537、签名长度是否与 RSA 模长匹配。这些都是防绕过的基础。我在审计时一般会加一段"负面测试"，故意篡改一个字节的 BL33 镜像，确认启动被拦截在可信边界之外。

4.3 固件安全审计的检查清单

做固件工程审计不能只看启动代码，还要评估运行时的安全状态。根据我的经验，一份最关键的安全审计清单包含以下内容：

• SMC 调用入口检查：runtime_svc.c中是否有非法服务处理？返回错误码是否泄漏敏感信息？
• 中断管理：安全中断和普通中断的配置是否合理？在 EL3 中断异常向量中，是否关闭了不必要的路由？
• 内存隔离：BL31 的内存是否对普通世界完全不可见？MMU 页表中是否误映射了 BL31 的代码段给普通世界？
• 调试接口：是否屏蔽了 JTAG/SWD 接口？相关 fuse 在烧录后是否应该熔断？
• 证书库：BL1 中用于验证 BL2 的根公钥是否被硬编码到 BootROM 的 eFuse 中？是否允许固件升级期间修改密钥？
• 随机数源：安全固件里的随机数是否来自硬件 TRNG，而不是使用不安全的伪随机算法？

这些检查项我会整理成表格，每项都关联对应的源码文件和风险等级。下面给出简化版供参考：

4.4 TBBR 工具链与镜像生成实操

要在自己的平台开启 TBBR，首先确保platform_def.h中定义了TRUSTED_BOARD_BOOT := 1。然后在plat.mk中增加：

CRT_KEYS := $(BUILD_PLAT)/keys $(eval $(call add_define,TRUSTED_BOARD_BOOT)) # 获取证书生成工具 $(eval $(call MAKE_TOOL,cert_create))

生成密钥与证书的命令大致为：

make PLAT=qemu \ TBBR_BOOT=1 \ GENERATE_COT=1 \ ROT_KEY=plat/qemu/keys/rot_key.pem \ BL33=./u-boot/u-boot.bin \ all fip

首次运行时 ATF 会生成多级密钥和证书。升级密钥链表上是rot_key.pem（根密钥），下面是bl31_key.pem、bl32_key.pem、bl33_key.pem、non_volatile_counter等。生产环境里，根密钥的私钥必须离线保存，并且建议放到 HSM 里，避免开发机被入侵导致信任根泄露。

生成完fip.bin后，可以用fiptool查看内容：

./tools/fiptool/fiptool info fip.bin

如果在fiptool info的输出中看到BL33有Certificate字段，说明 TBBR 的证书已经正确嵌入。启动时如果认证失败，BL2 会打印一条Authentication failed或Failed to load image的日志并停在安全状态等待复位。

5. 实际运行和常见问题排查记录

5.1 把 ATF 跑在 QEMU 上

我在真正接触物理板卡前，习惯先在 QEMU 上验证 ATF 的启动流程。QEMU 对 ARM 安全固件的模拟相当真实，而且还支持 TrustZone，这就给调试提供了极大的便利。

具体操作：

qemu-system-aarch64 \ -machine virt,secure=on \ -cpu cortex-a53 \ -smp 4 \ -m 1G \ -bios ./build/qemu/release/bl1.bin \ -nographic \ -device loader,file=./build/qemu/release/fip.bin,addr=0x04000000

-bios bl1.bin直接模拟片上 ROM 初始化；-device loader把 FIP 放到 BL2 期望的地址。启动后正常会看到 BL1、BL2、BL31、BL33 的串口输出，最后进入 U-Boot 命令行。

我在 QEMU 上验证时发现，很多问题都不是代码问题，而是版本和启动参数不匹配。如果 QEMU 版本较老，对armv8.5或RME特性支持不全，ATF 编译时如果开了相关 feature 就会启动失败。这类问题看错误日志很关键，但日志可能只停在PANIC at PC : 0x...。这时可以先把平台相关的ERROR日志级别调高，在串口输出来找线索。

5.2 常见问题速查表

我把实际移植和调试中遇到的高频问题整理成表格，方便大家对照：

5.3 排查实录：一次 BL31 跳转进入 Linux 失败

分享一下我印象最深的一次排查经历。当时我已经把 ATF 跑在了 QEMU 上，BL1、BL2、BL31 都正常，BL33（U-Boot）也能启动并引导内核，但内核启动到一半就重启了。反复试了几次，最后发现根本原因在 U-Boot 与 ATF 的 PSCI 配合上。

U-Boot 有两种引导内核的电源管理方式：一种是自己直接操作 CPU 寄存器，一种是调用 ATF 的 PSCI 接口。我移植的 U-Boot 版本里CONFIG_ARM_PSCI_FW没有开启，导致 U-Boot 尝试自己去核间启动，但它的启动序列和 ATF 的 BL31 驻留产生了冲突。开启这个配置后，U-Boot 不再自己操办电源管理，而是把CPU_ON、CPU_OFF、SYSTEM_RESET这些请求都委托给 SMC，由 BL31 统一处理，问题就消失了。

这个案例给我的启发是：ATF 移植不能只盯着 ATF 自己的代码，还要关注它与 U-Boot、Linux 之间的接口约定。特别是在做平台移植的时候，方案设计阶段就要把 PSCI 的调用方协议定清楚，否则后面调试电源管理问题时，你会同时面对内核、U-Boot、ATF、SoC 四个层面的信息噪音。

5.4 arm 交叉编译和工具链选择建议

关于交叉编译，我刚才提过 AC5 不适用于 AArch64 的 ATF。再强调一遍，arm compiler 5.06、5.06u7 这类 ARMCC 工具链是给 Cortex-M/A-R 32 位架构用的老编译器，编译 ATF 或者任何 AArch64 固件都是不适用的。我看到不少嵌入式新手在这个问题上走了弯路，有人甚至下载了 AC5 然后费劲折腾半天编译不过，最后发现方向错了。

如果你做的是 Cortex-A 系列 AArch64 固件，建议直接用：

# 安装 aarch64 交叉工具链 sudo apt install gcc-aarch64-linux-gnu

或者从 ARM 官网下载AArch64 GNU/Linux toolchain，版本选择最新的 LTS 即可。ATF 对 GCC 的版本要求不算苛刻，但太老的 4.x 版本在某些ATTR特性上可能会报错，建议至少用 GCC 8 以上。

另外，如果你需要把 BL33（比如 U-Boot）也交叉编译出来，U-Boot 用同一套aarch64-linux-gnu-gcc编译完全没问题。如果你构建一个小根文件系统放在 SD 卡或 virtio 盘上，可以先用busybox搭一个最小的rootfs，方便在板子起来后验证各种常用命令工具，这也是排查系统是否真正稳定运行的关键一步。之前我在一个项目里靠着往 rootfs 里临时塞了i2c-tools、mmc-utils这些 arm 工具，才发现板卡的 eMMC 在BL31跑完进入 OS 后存在时钟配置不对的问题。

5.5 关于系统挂起唤醒与 PSCI 深度睡眠的移植注意点

电源管理中的深度睡眠（affinity suspend）是我遇到过代码最绕的设计之一。它牵扯到多级低功耗状态（core、cluster、system），每一级都有对应的进入与退出回调。ATF 的 PSCI 框架在psci_suspend.c里实现了一套状态机的运行逻辑，但底层跟 SoC 强相关：有的 SoC 要求 CPU 进入 WFI 前刷新 cache，有的要求关闭 L2 电源前先保存 GIC 状态，这些细节都必须写进你在plat_pm.c里实现的pwr_domain_suspend和pwr_domain_suspend_finisher。

做这套操作时最危险的是乱序。假设你按手册里的步骤配置了寄存器，但时序错了，系统大概率会在唤醒时 hang 住。遇到这种问题，我的建议是先在底层加串口 trace：在进入低功耗前打印before suspend，在唤醒后打印after resume，通过日志确认它到底卡在哪一步。如果打印完before suspend后就没有后续，那说明唤醒路径没有执行的入口，很有可能是 reset vector 配置错误导致 CPU 醒来后跳到了一个空地址或安全配置异常的区域。

现在的 ARM 系统里，系统级低功耗（SYSTEM_SUSPEND）通常还会关联SCMI协议与运行在其它处理器核上的电源管理服务通信，这种方案下，消息传递的握手确认逻辑也是移植时容易遗漏的点。

6. 高级主题：RME、FF-A 与 ATF 的未来方向

6.1 机密计算与 Realm 管理扩展

近几年 ARM 在安全固件领域最大的变化是 RME（Realm Management Extension）的引入。RME 在原有的安全世界/普通世界基础上增加了 Realm 世界，用于支持机密计算场景，让 Linux 这样的普通世界根本不感知的机密虚拟机能在 Realm 世界里运行。ATF 的 master 分支里可以看到lib/gpt_rme相关的代码，它实现了 GPT（Granule Protection Table）的初始化和管理，这是 RME 的核心机制之一。

从工程审计视角看，RME 给 ATF 带来的复杂度提升是显著大于传统的 TBBR 的。因为 GPT 的颗粒检查、状态转换、Realm 世界与正常世界的共享内存管理，每一环都可能成为攻击面。目前很多 SoC 厂商还没有完整支持 RME，但从设计方向看，未来做 ARM 安全固件的人迟早要过这一关。

6.2 FF-A 与虚拟机间安全通信

FF-A（Firmware Framework for Arm A-profile）是 ARM 定义的另一个重要规范，它的目标是标准化安全世界/普通世界之间的通信，取代老旧的SMC调用约定。ATF 里已经有services/ff-a的相关实现，比如用 FF-A 规范的direct message传递函数调用。做高安全等级的产品时，想把 TEE 功能提供给多个普通世界分区使用，FF-A 会是一个更规范的方案。

不过实话实话，FF-A 在生态上的落地速度没有想象中快，不少厂商仍然基于旧的 OP-TEE + SMC 方式工作。如果你不急着上马高度虚拟化的机密计算场景，可以先在不改动架构的前提下保持对 FF-A 规范的关注。

6.3 移植到新平台前需要关注的 LTS 分支选择

TF-A 的发版节奏里，LTS 分支会比 master 保守很多。我个人的教训是，凡是直接用于量产的平台，一定切换到 LTS 分支，而不是追踪 master。LTS 分支会周期性合入修复 CVE 的安全补丁，API 变化较小，编译工具链和下游 U-Boot 的兼容性也更好。你在用git clone拉取 ATF 源码时，可以显式选择 LTS 分支：

git clone --branch lts-v2.8 https://github.com/ARM-software/arm-trusted-firmware.git

然后在make之前看一下docs/plat/下的移植指南，确认这个版本与你要用的 U-Boot、OP-TEE 版本是否匹配。ATF、OP-TEE、U-Boot、Linux 四者的版本匹配关系我建议你固定成一组，不要单独升其中一个，否则容易出兼容性问题。

6.4 从"跑通"到"能用"：平台移植的完整交付建议

很多朋友做 ATF 移植止步于"启动打印通过了"或"Linux 能起来了"，但在真实产品上线前，这部分工作还远远不够。我的经验是，一个合格的 ATF 移植交付至少要包含以下内容：

• BL31 常驻稳定性：跑压力测试，让系统反复执行reboot、suspend/resume、CPU hotplug，至少几百次不出问题。
• 安全启动验证报告：完整记录ROT_KEY生成、证书链签名、镜像烧录、验证启动的全流程，并附上验证成功的串口日志。
• 安全审计清单：如果这个产品会过 CCC、FIPS 或者等保，ATF 只是信任链的一部分，需要配合 Root of Trust、密钥管理、安全存储一起说明。
• 构建复现文档：记录你的make命令行、编译工具链版本、BL33 和 TEE 的 commit，保证 team member 可以复现你的完整构建。

我在实际项目里还养成了一个习惯：每次移植完成，都会把编译好的fip.bin和对应的bl31.elf保存到专门的 build artifact 仓库里，并记录提交哈希。否则两个月后回来找问题，连当时烧到板子上的镜像到底是哪个版本都说不清，那种感觉实在太痛苦了。

最后再分享一个小技巧：调 ATF 问题时不要只盯着 ATF 自身的日志，把BL33（U-Boot）的CONFIG_LOGLEVEL和 Linux 内核的earlycon都打开，会给你很多跨层排查的线索。我见过太多的"ATF 问题"其实是 U-Boot 的 DTS 配置、内核 PSCI 驱动版本或者 bootloader 传递参数的问题，全链路日志一开往往十分钟内就能定位。做底层固件就是这样，很多问题不是难度高，而是信息不够。先把日志铺开，再把耐心准备好，剩下的事情就顺理成章了。