Support matrix

What each shipped recipe has been taken through, and against which pins. Every column but the last two is read from the recipe’s lock — the exact pins a build resolves — so this table cannot claim a combination that was never built.

The date is when the claim was last established: for validated, the day the image booted; otherwise the day the claim was last assessed. Re-pinning a lock under a validated claim is flagged by boot2deb update, because moving the pins retires the evidence the claim rested on.

A status says how far a build point has been taken, not that everything on the board works. What each one does not do is under Caveats below, and is printed at the end of a build of that recipe.

Caveats

Limitations that hold whatever you build: they come from the silicon, the board, a capability the recipe selected, or the build point itself, and no rebuild lifts them. The first two are listed once per device, since they hold for every recipe on it; the rest are listed per recipe, and a (feature) tag marks the ones that follow their capability onto any other recipe composing it. A recipe with none listed is not a recipe with none — nothing mechanical establishes that — only one that states none.

Anything a running system could be asked about belongs in that board’s selftest expectations instead, where it fails rather than merely informs. These are the ones that cannot be checked from the running system.

asus-c100p

• (SoC) HDMI tops out at 4K30 and cannot reach 4K60: the RK3288 caps TMDS at 340 MHz, its PHY has no scrambling above that, and the VOP cannot emit YUV420, so there is no reduced-rate path either.
• (board) Two display controllers advertise the same maximum resolution and DRM decides at runtime which one the HDMI encoder lands on; the smaller (VOPL) tops out at 2560x1600. A 4K display showing only part of the picture is that, and dmesg | grep -i vop says which controller it got.

asus-c201-libreboot

• (SoC) HDMI tops out at 4K30 and cannot reach 4K60: the RK3288 caps TMDS at 340 MHz, its PHY has no scrambling above that, and the VOP cannot emit YUV420, so there is no reduced-rate path either.
• (board) Two display controllers advertise the same maximum resolution and DRM decides at runtime which one the HDMI encoder lands on; the smaller (VOPL) tops out at 2560x1600. A 4K display showing only part of the picture is that, and dmesg | grep -i vop says which controller it got.

asus-c201

• (SoC) HDMI tops out at 4K30 and cannot reach 4K60: the RK3288 caps TMDS at 340 MHz, its PHY has no scrambling above that, and the VOP cannot emit YUV420, so there is no reduced-rate path either.
• (board) Two display controllers advertise the same maximum resolution and DRM decides at runtime which one the HDMI encoder lands on; the smaller (VOPL) tops out at 2560x1600. A 4K display showing only part of the picture is that, and dmesg | grep -i vop says which controller it got.

asus-chromebit-cs10

• (SoC) HDMI tops out at 4K30 and cannot reach 4K60: the RK3288 caps TMDS at 340 MHz, its PHY has no scrambling above that, and the VOP cannot emit YUV420, so there is no reduced-rate path either.

h96-max-m9

• (SoC) HDMI tops out at 4K30 and cannot reach 4K60: the dw-hdmi-qp bridge has no SCDC/scrambling support and rejects every mode above 340 MHz TMDS, even where the display advertises 4K60. This is upstream behaviour, not a device-tree limitation.
• (SoC) There is no mainline hardware video encoder for this SoC. Decode is driven (VDPU383, H.264 and HEVC, 1080p and 4K); encode is not driven at all.
• (SoC) Hardware H.264 decode fails intermittently, per decode session, and when it fails the whole session is wrong. Most sessions are bit-exact against the software decoder; roughly one in three to one in six comes out visibly corrupt instead, diverging from the first frame onward at about 17 dB PSNR. It is all-or-nothing per session, not per frame, and re-running the same file usually succeeds. HEVC is unaffected and is bit-exact against software on every run. Until this is fixed, do not rely on hardware H.264 decode; the software decoder is correct and fast enough (about 160 fps at 1080p, 40 at 4K).
• (SoC) The NPU computes but nothing can drive it yet: the rocket userspace stack targets RK3588 only, so no RK3576 userspace exists.
• (board) Only the blue port beside HDMI carries USB 3.0. It reaches 5 Gbps and holds ~154 MB/s over sustained reads. The black ports never will – they sit behind an internal USB 2.0 hub, and their SuperSpeed lane reaches no connector.
• (board) A drive in the blue port that enumerates at 480 Mb/s is usually not seated. With the board sitting back from the enclosure’s front panel a plug bottoms out on the case before the connector’s recessed SuperSpeed contacts mate, so USB 2.0 works perfectly and SuperSpeed is silent. Push the plug fully home, or reseat the board against the panel.
• (board) There is no SD-card slot: it is depopulated on this box. eMMC and USB are the only storage.

