3. 开发环境搭建
OP-TEE 的调试与稳定性工程，第一步不是写代码，而是把“可复现、可观测、可回退”的开发环境搭起来。环境搭建的质量直接决定了后续能否稳定复现问题、能否快速定位崩溃、能否在 QEMU 与真实硬件之间做对照验证。本节围绕源码获取、编译工具链、QEMU 模拟器和真实硬件平台（STM32MP157、i.MX8）四条主线展开，并给出可落地的配置方法与常见误区。
一、核心原理：OP-TEE 的三层构建体系
OP-TEE 并不是一个单一工程，而是由多个仓库协同构建的系统。理解其分层结构，是环境搭建的前提：
- OP-TEE OS（optee_os）：运行在安全世界（Secure World）的 TEE 内核，负责 SMC 处理、会话管理、内存隔离与 TA 加载。
- OP-TEE Client（optee_client）：运行在非安全世界（Normal World）的用户态库与守护进程（tee-supplicant），提供 CA 调用接口。
- OP-TEE Test / Examples：xtest 测试套件与示例 TA，用于验证环境是否可用。
- 构建入口（build 仓库）：通过 repo 清单统一拉取上述仓库，并用 Makefile 驱动交叉编译。
因此，环境搭建的本质是：准备正确的交叉编译工具链，拉取匹配版本的源码清单，选择目标平台（QEMU 或真实硬件），并让 ATF、U-Boot、Linux 内核与 OP-TEE 形成一致的启动链。任何一环版本错配，都会表现为启动卡死、SMC 无响应或 TA 加载失败。
二、方法流程：从零到可运行 xtest
推荐使用官方 build 仓库的 repo 清单，避免手工拼装版本。典型流程如下：
# 1. 安装依赖（Ubuntu 20.04/22.04）
sudo apt install -y repo git build-essential \
python3-pip python3-pyelftools \
gcc-aarch64-linux-gnu gcc-arm-linux-gnueabihf \
libssl-dev bc flex bison libncurses-dev
# 2. 拉取源码清单
mkdir -p ~/optee && cd ~/optee
repo init -u https://github.com/OP-TEE/manifest.git \
-m qemu_v8.xml -b 3.22.0
repo sync -j8
# 3. 编译 QEMU 环境
cd build
make toolchains # 拉取并安装交叉工具链
make -j$(nproc) # 编译 ATF/U-Boot/OP-TEE/Linux
# 4. 启动并运行测试
make run # 启动 QEMU
# 在 QEMU 串口登录后执行：
xtest对于真实硬件，只需把清单换成 stm32mp1.xml 或 imx8.xml，并指定 PLATFORM=stm32mp1 或 PLATFORM=imx-mx8mqevk。编译产物包括 tee-header_v2.bin、tee-pager_v2.bin、tee-pageable_v2.bin，它们需要被 ATF 或 U-Boot 正确加载到安全内存区域。
三、案例/场景：QEMU 与真实硬件的差异
QEMU 是验证功能逻辑的首选，但它无法完全替代真实硬件。下表对比了两类环境的关键差异，便于选择调试策略：
| 对比项 | QEMU v8 | STM32MP157 | i.MX8（如 8MQ EVK） |
|---|---|---|---|
| 启动速度 | 秒级，可反复重启 | 依赖 SD 卡烧写，分钟级 | 依赖 SD/eMMC，分钟级 |
| 安全内存布局 | 固定虚拟地址，易观察 | 需核对 DDR 保留区 | 需核对 OCRAM/DDR 分区 |
| 调试手段 | GDB + 串口，支持单步 | JTAG/SWD + 串口 | JTAG + 串口 |
| 典型问题 | 与真实中断/时钟差异 | ATF 版本与 BL32 加载地址 | SCU/电源域与 TZ 配置 |
xtest 全量用例，再迁移到真实硬件。真实硬件上优先验证 xtest 1001（基础会话）与 xtest 4001（TA 加载），这两类用例能最快暴露启动链与内存配置问题。
四、误区与复盘
CROSS_COMPILE 与 PLATFORM 匹配。
BL32_BASE 与 OP-TEE 的 CFG_TZDRAM_START 不一致，OP-TEE 会被覆盖或无法跳转，表现为串口无 OP-TEE 日志。
tee-supplicant，TA 的动态加载与 RPMB 访问会失败，xtest 报 TEEC_ERROR_ITEM_NOT_FOUND。可用 ps | grep tee-supplicant 确认。
复盘时建议记录三件事：源码清单版本（repo manifest 的 commit）、工具链版本（aarch64-linux-gnu-gcc --version）、启动链各阶段的串口日志。这三项信息能在出现“换台机器就复现不了”的问题时，快速定位是环境差异还是代码缺陷。环境搭建不是一次性任务，而是后续所有调试与稳定性工作的基线，值得投入时间把它固化为一键脚本。