Non-functional NPU Support on Dragon Q6A (QCS6490) under Ubuntu 24.04 (Noble)

Dragon Series
1

As an Electronics Engineer and Quality Surveillance (QS) professional, I feel obligated to warn the community about the current state of the Radxa Dragon Q6A.

Radxa markets this board heavily on its 12 TOPS NPU (Qualcomm QCS6490). However, if you are a Python developer or working on AI projects (Whisper, Vision, etc.), this NPU is currently “dead silicon.”

The Reality Check:

  • No Python Support for Ubuntu 24.04 (Noble): There are zero functional official .whl files for onnxruntime-qnn targeting Python 3.12.

  • Broken Toolchain: The Qualcomm QNN libraries provided in the official images are not integrated into the Python environment. Even with manual linking (LD_LIBRARY_PATH), the standard ONNX Runtime does not recognize the QNNExecutionProvider because it hasn’t been compiled with Qualcomm’s proprietary hooks.

  • “Binary Blobs” Everywhere: You are stuck with closed-source blobs that Radxa hasn’t bothered to bridge for the most common development language (Python).

Conclusion: I bought this board for 130 EUR specifically for the NPU-accelerated AI performance. What I got is a high-spec CPU with a completely unusable NPU for any standard AI framework.

Radxa Team: Stop selling hardware based on features that are software-locked or unsupported in your “official” releases. Professional users demand stable Python wheels and proper QNN integration, not just “specs on a PDF.”

#Radxa #DragonQ6A #QCS6490 #SBC #NPU #Qualcomm #Fail

2

I don’t quite understand what you meant here. We provide NPU documentations, and one of the validation step is using Python.

3

I have already reviewed the ‘NPU Quick Validation’ guide. The issue is not with the inference script itself, but with the broken OS/Kernel architecture in the official r2 OS image that prevents the script from accessing the hardware. Here is the exact technical summary of the problem:

Missing Hardware Nodes (/dev/fastrpc*): The libQnnHtp.so backend fails because the fastrpc nodes are never created in the OS. Checking dmesg clearly shows ‘Direct firmware load failed with error -2’. The OS fails to initialize the NPU because the firmware is missing from initramfs and the pd-mapper daemon is broken/absent in your official image.

Dependency Hell: As other users have also reported, attempting to manually install or fix the fastrpc package completely breaks the OS dependency tree.

NPU vs. VPU Conflict (The Dealbreaker): Even if we force fastrpc to work, it fundamentally conflicts with qcom-fastrpc1. This means the board physically cannot run AI Inferencing (NPU) and Hardware Video Acceleration (VPU) at the same time.

The validation guide assumes a perfectly working OS environment, which the current official release simply does not provide.

4

@Morgan please take a look.

5

Hi @yarkinsen,

If you would like to develop with the NPU using Python, you can use QAI App Builder. There are also several demo examples available here for reference:
QAI App Builder Demo

If you prefer to use ONNX Runtime with the QNN Execution Provider, please refer to the following documentation:
QNN ONNX Runtime Execution Provider

We have already built the Python 3.12 wheel package, and you can install it directly via pip3.

Best regards,
Morgan

6

@Morgan @RadxaYuntian

I am new to the Radxa community; set up my Radxa Q6A with these:

OS & Kernel Details

  • OS: Armbian 26.2.4 (Ubuntu 24.04 LTS “Noble Numbat”)
  • Kernel: Linux 6.18.2-current-qcs6490
  • Architecture: aarch64 (ARM64)

I am attempting to use QNN/Hexagon NPU acceleration with llama.cpp, but NPU initialization fails with DMA allocation related errors.

On the newer Armbian Ubuntu 24 setup with the 6.18 upstream-oriented kernel, QNN/NPU inference fails.

My understanding is that the current QNN SDK / firmware blobs may still depend on Qualcomm BSP-specific kernel behavior or patches that are not yet fully available in the newer upstream-oriented kernels.

I wanted to ask:

  1. Are there any planned official kernel updates or BSP syncs that are expected to improve QNN/NPU compatibility on Ubuntu 24 / newer kernels?

  2. Are there any currently known patches, configs, or workarounds (apart from the official Radxa OS) ?

At the moment the issue seems isolated specifically to QNN/NPU acceleration on the newer stack.
Any guidance would be greatly appreciated.

7

Hi everyone,

I wanted to share a quick update on my experience with the Dragon Q6A and where things stand from a developer’s perspective.

As someone who actively uses and appreciates Radxa products in general, I must admit I have grown quite tired of the endless update loops, broken dependencies, library conflicts, and the ongoing struggle just to get the NPU working specifically within the Dragon series.