rk3576-evb1-v10

• (SoC) HDMI tops out at 4K30 and cannot reach 4K60: the dw-hdmi-qp bridge has no SCDC/scrambling support and rejects every mode above 340 MHz TMDS, even where the display advertises 4K60. This is upstream behaviour, not a device-tree limitation.
• (SoC) There is no mainline hardware video encoder for this SoC. Decode is driven (VDPU383, H.264 and HEVC, 1080p and 4K); encode is not driven at all.
• (SoC) Hardware H.264 decode fails intermittently, per decode session, and when it fails the whole session is wrong. Most sessions are bit-exact against the software decoder; roughly one in three to one in six comes out visibly corrupt instead, diverging from the first frame onward at about 17 dB PSNR. It is all-or-nothing per session, not per frame, and re-running the same file usually succeeds. HEVC is unaffected and is bit-exact against software on every run. Until this is fixed, do not rely on hardware H.264 decode; the software decoder is correct and fast enough (about 160 fps at 1080p, 40 at 4K).
• (SoC) The NPU computes but nothing can drive it yet: the rocket userspace stack targets RK3588 only, so no RK3576 userspace exists.

rk3576-generic

• (SoC) HDMI tops out at 4K30 and cannot reach 4K60: the dw-hdmi-qp bridge has no SCDC/scrambling support and rejects every mode above 340 MHz TMDS, even where the display advertises 4K60. This is upstream behaviour, not a device-tree limitation.
• (SoC) There is no mainline hardware video encoder for this SoC. Decode is driven (VDPU383, H.264 and HEVC, 1080p and 4K); encode is not driven at all.
• (SoC) Hardware H.264 decode fails intermittently, per decode session, and when it fails the whole session is wrong. Most sessions are bit-exact against the software decoder; roughly one in three to one in six comes out visibly corrupt instead, diverging from the first frame onward at about 17 dB PSNR. It is all-or-nothing per session, not per frame, and re-running the same file usually succeeds. HEVC is unaffected and is bit-exact against software on every run. Until this is fixed, do not rely on hardware H.264 decode; the software decoder is correct and fast enough (about 160 fps at 1080p, 40 at 4K).
• (SoC) The NPU computes but nothing can drive it yet: the rocket userspace stack targets RK3588 only, so no RK3576 userspace exists.

asus-c201-libreboot/libre-forky

• The internal BCM4354 Wi-Fi and Bluetooth do not work. linux-libre removes brcmfmac’s firmware request and btbcm’s patchram filename, and this radio is the one part of the board that cannot run without a blob. An AR9271 USB adapter (firmware-ath9k-htc, in Debian main and already installed) is the supported way onto a network.

asus-c201/libre-forky

• The internal BCM4354 Wi-Fi and Bluetooth do not work. linux-libre removes brcmfmac’s firmware request and btbcm’s patchram filename, and this radio is the one part of the board that cannot run without a blob. An AR9271 USB adapter (firmware-ath9k-htc, in Debian main and already installed) is the supported way onto a network.

h96-max-m9/media-accel

