4. OP-TEE启动链全景

在ARMv8-A可信启动体系中，OP-TEE并不是一个“独立启动”的固件，而是嵌入在ARM Trusted Firmware（TF-A）启动链中的安全世界执行环境。理解OP-TEE的启动过程，必须把它放回完整的启动链中：从芯片上电后的BootROM开始，依次经过BL1、BL2、BL31、BL32，最终到达BL33（通常为U-Boot或UEFI），再由BL33引导Linux内核。OP-TEE对应的是BL32阶段，即Secure Payload（安全载荷）。

一、启动阶段划分与职责

ARMv8-A的启动链通常被划分为多个Boot Loader阶段（BL），每个阶段运行在不同的异常等级（Exception Level, EL）上，承担不同的安全职责。下表给出各阶段的典型运行级别与核心职责：

二、启动流程与镜像加载关系

整个启动链可以理解为一条“信任传递链”：BootROM信任BL1，BL1信任BL2，BL2信任BL31/BL32/BL33。每一级都会对下一级镜像进行签名校验，只有校验通过才会跳转执行。OP-TEE的BL32镜像通常被打包进FIP（Firmware Image Package）中，由BL2负责解析和加载。

在BL2阶段，平台代码会根据FIP中的镜像描述，将BL32加载到安全内存（Secure RAM）中的指定地址。BL31启动后，会通过bl31_main中的bl32_init回调跳转到BL32入口。OP-TEE OS启动完成后，会通过SMC返回BL31，BL31再继续跳转到BL33。

BootROM → BL1 → BL2 → BL31 → BL32(OP-TEE) → BL31 → BL33 → Linux
                │       │
                │       └── 加载并校验 BL32/BL33
                └── 解析 FIP，加载 BL31/BL32/BL33

三、OP-TEE在BL32阶段的关键初始化

OP-TEE OS在BL32阶段完成的核心初始化包括：

• 异常向量与MMU初始化：建立S-EL1的异常向量表，配置安全世界页表，隔离安全内存与正常内存。
• 平台早期初始化：通过plat_early_init完成GIC、UART、时钟等平台相关配置。
• TEE核心初始化：初始化线程调度、会话管理、共享内存、TA加载器等核心子系统。
• 安全监控调用接口：注册SMC处理函数，建立与BL31的通信通道。
• 返回BL31：初始化完成后，通过thread_return_to_el3返回EL3，由BL31继续启动BL33。

四、典型场景与常见误区

在实际平台移植中，最常见的误区是认为“OP-TEE启动就是BL32启动”。实际上，BL32只是OP-TEE OS的入口阶段，它依赖BL2正确加载镜像、BL31正确配置EL3运行时环境。如果BL31没有正确设置bl32_init回调，或者FIP中没有包含BL32镜像，OP-TEE根本无法启动。

另一个常见问题是安全内存划分冲突。BL32需要一块独立的Secure RAM区域，如果与BL31或BL33的内存布局重叠，会导致启动异常或运行时崩溃。移植时应仔细检查平台内存映射表，确保BL32区域与正常世界内存严格隔离。

# 典型FIP镜像列表
fip.bin:
  - bl31.bin
  - bl32.bin   # OP-TEE OS
  - bl33.bin   # U-Boot
  - tb-fw.bin  # Trusted Board Boot

五、启动链全景图

下图展示了从BootROM到BL33的完整启动链，以及OP-TEE（BL32）在其中的位置与交互关系。图中同时标注了各阶段的运行级别和关键动作，便于建立整体认知。

通过这张全景图可以清晰看到：OP-TEE（BL32）位于BL31之后、BL33之前，运行在S-EL1安全世界。它由BL2负责加载、由BL31负责跳转，并在初始化完成后返回BL31，最终由BL31启动BL33进入正常世界。整个启动链环环相扣，任何一级的配置错误都会导致OP-TEE无法正常启动。