The RK3399 has two independent crypto IP blocks (crypto0 and
crypto1) for AES, DES/3DES, SHA, and HMAC offload. Linux exposes
them through drivers/crypto/rockchip/. We don’t drive either of them.
Identity
| Property | Value |
|---|---|
| Blocks | RK3399 Crypto v1 (crypto0) and Crypto v2 (crypto1) |
| DTS compatible | rockchip,rk3399-crypto |
| Algorithms | AES (ECB/CBC/CTR), DES/3DES, SHA-1/256, MD5, HMAC |
| Linux driver | drivers/crypto/rockchip/ |
Driver
· not started No driver in tree.
Software crypto on the A72 cores is fast enough for the current
workload — SSH session-bus, HTTPS via pkg, ZFS dataset crypto if it
were enabled — and the kernel’s aesni-equivalent path on aarch64
(armv8_crypto) covers the only hot use case (TLS / ZFS bulk AES).
No bring-up is planned. If it were, the path would be:
- Decide on the FreeBSD shape —
crypto(9)opencrypto session provider, or acryptodev-bound device driver. Linux’s rockchip crypto driver registers as acrypto_engineasync accelerator. - Port the register programming from
drivers/crypto/rockchip/rk3288_crypto*.c. Crypto v1 (crypto0) and v2 (crypto1) have different register layouts. - Benchmark against
armv8_cryptoAES-NI-equivalent. If the on-die block isn’t materially faster than the inline AES instructions, the driver is not worth carrying.
Skipping this is intentional. RK3399 crypto offload is a low-priority
item in HARDWARE.md (under System Peripherals) and would compete for
attention with subsystems users actually notice (audio, modem, sensors).
Status
| Question | Answer |
|---|---|
| Probes? | n/a |
| Used by anything? | No — armv8_crypto covers AES |
| User-visible? | No |
| Blocking? | No |
Open work
- None planned. Re-evaluate only if a workload demonstrably benefits (e.g. wireguard at multi-Gbps, which this hardware can’t reach anyway).
Related
- Hardware reference — System Peripherals row.
HARDWARE.md— RK3399 Crypto x2 listed as “low priority — software crypto works.”