一篇看懂 OP-TEE瑞萨 RZ/T2H 如何通过 PTA 安全服务实现 OTP 读写访问

我先联网检索 OP-TEE、瑞萨 RZ/T2H 与 OTP 访问的技术资料。

我精读这篇主稿，提取 OP-TEE 架构、RZ/T2H OTP 访问流程和组件细节。

我再核对瑞萨 RZ/T2H 硬件规格和 OP-TEE 官方架构定义，作为交叉信源。

直接说结论：瑞萨 RZ/T2H 基于 Arm TrustZone 硬件隔离和开源 OP-TEE 框架，把 OTP（One-Time Programmable Memory，一次性可编程存储器）的访问封装在安全世界的伪可信应用（PTA）里。Linux 普通世界的客户端应用（CA）不直接碰 OTP 寄存器，而是通过 TEE Client API 发起请求，经 Linux 内核 TEE 驱动、Arm Trusted Firmware（ATF）进入 OP-TEE OS，再由框架分发到 OTP PTA，最后调用底层 OTP 驱动完成读或写。这样设备密钥、产品序列号、安全配置参数等敏感信息可以放在 OTP 中，底层控制逻辑不会暴露给普通 Linux 环境。下面按 OP-TEE 基础概念、平台背景、调用链路、PTA 实现、编译验证这条线把整套方案讲清楚。

一、先认识 OP-TEE 的基本架构

OP-TEE（Open Portable Trusted Execution Environment）是运行在 Arm TrustZone 之上的开源 TEE 实现，遵循 GlobalPlatform 的 TEE Internal Core API 和 TEE Client API 规范。TrustZone 把系统分成两个相互隔离的执行世界：

世界	角色	运行内容
Normal World（普通世界，REE）	富执行环境	Linux 内核、用户空间应用、TEE 客户端库和守护进程
Secure World（安全世界）	可信执行环境	OP-TEE OS 内核、TEE Core、可信应用（TA）、加密服务和安全硬件驱动

CPU 通过 NS（Non-Secure bit）和 SMC（Secure Monitor Call）指令在两个世界之间切换。OP-TEE 的主要组件包括：

optee_os：安全世界操作系统本体，包含可信 OS 内核、TEE Core、TA 加载与调度、加密服务和 Secure Monitor 调用接口。
optee_client：普通世界侧客户端库和守护进程，包括 libteec、tee-supplicant 和 TEE Client API 实现。
Linux 内核 TEE 框架与驱动：负责把普通世界请求路由到安全世界。
TA（Trusted Application）：运行在安全世界、受内核保护的可信应用。
CA（Client Application）：普通世界里调用 TA 服务的客户端应用。

二、RZ/T2H 平台背景

RZ/T2H 是瑞萨面向工业机器人、运动控制器、PLC 等场景的高端 MPU，硬件上具备运行 OP-TEE 的基础：

项目	公开规格
应用处理器	四核 Arm Cortex-A55，1.2GHz
实时控制核	双核 Arm Cortex-R52，1.0GHz
安全扩展	支持 Arm TrustZone；具备 Secure Boot、TRNG、AES、Hash、RSA、JTAG 认证等安全特性
典型应用	工业机器人、运动控制器、PLC、多轴电机控制、工业以太网

RZ/T2H 的 Cortex-A55 跑 Linux，OP-TEE OS 运行在 Secure World，与 Linux 形成物理隔离；安全世界中的服务可以直接访问只有安全态才能触碰的寄存器和安全外设。

三、CA 到 OTP 驱动的完整调用链路

一次 OTP 读写请求在两个世界之间的流转顺序如下：

步骤	执行位置	动作
1	普通世界 CA	调用 TEE Client API 函数（TEEC_InitializeContext、TEEC_OpenSession、TEEC_InvokeCommand、TEEC_CloseSession 等），通过 OTP_UUID 找到安全世界对应实例
2	普通世界客户端库	TEE Client API 库把请求路由到 OP-TEE Linux 内核驱动
3	普通世界内核	OP-TEE Linux Driver 将请求路由到 Arm Trusted Firmware（ATF）
4	安全世界 OP-TEE OS	框架判断应由哪个 TA/PTA 处理该请求
5	安全世界 PTA	控制权交给 OTP PTA，由其调用底层 OTP 驱动执行读或写
6	返回路径	处理完成后控制权逐层返回 CA，CA 收到返回值和处理后的数据

