1. ATF初探
各位同学，欢迎来到《ATF移植实战》的第一章。
说实话，我刚开始接触ARM Trusted Firmware（简称ATF）的时候，也是一头雾水。那时候我刚从MCU开发转到嵌入式Linux，面对着一堆陌生的术语——EL3、Secure Monitor、TrustZone……嗯，确实有点懵。
但别担心，这一章我会用最直白的方式，带你搞清楚ATF到底是什么、为什么需要它、以及它在整个ARM生态里扮演什么角色。
1.1 什么是ATF？
ATF，全称ARM Trusted Firmware，是ARM官方提供的一套开源固件参考实现。它运行在ARM处理器最高特权级——EL3（Exception Level 3）。
你想想看，一个系统里总得有个“老大”吧？EL3就是这个老大。它负责管理安全世界和普通世界之间的切换，处理电源管理、系统初始化这些底层活。
我个人习惯把ATF理解为“ARM系统的看门人”。它不直接跑你的应用，但它决定了你的系统能不能安全、稳定地启动和运行。
核心要点：ATF = ARM Trusted Firmware，运行在EL3，负责安全监控和底层固件服务。
1.2 为什么需要ATF？
好，问题来了——为什么非得有ATF？我直接用U-Boot或者Linux内核不行吗？
答案很简单：安全。
ARM从Cortex-A系列开始引入了TrustZone技术。这个技术把系统分成了两个世界：
- 安全世界（Secure World）：运行可信代码，比如指纹识别、支付、DRM版权保护
- 普通世界（Normal World）：运行Linux、Android这些通用操作系统
这两个世界之间不能随便串门。ATF就是那个“门卫”，负责检查进出权限。
我在项目中遇到过一件事：有个客户的产品在量产阶段突然发现安全启动校验失败。查了两天，最后发现是ATF的BL2阶段签名验证逻辑有个小bug。嗯，从那以后我再也不敢轻视ATF的启动流程了。
避坑指南：我曾经以为ATF只是个“启动加载器”，后来才发现它贯穿了整个系统运行周期。电源管理、PSCI、安全中断……这些都得靠ATF。
1.3 ATF在ARM生态系统中的位置
要理解ATF的位置，你得先看看ARM系统的启动流程。我画了一张图，帮你理清思路：
从这张图你能看到，ATF覆盖了从BL1到BL31的整个安全启动链。它不只是一个“启动加载器”，更是一个运行时安全监控框架。
1.4 ATF的核心组件
ATF主要包含以下几个部分：
| 组件 | 功能 | 运行阶段 |
|---|---|---|
| BL1 | 第一级启动加载器，初始化最小系统 | 上电后立即执行 |
| BL2 | 第二级启动加载器，加载并验证后续镜像 | BL1之后 |
| BL31 | 运行时固件，提供PSCI、安全中断等服务 | 系统启动后常驻 |
| BL32 | 可选的TEE操作系统（如OP-TEE） | 与BL31并行 |
| BL33 | 非安全世界的引导加载程序（如U-Boot） | 最后阶段 |
注意：BL32不是必须的。如果你的产品不需要TEE（比如纯工业控制），可以只跑BL1+BL2+BL31+BL33。我做过一个项目就是这样，省掉了TEE，启动时间缩短了200ms。
1.5 ATF与ARM生态的关系
ARM生态系统里，ATF处于一个承上启下的位置：
- 向下：它直接操作ARM架构的底层硬件，包括GIC（中断控制器）、MMU、系统寄存器
- 向上：它为U-Boot、Linux内核、Android提供标准化的接口（比如PSCI）
- 横向：它与TEE（如OP-TEE）、Hypervisor（如Xen）协同工作
说白了，没有ATF，你的ARM Linux系统也能跑——但跑在“裸奔”状态，没有任何安全隔离。这在消费电子、车联网、工业控制这些领域，是绝对不允许的。
我记得有一次帮客户做安全审计，发现他们的产品直接把Linux跑在EL3上。嗯，这相当于把整个系统的“钥匙”挂在了大门口。后来我们帮他们移植了ATF，才通过了安全认证。
1.6 本章小结
这一章我们聊了：
- ATF是ARM官方的安全固件参考实现，运行在EL3
- 它解决了安全世界与普通世界之间的隔离问题
- 它在ARM启动流程中占据核心位置，从BL1到BL31
- 它是整个ARM生态的安全基石
下一章，我们会动手搭建ATF的编译环境，真正开始写代码。准备好了吗？
一句话记住ATF：它是ARM系统的“安全看门人”，没有它，你的系统就像没锁门的房子。