I'm considering getting a cheap Radxa Rock 5B board, as with 8Gb, it would cost me about 120€/$, which is fine and less than a N100 or similar, while having similar performance and transcoding capabilities.

But I'm seeing this SBCs have a lot of "problems" with their software. Like for example, only shipping the drivers and support for their hardware accelaration (RK3588, with RKMPP) on the vendor kernel, which is still the ancient 6.1.115 (2022-2023)

The only modern images for it are from Dietpi or Armbian (both of them mantained by volunteers, which in itself adds to worries about "trustability" of the system), and even if they are 6.8 Linux kernel, you lose the ability to have HW acceleration and transcoding.

I love the idea behind this systems, being capable of running fanless, for cheap, small space and so on, but I wonder if they are just not worth the effort to get them?

For example, I fear getting this SBC, having to use the vendor forked kernel (6.1.115) which is already 3 years old and with multiple CVEs reported (even copy fail!), and being stuck there forever.

What do you think? Anybody running mainline at least on this devices and getting good transcoding / GPU / NPU support? Or are the users just hostages to Rockchip desires, and them just doing the bare minimum effort?

Orange Pi 5 Plus (RK3588) as a fully open-source daily driver — mainline Ubuntu 26.04, EDK2 UEFI, dual 4K HDR10+, HW decode for AV1/H.264/H.265/VP9, Vulkan 1.4 + Zink + OpenCL on Mali, NPU — all off a 64 GB SD card

