[Contribution] RK3576 Mainline Support: TRNG, Thermal OTP, and NPU Infrastructure

[th3cavalry]

Overview

To assist with the flipper-devel mainline effort, we'd like to contribute several RK3576 hardware block implementations that we stabilized while porting the mainline kernel to the PhotoniCAT 2.

Disclaimer: While some of the initial integration was "vibe coded", this code is fully functional on live hardware across both OpenWrt and Ubuntu/Debian builds (building, flashing, and operating reliably).

What we are sharing:

1. Hardware RNG (TRNG): Support for the RK3576 standalone TRNG. Given Flipper's role as a security tool, a functional hardware RNG is critical.
2. Thermal OTP & TSADC: Support for reading thermal trim values directly from OTP memory. This is required for accurate temperature monitoring across the A72/A53/NPU clusters to prevent throttling issues.
3. PCIe & Naneng Combo PHY: Stability fixes for Gen2x1 configurations, specifically addressing PHY initialization issues we encountered with M.2 expansion modules.
4. NPU Infrastructure: Our rk3576.dtsi already includes the full power domain hierarchy (PD_NPUTOP, PD_NPU0, PD_NPU1), npu_grf system controllers, and all seven NPU QoS nodes. This provides the necessary "wiring" to enable the RKNPU2 stack.

References

• Mainline Tracking Repo: photonicat/rockchip_rk3576_linux_mainline
• Specific Patches: See the patches/kernel/ directory in the repository above (e.g., 060-v6.13-arm64-dts-rockchip-Add-rk3576-SoC-base-DT.patch and 330-02-thermal-rockchip-support-reading-trim-values-from-otp.patch).

Let us know if you'd like us to open a PR against the flipper-devel branch or if you'd prefer the patches formatted via git send-email.

[alchark]

Hi @th3cavalry, thanks a lot for sharing these! I believe we already have thermal trim support integrated, but the rest would be great to have upstream.

With Linux and U-boot patches in particular, I strongly believe that the best way is to submit them to the appropriate upstream mailing lists (along with appropriate sign-offs, DT binding changes where relevant, etc) and then b4 shazam from there to our respective dev branches as required until everything is merged to master.

Would you like to join forces in preparing them for initial submission? We can use our tree as the staging area for that prep work and testing if that helps!

[th3cavalry]

Hi @th3cavalry, thanks a lot for sharing these! I believe we already have thermal trim support integrated, but the rest would be great to have upstream.

With Linux and U-boot patches in particular, I strongly believe that the best way is to submit them to the appropriate upstream mailing lists (along with appropriate sign-offs, DT binding changes where relevant, etc) and then b4 shazam from there to our respective dev branches as required until everything is merged to master.

Would you like to join forces in preparing them for initial submission? We can use our tree as the staging area for that prep work and testing if that helps!

I would absolutely love to! Would definitely be a learning experience since I'm still pretty new to these things.

I never thought my personal project would be helpful to something as big as this until I read an article yesterday about the Flipper One.

[gahingwoo]

Hi @th3cavalry, thanks a lot for sharing these! I believe we already have thermal trim support integrated, but the rest would be great to have upstream.
With Linux and U-boot patches in particular, I strongly believe that the best way is to submit them to the appropriate upstream mailing lists (along with appropriate sign-offs, DT binding changes where relevant, etc) and then b4 shazam from there to our respective dev branches as required until everything is merged to master.
Would you like to join forces in preparing them for initial submission? We can use our tree as the staging area for that prep work and testing if that helps!

I would absolutely love to! Would definitely be a learning experience since I'm still pretty new to these things.

I never thought my personal project would be helpful to something as big as this until I read an article yesterday about the Flipper One.

Hi, I'm working on the OP-TEE (BL32) side for RK3576 — patches are pending review at OP-TEE OS #7821 and TF-A Gerrit #51089.
Your TRNG implementation is exactly what I need — currently using Fortuna SW PRNG as fallback for HUK generation, but hardware TRNG would be the proper solution. Would love to reference your TRNG driver to implement the OP-TEE side.
Also useful to know about the OTP row offsets from your thermal work — that might unblock the persistent HUK implementation.

[alchark]

I’m afraid that the OTPs required for OP-TEE are probably different from those used for thermal trim values. RK3576 has a separate “secure” OTP block which by the sound of it needs to be used in the secure OS.

There are also two TRNG blocks which may or may not work the same - but definitely live at different MMIO base addresses