TEE-OS for RK3576

[alchark]

RK3576 is not currently supported in the upstream OP-TEE, which is the basis for Rockchip's closed source BL32 boot stage (as published in binary form in their rkbin repository).

It should be close enough to the already-supported RK3588 for an initial implementation, but the exact differences are unknown, as the security related hardware blocks are not documented in RK3576 TRM documents.

Help would be appreciated in obtaining the relevant documents and/or in implementing OP-TEE support for RK3576

[altgreen64]

Proposed Approach to Enable OP‑TEE Support for RK3576
Below is a concrete, realistic plan that can help move this issue forward even without full security documentation from Rockchip. This approach mirrors how support for previous Rockchip SoCs (RK3399, RK3568, RK3588) was introduced and can be executed incrementally.

1. Start from the RK3588 OP‑TEE Platform
   RK3576 is architecturally close to RK3588, so the most practical first step is to clone the existing rk3588 platform inside OP‑TEE and create a new rk3576 target.

This gives:

a working build structure,

correct directory layout,

initial stubs for clocks, GIC, UART, SMC handlers, memory map, etc.

All uncertain parts can be marked with TODO: verify on RK3576.

2. Extract Information From the Existing BL32 Binary (rkbin)
   Rockchip already ships a proprietary BL32 (OP‑TEE) for RK3576 in rkbin.
   Even though it is closed‑source, it can still provide valuable hints:

Compare RK3576 BL32 with RK3588 BL32 using:

strings, binwalk, hexdump

Identify:

MMIO regions referenced by the secure world

SMC IDs used

Differences in memory layout

Potential secure hardware blocks (OTP, crypto engines, secure GRF)

Light static analysis (Ghidra/IDA) can help map out:

entry points,

SMC dispatch tables,

initialization sequences.

This is often enough to reconstruct the minimal requirements for a functional OP‑TEE port.

3. Align With the RK3576 Boot Flow
   Even without full TRM coverage, the boot flow is expected to follow the same pattern as RK3588:

Kod
BL1 (ROM) → BL2 (SPL) → BL31 (TF‑A) → BL32 (OP‑TEE) → BL33 (U‑Boot/Linux)
To ensure compatibility:

Inspect TF‑A for RK3576 to see:

which SMCs it expects from BL32,

how secure DRAM regions are reserved,

what memory addresses BL32 must occupy.

This allows the new OP‑TEE platform to match TF‑A’s expectations.

4. Bring Up a Minimal “Stub” OP‑TEE for RK3576
   Before implementing full secure services, create a minimal OP‑TEE build that:

initializes UART for logging,

registers a basic SMC handler,

boots far enough for TF‑A to hand off to BL33,

returns stub responses for unimplemented SMCs.

This allows testing on real hardware and provides immediate feedback:

Does BL32 load correctly?

Which SMCs are called?

Are there missing secure regions?

Even a minimal bring‑up is extremely valuable for iterating.

5. Document All Findings Publicly
   Since Rockchip’s TRM does not describe the secure blocks for RK3576, the community can build a working knowledge base:

MMIO addresses discovered from BL32 analysis

secure region layout

required SMCs

differences vs RK3588

A living document such as
“RK3576 Secure World Notes (Reverse‑Engineered)”
would help everyone working on OP‑TEE, TF‑A, and Linux bring‑up.

6. Request Specific Missing Documentation From Rockchip
   Instead of a general request, it helps to list exactly what is missing:

secure GRF registers,

OTP/efuse layout,

crypto engine registers,

TrustZone memory regions,

secure boot fuse behavior.

Even partial or NDA‑light documentation would unblock upstream support.

Summary
This plan allows OP‑TEE support for RK3576 to progress without waiting for full official documentation, while still leaving the door open for Rockchip to provide missing details later.

If helpful, I can also prepare:

a PR skeleton for the new rk3576 platform,

a checklist for minimal bring‑up,

or a diff template comparing RK3588 → RK3576.

Just let me know.

[gahingwoo]

Hi, I've got OP-TEE running on RK3576 (tested on Radxa ROCK 4D, same SoC as Flipper One).

Boot log confirming full chain: DDR → SPL → BL31 → OP-TEE (BL32) → U-Boot:

