📚 课程目录第3章 OP-TEE开发环境搭建

3. OP-TEE开发环境搭建

OP-TEE 的开发环境搭建是后续所有驱动开发、安全外设集成与调试工作的基础。一个可复现的环境应当同时具备四个要素：可信的源码来源、匹配的交叉编译工具链、可运行的平台载体（QEMU 或真实硬件），以及可观测、可断点、可追踪的运行与调试通道。本节围绕这四条主线展开，帮助读者建立从零到“能跑起来、能停下来、能看进去”的完整环境。

一、核心原理：OP-TEE 的双世界构建模型

OP-TEE 采用 ARM TrustZone 的双世界架构：Normal World 运行 Linux 与用户态应用，Secure World 运行 OP-TEE OS 与可信应用（TA）。因此一次完整构建实际上包含三部分产物：

OP-TEE OS：运行在 Secure EL1 的安全内核，提供 TA 加载、系统调用与安全外设驱动框架。
OP-TEE Client（optee_client）：运行在 Linux 用户态的库与守护进程（tee-supplicant），负责与安全世界通信。
OP-TEE Test / TA：验证环境是否可用的测试套件（xtest）与示例 TA。

构建系统通过 build/ 目录下的 Makefile 统一编排，使用 make 目标驱动，并依赖 CROSS_COMPILE、PLATFORM、ARCH 等变量决定目标平台与工具链。理解这一点，就能明白为什么“换平台”往往只需要改几个变量，而不是重写构建脚本。

  关键认知：OP-TEE 的构建不是单一工程，而是“安全内核 + 用户态客户端 + 测试 TA”的组合构建，三者必须使用同一套工具链与同一平台配置，否则会出现 ABI 不匹配或 TA 加载失败。

二、源码获取：分层拉取与版本对齐

推荐使用官方 manifest 方式获取源码，以保证各仓库版本一致。常见做法是使用 repo 工具同步：

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

若网络受限，也可以分别克隆核心仓库：

git clone https://github.com/OP-TEE/optee_os.git
git clone https://github.com/OP-TEE/optee_client.git
git clone https://github.com/OP-TEE/optee_test.git
git clone https://github.com/OP-TEE/build.git

需要特别注意版本对齐：optee_os、optee_client、optee_test 与 Linux 内核的 OP-TEE 驱动（drivers/tee）之间存在接口约定。混用不同分支可能导致 TEE_IOCTL 调用失败或 TA 签名校验不通过。建议在项目初期固定一个 release tag，并在团队内共享同一份 manifest。

三、编译工具链：交叉编译器的选择与验证

OP-TEE OS 运行在 AArch64 或 AArch32 安全态，必须使用交叉编译器。QEMU v8 平台通常使用 aarch64-linux-gnu- 工具链；若构建 32 位平台则使用 arm-linux-gnueabihf-。工具链来源可以是 Linaro、Arm GNU Toolchain 或发行版包管理器。

sudo apt install gcc-aarch64-linux-gnu \
                 gcc-arm-linux-gnueabihf \
                 make bc flex bison libssl-dev

aarch64-linux-gnu-gcc --version

验证工具链后，设置环境变量并编译：

export CROSS_COMPILE=aarch64-linux-gnu-
export PLATFORM=vexpress-qemu_armv8a
export ARCH=arm64

cd optee_os
make -j$(nproc)

编译成功后会在 out/arm-plat-vexpress/core/ 下生成 tee.bin、tee.elf 等产物。若出现 undefined reference 或 cannot find -lstdc++，通常是工具链不完整或 CROSS_COMPILE 未生效。

四、QEMU 与真实硬件平台：两条验证路径

QEMU 是学习与快速验证的首选，它模拟 TrustZone 与安全外设，启动快、可重复、便于调试。真实硬件则用于验证实际外设、时钟、电源与中断行为。两者在环境搭建上的差异如下表所示：

对比项	QEMU v8	真实硬件（如 RK3399、i.MX8）
平台配置	vexpress-qemu_armv8a	rockchip、imx 等
启动方式	QEMU 直接加载 tee.bin 与内核	U-Boot / TF-A 引导，需烧录
调试通道	GDB + QEMU 内置 stub	JTAG / 串口 / 内核日志
外设验证	模拟设备，行为受限	真实寄存器与中断
适用阶段	入门、CI、功能验证	驱动开发、性能与稳定性

QEMU 启动示例：

cd build
make run-only
# 或手动启动
qemu-system-aarch64 -machine virt,secure=on \
  -cpu cortex-a57 -smp 2 -m 1024 \
  -bios bl1.bin -kernel tee.bin \
  -append "console=ttyAMA0" -nographic

真实硬件上，通常需要先构建 TF-A（BL1/BL2/BL31）、U-Boot 与 Linux 内核，再将 tee.bin 打包进启动镜像。此时要确认 OPTEE 在设备树中的 reserved-memory 区域与 optee 节点配置正确，否则 Linux 侧无法探测到 TEE 设备。

五、运行与调试环境配置

运行环境的核心是 tee-supplicant 与内核 TEE 驱动。Linux 启动后应能看到：

[    1.234567] optee: probing for conduit method from DT.
[    1.235000] optee: initialized driver
/dev/tee0
/dev/teepriv0

随后启动用户态守护进程并运行测试：

tee-supplicant &
xtest

若 xtest 全部通过，说明安全世界与正常世界的通信链路已打通。调试方面，QEMU 下可使用 GDB 连接安全态：

qemu-system-aarch64 ... -s -S
aarch64-linux-gnu-gdb out/arm-plat-vexpress/core/tee.elf
(gdb) target remote :1234
(gdb) b tee_entry_std
(gdb) c

建议在 QEMU 阶段就配置好 GDB 断点与日志级别（CFG_TEE_CORE_LOG_LEVEL），这样迁移到真实硬件时，调试思路与符号信息可以复用，减少“换平台即失明”的问题。

六、常见误区与复盘

工具链混用：用 32 位编译器构建 64 位平台，导致 tee.bin 无法加载。应统一 CROSS_COMPILE 与 ARCH。
版本不对齐：optee_os 与 optee_client 分支不一致，出现 TA 加载失败。应固定 manifest 或 release tag。
忽略设备树：真实硬件上未配置 reserved-memory，导致 TEE 驱动 probe 失败。
调试通道未开：未启用 -s -S 或未保留符号，导致无法定位安全态异常。

复盘建议：把环境搭建过程脚本化，记录每一步的版本号、命令与预期输出。这样当环境损坏或需要在新机器上复现时，可以快速定位是工具链、源码还是平台配置的问题。