四、为什么 OTP 服务选用 PTA

OP-TEE 里可信应用分两类，OTP 底层服务采用的是 PTA：

类型	特点	适用场景
PTA（伪可信应用）	内置在 TEE 操作系统中的高权限安全服务；不是独立 .ta 文件，而是注册在 OP-TEE Core 中的内建服务	封装只有 Secure World 才能访问的寄存器、安全外设或底层平台能力
UTA（用户模式可信应用）	标准用户模式 TA，在 Secure World 用户态运行，可独立开发、签名和部署，隔离性更好	客户业务逻辑类应用

OTP 读写需要直接访问 OP-TEE Core 内部接口和安全硬件驱动，并且要作为其他 TA 共用的底层安全服务，因此采用 PTA。在软件分层上，OTP 组件与 FLASH、SPI、SCE 驱动处于同一层级。

五、OTP 读写的具体实现

1. CA 侧实现

在瑞萨提供的 optee-ta-sample 配方中增加 otp 目录，包含 otp.c、pta_otp.h 和对应 Makefile。otp.c 作为 OTP CA 示例，负责注入参数并调用 TEE Client API：

用 TEEC_InitializeContext 初始化上下文；
用 TEEC_OpenSession 通过 UUID 打开 OTP 实例；
用 TEEC_InvokeCommand 下发读或写命令；
最后用 TEEC_CloseSession 关闭会话。

对外命令行形式为：

操作	示例命令	含义
读	rz_optee_ta_otp read 0x0204 1	读取地址 0x0204 的 OTP 数据，1 个 word
写	rz_optee_ta_otp write 0x0204 0x01	向地址 0x0204 写入 1 个 word，值为 0x01

2. PTA 侧实现

已有 r_otp_read 函数基础上，参照用户手册增加 r_otp_write(uint32_t addr, uint32_t val)；
在 otp_regs.h 中补充对应寄存器宏；
pta_otp.c 注册 PTA 响应函数，按命令号 OTP_CMD_READ / OTP_CMD_WRITE 分发到 otp_read / otp_write；
在 sub.mk 中加入对应编译条目。

3. OTP 写入流程（按 RZ/T2H 用户手册）

步骤	操作内容
A	假定 OTP 当前处于掉电状态；检查 OTPPWR 寄存器 PWR 位为 0、OTPSTR 寄存器 CMD_RDY 位为 0，确认掉电处理完成
B	将 OTPPWR 的 PWR 位和 ACCL 位置 1，确认 OTPSTR 的 CMD_RDY 位变为 1
C	把写入地址设置到 OTPADRWR 寄存器
D	把待写入数据设置到 OTPDATAWR 寄存器
E	将 OTPSTAWR 寄存器的 STAWR 位置 1
F	OTP 控制器开始写入；CMD_RDY 从 1 变为 0。若地址属于禁止写入区域，STAWR 不会置 1、CMD_RDY 保持 1，且 OTPSTR 的 ERR_WP 位置 1
G	控制器将 OTPDATAWR 的值写入 OTP；流程完成前必须保持 OTPADRWR 和 OTPDATAWR 不变
H	轮询 STAWR 位直到变为 0，确认写入命令接收完成
I	轮询 CMD_RDY 位直到变为 1，确认写入操作完成
J	CMD_RDY 为 1 后，确认 OTPSTR 的 ERR_WP 和 ERR_WR 位均未置 1；任一置位表示写入错误
K	继续写入则从步骤 C 重复；访问结束后按是否执行过读取，决定是否先做虚拟读取（dummy read），再将 PWR、ACCL 清 0 并等待 CMD_RDY 变 0，使 OTP 回到掉电状态