DDR 2f85f4b2d4 cym 24/11/07-19:07:28,fwver: v1.09
In
ch0 ttot6
ch1 ttot6
ch0 ttot8
LPDDR5, 2736MHz
channel[0] BW=16 Col=10 Bk=16 CS0 Row=17 CS1 Row=17 CS=2 Die BW=8 Size=6144MB
ch1 ttot8
channel[1] BW=16 Col=10 Bk=16 CS0 Row=17 CS1 Row=17 CS=2 Die BW=8 Size=6144MB
Manufacturer ID:0x13
CH0 RX Vref:27.0%, RX DQS Vref:27.8%, TX Vref:20.0%,22.0%
DQ roc:
p7 n0, p7 n0, p1 n0, p6 n0, p3 n0, p7 n0, p0 n5, p1 n0, p1 n1, 
p6 n0, p0 n0, p3 n0, p5 n0, p2 n0, p6 n0, p0 n2, p5 n0, p1 n1, 

DQ rds:l0 h1 l0 h1 l0 h1 l0 l0, l0 h1 l0 l0 l0 l0 l0 l0 
DQS roc: p3, n0, p2, n0

CH1 RX Vref:28.2%, RX DQS Vref:31.2%, TX Vref:19.0%,21.0%
DQ roc:
p1 n0, p4 n0, p6 n0, p3 n0, p3 n0, p7 n0, p0 n3, p2 n0, p5 n0, 
p1 n0, p7 n0, p3 n0, p1 n0, p6 n0, p7 n0, p0 n0, p0 n3, p5 n0, 

DQ rds:h1 h1 l0 l0 l0 h1 l0 l0, l0 l0 h1 l0 l0 l0 h1 l0 
DQS roc: p0, n0, p2, n0

stride=0x3, ddr_config=0x6
hash bank_mask0-3 0x0 0x2100 0x44200 0x88400, rank_mask0 0x800
change to F1: 534MHz
ch0 ttot6
ch1 ttot6
change to F2: 1320MHz
ch0 ttot8
ch1 ttot8
change to F3: 1968MHz
ch0 ttot7
ch1 ttot7
change to F0: 2736MHz
ch0 ttot8
ch1 ttot8
out

U-Boot SPL 2026.04-rc1 (May 23 2026 - 19:34:42 +1200)
Trying to boot from SPI
## Checking hash(es) for config config-1 ... OK
## Checking hash(es) for Image atf-1 ... sha256+ OK
## Checking hash(es) for Image u-boot ... sha256+ OK
## Checking hash(es) for Image fdt-1 ... sha256+ OK
## Checking hash(es) for Image atf-2 ... sha256+ OK
## Checking hash(es) for Image atf-3 ... sha256+ OK
## Checking hash(es) for Image tee-1 ... sha256+ OK
NOTICE:  BL31: v2.14.0(debug):dc7c828-dirty
NOTICE:  BL31: Built : 19:07:54, May 23 2026
INFO:    soc cold boot
INFO:    ARM GICv2 driver initialized
INFO:    enable memory repair
INFO:    BL31: Initializing runtime services
INFO:    BL31: cortex_a53: CPU workaround for erratum 855873 was applied
INFO:    BL31: cortex_a53: CPU workaround for erratum 1530924 was applied
INFO:    BL31: Initializing BL32
I/TC: 
I/TC: No non-secure external DT
I/TC: OP-TEE version: d820f13-dev (gcc version 13.3.0 (Ubuntu 13.3.0-6ubuntu2~24.04.1)) #1 Sat May 23 07:08:08 UTC 2026 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html
I/TC: Primary CPU initializing
I/TC: Primary CPU switching to normal world boot
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x40800000
INFO:    SPSR = 0x3c9


U-Boot 2026.04-rc1 (May 23 2026 - 19:34:42 +1200)

Model: Radxa ROCK 4D
SoC:   RK3576
DRAM:  12 GiB
PMIC:  RK806 (on=0x40, off=0x00)
Core:  1050 devices, 32 uclasses, devicetree: separate
MMC:   mmc@2a310000: 0
Loading Environment from nowhere... OK
In:    serial@2ad40000
Out:   serial@2ad40000
Err:   serial@2ad40000
Net:   eth0: ethernet@2a220000
Hit any key to stop autoboot: 0
=> 

I'm happy to share the platform code. https://github.com/gahingwoo/bl32-rk3576. If someone wants to handle the PR to integrate this into the build scripts, I'll hand over the implementation — I'll credit you as co-author. Drop a comment here or ping me directly.

— gahingwoo

[gahingwoo]

RK3576 is not currently supported in the upstream OP-TEE, which is the basis for Rockchip's closed source BL32 boot stage (as published in binary form in their rkbin repository).

It should be close enough to the already-supported RK3588 for an initial implementation, but the exact differences are unknown, as the security related hardware blocks are not documented in RK3576 TRM documents.

