Bringing Up the RK3576 NPU on Mainline Linux: An End-to-End Open Stack, and What a Register Diff Keyed on Addresses Cannot See

Abstract

The Rockchip RK3576 ships a 6 TOPS NPU whose only fully open software stack is the mainline drivers/accel/rocket driver with the Mesa Teflon delegate. This paper reports a complete open bring-up on a Radxa ROCK 4D, and supersedes version 1 of this work (10.5281/zenodo.21348017), whose central claim was false. Positive. MobileNet V1 runs end to end on the NPU through the open stack, with 1000 of its 1001 outputs within one count of a CPU reference, against 1001 channels of zero in every run before. That reference is degenerate and the paper says so: an empty buffer scores 983 on it, measured. What settles it is the label, and the label was checked: the NPU picks the class the CPU picks, with the same five classes in the same order. charsiu, written for this work, opens /dev/accel/accel0 directly with neither Mesa nor the vendor runtime in the path, computes a signed int8 matmul byte exact, and issues 32 tasks from a single job. Driver support is on the list as [PATCH v8 00/12], no patch of the twelve yet applied. Negative, and this is the part worth reading. Version 1 localized a chained-task compute failure to sub-MMIO sequencer state and asked for RTL or JTAG. Two separate failures produced that conclusion, one in each of two source trees, and the same register is implicated in both to different standards of proof. On the development fork the register played no part at all, and an earlier draft of this version said it did: I read a printed register value as what the driver had written when it is a readback. That reading is withdrawn inside the paper rather than deleted. What actually stood between that tree and a working network was fifteen ordinary faults in register and buffer generation, each smaller than the resolution of the oracle then in use, an oracle that could not distinguish a recomputation from an output buffer that was never written. On the upstream series, cut from the same work a month later, a fix I had written in the fork in June is one I did not carry across, so six posted revisions asked the hardware for 28673 tasks. I found which register in one run, once I aligned a trace on values rather than on register addresses. The instrument defect generalizes: an ordered diff keyed on the register address is blind to a different value written to a matched address, which is exactly what a field-layout error looks like. Ordering was never the problem; the alignment key was. It had a cost. A correct counterexample and the correct discriminating experiment were both supplied from outside, nineteen days before the fix, and were declined on the strength of a comparison that could not have seen the difference. The record is the larger half: three occasions inside twenty-one days where the answer was already written down in my own ledger and a frame proposed beside it won instead. Artifacts: https://github.com/gahingwoo/linux-rk3576-npu (driver, ledger, replay harness), https://github.com/gahingwoo/mesa-rk3576 branch rk3576 (the rocket/Teflon userspace where the fifteen faults were fixed), https://github.com/gahingwoo/charsiu (open LLM runtime on the same driver), https://github.com/gahingwoo/kiln (vendor stack on a mainline kernel, used as the same-kernel control).