4. 开发环境搭建

OP-TEE 的 Trusted Application（TA）开发并不是在目标板上直接编译，而是在宿主机上通过交叉编译工具链生成 ARM 架构的可执行文件，再与 OP-TEE OS、Normal World 的 Linux 内核以及根文件系统一起打包运行。因此，开发环境搭建的核心是“宿主机工具链 + OP-TEE 源码 + 运行平台 + 构建系统”四件事的协同。理解它们之间的依赖关系，比记住某一条命令更重要。

一、核心原理：为什么必须交叉编译

OP-TEE 运行在 ARM 的 Secure World（安全世界），TA 最终以 ARM 指令集在 TrustZone 的安全环境中执行。宿主机通常是 x86_64 的 Linux，CPU 指令集与目标平台不同，无法直接生成可运行的二进制。交叉编译工具链提供 arm-linux-gnueabihf- 或 aarch64-linux-gnu- 前缀的编译器、链接器和 binutils，把 C 源码翻译成目标架构的机器码。

OP-TEE 的构建分为两个世界：Secure World 侧包括 OP-TEE OS 和 TA，使用 CROSS_COMPILE 指定工具链；Normal World 侧包括 Linux 内核、驱动和客户端应用，使用 CROSS_COMPILE 与内核架构参数。两者必须使用同一套或兼容的 ABI，否则 TA 与 CA 之间的共享内存、会话参数会解析错位。

二、交叉编译工具链的选择与验证

推荐使用 Linaro 或 ARM 官方发布的 GNU 工具链。对于 32 位 ARMv7 平台（如 QEMU vexpress、部分 i.MX6 板），使用 arm-linux-gnueabihf；对于 64 位 ARMv8 平台（如 QEMU virt、RK3399、树莓派 3/4），使用 aarch64-linux-gnu。工具链版本不宜过新，OP-TEE 对 GCC 版本有一定兼容范围，过新的编译器可能触发未预期的警告或链接错误。

# 以 aarch64 为例，下载并解压工具链
wget https://developer.arm.com/-/media/Files/downloads/gnu-a/10.3-2021.07/binrel/gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu.tar.xz
tar -xf gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu.tar.xz -C /opt/

# 加入环境变量
export PATH=/opt/gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu/bin:$PATH
export CROSS_COMPILE=aarch64-none-linux-gnu-

# 验证
${CROSS_COMPILE}gcc --version
${CROSS_COMPILE}ld --version

验证时不要只看 gcc --version，还要确认 ld、objcopy、readelf 都存在。OP-TEE 构建过程中会调用 objcopy 生成 TA 的二进制镜像，缺少该工具会在链接阶段报错。

三、OP-TEE 源码获取与目录结构

OP-TEE 官方推荐使用 repo 工具管理多仓库。整个工程由 optee_os、optee_client、optee_test、linux、build、trusted-firmware-a 等仓库组成，build 仓库中的 manifest 决定了各仓库的版本组合。

mkdir optee && cd optee
repo init -u https://github.com/OP-TEE/manifest.git -m qemu_v8.xml
repo sync -j4

同步完成后，目录中会出现 optee_os/、optee_client/、optee_test/、build/、linux/、qemu/ 等。TA 开发主要关注 optee_examples/ 或自建 TA 目录，CA 则放在 optee_client 或独立应用中。

四、QEMU 与真实硬件平台

QEMU 是学习和验证 TA 逻辑的首选平台，它不需要真实开发板，启动快、可调试、可反复烧写。QEMU 平台通常使用 qemu_v8.xml 或 qemu.xml manifest，运行 make run 即可启动包含 OP-TEE OS、Linux 和根文件系统的完整系统。真实硬件平台则涉及 U-Boot、TF-A、OP-TEE OS、Linux 的分级启动链，烧写和调试成本更高，但能验证真实的中断、时钟、外设和安全启动行为。

五、构建系统与编译流程

OP-TEE 的构建系统以 Makefile 为核心，build/ 仓库提供顶层入口。常见变量包括 PLATFORM、ARCH、CROSS_COMPILE、CROSS_COMPILE64、TA_DEV_KIT_DIR、O 等。TA 的编译依赖 optee_os 导出的开发套件，因此必须先编译 OP-TEE OS，再编译 TA。

# 编译 OP-TEE OS（以 QEMU v8 为例）
cd build
make -j4 \
  PLATFORM=vexpress-qemu_armv8a \
  CROSS_COMPILE=aarch64-none-linux-gnu- \
  CROSS_COMPILE64=aarch64-none-linux-gnu- \
  all

# 编译 TA 示例
make -j4 \
  PLATFORM=vexpress-qemu_armv8a \
  CROSS_COMPILE=aarch64-none-linux-gnu- \
  optee-examples

编译流程可以概括为：配置平台参数 → 编译 OP-TEE OS 生成 tee.bin 和开发套件 → 编译 TA 生成 .ta → 编译 CA 生成可执行文件 → 打包进根文件系统 → 启动平台加载。若使用 make run，构建系统会自动完成镜像组装和 QEMU 启动。

六、常见误区与复盘

• 工具链前缀写错：32 位平台误用 aarch64，或 64 位平台误用 arm-linux-gnueabihf，会在链接阶段报架构不匹配。务必先确认 PLATFORM 对应的架构。
• 先编 TA 后编 OS：TA 依赖 OP-TEE OS 导出的 ta_dev_kit，顺序颠倒会找不到头文件和链接脚本。
• 忽略 CROSS_COMPILE64：在 ARMv8 平台上，OP-TEE OS 可能同时涉及 32 位和 64 位组件，只设置 CROSS_COMPILE 可能导致部分目标编译失败。
• QEMU 能跑不等于硬件能跑：QEMU 对中断控制器、时钟和电源管理的模拟与真实 SoC 有差异，TA 中若直接操作硬件寄存器，必须回到真实平台验证。
• manifest 版本混用：不同 repo init 分支对应的 OP-TEE OS 与 client 版本可能不兼容，建议固定一个 manifest 并记录版本。