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
I don’t quite understand what you meant here. We provide NPU documentations, and one of the validation step is using Python.
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.
@Morgan please take a look.
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
@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:
-
Are there any planned official kernel updates or BSP syncs that are expected to improve QNN/NPU compatibility on Ubuntu 24 / newer kernels?
-
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.
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,
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
Someone here got it to work