4. 使用 OTP 的注意事项

某些区域可施加 WORDLOCK，加锁区域不能再写入；已写入的位再次写入 0 或 1 都保持为 1。
OTP 是一次性编程区域，写入过程中禁止复位，复位后无法保证正常工作。
部分区域用于存放密钥，开发测试时应使用 user area（示例中为 0x204 到 0x3FF 区域，每个地址 4 字节），不要随意改写密钥区。

六、Yocto 编译与验证流程

1. 修改与打补丁

optee-os 源码由 git 管理，修改和新增文件后生成 patch：

git add 后用 git diff --cached > otp.patch 生成补丁；
把 otp.patch 放到 meta-rz-features/meta-rz-security/recipes-bsp/optee/files/ 下；
增加 optee-os_git.bbappend 文件加载补丁。

2. 编译 OP-TEE OS 与固件

MACHINE=rzt2h-dev bitbake -c cleansstate optee-os

MACHINE=rzt2h-dev bitbake optee-os

MACHINE=rzt2h-dev bitbake -c cleanall firmware-signing

MACHINE=rzt2h-dev bitbake -c cleansstate firmware-pack

MACHINE=rzt2h-dev bitbake firmware-pack

OP-TEE OS 在 secure boot 下与 BL31、BL33 一起绑定到 FIP；FIP 生成后会签名，公钥放入 BL2，因此需要重新编译 firmware-signing。

3. 编译 OTP 例程

在 /build/tmp/work/rzt2h_dev-poky-linux/ 路径下可看到 optee-client、optee-example、optee-os、optee-ta-sample：

optee-client：普通世界客户端库与守护进程；
optee-example：官方 hello world、secure storage、random 等示例；
optee-os：安全世界操作系统本体；
optee-ta-sample：瑞萨提供、可直接访问 OP-TEE Core 内部接口和安全硬件驱动的 PTA 例程（含 SCE、SPI、FLASH 等）。

编译命令：

MACHINE=rzt2h-dev bitbake -c cleansstate optee-ta-sample

MACHINE=rzt2h-dev bitbake optee-ta-sample

最终生成 rz_optee_ta_otp 应用程序。

4. 上机验证

把重新生成的 bl2-tbb_bp_xspi0-rzt2h-dev.srec 和 fip-tbb-rzt2h-dev.srec 通过 SCI 烧写到 xspi0，再把 otp/host 下的 rz_optee_ta_otp 拷贝到 RZ/T2H 的 /home/root 运行。

验证项	操作与结果
读取默认数据	rz_optee_ta_otp read 0x00e5 1；0x0E5 是 unique ID 的前 32 位，示例读出 0x3802120B，日志出现 otp_read has been called
写入 user area	rz_optee_ta_otp write 0x0204 0x1；日志出现 otp_write has been called、r_otp_write called，提示 Write successful at address 0x204 with value 0x00000001
回读校验	rz_optee_ta_otp read 0x0204 1；回读 0x00000001，与写入值一致，表示写入成功

七、结论

在 RZ/T2H 上，OP-TEE 的作用是把 OTP 这类只能由安全态访问的硬件资源，包装成普通 Linux 可经授权调用的安全服务：CA 在普通世界发请求，请求穿过内核驱动和 ATF 进入安全世界，OP-TEE OS 把命令分发给 OTP PTA，PTA 再调用底层驱动操作 OTP 寄存器。选用 PTA 是因为它需要访问 Core 内部接口和安全硬件、并作为底层公共服务复用。工程上要走 Yocto 补丁、optee-os 与固件打包签名、optee-ta-sample 编译、烧写和回读验证这条完整链路；实际开发中必须区分密钥区和 user area，遵守 OTP 一次性编程和写保护规则。源码细节需以瑞萨官方 BSP、用户手册和对应版本代码为准。

【相关 FAQ】

问题 1：RZ/T2H 上的 OP-TEE 是怎么实现 OTP 访问的，为什么不让 Linux 直接读写 OTP？

