1. 课程导入
在嵌入式安全领域，OP-TEE（Open Portable Trusted Execution Environment）已经成为 ARM 平台上最主流的开源可信执行环境实现之一。它运行在 ARM TrustZone 的安全世界（Secure World）中，与运行在普通世界（Normal World）的 Linux 内核、U-Boot 以及用户态应用协同工作，为密钥管理、安全存储、可信支付、DRM、生物识别等场景提供隔离的安全执行能力。然而，很多工程师在第一次接触 OP-TEE 时，往往会被"启动链"和"平台移植"这两个词卡住：代码从哪里开始执行？BL1、BL2、BL31、BL32、BL33 之间是什么关系？为什么换一块开发板就要改这么多东西？本课程正是围绕这些问题展开，帮助学习者建立从芯片上电到安全世界可用的完整认知链路。
一、学习目标：从"能跑"到"能移植"
本课程的学习目标分为三个层次。第一层是理解启动链：能够清晰描述 ARMv8-A 平台上从复位向量到 OP-TEE 初始化完成的完整流程，理解 ATF（ARM Trusted Firmware）在其中的枢纽作用，以及 BL32 与 OP-TEE 的对应关系。第二层是掌握移植方法：能够针对一块新的 SoC 或开发板，独立完成 OP-TEE OS、ATF、U-Boot、Linux 内核与根文件系统的配置、编译与联调。第三层是具备排障能力：当启动卡死、安全世界无法进入、TA 加载失败时，能够通过日志、寄存器、内存布局等线索定位问题。这三层目标对应课程的三条主线：启动链原理、平台移植实操、问题诊断与复盘。
二、核心概念：启动链中的关键角色
ARMv8-A 的可信启动链通常被划分为多个 Boot Loader 阶段，每个阶段承担不同的职责。BL1 位于芯片内部 ROM，负责最基础的信任根建立；BL2 通常运行在 SRAM 中，负责加载后续镜像；BL31 是 ATF 的运行时固件，负责安全监控调用（SMC）处理、电源管理、异常向量等；BL32 就是 OP-TEE OS 本体，运行在安全世界 EL1；BL33 则是普通世界的引导程序，通常是 U-Boot。理解这些阶段的执行顺序、运行异常等级（EL）以及内存布局，是掌握 OP-TEE 启动链的基础。
另一个核心概念是平台移植层。OP-TEE OS 通过 core/arch/arm/plat-xxx/ 目录下的平台代码与具体 SoC 对接，包括串口、时钟、中断控制器、内存映射、TZASC/TZPC 配置等。ATF 同样有 plat/vendor/soc/ 目录。移植的本质，就是把这些平台相关代码从参考板适配到目标板。
三、整体框架：三条主线与四个层次
本课程的整体框架可以概括为"三条主线、四个层次"。三条主线分别是：启动链原理线、平台移植实操线、问题诊断复盘线。四个层次则是：芯片层（复位、时钟、内存）、固件层（BL1/BL2/BL31/BL32/BL33）、系统层（Linux、U-Boot、设备树）、应用层（TA、CA、安全服务）。每一章都会在这张框架图上定位自己的位置，避免学习者陷入"只见树木不见森林"的困境。
| 层次 | 关键对象 | 典型问题 | 对应章节方向 |
|---|---|---|---|
| 芯片层 | 复位向量、时钟、SRAM、TZASC | 上电后第一条指令在哪里？ | 启动链基础 |
| 固件层 | BL1/BL2/BL31/BL32/BL33 | 各阶段如何交接？ | ATF 与 OP-TEE 集成 |
| 系统层 | U-Boot、Linux、设备树 | 普通世界如何感知安全世界？ | 驱动与共享内存 |
| 应用层 | TA、CA、安全存储 | TA 如何加载与通信？ | TA 开发与调试 |
四、方法流程：平台移植的标准动作
平台移植不是"改到能跑就行"，而应遵循一套可复用的流程。第一步是确定参考平台，选择与目标 SoC 最接近的已有平台作为基线，例如 QEMU、STM32MP1、i.MX8M、RK3399 等。第二步是梳理内存布局，明确安全内存、共享内存、OP-TEE OS 加载地址、TA 加载地址。第三步是适配串口与时钟，这是最早能看到日志的关键。第四步是配置 ATF 与 OP-TEE 的编译参数，包括 PLATFORM、CFG_TEE_CORE_LOG_LEVEL、CFG_TZDRAM_START 等。第五步是联调与验证，通过 xtest 和自定义 TA 验证安全世界功能。
# 典型 OP-TEE 编译命令示例
make PLATFORM=stm32mp1 \
CROSS_COMPILE=aarch64-linux-gnu- \
CFG_TEE_CORE_LOG_LEVEL=3 \
CFG_TZDRAM_START=0xde000000 \
CFG_TZDRAM_SIZE=0x02000000
# ATF 编译示例
make PLAT=stm32mp1 \
CROSS_COMPILE=aarch64-linux-gnu- \
BL32=/path/to/optee_os/out/arm/core/tee-header_v2.bin \
BL33=/path/to/u-boot/u-boot-nodtb.bin五、案例与场景：从 QEMU 到真实开发板
课程会以 QEMU 作为第一个实验环境，因为 QEMU 的 virt 平台已经内置了 OP-TEE 支持，可以快速验证启动链是否理解正确。随后会切换到一块真实开发板（如 STM32MP157 或 i.MX8M Mini），完整走一遍移植流程。真实板卡上会遇到 QEMU 不会出现的问题：DDR 初始化时序、TZASC 区域配置、安全启动熔丝、U-Boot 的 optee 命令、Linux 侧 /dev/tee0 设备节点等。这些差异正是平台移植工程的核心价值所在。
六、常见误区与复盘
- 误区一：把 OP-TEE 当成一个独立程序。实际上 OP-TEE OS 是 BL32，必须由 ATF 的 BL31 加载并跳转，脱离 ATF 单独运行通常无法进入安全世界。
- 误区二：只改 OP-TEE 不改 ATF。BL31 负责安全世界的入口地址、异常向量和 SMC 分发，ATF 平台代码不改，OP-TEE 往往连日志都出不来。
- 误区三：忽略内存布局冲突。安全 DRAM、共享内存、U-Boot 重定位地址、Linux 内存节点之间必须严格对齐，否则会出现随机崩溃。
- 误区四：日志级别开太低。移植阶段建议全开日志，稳定后再逐级关闭，否则排障成本极高。