How to deploy OP-TEE OS on redpesk

A brief story about OP-TEE

OP-TEE is an Open Portable Trusted Execution Environment (TEE) designed as a secure companion to a non-secure Linux kernel running on ARM Cortex-A cores using the ARM TrustZone technology.

With OP‑TEE, sensitive operations remain protected even if the rich OS is compromised including keeping private keys confined to secure world, sealed storage of secrets encrypted filesystems, PIN/DRM checks, signature management, image authentication (Zephyr RTOS, firmwares…), etc. You can find below a schema showing a simplified OP-TEE architecture.

optee-architecture

Trusted Applications (TAs) are small secure-world programs that OP‑TEE loads, verifies, and runs isolated from Linux and from other TAs using ARM TrustZone protections. Normal‑world Client Applications call TAs via the GlobalPlatform TEE Client API, while TAs use the TEE Internal Core API for crypto, secure storage, and shared memory; signatures are checked before execution to ensure integrity and authenticity.

Experiment with OP-TEE on NXP i.MX8MP based boards

OP‑TEE can be deployed on redpesk OS for ARMv8 SoCs by enabling OP‑TEE in the boot chain (ARM Trusted Firmware/U‑Boot), including OP‑TEE OS and client packages in the image, and validating with xtest program or other samples on the target. Generally, ATF loads OP‑TEE first, then U‑Boot proceeds and the Linux Kernel boots with the OP‑TEE device tree node automatically provided by firmware.

NOTE:
For now, OP-TEE within redpesk OS has only been deployed and successfully tested on the SolidRun Hummingboard Pulse which uses NXP i.MX8MP SoC.
It could certainly be the same procedure for other platforms on which manufacturers use i.MX8 for their boards depending if OP-TEE is supported (SolidRun, NXP, etc.)
 
Please contact us if you want to deploy OP-TEE to other targets or if you have issues with OP-TEE on NXP i.MX8MP based boards.

Requirements to build OP-TEE OS in your BSP

For our demonstration, we used a redpesk OS batz 2.0 image on the SolidRun Hummingboard Pulse using Kernel 5.15, U-Boot v2022.04 (cf. NXP Yocto kirkstone recipes).

So you can find all these components on the official redpesk OS download repositories for this BSP version.

Confirm that OP-TEE Kernel module has been probed

  • Verify OP-TEE device nodes at runtime:
[root@localhost ~]# ls -l /dev/tee*
crw------- 1 root root 244,  0 Oct  9 17:11 /dev/tee0
crw------- 1 root root 244, 16 Oct  9 17:11 /dev/teepriv0
  • Verify OP-TEE Kernel modules logs:
[root@localhost ~]# dmesg |grep tee
[    1.705502] optee: probing for conduit method.
[    1.709960] optee: revision 3.19
[    1.711526] optee: dynamic shared memory is enabled
[    1.719972] optee: initialized driver

If no /dev/tee device appears, you may check that the optee-os package is present in your BSP, OP‑TEE is enabled in ATF and OP-TEE configs are activated in U‑Boot AND the Linux Kernel.

  • Verify OP-TEE boot sequence if some debugging levels for logs are enabled (optional):
I/TC: OP-TEE version: 3.16.0-694-g00919403f (gcc version 15.2.1 20250808 (Red Hat Cross 15.2.1-1) (GCC)) #1 Wed Oct  8 13:12:58 UTC 2025 aarch64
I/TC: Primary CPU initializing
D/TC:0 0 boot_init_primary_late:1375 Executing at offset 0 with virtual load address 0x56000000
D/TC:0 0 call_preinitcalls:21 level 2 mobj_mapped_shm_init()
D/TC:0 0 mobj_mapped_shm_init:463 Shared memory address range: 56400000, 58400000

Run OP-TEE client called tee-supplicant

After OP-TEE OS is configured, you must have an OP-TEE client to be able to run your Trusted Applications.

Test OP-TEE communication with xtest

If both OP-TEE OS and OP-TEE client are successfully running, you can go to OP-TEE test side to validate the communication between Trusted Execution Environment (OP-TEE OS) and Rich Execution Environment (redpesk OS).