Due to the persistent NPU/VPU conflicts, missing hardware nodes, and dependency issues that I previously mentioned, I ultimately decided to return my Q6A board. To get my project up and running without constant software roadblocks, I chose to invest in a Raspberry Pi 5 combined with the official AI Kit (13 TOPS). While it cost a bit more overall, the out-of-the-box software stability and robust library support allowed me to achieve a completely working, stress-free environment immediately.

I have been tracking the newly released Dragon Q8B, and while the hardware specs (especially the NPU throughput) look incredibly promising on paper, community feedback indicates it is still suffering from similar early-stage software issues, hacky kernel workarounds, and instability under heavy inference loads.

As developers who want to utilize these high-performance Qualcomm NPUs effectively, we really need a stable, production-ready foundation rather than constant troubleshooting. Could the Radxa team provide a clear roadmap on when we can expect synchronized BSP kernels, proper library packaging, and fully stable, out-of-the-box NPU support for these boards?

Best regards,

1 Like
8

Same here… I grew tired of the NPU/VPU thing… This never worked, even with a 2b parameter model. just too many bugs and issues… Only CPU is useful lol

9

Someone here got it to work

10

Thanks for sharing @Hackerman — I went through Olof’s writeup carefully. Good news: it confirms the NPU is not dead silicon after all. The root cause was a firmware mismatch — Radxa’s shipped cdsp.mbn (c3-00098) has no matching fastrpc shell binary, so the DSP silently rejects it with 0x80000600. Swapping in the generic upstream QCM6490 firmware plus the exactly matching shell from linux-msm/hexagon-dsp-binaries gets fastrpc_test to pass on Armbian edge.

That said, not much has actually changed for real-world use:

- This only gets the FastRPC layer up. A working Python / onnxruntime-QNN pipeline for actual inference workloads is still not demonstrated.

- The NPU/VPU conflict from my original report remains unaddressed.

- The fix is manual firmware surgery that any update can break — not something you can build a project on.

So the board went from “dead silicon” to “proven working hardware with broken official packaging.” That’s progress, and honestly it makes this an easy fix for Radxa: ship matched cdsp.mbn + shell binaries in the official image. Really hoping we see that update soon — the hardware deserves better software.

11

Hi @yarkinsen frustration is fair, but I think the expectation needs calibrating.

A Qualcomm Hexagon DSP NPU (fastRPC + proprietary QNN blobs) is never going to give you the install-and-go experience of a Hailo stick (RPi AI Kit) which is a different class of hardware, on every board, from every vendor. The Q6A NPU is working: I’ve got a full QNN/HTP pipeline running CNN and ViT models on Armbian’s current 6.18.2 kernel. In my point of view the actual limiter isn’t the kernel or Radxa’s packaging… it’s DSP firmware capability.

So the Q6A is a genuinely good board for NPU work ,12 TOPS of capable hardware and a working pipeline. What needs to know is, that it’s a Qualcomm DSP stack that needs firmware pairing and currently tops out at INT8. So not every NPU runs every ML job. Vendor stacks, supported precisions and software differ widely between accelerators (e.g. Rockchip RKNN, Qualcomm QNN).

12

Fair on the hardware-class comparison — a Hexagon DSP stack was never going to behave like a Hailo module, and calling out the INT8 ceiling is useful. Glad to hear CNN and ViT are running for you.

That said, my original report wasn’t “this isn’t as easy as Hailo.” It was that on the official r2 image the fastrpc nodes are never created and dmesg reports firmware load error -2. That’s not a calibration issue; that’s an image that can’t bring up the accelerator it ships with.

And note that you’re on Armbian 6.18.2, not Radxa’s official release — and Olof only got fastrpc_test to pass after manually swapping in the upstream QCM6490 cdsp.mbn and version-matching the shell binary. If DSP firmware capability were the real limiter, that pairing wouldn’t have fixed anything. Shipping matched firmware is packaging.

So: capability limits (INT8, vendor-specific toolchains) — agreed, users should expect those. Integration defects (missing nodes, unmatched blobs, NPU/VPU contention) — still open.

Could you share your image version, the QC_IMAGE_VERSION_STRING of your cdsp.mbn, whether you replaced the shell binary, and whether hardware video decode runs concurrently with inference? That last point is the one nobody has answered. I returned my board so I can’t test it — if concurrent NPU + VPU works for you, that’s a meaningful update.

13

good questions, let me try to answer them directly.

Image version: Armbian 26.5.1 noble, kernel 6.18.2-current-qcs6490.

