2. 开发环境搭建：硬件平台要求与构建实战

说实话，搭建OP-TEE的开发环境，是很多人入门时第一个“劝退点”。我当年第一次搞的时候，光交叉编译工具链就折腾了两天。但你别怕，这东西说白了就是三板斧：选对硬件、拉对代码、配好工具链。今天我就带你把这几个坑都填平。

2.1 硬件平台怎么选？

OP-TEE支持三种硬件形态，我按推荐程度排个序：

平台类型 适用场景 上手难度 我的建议
QEMU（虚拟化） 学习、原型验证、CI测试 ★☆☆☆☆ 新手首选，零硬件成本
FPGA（如Xilinx Zynq） 硬件原型、定制化验证 ★★★☆☆ 适合有FPGA经验的团队
开发板（如HiKey、RPi3） 产品级开发、性能调优 ★★☆☆☆ 最终部署必须走这条路
我的经验：如果你只是学API调用和TA开发，QEMU完全够用。我带的团队里，80%的接口适配工作都是在QEMU上先跑通的。等逻辑验证没问题了，再烧到开发板上做硬件联调。

2.2 源码下载与分支选择

OP-TEE的源码管理有点特殊——它不是单个仓库，而是一个多仓库项目。官方推荐用repo工具来管理。我个人习惯用这个命令来初始化：

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

这里有个关键点：分支选择。OP-TEE的发布节奏大概半年一个版本。我建议你选master分支，或者最新的稳定标签。为什么？

  • master分支：功能最新，但偶尔会有小bug。适合想尝鲜的。
  • 稳定标签（如3.19.0）：经过充分测试，适合产品开发。
  • 旧版本（如3.12.0）：除非你用的硬件只支持旧版，否则别碰。
避坑指南：我曾经因为用了过时的3.10.0版本，结果发现它不支持我手里的HiKey960的某些外设。折腾了一周才发现是版本问题。所以，先查硬件兼容列表，再选分支。

2.3 交叉编译工具链配置

OP-TEE的编译需要两套工具链：一套给REE侧（Linux内核），一套给TEE侧（OP-TEE OS）。说白了，就是ARM的交叉编译器。

我推荐直接用官方预编译的aarch64-none-elf-和aarch64-linux-gnu-。安装方式很简单：

# 下载ARM官方工具链
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-elf.tar.xz
tar -xf gcc-arm-10.3-2021.07-x86_64-aarch64-none-elf.tar.xz
export PATH=$PWD/gcc-arm-10.3-2021.07-x86_64-aarch64-none-elf/bin:$PATH

# 同样方式安装aarch64-linux-gnu工具链
# ...

配置环境变量时，我建议你写个脚本，别每次都手动export。这是我的setup_env.sh：

#!/bin/bash
export TOOLCHAIN_DIR=/opt/toolchains
export PATH=$TOOLCHAIN_DIR/gcc-arm-10.3-2021.07-x86_64-aarch64-none-elf/bin:$PATH
export PATH=$TOOLCHAIN_DIR/gcc-arm-10.3-2021.07-x86_64-aarch64-linux-gnu/bin:$PATH
export CROSS_COMPILE=aarch64-linux-gnu-
export CC=$CROSS_COMPILE-gcc
export LD=$CROSS_COMPILE-ld
关键检查点：配置完后，运行aarch64-none-elf-gcc --version，如果能正常输出版本号，说明工具链没问题。如果报错，八成是PATH没配对，或者下载的包不完整。

2.4 构建OP-TEE OS与Client API

构建过程其实已经被官方脚本封装好了。你只需要在源码根目录下执行：

cd build
make -j$(nproc) toolchains
make -j$(nproc) all

第一次构建会比较慢，大概20-30分钟。为什么？因为要编译Linux内核、OP-TEE OS、ATF（ARM Trusted Firmware）以及一堆测试用例。我建议你泡杯咖啡等着。

构建完成后，你会得到这些关键产物：

  • op-tee.elf：OP-TEE OS的镜像文件
  • tee-pager_v2.bin：分页后的TEE二进制
  • libteec.so / libteec.a：Client API的共享库和静态库
  • tee-supplicant：REE侧的后台服务进程

这里我特别想强调Client API的构建。很多新手以为Client API是OP-TEE OS的一部分，其实它是运行在REE侧的用户态库。构建时，它会生成libteec，你的CA（Client Application）就是链接这个库来调用TEE功能的。

调试小技巧：构建时加CFG_TEE_CORE_LOG_LEVEL=3，可以打开OP-TEE OS的详细日志。我在调试TA和CA通信问题时，这个选项救了我无数次。

2.5 整体架构与构建流程

为了让你更直观地理解整个开发环境的构成，我画了张图：

OP-TEE 开发环境构建流程 硬件平台选择 源码下载与分支 交叉工具链配置 make -j$(nproc) all 构建 OP-TEE OS (op-tee.elf) Client API (libteec) tee-supplicant QEMU启动 / 开发板烧录 / 功能验证 💡 构建要点： • 首次构建需联网下载工具链，建议使用稳定的网络环境 • 如果构建失败，先检查 build/common.mk 中的平台配置

2.6 验证环境是否搭建成功

构建完成后，别急着写代码。先跑一下官方自带的测试用例，确认环境没问题。我的标准流程是：

  1. 启动QEMU：make run-only，看到OP-TEE的启动日志
  2. 运行xtest：在QEMU的终端里执行xtest，这是OP-TEE的测试套件
  3. 检查Client API：写一个简单的CA，调用TEEC_InitializeContext，看能否成功连接TEE
成功标志：如果xtest全部通过（或者大部分通过），说明你的开发环境搭建成功了。我第一次跑通时，看到满屏的"PASS"，心里那个踏实啊。

嗯，环境搭建这部分就这些。你可能会觉得步骤有点多，但相信我，一次配好后面能省很多事。我见过太多人因为工具链版本不对、分支选错，浪费了大量时间。按照我上面说的来，基本不会出大问题。

← 上一章 📖 返回目录 下一章 →