For the Rockchip RK3576, AI inference has required Rockchip's proprietary RKNPU runtime, which does not run under mainline Linux and cannot be pulled into CI without vendor SDK wrappers. A developer named Ga Hing Woo just removed that constraint. He reverse-engineered the RK3576 NPU compute registers (the TRM lists 4,381 pages and does not mention "CNA", "CMAC", or "convolution" once), validated a single-task int8 convolution path to byte-exact agreement with a CPU reference, published a technical paper on Zenodo, and posted the code on GitHub. The RK3576 now has a documented, open-source path to mainline Linux inference.
The work is methodologically careful in a way that matters for anyone building on it. Chained tasks still stall; Ga Hing Woo traced the failure to a sub-MMIO sequencer bit (CNA/CORE/DPU executer bit 16) that never engages on chained workloads, and reported it as a clean negative result rather than a claimed fix. A second developer (MidG971) hit the same wall independently on the RK3568, confirming the root cause across chips. The byte-exact baseline on single tasks gives any contributor a numerical target to validate against.
A secondary artifact, Kiln, packages the vendor RKNPU/RKLLM runtime to run on a mainline kernel, bridging the gap while the Rocket driver is completed. Numbers on Radxa ROCK 4D: Llama-3.2-1B at 13 tok/s, Qwen2.5-1.5B at 9 tok/s, MobileNet at 169 fps. These are not impressive inference numbers. The point is that they run on a $50 SBC under a mainline kernel with open-source driver code that a CI runner can pull and execute.
Vendor SDK lock-in is the same structural problem as proprietary EDA binary blobs: it makes automated validation impossible without a license check in the critical path. A mainline Linux NPU driver makes the AI compute surface testable in CI. Rockchip ships millions of RK3576-based boards. Every product team building on that silicon just had their validation loop shortened by the time it takes to set up a vendor SDK account.