Firmware: CDSP.HT.2.5.c4-00004-KODIAK-1. I did NOT use Olof’s c3-00103 swap, instead the c4-00004 firmware is actually from Radxa OS r2 (Feb 2026). The problem on Armbian ist, that the current version ships an older c3-00098 that has no matching fastRPC shell, so the DSP silently rejects everything with 0x80000600. The fix for me was to install the matched set that Radxa OS uses:

  • DSP firmware: cdsp.mbn (CDSP.HT.2.5.c4-00004-KODIAK-1) and adsp.mbn (ADSP.HT.5.5.c9-00028-KODIAK-2), extracted from the Radxa OS r2 rootfs
  • fastRPC userspace: libcdsprpc.so.1.0.0 + cdsprpcd/adsprpcd daemons
  • CDSP shell + skel libs: fastrpc_shell_unsigned_3 plus the full /usr/lib/dsp/cdsp/ tree (libc++.so.1, libQnnHtpV68Skel.so, etc.) — these are version-matched to the firmware
  • udev rule: sets /dev/fastrpc-* and /dev/dma_heap/* to group fastrpc, mode 0660

I also found an community install script that copies everything into place, then a gated remoteproc restart verifies the firmware loads before committing to a reboot… but the same result can be achieved by extracting these files from the Radxa OS r2 rootfs tarball directly.

QC_IMAGE_VERSION_STRING:

cdsp.mbn: CDSP.HT.2.5.c4-00004-KODIAK-1
adsp.mbn: ADSP.HT.5.5.c9-00028-KODIAK-2

NPU + VPU concurrency: Can’t answer definitively, I only tried Immich ML (face recognition + CLIP image search), no video decode. Haven’t tested concurrent VPU. That’s a valid open question.

The firmware swap gets the fastRPC + QNN HTP stack fully working — LoadBackend → CreateDevice → CreateContext → FinalizeGraphs → ExecuteGraphs all succeed. Both CNN (ArcFace) and ViT (SigLIP2-SO400M) models compile and run on the NPU with DDR traffic confirmed. That’s real inference, not just fastrpc_test.

14

Thank you for this — I appreciate that you answered all four questions directly and were clear about what you hadn’t tested.

One detail in your answer stood out to me: the c4-00004 set came out of Radxa OS r2. So a correctly matched firmware set already exists and is already shipped by Radxa. If that’s right, then I’d gently suggest the limiter isn’t really DSP firmware capability — it’s that the matched set isn’t distributed or documented as a coherent unit. You had to assemble the firmware pair, libcdsprpc, the cdsprpcd/adsprpcd daemons, the shell, the full /usr/lib/dsp/cdsp/ tree and a hand-written udev rule, all version-pinned, by extracting blobs from a rootfs tarball — and any single mismatch gives you a silent 0x80000600 with no diagnostic. That’s a packaging and documentation gap more than a hardware one, and I’d argue a very fixable kind of gap.

I should also update my own position. The Python 3.12 QNN wheels Morgan pointed to do exist now, and you’ve shown a full LoadBackend → ExecuteGraphs path with real models and confirmed DDR traffic. “Dead silicon” described what I could observe back in April; it clearly doesn’t describe the situation today, so I’m happy to retire that phrasing.

Two things I’d still consider open, and I mention them as caveats for future readers rather than as criticism of your result:

- Your workload is static-graph CNN/ViT. Rahul007 was on the same 6.18.2 kernel running llama.cpp with a 2B model and hit DMA allocation failures. So “the NPU works” may currently hold for a fairly specific model class, which seems worth stating plainly.

- NPU/VPU concurrency is still untested, and it remains the blocker for anything combining camera ingest with inference. If you ever get the chance to try hardware video decode alongside Immich ML, that result would be very welcome here.

One thing I still can’t reconcile, and I’d value your read on it: my original failure was on the official r2 image, where I got firmware load error -2 and no fastrpc nodes at all. If r2 carries the matched set, my breakage must have been in the userspace or initramfs layer — missing daemons or udev rules rather than firmware pairing. Does that match what you found in the r2 rootfs? And if you’re able to link that community install script, I think it would help the next person more than anything else in this thread.

@Morgan @RadxaYuntian — if it’s feasible, it would be great to see this shipped as a single versioned package (firmware, shell, skel tree, daemons and udev rules pinned together) with the required set documented on the NPU page. As far as I can tell every piece already exists in your own r2 image, so this may be a relatively small change with a big effect on the out-of-the-box experience.

15

I think @Rahul007 has confirmed that it is working here

16

Adding a data point that narrows this down. Dragon Q6A, RadxaOS RSDK 2026-02-14, kernel 6.18.2-4-qcom.

Following the thread I checked the firmware pairing — I already have CDSP c4-00004 / ADSP c9-00028, the versions @Dual-O reports working. So on RadxaOS the firmware mismatch from post 10 isn’t the (only) issue.

I also found three things missing from a default RadxaOS install that the docs don’t mention:

  • fastrpc / libcdsprpc1 were at 1.0.4-1 and missing libadsp-default-listener1 and libcdsp-default-listener1 entirely; reinstalling pulls 1.0.6-3 plus the listener libs
  • protection-domain-mapper was not installed
  • qrtr-tools was not installed

With all of those installed and running, qrtr-lookup shows the full DSP service registry (subsystem control, thermal, CoreSight on nodes 5 and 10), so QMI to both DSPs works. But fastrpc_test -a v68 still fails 3/3 with 0x80000600: Unable to create FastRPC session, and the kernel still logs on every bring-up:

qcom,fastrpc …glink-edge.fastrpcglink-apps-dsp: no reserved DMA memory for FASTRPC

Two further notes:

  1. The DSPs don’t auto-boot — request_firmware failed: -2 every boot despite the blobs being present at /lib/firmware/qcom/qcs6490/radxa/dragon-q6a/, so echo start > /sys/class/remoteproc/remoteprocN/state is needed first.
  2. Leaving the DSPs running has hung the board twice, once requiring fsck from initramfs.

@Dual-O — could you share the community install script and udev rules you mentioned? Given identical firmware, I suspect the difference is your Armbian kernel having the fastrpc memory-region binding that the RadxaOS 6.18.2-4 device tree lacks. If so, that’s a DT fix Radxa could ship.

17

While investigating the NPU issue, I found another problem with the official Ubuntu repository.

radxa-firmware-qcs6490 version 0.2.38 cannot be installed because it depends on firmware-qcom-audioreach, but that package is not present in the repository.

Reproduction:



apt policy radxa-firmware-qcs6490
apt-cache depends radxa-firmware-qcs6490
apt-cache showpkg firmware-qcom-audioreach
apt-cache search audioreach

Output shows that firmware-qcom-audioreach has no published versions and no provider, making the firmware package impossible to install.

18

It is available here.

We also have it in our qcs6490-noble apt repo. Check if you are using our official system since that repo is preconfigured in our system.

19

@Element_9 this is the missing piece, thank you. That kernel line — no reserved DMA memory for FASTRPC — is the first thing in this thread that actually explains the failure rather than working around it.

Putting the reports together, it looks like there are two independent defects, which is why people kept talking past each other:

  1. Armbian: ships c3-00098 with no matching fastRPC shell, so the DSP rejects everything with 0x80000600. Fixed by @Dual-O by transplanting the matched c4-00004 / c9-00028 set out of RadxaOS r2.
  2. RadxaOS: firmware pairing is already correct, but fastRPC has no reserved DMA region, so session creation fails with the same 0x80000600 even after installing the missing listener libs, protection-domain-mapper and qrtr-tools.

Same error code, two different root causes. That also fits my original report: correct r2 image, blobs present, request_firmware failed: -2, no fastrpc nodes. I’d installed the QNN wheels and worked through the userspace side without ever getting a session, which is consistent with the problem sitting below userspace entirely.

The DT hypothesis seems the most plausible explanation for why Armbian works and RadxaOS doesn’t on identical firmware, though I’d note the reserved-memory warning can be benign on some Qualcomm platforms when fastrpc falls back to dma_heap — so it’s worth confirming rather than assuming. A dtc -I dtb -O dts on both the Armbian 6.18.2-current-qcs6490 and RadxaOS 6.18.2-4-qcom DTBs, diffing the fastrpc node and its memory-region reference, should settle it in a few minutes. If the binding really is absent on RadxaOS, that’s a one-line DT fix.

Two other things from your post deserve more attention than they’re getting:

  • The DSPs don’t auto-boot. request_firmware failed: -2 with the blobs present, requiring a manual echo start > /sys/class/remoteproc/remoteprocN/state, is its own bug — a firmware path, naming or initramfs timing issue, independent of the DMA problem.
  • Leaving the DSPs running hung the board twice, once needing fsck. For anyone considering this board for an always-on workload, that’s more significant than the inference numbers. It’s worth its own investigation.

Separate from Yalil’s audioreach point: could someone confirm whether the fastrpc memory-region binding is present in the RadxaOS 6.18.2-4-qcom device tree? If Armbian carries it and RadxaOS doesn’t, that would explain every report in this thread and looks like a small fix with a large payoff.

On the audioreach package — glad there’s a location for it, but if is on the official image with the preconfigured repo and firmware-qcom-audioreach still resolves to no candidate, that suggests something is genuinely unpublished in the qcs6490-noble repo rather than a misconfiguration on the user’s side. Might be worth a second look at the repo index.

20

fastrpc on cdsp doesn’t need reserved DMA memory. If it doesn’t work, something else is not configured properly. It could be an unnecessary package replacing the actually required firmware during an apt instasll process. The no reserved DMA memory for FASTRPC error is misleading.

protection-domain-mapper and qrtr-tools are not required either. pd-mapper service is now provided by the in-kernel qcom_pd_mapper driver.