回答 1：RZ/T2H 依托 TrustZone 把 OP-TEE OS 放在安全世界，OTP 读写由安全世界的 OTP PTA 调用底层驱动完成；Linux 普通世界的 CA 通过 TEE Client API 经内核驱动、ATF 进入 OP-TEE OS 再分发到 PTA。这样 OTP 中的密钥、序列号和安全配置不会被普通 Linux 直接访问或篡改，底层控制逻辑也不暴露给非安全态。

问题 2：OP-TEE 里的 PTA 和 UTA 有什么区别，RZ/T2H 的 OTP 服务为什么用 PTA？

回答 2：PTA 是注册在 OP-TEE Core 中的内建高权限服务，适合封装只有安全世界才能访问的寄存器、安全外设和底层平台能力；UTA 是用户模式可信应用，可独立开发、签名和部署，更适合业务逻辑。OTP 服务需要直接访问 Core 内部接口和安全硬件驱动，并作为其他 TA 共用的底层安全服务，所以在 RZ/T2H 方案中采用 PTA。

问题 3：RZ/T2H 读写 OTP 用的是什么命令和接口，调用链路经过哪些组件？

回答 3：CA 侧使用 TEEC_InitializeContext、TEEC_OpenSession、TEEC_InvokeCommand、TEEC_CloseSession 等 TEE Client API，对外命令为 rz_optee_ta_otp read/write 地址数据/字数；链路依次经过 CA、libteec、Linux 内核 TEE 驱动、ATF、OP-TEE OS、OTP PTA，最后由 r_otp_read / r_otp_write 底层驱动操作寄存器。

问题 4：RZ/T2H 写入 OTP 时需要遵循哪些寄存器流程和安全约束？

回答 4：写入流程依次是确认掉电状态、置位 PWR/ACCL 并等待 CMD_RDY、设置地址寄存器 OTPADRWR、设置数据寄存器 OTPDATAWR、置位 STAWR 启动写入、轮询 STAWR 和 CMD_RDY、检查 ERR_WP/ERR_WR 错误位，结束后按规定回到掉电状态；加 WORDLOCK 的区域不可写，OTP 一次性编程，已写位不可改回，写入过程中禁止复位，测试应使用 user area。

问题 5：在 RZ/T2H 上编译验证 OP-TEE OTP 方案需要走哪些步骤？

回答 5：先把对 optee-os 的修改打成 patch 放入 recipes-bsp/optee/files 并配 bbappend；再用 bitbake 编译 optee-os、重新编译 firmware-signing 和 firmware-pack 完成 FIP 打包签名；然后编译 optee-ta-sample 生成 rz_optee_ta_otp；烧写 BL2 和 FIP 固件后，在板子上执行读 unique ID、写 user area、回读比对三步验证。

【参考资料】

[2026-11-10]（一篇看懂 OP-TEE：瑞萨 RZ/T2H 如何实现 OTP 访问）电子工程专辑
[2026-11-05]（Getting Started - Renesas RZ Linux BSP Plus）renesas-rz.github.io
[2026-10-10]（About OP-TEE）OP-TEE 官方文档
[2026-09-13]（Secure storage）OP-TEE 官方文档
[2026-02-16]（Trusted Applications）OP-TEE 官方文档
[2025-02-07]（RZ/T2H MPU 产品页）RA 生态工作室（瑞萨 MCU/MPU 中文网站）
[2026-07-14]（The Linux Kernel Archives：OP-TEE driver）Linux Kernel 文档

【免责声明】

以上内容基于公开技术文章、OP-TEE 官方文档及瑞萨产品资料整理，寄存器名称、命令号、编译路径和示例输出随 BSP 版本（如 Linux 内核版本、Yocto 配方）可能存在差异；OTP 写入涉及不可逆操作和密钥区保护，实际开发请以瑞萨官方用户手册、安全手册和对应版本源码为准，本文不构成硬件设计或量产安全方案的最终依据。

本文来自作者[星核听波人]投稿，不代表环球科技潮立场，如若转载，请注明出处：https://www.zennew.com/kjyw/202611/973.html