• (feature) 10-bit content decodes in hardware, but nothing downstream can use the result without a copy. The decoder emits NV12 for 8-bit and NV15 — 10-bit packed 4:2:0 — for 10-bit. Nothing in this image consumes NV15: Vulkan has no such format, Mesa and ffmpeg’s filters cannot import it, and the decoder cannot be asked for P010 instead because the hardware writes NV15 natively. A 10-bit transcode therefore converts on the CPU. RGA can convert NV15 to P010, but ffmpeg cannot reach RGA here (see the next caveat); a program speaking librga directly can. The display controller scans NV15 out unconverted, so playback to a KMS plane is unaffected.
• (feature) ffmpeg has no RGA filters here. scale_rkrga and vpp_rkrga need --enable-rkmpp, and MPP needs the vendor mpp_service kernel framework that mainline does not have. ffmpeg scales on CPU or GPU; RGA is reached through librga by a program that speaks its API.
• (feature) RGA colour conversion covers BT.601 limited and full range and BT.709, but not BT.2020.
• (feature) Pass RGA its buffers as DMA-BUF file descriptors (importbuffer_fd). librga’s virtual-address import, which builds an IOMMU mapping per call over ordinary process memory, faults the RGA IOMMU on roughly a third of jobs: the job times out after a second, the core is soft-reset, and the destination is left untouched. The same operations over DMA-BUF run clean and about seven times faster.

turing-rk1/jellyfin-forky

• (feature) Scaling inside a hardware transcode runs on the CPU. The RGA filters (scale_rkrga, vpp_rkrga, overlay_rkrga) accept only frames carrying an RKMPP hardware context, and the mainline V4L2 decoder hands out plain DRM PRIME frames, which they reject; hwmap does not bridge the two either. A decode/scale/encode chain therefore downloads frames to system memory, scales them with swscale, and re-uploads them to the encoder. RGA still accelerates a scale fed from software-decoded frames, and the 2D engine itself works.
• (feature) The h264_rkmpp, hevc_rkmpp, vp8_rkmpp and vp9_rkmpp decoders are compiled in but fail to open: MPP finds no decode client on a mainline kernel, where rkvdec is a V4L2 stateless driver rather than an MPP service. Hardware decode is reached with -hwaccel v4l2request. The matching *_rkmpp encoders do work.
• (feature) 10-bit content decodes in hardware, but a 10-bit transcode still converts on the CPU. The V4L2 decoder emits NV12 for 8-bit and NV15 — 10-bit packed 4:2:0 — for 10-bit, and no filter or encoder in this build imports NV15. The decoder cannot be asked for P010 instead; the hardware writes NV15 natively. RGA converts NV15 to P010, but only for a program that speaks librga directly, since the RGA filters reject these frames as described above.
• (feature) Every ffmpeg-rk invocation writes mpp_platform: client N driver is not ready! to standard error, once per vendor service client MPP looks for and does not find on a mainline kernel. It is harmless and appears even for ffmpeg -version, but it is captured by anything that logs the process’s stderr.
• Transcoding is hardware-encode only. The seeded /etc/jellyfin/encoding.xml selects the rkmpp acceleration type with an empty hardware-decoding codec list, so video is decoded and scaled on the CPU and encoded on the VEPU580. Re-enabling any codec under Playback > Transcoding > “Enable hardware decoding for” makes Jellyfin emit -hwaccel rkmpp, whose decoder cannot open on a mainline kernel, and those streams fail outright rather than falling back to software.
• Jellyfin’s bundled FFmpeg is not installed — the recipe supplies /opt/ffmpeg-rk/bin/ffmpeg instead, which is the only build here that can reach the VEPU580. There is therefore no second encoder to fall back to: Jellyfin validates the path during startup and exits if the binary does not run, so pointing Dashboard > Playback > Transcoding > “FFmpeg path” at something invalid leaves the server failing to start rather than transcoding in software.

turing-rk1/jellyfin-trixie

