Sharing results and two findings from shipping a distribution on CP8180, in case either saves you a support cycle.
Context: NCZ-OS 26.7 ships on Sky1 (Radxa Orion O6N and Minisforum MS-R1) using the 26Q2 SDK — cix-npu-driver-dkms 6.2.0, cix-vpu-driver, cix-gpu-kmd. All three validated on hardware with real workloads.
Finding 1 — an NPU failure that looks like dead silicon but is a version mismatch
If this reaches you as a bug report, it is very likely not a driver defect:
[UMD ERR] aipu.cpp:57: query capability [fail]
RuntimeError: npu: noe_init_context fail
Cause: a UMD/KMD version mismatch. An older user-mode driver cannot query a newer kernel driver's capabilities, so context init fails before any job is dispatched. In our case a Python environment held libnoe 2.0.0 / NOE-Engine 2.0.0 against the 6.2.0 kernel driver. Re-syncing to libnoe 3.1.3 / noe_engine 3.0.0 fixed it immediately.
Why it is easy to misdiagnose: it presents exactly like non-functional hardware. /dev/aipu exists, the driver probes cleanly, the ZHOUYI V3 banner prints, dmesg is clean, and /proc/interrupts shows the aipu line stuck at 0. We had recorded it in our own documentation as a driver bug for two weeks before finding the real cause.
With matched versions the NPU works well — nomic-embed-text-v1.5_256.cix at 95.5 ms per 256-token embed, bit-identical across repeated runs, on both an O6N and an MS-R1.
Suggestion: a version check at noe_init_context that reports the UMD and KMD versions on mismatch would turn a multi-day investigation into a one-line error.
Finding 2 — the VPU needs its firmware staged, and fails silently without it
amvx loads and enumerates /dev/video0 and /dev/video1 with no firmware present. v4l2-ctl --info succeeds. Nothing logs an error. Decode simply produces nothing.
It needs the 16 *.fwb codec blobs in /lib/firmware. With them: Linlon v5276, 4 cores, 8 decode formats (H.263/H.264/HEVC/MPEG-2/MPEG-4/VP8/VP9/AV1) and hardware H.264/HEVC/VP8/VP9 encode, confirmed through ffmpeg V4L2 mem2mem.
Six VA-API patches, published with reproducers
Browser hardware video decode did not work at all on this platform until four defects in cix-vaapi 1.1.0 were fixed. All four failed silently — no component logged an error — so we published standalone C reproducers alongside the patches so a driver author can confirm each one without building a browser.
Roughly: RTFormat not reported from vaQueryConfigAttributes; no surface pool allocated when a context has no render targets; VA_EXPORT_SURFACE_SEPARATE_LAYERS not honoured in vaExportSurfaceHandle; and exported surface IDs not bound to the surfaces the decoder writes.
Result after the patches: H.264 1080p and VP9 720p decode in hardware in Chromium — renderer CPU ~27% → ~3.5% on H.264, 0 dropped frames. AV1 remains blocked upstream. Verified by screenshotting the compositor and looking at the picture, not by trusting a proxy signal.
We would be glad to see any of these upstreamed into cix-vaapi, in whatever form suits you — happy to rework them.
Thank you for the SDK, the Sky1 patch series, and for pushing enablement into mainline. That last part matters well beyond this project: it is the difference between a board that needs a vendor tree indefinitely and one that eventually boots a distribution kernel.
Release and full documentation: https://gitlab.com/ncz-os/cix-installer
Sharing results and two findings from shipping a distribution on CP8180, in case either saves you a support cycle.
Context: NCZ-OS 26.7 ships on Sky1 (Radxa Orion O6N and Minisforum MS-R1) using the 26Q2 SDK —
cix-npu-driver-dkms 6.2.0,cix-vpu-driver,cix-gpu-kmd. All three validated on hardware with real workloads.Finding 1 — an NPU failure that looks like dead silicon but is a version mismatch
If this reaches you as a bug report, it is very likely not a driver defect:
Cause: a UMD/KMD version mismatch. An older user-mode driver cannot query a newer kernel driver's capabilities, so context init fails before any job is dispatched. In our case a Python environment held
libnoe 2.0.0/NOE-Engine 2.0.0against the 6.2.0 kernel driver. Re-syncing tolibnoe 3.1.3/noe_engine 3.0.0fixed it immediately.Why it is easy to misdiagnose: it presents exactly like non-functional hardware.
/dev/aipuexists, the driver probes cleanly, theZHOUYI V3banner prints,dmesgis clean, and/proc/interruptsshows theaipuline stuck at 0. We had recorded it in our own documentation as a driver bug for two weeks before finding the real cause.With matched versions the NPU works well —
nomic-embed-text-v1.5_256.cixat 95.5 ms per 256-token embed, bit-identical across repeated runs, on both an O6N and an MS-R1.Suggestion: a version check at
noe_init_contextthat reports the UMD and KMD versions on mismatch would turn a multi-day investigation into a one-line error.Finding 2 — the VPU needs its firmware staged, and fails silently without it
amvxloads and enumerates/dev/video0and/dev/video1with no firmware present.v4l2-ctl --infosucceeds. Nothing logs an error. Decode simply produces nothing.It needs the 16
*.fwbcodec blobs in/lib/firmware. With them: Linlon v5276, 4 cores, 8 decode formats (H.263/H.264/HEVC/MPEG-2/MPEG-4/VP8/VP9/AV1) and hardware H.264/HEVC/VP8/VP9 encode, confirmed throughffmpegV4L2 mem2mem.Six VA-API patches, published with reproducers
Browser hardware video decode did not work at all on this platform until four defects in
cix-vaapi1.1.0 were fixed. All four failed silently — no component logged an error — so we published standalone C reproducers alongside the patches so a driver author can confirm each one without building a browser.docs/upstream-patches/cix-vaapi/— the six patchesdocs/upstream-patches/cix-vaapi-repro/—vaprobe.c,vaprobe2.cdocs/HW-VIDEO-DECODE-STATUS.md— what works, with evidenceRoughly: RTFormat not reported from
vaQueryConfigAttributes; no surface pool allocated when a context has no render targets;VA_EXPORT_SURFACE_SEPARATE_LAYERSnot honoured invaExportSurfaceHandle; and exported surface IDs not bound to the surfaces the decoder writes.Result after the patches: H.264 1080p and VP9 720p decode in hardware in Chromium — renderer CPU ~27% → ~3.5% on H.264, 0 dropped frames. AV1 remains blocked upstream. Verified by screenshotting the compositor and looking at the picture, not by trusting a proxy signal.
We would be glad to see any of these upstreamed into
cix-vaapi, in whatever form suits you — happy to rework them.Thank you for the SDK, the Sky1 patch series, and for pushing enablement into mainline. That last part matters well beyond this project: it is the difference between a board that needs a vendor tree indefinitely and one that eventually boots a distribution kernel.
Release and full documentation: https://gitlab.com/ncz-os/cix-installer