TL;DR: No vendor BSP, no 5.10/6.1 legacy kernel, no MPP blobs, no libmali. A mainline-first RK3588 build that boots through real UEFI, drives two 4K HDR10+ displays, hardware-decodes all four major codecs (including VP9, which mainline still doesn't ship — solved out-of-tree + DKMS), plays HW video in a browser, runs conformant Vulkan 1.4, OpenCL 3.0, and Zink on the Mali-G610 — and Zink turns out to be 2× faster than native GL on the heaviest glmark2 scene. Every number below comes from original logs run on this exact box. Long post — grab a coffee.

Why this build is interesting (30-second explainer)

Rockchip boards traditionally get their video/GPU powers from the vendor BSP: an old kernel, the MPP userspace, /dev/mpp_service, and the closed libmali blob. It works, but you're frozen in time. The mainline way is different: V4L2 stateless decoding (kernel programs decoder registers, userspace parses bitstreams — GStreamer/browsers plug straight in), Panfrost/PanVK for graphics, and everything upstream, auditable and upgradeable. This build is 100% on that path. The one big missing piece on mainline was VP9 decode — that's the centerpiece of this post.

Hardware & boot chain

• Board: Orange Pi 5 Plus — RK3588 (4× Cortex-A76 + 4× Cortex-A55), 16 GB LPDDR4X
• Storage: 64 GB SD card. The entire OS runs off it. (Yes. Really. It's fine.)
• Boot: EDK2 UEFI in SPI NOR → GRUB → mainline kernel. The board behaves like a normal UEFI PC — boot menu, update-grub, standard workflows. No U-Boot scripting.
• Displays: both HDMI 2.1 ports driving 4K HDR10+ (daily pairing: one at 144 Hz, second up to 144 Hz depending on monitor; 144+144 and 144+30 both validated)
• Connectivity: Wi-Fi 7 (320 MHz, 2×2) + Bluetooth 5.4 — Qualcomm WCN7850 on the M.2 slot (ath12k)
• Extra silicon in use: HDMI input (Synopsys hdmirx as a V4L2 capture device), RGA 2D engine, NPU

Software stack

Layer	What
OS	Ubuntu 26.04 LTS ARM, KDE Plasma on Wayland
Kernel	Custom 7.0.0-rk3588-hdr+ — Collabora-based mainline tree + HDMI/HDR patches + merged OC device tree, self-packaged .debs
GPU (GL)	Panfrost, OpenGL ES 3.1 — Mesa 26.2.0-devel (git-c4a1d9583c)
GPU (Vulkan)	PanVK, Vulkan 1.4.352, conformanceVersion 1.4.1.2 (yes, conformant open-source Vulkan on Mali)
GL-on-Vulkan	Zink (and it has a surprise below)
OpenCL	rusticl, OpenCL 3.0 on the Mali-G610
NPU	Mainline rocket Gallium driver + Teflon TFLite delegate (built into my Mesa)
Video decode	Mainline V4L2 stateless + GStreamer v4l2codecs
VP9 decode	Out-of-tree VDPU381 backend packaged as DKMS (below)
Browser	ungoogled-chromium 147 custom build with V4L2 stateless HW decode

The "default OC" I daily-drive — and why exactly these values

CPU little (4× A55): 2.2 GHz @ 1.15 V
CPU big   (4× A76): 2.6 GHz @ 1.20 V
GPU (Mali-G610):    1.2 GHz @ 1.15 V
RAM (LPDDR4X):      2750–3200 MHz, stock voltage & timings

My rule: an overclock only counts if the whole stack stays clean under it. Every benchmark and every decode test in this post ran at these clocks with zero decoder timeouts and zero GPU faults — with one deliberate exception I'm keeping in the post because it's instructive: the glmark2 [terrain] scene, which exposes a native-GL driver edge at these clocks (full story in the Zink section — it's worth it). Pushing clocks further is possible for suicide runs; these are the daily values.

(Heads-up for GPU clock chasers: on Mesa/firmware combos newer than ~2026-04-20 there are reports of panthor MCU fatal panics around 1.19 GHz. My Mesa build is stable at 1.2 GHz; if you ever see that line under GPU load, drop the GPU OC first.)

[FILL IN: cooling / temps under load / power draw]

Proof: all four codecs decoded in hardware (output from this box)

$ v4l2-ctl --list-devices  +  --list-formats-out (per device)

rkvdec (VDPU381):   [0] 'S265' HEVC · [1] 'S264' H.264 · [2] 'VP9F' VP9   ← VP9 = the DKMS module
AV1 decoder:        [0] 'AV1F' AV1
hantro (G1):        [0] 'S264' H.264 · [1] 'MG2S' MPEG-2 · [2] 'VP8F' VP8
VEPU121 (encoder):  raw NV12/YUV in → H.264 out
rockchip-rga:       2D blit / colorspace conversion
snps_hdmirx:        HDMI capture input (V4L2)

$ gst-inspect-1.0 | grep v4l2sl
v4l2slav1dec · v4l2slh264dec · v4l2slh265dec · v4l2slvp9dec

Three independent decode engines, all plain V4L2 stateless devices, all driven by the same GStreamer plugin family. (Tip: /dev/videoN numbers shuffle between module reloads — match devices by driver name, never hardcode.)

The VP9 story (the part mainline doesn't give you)

Mainline kernel 7.0 ships H.264 + HEVC for the RK3588's VDPU381 decoder (Collabora's work). VP9 is not upstream yet. The working backend exists out-of-tree — written by D.V.A.B. Sarma on Collabora/Rockchip groundwork, integrated in the beryllium-org 7.0.y tree, adapted to mainline by the dongioia/rock5bplus project.

My integration: full rkvdec driver directory (VP9 wired in), built out-of-tree against my installed kernel headers, packaged as DKMS. Why DKMS matters: the module lands in /updates/dkms/, which depmod prioritizes — the stock kernel module stays untouched (revert = one command), and every future kernel (re)install rebuilds VP9 automatically. Verified across reboots and kernel reinstalls.

Measured decode performance (GStreamer fpsdisplaysink → fakesink, decode-only):

Test	Result
VP9 Profile 0, 1080p30	392 fps, 0 dropped (~13× realtime)
VP9 Profile 0, 4K30	~94 fps avg, 0 dropped (~3× realtime)
VP9 Profile 3 (4:4:4 12-bit — not in silicon)	~10 fps with clean per-frame timeouts, no oops — graceful failure (negative test)
dmesg across all runs	clean

Honest limits: Profile 0 (8-bit SDR) only — Profile 2 (10-bit HDR) isn't reported by this backend yet; HDR streams should use AV1 (HW-decoded anyway). And VP9 encode does not exist in RK3588 silicon, period — the encoder block does H.264/H.265/VP8/MJPEG. For scale: my 4× A76 encode the same 4K clip at ~20 fps that the VDPU381 decodes at 94.

GPU deep-dive: Panfrost, PanVK, Zink, OpenCL — all numbers from original logs

Vulkan identity (vulkaninfo)

deviceName         = Mali-G610 MC4
driverName         = panvk
apiVersion         = 1.4.352
driverInfo         = Mesa 26.2.0-devel (git-c4a1d9583c)
conformanceVersion = 1.4.1.2

A conformant Vulkan 1.4 implementation on a Mali GPU, fully open source. Two years ago this sentence didn't exist.

⭐ glmark2 — full suite, native Panfrost vs Zink, scene by scene

Same box, same clocks, same Mesa — two driver paths. Native = Panfrost OpenGL ES 3.1. Zink = OpenGL running on top of PanVK Vulkan 1.4. Full runs, every scene.

Native overall scores: glmark2-es2 = 4200 · glmark2-es2-wayland = 4000 (two separate benchmarks). Table below uses the es2-wayland run against the matching Zink es2-wayland run:

Scene	Native (FPS)	Zink (FPS)	Zink vs native
build (vbo)	5808	3456	−40%
texture (linear)	6920	3485	−50%
shading (phong)	4075	3227	−21%
bump (normals)	6953	3480	−50%
effect2d (blur 5×5)	2804	2283	−19%
pulsar	6583	3380	−49%
desktop (blur)	842	1331	+58%
desktop (shadow)	3357	2365	−30%
buffer (map)	566	642	+13%
buffer (subdata)	546	951	+74%
buffer (interleave)	696	843	+21%
ideas	2278	1974	−13%
jellyfish	3977	2681	−33%
terrain	~120 †	182–187	≈ +52%
shadow	2770	2683	−3%
refract	334	514	+54%
conditionals (avg of 3)	~5720	~3448	−40%
glmark2 Score	4200	2716

† terrain: my full-suite native runs trip a Mesa-devel batch-submit edge on this one scene at my OC (it logs a degraded ~88 fps while recovering), so I'm citing my typical isolated native result (~120 fps) here instead — a clean isolated log to lock the exact number is pending. Zink completed terrain cleanly in every run (182 fps ES2 context / 187 fps desktop-GL context; scores 2716 / 2711 — fully consistent). The ~+52% Zink advantage lines up with its wins on refract (+54%) and desktop-blur (+58%), so it's the representative figure. Native scores: glmark2-es2 → 4200, glmark2-es2-wayland → 4000 (two separate benchmarks, not two runs of one).

The pattern is the story: native GLES wins every light scene on raw throughput — but Zink wins every heavy one: buffer-subdata +74%, desktop-blur +58%, refract +54%, terrain ≈ +52%, buffer-interleave +21%. Wherever the workload gets complex (heavy geometry, blur passes, buffer streaming, refraction), the Vulkan-backed path is both faster and more robust. On modern Mali in 2026, GL-on-Vulkan is not a compatibility fallback — for complex workloads it's the fast path. Same silicon, same clocks, same Mesa; different driver architecture, different outcome.

vkmark — PanVK native Vulkan

Score: 5467 (runs: 5408 / 5467). Highlights:

Scene	FPS
cube	7577
clear	7302
desktop	5936
vertex (device-local)	5888
texture (aniso 16×)	5882
shading (phong)	4471

OpenCL on Mali — clinfo + clpeak (yes, really)

clinfo: platform rusticl, device Mali-G610 MC4 (Panfrost), OpenCL 3.0, 4 CUs, 11.09 GiB visible global memory (unified with system RAM). GL/Vulkan come from my custom Mesa 26.2-devel build; the OpenCL ICD is Ubuntu's Mesa rusticl package. (clinfo reports the 800 MHz base OPP; devfreq scales under load.)

clpeak:

Metric	Result
Global memory bandwidth	31.8 GB/s (float)
Single-precision compute	572 GFLOPS (float4)
Half-precision compute	1057 GFLOPS (half4) — >1 TFLOPS FP16 on an open-source stack
Integer compute	148 GIOPS
Transfer (write / read)	10.3 / 1.6 GB/s
Kernel launch latency	109.6 µs

The Mesa build behind all of this

Mesa 26.2.0-devel (git-c4a1d9583c), built from source, tuned for this exact CPU:

meson setup build \
  -Dprefix=/usr/local \
  -Dbuildtype=release \
  -Dgallium-drivers=panfrost,zink,rocket \
  -Dvulkan-drivers=panfrost \
  -Dplatforms=x11,wayland \
  -Dteflon=true \
  -Dglx=dri -Dopengl=true -Dgles1=enabled -Dgles2=enabled \
  -Degl=enabled -Dgbm=enabled \
  -Dllvm=enabled -Dshared-llvm=enabled \
  -Dvideo-codecs=all \
  -Doptimization=3 -Db_ndebug=true -Dshader-cache=enabled \
  -Dc_args='-O3 -mcpu=cortex-a76.cortex-a55 -mtune=cortex-a76.cortex-a55' \
  -Dcpp_args='-O3 -mcpu=cortex-a76.cortex-a55 -mtune=cortex-a76.cortex-a55' \
  -Dc_link_args='-Wl,-O1' -Dcpp_link_args='-Wl,-O1'

Note rocket in gallium-drivers and teflon=true — that's the mainline NPU path: Mesa's rocket driver for the Rockchip NPU with the Teflon TensorFlow Lite delegate. [FILL IN: NPU inference benchmark]

Hardware video in the browser

Stock Chromium/Firefox on ARM Linux won't touch the V4L2 stateless path (Firefox is VA-API-only → on Rockchip that means the BSP/MPP stack → dead end on mainline). The working route is a custom ungoogled-chromium 147 build (dongioia) with V4L2 stateless decode patched in.

Verified on this box (chrome://gpu + chrome://media-internals):

• Video Decode: Hardware accelerated
• kVideoDecoderName: V4L2VideoDecoder · kIsPlatformVideoDecoder: true
• Enumerated HW profiles: h264, hevc main/main10, vp9 profile0, vp8

[SCREENSHOTS: chrome://gpu + media-internals — incoming]

Two board-specific traps, both solved and documented so you don't repeat them:

1. Mali Valhall Skia YUV shader bug — Chromium's Ganesh-GL NV12 two-plane (R8/RG8) shader miscompiles on Panfrost → tile garbage on VP9. Fix: the build's CHROMIUM_RK3588_FORCE_LIBYUV=1 env (CPU NV12→RGBA conversion). Clean picture, at a CPU cost.
2. Never enable Vulkan in the browser here. Chromium tells you itself: '--ozone-platform=wayland' is not compatible with Vulkan. PanVK is for vkmark and games; the browser stays on ANGLE/GLES. (Ironic given the Zink story above? Welcome to 2026.)

Real-world playback at my clocks: 1080p60 & 1440p60 smooth · 4K30 smooth · 4K60 drops (the LibYUV CPU conversion is the ceiling — the decoder itself does 4K at 94 fps). For 4K60 I use gst-play/Clapper on the pure HW path. Also tested an experimental "zero-copy" 148 build: no measurable gain on my box, so 147 stays production.

CHROMIUM_RK3588_FORCE_LIBYUV=1 chromium \
  --ozone-platform=wayland \
  --enable-features=AcceleratedVideoDecodeLinuxV4L2,AcceleratedVideoDecodeLinuxZeroCopyGL,WaylandWindowDecorations \
  --disable-features=UseChromeOSDirectVideoDecoder \
  --use-gl=angle --use-angle=gles

What does NOT work (so you don't waste a weekend)

• VP9 encode — not in the silicon. Use HW H.265 encode or libvpx on CPU.
• VP9 Profile 2 (10-bit HDR) decode — not in this backend yet (watch chewitt/LibreELEC & Collabora).
• 4K60 video inside the browser — CPU-bound by the LibYUV workaround; use a GStreamer player.
• Vulkan compositing in Chromium on Wayland — incompatible; GLES only.
• glmark2 [terrain] on native Panfrost GL — trips a Mesa-devel batch-submit edge at my clocks (see the asterisk in the comparison table). Zink runs the same scene clean at 182–187 fps — the recommended path for that class of workload anyway.
• MPP / /dev/mpp_service — BSP-only by design; this build is mainline V4L2 instead.
• rkvdec second core — mainline ignores it for now ("missing multi-core support"); one core is already this fast.
• Widevine DRM in the ungoogled build — Netflix & co. need a stock browser.

Reproducibility — the fresh-install kit

The point of the whole project: everything lands on a fresh Ubuntu 26.04 ARM from a small kit, in stages:

deps → kernel (.deb ×4) → GRUB + OC DTB → VP9 (DKMS) → cold boot
     → Mesa → NPU env → browser → verification

Kit: 4 kernel .debs · OC + stock device trees · staged master setup script · enable-vp9-opi5plus.sh (DKMS install/status/remove, dynamic device discovery) · install-browser-hw-opi5plus.sh (sha256-verified, validated flags baked in) · the Mesa build above · diagnostics script.

Credits — this stands on a lot of shoulders

• D.V.A.B. Sarma — a special, personal, huge thank-you. 🙏 The VP9 VDPU381 backend at the heart of this post is his code, and he personally encouraged me to run his VP9 driver on top of my Collabora-based stack. Every VP9 number above exists because of him.
• Collabora (Detlev Casanova, Benjamin Gaignard & team) — mainline VDPU381 H.264/HEVC, the dw_hdmi_qp HDMI/HDR display work, and the rockchip-3588 kernel tree this build stands on.
• dongioia / rock5bplus-rkvdec2 — the mainline VP9 adaptation, the Chromium V4L2 builds, and the best public analysis of the RK3588 browser video pipeline.
• beryllium-org — the 7.0.y integration tree.
• Mesa Panfrost / PanVK / Zink / rusticl / rocket developers and GStreamer v4l2codecs developers — the reason "conformant open-source Vulkan on Mali" and "OpenCL on Mali without blobs" are sentences now.

How this was built — pair-engineering with AI (full transparency)

I started learning programming only a few months ago. This entire project was built in pair-engineering sessions with Anthropic's Claude — Claude Opus 4.8 (via Claude Code, doing the agentic heavy lifting) and Claude Fable 5 (chat), on the Max plan. Claude did the research across kernel trees and mailing lists, made the integration calls (which VP9 tree, why DKMS over a raw module, MMAP vs DMABUF), wrote the install scripts, and debugged everything from a stale-object kernel crash to a Mali shader bug inside Chromium — while I did all the hardware-side work: flashing, building, testing, breaking things and un-breaking them, and validating every number on real silicon. The upstream developers above wrote the actual driver code — but turning it into this system was a human+AI job, and honestly, most of the integration-engineering credit goes to Claude. Take that as you will — the logs are original and the dmesg is clean.

Appendix — reproduce my numbers

# VP9 present on the decoder?
v4l2-ctl -d /dev/videoN --list-formats-out          # expect 'VP9F' next to S264/S265

# VP9 decode benchmark (no display):
gst-launch-1.0 filesrc location=clip.webm ! matroskademux ! vp9parse ! \
  v4l2slvp9dec ! fpsdisplaysink video-sink=fakesink text-overlay=false sync=false

# make a Profile-0 test clip:
ffmpeg -f lavfi -i testsrc2=size=3840x2160:rate=30 -t 10 -c:v libvpx-vp9 \
  -pix_fmt yuv420p -b:v 12M -deadline realtime -cpu-used 8 -row-mt 1 4k-vp9-p0.webm

# watch with HW decode:
gst-play-1.0 4k-vp9-p0.webm        # or: clapper

# GPU / compute:
glmark2-es2-wayland                                       # native Panfrost
MESA_LOADER_DRIVER_OVERRIDE=zink glmark2-es2-wayland      # the Zink run
vkmark
vulkaninfo | grep -E 'deviceName|apiVersion|conformance'
clinfo | head -40
clpeak

# browser check: chrome://media-internals → kVideoDecoderName: V4L2VideoDecoder
# health check after any test:
sudo dmesg | grep -iE 'rkvdec|timeout|panthor'      # should be empty

Questions welcome — happy to share scripts, logs, or run more benchmarks in the comments.

I've recently bought a Radxa 12L NIO 16GB RAM+512GB UFS model because the price was really attractive.

The issue: I've successfully flashed any of the images supported by this board (official Ubuntu, armbian, collabora Debian ones..), the "only" issue I have is that none of them shows anything, on usb-c or HDMI.

The thing I've noticed is that for Armbian and Collabora, the power LED stays green, while for the official Ubuntu Image, it starts with green and then ends up being cyan.

I have pressed the power button for 1/2 seconds too, but as said, no video output is possible, so I can't really use the board later on.

I don't have a UART Debugger, so I can't read what's happening as well.

Has anyone faced this issue? All the images I.have used are for UFS, even if the genio-flash tool shows "mmc0" during the flashing operation.

I found a fork of Batocera. https://github.com/suckbluefrog/Batocera-Custom-Arm-Builds

Use this at your own risk, as this is not from the Batocera team.

I tested on a Radxa Dragon Q6A (Qualcomm Snapdragon QCS6490). It comes with a couple of apps, like browsers (Brave and Firefox), I installed Waydroid, but I didn't really do anything with it.

I got Lugaru HD working with PortMaster, God of War with ARMSX2, Super Stardust HD with RPCS3, Ascendant with Lutris and Half-Life 2 with Steam.

Here is my video review: https://youtu.be/lvwGHYeOwwE

Hello, all!

I'm seriously considering replacing my home network's gateway with a Banana Pi BPI-RV2. It combines 1 x 2.5 Gbps Ethernet "WAN" interface with 5 x 1 Gbps interfaces; the memory is unimpressive at 512 MB, but all in all, I believe it will meet my needs.

Now, I'd like to add a 5G modem. As the options for USB on this device are limited to USB 2.0, the modem will have to be m.2 form factor. I'd like to eventually purchase a cheap data plan and use the 5G modem as back-up. Kind of a modern day "dial demand routing," (DDR) if you will. Has anyone done this with Linux and a 5G m.2 modem? What was your experience? Which modem do you recommend? How stable are the drivers? How fast is your throughput?

Thanks!

I want to make custom Captive portal, Host VPN and DNS and other networking works, need some suggestions of low price 4GB-8GB SBC with 2 gigabit Ethernet port. Better if it has NVMe socket or suggest module. Thank you.

As title suggests I’m desperately looking to source a 16GB LattePanda IOTA for a project, however DFRobot themselves - LattePanda’s parent company and primary global retailer, is out of stock due to CPU shortages.

I was really hoping someone might have a source to purchase one? Or maybe if someone is looking to sell theirs?

Thanks in advance for any help or advice.

Hi everyone,

I'm looking for an alternative to the Raspberry Pi Zero 2W since they are unobtainium. I'm looking for something with the same form factor that also has a CSI camera port. I'll be streaming from MediaMTX a 1080p 50 FPS stream from a camera module v3 so I need it to have a CPU that will keep up. Any suggestions?

Thanks

​

I genuinely want to know whether anyone has successfully used the hardware accelerators on the Dragon Q6A for LLM inference.

At this point I've spent months trying to make this board do what it was advertised to do.

---

Phase 1: Hexagon NPU

The original plan was to use the Qualcomm Hexagon NPU through QNN / AI Engine.

After burning an embarrassing number of hours (and probably enough AI tokens to train a large dinosaur 🦖), I never managed to get a practical end-to-end LLM pipeline working.

Eventually the Hexagon became...

HexaGONE. 😅

So I moved on.

---

Phase 2: Vulkan GPU

Next I tried llama.cpp with Vulkan.

Current setup

- Radxa Dragon Q6A (QCS6490)

- Armbian 24.04

- Linux 6.18.2

- Mesa Turnip 25.2.8

- Latest "llama.cpp" built from source with "GGML_VULKAN=ON"

- Adreno 643 detected correctly

GPU detection works:

Vulkan0: Turnip Adreno (TM) 643

8689 MiB VRAM

"llama.cpp --list-devices" works correctly.

CPU inference works perfectly.

However, the moment Vulkan actually starts doing inference, one of two things happens.

Case 1: GPU crashes

vk::DeviceLostError

vk::Device::waitForFences: ErrorDeviceLost

or

vk::Queue::submit: ErrorDeviceLost

---

Case 2: Complete nonsense output

The model starts generating...

Tobacco...

Jupiter...

TPM...

😂

Chinese...

Arabic...

Random Unicode...

...which honestly feels like the GPU is having a philosophical crisis.

---

Things I've already tried

- Fresh "llama.cpp" build

- Latest upstream source

- CPU-only inference (works)

- GPU offload from 1 layer to all layers

- Flash Attention ON/OFF

- Different thread counts

- Different batch sizes

- Different microbatch sizes

- Different context lengths

- KV offload ON/OFF

- OP offload ON/OFF

- Multiple GGUF models

- Killed every stale GPU process

- Verified Vulkan installation

- Verified GPU detection

- Plenty of free GPU memory

Nothing consistently works.

---

NPU status

The original goal wasn't even Vulkan.

It was to get the Hexagon DSP / NPU running for LLM inference.

Over the past few months I've tried (or attempted to integrate):

- Qualcomm AI Engine Direct

- Qualcomm QNN SDK

- QAIRT

- Qualcomm AI Hub models

- QAI Hub exported models

- x86 Linux compilation and cross-compilation workflows

- ONNX → QNN conversion

- HuggingFace exports

- Qualcomm sample applications

- FastRPC

- Hexagon runtime setup

- Custom Python wrappers

- "llama.cpp" experiments

- Multiple model families (Gemma, Llama, Qwen and others)

- Multiple quantizations and export formats

I also burned an unhealthy amount of time using multiple AI coding agents (Gemini, GLM, ChatGPT, Claude, etc.) trying different approaches.

Between myself and various AI coding agents, we've probably burned billions of inference tokens trying to make this board cooperate.

The result?

Not a single stable end-to-end LLM pipeline on the Hexagon NPU.

Eventually...

Hexagon became HexaGONE. 😅

So I abandoned the NPU and switched to Vulkan...

...which is now throwing "vk::DeviceLostError".

---

Current status

- ❌ Hexagon NPU doesn't work

- ❌ Vulkan GPU crashes or produces garbage

- ✅ CPU works... at a blazing 2-3 tokens/sec 🔥

---

My question

Has anyone actually managed to get reliable LLM inference running on the Dragon Q6A using:

- Vulkan

- Qualcomm QNN / Hexagon

- Any other GPU/NPU backend

If yes, could you please share:

- Kernel version

- Mesa version

- Driver stack

- "llama.cpp" commit

- Model used

- Exact command line

At this point I'm genuinely trying to answer a simple question:

Has anyone actually achieved hardware-accelerated LLM inference on the Dragon Q6A?

I don't mean demos.

I don't mean benchmark screenshots.

I mean a real GGUF model generating text reliably using either:

- Hexagon NPU

- Vulkan GPU

- Or a QAIRT compiled model running on the genie?

If you've actually managed to get either the Hexagon NPU or Vulkan GPU working for real-world LLM inference on this board, I'd genuinely love to compare notes.

Because after months of debugging, I'm honestly starting to wonder whether this board's AI acceleration is production-ready... or whether everyone is quietly fighting the same dragons.

Any guidance from Radxa, Qualcomm, Mesa Turnip developers, or fellow Dragon Q6A owners would be hugely appreciated.

Right now the only things accelerating reliably are my blood pressure, my hair loss, and my appreciation for CPUs that simply do their job.

i really like the raspberry pi boards, atm my homelab is 3 different raspberry pi boards but when i look online, im shocked by the prices, even the prices of the raspi 3, which is nearly 10 yrs old at this point?

so if i needed a cheap board, with 1+ gb of ram, what do we buy now?

Today I came across a UTCTech video talking about "DIY Phone". Linux based, USB, HDMI, and the such. But it became clear this thing is meant to be a tinkering device so you can have a pocket PC with the CM5.

But it got me thinking about an actual SBC/DIY phone. With Mobile data, Phone and Text, and the works. To try and get off Android and IOS and AI.

But a search through YouTube made it abundantly clear we are not there yet. Maybe its because theres protocols you have to do in order to get a sim card to work on a device that is only approved by the Telecom Companies or whatever.

But I have no sense and this thought project became a day dream. Thinking of cool features, like the fact that the CM5 has PCIe Gen 3 which CAN allow for an eGPU. Wouldn't it be cool to have a phone that you can take to work, use it like a normal phone, and then go home, plop that into a dock and use it to play PS4 era steam games and emulation, since the CM5 can do emulation but suffers due to its iGPU?

I know the DIY crowd, the Linux crowd, and rhe SBC crowd would jump at the chance to make this a possibility, but I lack the knowledge, vocabulary, and experience to seperate fantasy from reality in regards to this type of tech.

Kinda like CEOs thinking AI can fully replace all workers, only to find out its way to expensive.

But the SBC crowd doesnt care about costs as the main reason to do things. Its driven by "Fuck it, we ball".

So, bring me down to earth. I know SBCs and FPGAs have allowed the retro handheld emulation market to boom. So why not basic phones? You know, in like 30 years?

Hi, there is a TaoBao device boasting wii-like games. At 10x the price less than a pi. How does a small & cheap device have more power than raspberry pi? And can I access the device (hijack) to create my own games (using AI)? Or can I build my own using cheaper components from scratch?

Hi everyone,

I’m an Electrical Engineering undergraduate student working on my final year senior capstone project. We are building an autonomous solar farm inspection robot, and I’m heavily considering the Radxa Dragon q6A (12GB RAM, Qualcomm QCS6490) primarily for its 12 TOPS NPU and high memory bandwidth.

Since we have a strict graduation deadline, we need a stable hardware foundation. I’d love to get your insights on whether this board has underlying software/hardware quirks, especially regarding:

1. Dual-Camera & USB Stack Stability: The robot will process dual streams in real-time—one RGB USB camera and one Uni-T UTi120 Mobile thermal camera (running a custom C++ port of libusb). Does the Qualcomm Linux kernel handle heavy, concurrent USB bulk transfers well without randomly dropping connections?

2. Qualcomm QNN / SNPE SDK Learning Curve: We need to quantize and deploy custom Object Detection models (YOLOv8-nano variant) to the 12 TOPS NPU. How painful is the current QNN C++ API workflow on Radxa’s official Ubuntu 22.04 headless server? Are there major kernel bugs that could halt our project progress?

3. M.2 2230 NVMe Thermals: We'll be doing heavy async logging/backups directly to an M.2 2230 SSD while operating outdoors. Does the board overheat quickly under combined NPU + SSD write workloads?

4. UART / CAN Bus Reliability: For GPS parsing and sending real-time actuation commands to a lower-level motor controller (STM32).

Given that this is a time-sensitive graduation project, would we be safer sticking to the tried-and-tested Rockchip RK3588 ecosystem (like the Rock 5B+/5T) where community support is broader, or is the Dragon q6A ready for a pure C++ production pipeline now?

Appreciate any insights, benchmark experiences, or warnings!

Hi all,

I am a student who wish to put SLAM capability on my drone. I am looking for an SBC powerful enough to do this (a good CPU and at least 4GB RAM), fairly light weight while also being not a pain to work with and... is available in 2026. But so far, my luck has ran dry:

Option 1: Radxa Zero 3W. Fantastic power in small form factor, camera ecosystem mature. But not a single vendor has the 4GB / 8GB version in stock anymore.

Option 2: Radxa 5 series. Equally powerful and mature, but a bit big on the form factor - i'll have to use my 10 inch quadcopter which scares people. Also out of stock

Option 3: Pi 4B. So far the best bet, still means i have to use the 10 inch quad, but at least i already have one and camera is plug and play. CPU slightly on the weaker side.

Option 4: Radxa A7Z. Small form factor with fantastic compute power on paper, but i haven't been able to get a single camera frame out of my A7A which uses the exact same chip as the A7Z due to ISP firmware mismatch, so my hope is not high.

Option 5: Pi 5. It doesnt have hardware encoder, so video stream in real time sucks CPU resources hard. And it is still the big form factor.

Seems like the entire reason the SBC market is stagnating is the entire data center hoarding all the RAM chips.

If anyone has a suggestion, i would love to hear it.

Thanks