• (feature) Scaling inside a hardware transcode runs on the CPU. The RGA filters (scale_rkrga, vpp_rkrga, overlay_rkrga) accept only frames carrying an RKMPP hardware context, and the mainline V4L2 decoder hands out plain DRM PRIME frames, which they reject; hwmap does not bridge the two either. A decode/scale/encode chain therefore downloads frames to system memory, scales them with swscale, and re-uploads them to the encoder. RGA still accelerates a scale fed from software-decoded frames, and the 2D engine itself works.
• (feature) The h264_rkmpp, hevc_rkmpp, vp8_rkmpp and vp9_rkmpp decoders are compiled in but fail to open: MPP finds no decode client on a mainline kernel, where rkvdec is a V4L2 stateless driver rather than an MPP service. Hardware decode is reached with -hwaccel v4l2request. The matching *_rkmpp encoders do work.
• (feature) 10-bit content decodes in hardware, but a 10-bit transcode still converts on the CPU. The V4L2 decoder emits NV12 for 8-bit and NV15 — 10-bit packed 4:2:0 — for 10-bit, and no filter or encoder in this build imports NV15. The decoder cannot be asked for P010 instead; the hardware writes NV15 natively. RGA converts NV15 to P010, but only for a program that speaks librga directly, since the RGA filters reject these frames as described above.
• (feature) Every ffmpeg-rk invocation writes mpp_platform: client N driver is not ready! to standard error, once per vendor service client MPP looks for and does not find on a mainline kernel. It is harmless and appears even for ffmpeg -version, but it is captured by anything that logs the process’s stderr.
• Transcoding is hardware-encode only. The seeded /etc/jellyfin/encoding.xml selects the rkmpp acceleration type with an empty hardware-decoding codec list, so video is decoded and scaled on the CPU and encoded on the VEPU580. Re-enabling any codec under Playback > Transcoding > “Enable hardware decoding for” makes Jellyfin emit -hwaccel rkmpp, whose decoder cannot open on a mainline kernel, and those streams fail outright rather than falling back to software.
• Jellyfin’s bundled FFmpeg is not installed — the recipe supplies /opt/ffmpeg-rk/bin/ffmpeg instead, which is the only build here that can reach the VEPU580. There is therefore no second encoder to fall back to: Jellyfin validates the path during startup and exits if the binary does not run, so pointing Dashboard > Playback > Transcoding > “FFmpeg path” at something invalid leaves the server failing to start rather than transcoding in software.

turing-rk1/media-accel-forky

• (feature) Scaling inside a hardware transcode runs on the CPU. The RGA filters (scale_rkrga, vpp_rkrga, overlay_rkrga) accept only frames carrying an RKMPP hardware context, and the mainline V4L2 decoder hands out plain DRM PRIME frames, which they reject; hwmap does not bridge the two either. A decode/scale/encode chain therefore downloads frames to system memory, scales them with swscale, and re-uploads them to the encoder. RGA still accelerates a scale fed from software-decoded frames, and the 2D engine itself works.
• (feature) The h264_rkmpp, hevc_rkmpp, vp8_rkmpp and vp9_rkmpp decoders are compiled in but fail to open: MPP finds no decode client on a mainline kernel, where rkvdec is a V4L2 stateless driver rather than an MPP service. Hardware decode is reached with -hwaccel v4l2request. The matching *_rkmpp encoders do work.
• (feature) 10-bit content decodes in hardware, but a 10-bit transcode still converts on the CPU. The V4L2 decoder emits NV12 for 8-bit and NV15 — 10-bit packed 4:2:0 — for 10-bit, and no filter or encoder in this build imports NV15. The decoder cannot be asked for P010 instead; the hardware writes NV15 natively. RGA converts NV15 to P010, but only for a program that speaks librga directly, since the RGA filters reject these frames as described above.
• (feature) Every ffmpeg-rk invocation writes mpp_platform: client N driver is not ready! to standard error, once per vendor service client MPP looks for and does not find on a mainline kernel. It is harmless and appears even for ffmpeg -version, but it is captured by anything that logs the process’s stderr.
• (feature) This feature adds 25 packages and roughly 305 MiB to the installed system, measured against the RK3588 media-accel package set on forky. Two thirds of it is not the driver: mesa-vulkan-drivers is 144 MiB, and it depends on libllvm21 (127 MiB) and through it libz3-4 (25 MiB), which are there for the lvp software rasterizer Debian ships in the same package rather than for PanVk. Debian offers no per-driver package — that one carries the AMD, Intel, NVIDIA, virtio and software back ends as well as the Mali one this hardware uses — so an image that wants PanVk takes all of them and the LLVM they imply.
• (feature) Vulkan conformance is a per-GPU fact, not a per-feature one. PanVk is conformant on the RK3588’s Mali-G610 and is not conformant on the RK3576’s Mali-G52; the same package installs on both and only the first carries a conformance claim.
• (feature) A software Vulkan device (lvp, llvmpipe) enumerates alongside the hardware one. Anything that leaves device selection to the default can bind it and run GPU work on the CPU, which is slower than not using this feature at all and does not announce itself.