Help would be appreciated in obtaining the relevant documents and/or in implementing OP-TEE support for RK3576

Update: I've submitted the patches upstream.
OP-TEE OS — PR #7821: adds PLATFORM_FLAVOR=rk3576 with GIC-400, TZDRAM, SGRF Firewall, and UART0 fixes.
TF-A — Gerrit #51089: fixes GICV2_G0_FOR_EL3 when SPD=opteed, which was causing the EL3 panic on RK3576.
Both are pending review. Once merged, this can be integrated into the Flipper One build scripts without carrying out-of-tree patches.

[alchark]

@gahingwoo that’s excellent progress, thanks a lot!

While you were working on this, did you get any clue how much trouble would it be to add HUK derivation and signatures support? Likely needs OTP, TRNG and hardware crypto, maybe also hardware timer

[gahingwoo]

@gahingwoo that’s excellent progress, thanks a lot!

While you were working on this, did you get any clue how much trouble would it be to add HUK derivation and signatures support? Likely needs OTP, TRNG and hardware crypto, maybe also hardware timer

@alchark I haven't looked into OTP/TRNG yet, but here's what I found in the existing codebase:
The rockchip_otp.c driver already exists in OP-TEE and the RK3576 OTP controller is at 0x2a480000. The main blocker for HUK is just the OTP row offset for the HUK slot — RK3588 uses 0x104 but RK3576 likely differs. This should be findable in the Rockchip downstream kernel dtsi (nvmem-cells).
Once that offset is confirmed, HUK support should be straightforward — plat_get_huk_seed() can be ported directly from the RK3588 implementation.
TRNG is a separate effort and not strictly needed for initial HUK (OP-TEE's Fortuna PRNG is sufficient for first bring-up).
Key Ladder looks like it needs proprietary docs — probably out of scope without NDA material.

[gahingwoo]

@gahingwoo that’s excellent progress, thanks a lot!
While you were working on this, did you get any clue how much trouble would it be to add HUK derivation and signatures support? Likely needs OTP, TRNG and hardware crypto, maybe also hardware timer

@alchark I haven't looked into OTP/TRNG yet, but here's what I found in the existing codebase: The rockchip_otp.c driver already exists in OP-TEE and the RK3576 OTP controller is at 0x2a480000. The main blocker for HUK is just the OTP row offset for the HUK slot — RK3588 uses 0x104 but RK3576 likely differs. This should be findable in the Rockchip downstream kernel dtsi (nvmem-cells). Once that offset is confirmed, HUK support should be straightforward — plat_get_huk_seed() can be ported directly from the RK3588 implementation. TRNG is a separate effort and not strictly needed for initial HUK (OP-TEE's Fortuna PRNG is sufficient for first bring-up). Key Ladder looks like it needs proprietary docs — probably out of scope without NDA material.

Update: HUK framework is working.

I/TC: RK3576: using ephemeral HUK (CFG_RK3576_PERSIST_HUK=n)

OTP driver initializes cleanly. Currently falling back to SW PRNG (Fortuna) since the HUK row offset at 0x104 returns all-zero — likely a different offset on RK3576. Persistent HUK (CFG_RK3576_PERSIST_HUK=y) is gated until the correct offset is confirmed from TRM.
Should I include the HUK framework in the existing OP-TEE PR (#7821), or keep it as a follow-up once the OTP row offset is confirmed?

[alchark]

I’d rather proceed in incremental steps, so a different PR sounds better. Have the initial support merged upstream first, then we can include it in autobuilds for easier testing, then proceed with adding functionality

[gahingwoo]

I’d rather proceed in incremental steps, so a different PR sounds better. Have the initial support merged upstream first, then we can include it in autobuilds for easier testing, then proceed with adding functionality

Makes sense, will wait for the initial PR to merge upstream first. Thanks!

[alchark]

Let us please use proper form for code submission. Pasting a wall of text into an issue comment is not one

[alchark]

For the avoidance of doubt, proper forms of code submission include:

• Git pull request
• Link to a public Git repository with a known fork base from the respective upstream repository, full commit descriptions (including sign-offs and attribution) and unambiguous license+copyright information
• Patch submission to an upstream project following respective upstream rules (preferred)

While a Github gist is marginally better than inserting code into the text of a comment, it’s still not the way to submit code.

May I please also ask contributors to check for pre-existing work and cooperate with the authors thereof, rather than (vibe-)code a dozen of competing implementations with no clear indication how or why they differ from prior takes