turing-rk1/media-accel-trixie

• (feature) Scaling inside a hardware transcode runs on the CPU. The RGA filters (scale_rkrga, vpp_rkrga, overlay_rkrga) accept only frames carrying an RKMPP hardware context, and the mainline V4L2 decoder hands out plain DRM PRIME frames, which they reject; hwmap does not bridge the two either. A decode/scale/encode chain therefore downloads frames to system memory, scales them with swscale, and re-uploads them to the encoder. RGA still accelerates a scale fed from software-decoded frames, and the 2D engine itself works.
• (feature) The h264_rkmpp, hevc_rkmpp, vp8_rkmpp and vp9_rkmpp decoders are compiled in but fail to open: MPP finds no decode client on a mainline kernel, where rkvdec is a V4L2 stateless driver rather than an MPP service. Hardware decode is reached with -hwaccel v4l2request. The matching *_rkmpp encoders do work.
• (feature) 10-bit content decodes in hardware, but a 10-bit transcode still converts on the CPU. The V4L2 decoder emits NV12 for 8-bit and NV15 — 10-bit packed 4:2:0 — for 10-bit, and no filter or encoder in this build imports NV15. The decoder cannot be asked for P010 instead; the hardware writes NV15 natively. RGA converts NV15 to P010, but only for a program that speaks librga directly, since the RGA filters reject these frames as described above.
• (feature) Every ffmpeg-rk invocation writes mpp_platform: client N driver is not ready! to standard error, once per vendor service client MPP looks for and does not find on a mainline kernel. It is harmless and appears even for ffmpeg -version, but it is captured by anything that logs the process’s stderr.
• (feature) This feature adds 25 packages and roughly 305 MiB to the installed system, measured against the RK3588 media-accel package set on forky. Two thirds of it is not the driver: mesa-vulkan-drivers is 144 MiB, and it depends on libllvm21 (127 MiB) and through it libz3-4 (25 MiB), which are there for the lvp software rasterizer Debian ships in the same package rather than for PanVk. Debian offers no per-driver package — that one carries the AMD, Intel, NVIDIA, virtio and software back ends as well as the Mali one this hardware uses — so an image that wants PanVk takes all of them and the LLVM they imply.
• (feature) Vulkan conformance is a per-GPU fact, not a per-feature one. PanVk is conformant on the RK3588’s Mali-G610 and is not conformant on the RK3576’s Mali-G52; the same package installs on both and only the first carries a conformance claim.
• (feature) A software Vulkan device (lvp, llvmpipe) enumerates alongside the hardware one. Anything that leaves device selection to the default can bind it and run GPU work on the CPU, which is slower than not using this feature at all and does not announce itself.