Hello Radxa team,
I have been working with the Dragon Q6A (QCS6490) for several weeks on a real-time audio project (Neural Amp Modeler, professional bass amplifier). I purchased the board, I am the owner of the hardware.
The Problem: I cannot access the MI2S/LPAIF audio registers (0x03B00000) directly from the CPU. Any readl() access causes a bus hang or kernel panic. The reason: Qualcomm’s TrustZone (XPU/SMMU/NoC Firewall) locks the entire LPASS region from CPU access. Only the ADSP (Hexagon DSP) is permitted to access it.
The Consequence: I am forced to use the AudioReach/ADSP path. This enforces a minimum scheduling interval of 10ms (480 frames at 48kHz). For real-time audio processing this is unusable. On a Raspberry Pi 5 with direct I2S/DMA I had stable 32 frames (0.67ms) for hours.
What we tried (all failed):
-
LPASS CPU driver (lpass-sc7280.c) — bus hang due to XPU
-
Global SMMU disable via devcfg — kernel panic
-
devcfg permission byte patching — permissions are in TZ (dual-signed), not in devcfg
-
AudioReach container set to Synchronous + Low-Latency — ADSP still enforces 10ms
-
hw_constraint_step patched in kernel driver — test pending
My questions for Radxa:
-
Is there an official way to unlock the LPAIF registers for CPU access?
-
Is the board truly “unfused” as advertised? If so, why can’t I modify the TrustZone configuration?
-
Is there a BSP or firmware configuration that enables low-latency audio (<2ms)?
-
Does Radxa have contact with Qualcomm to enable an LPASS permission change for the Dragon Q6A?
-
Why is this board marketed as a “maker board” when fundamental hardware blocks are locked from the owner?
I purchased this board to work with it. I don’t want to use Qualcomm’s smartphone software, I want to run my own software on my own hardware. That should be self-evident.
Thank you.
Hi,
Thank you for your interest in the real-time audio capabilities of the Dragon Q6A.
First, to clarify: the board is not locked by us in any way. By default, Qualcomm restricts direct CPU access to the LPASS hardware block. However, you can enable access by following these steps:
- Make sure you have the latest BIOS installed, version 260120 or newer.
- Press F2 during boot to enter the BIOS setup, then go to
Radxa Platform Configuration → Hypervisor Settings
- Set Hypervisor Override to Enabled.
- Set ADSP firmware preload to Disabled.
- Save the settings and reboot.
After that, you should be able to enable the lpass-cpu drivers and the required device tree nodes. In this configuration, direct CPU access to LPASS should work, and you should no longer see bus hangs or kernel panics caused by the access restriction.
That said, I did a quick test and I suspect the lpass-cpu drivers in the mainline kernel still have some issues that prevent audio from working properly. I have seen kernel oops during testing. My guess is that these drivers have not been used or tested much for a long time, since they were originally intended for SC7280 Chromebooks that never actually reached the market.
In any case, I currently have a work-in-progress kernel tree here:
v6.18.20-wip-lpass-cpu
If you have any ideas on how to improve or fix the lpass-cpu drivers, I would be very interested to hear them 
Hi strongtz,
Thank you so much for this incredibly helpful reply — this is exactly the breakthrough we’ve been looking for.
A bit of background on what we’re doing: We’re building a custom real-time audio processor (neural amp modeler for bass guitar) on the Dragon Q6A. The signal chain is Q6A ↔ ADAU1467 DSP via Primary MI2S, running S32_LE at 48kHz stereo. The Q6A is the I2S slave, the ADAU1467 is master.
Over the past few weeks we’ve gone through quite a journey trying to get low-latency audio working:
- We got MI2S audio running via AudioReach/ADSP with a custom topology, a dummy codec driver, and several kernel patches (q6apm-dai, snd-q6apm, snd-q6dsp-common, snd-soc-sc8280xp, bluepedal-codec.ko)
- We managed to get the period size down to 96 frames (2ms) by patching the step constraint in q6apm-dai.c — stable, no overruns
- But AudioReach adds internal buffering stages (RX → Processing → TX), so the actual end-to-end latency is higher than the period size alone
- We tried everything to access LPASS registers directly — DTB patches, devcfg analysis, even exploring EUD/JTAG — all blocked by the XPU/NoC firewall
So your BIOS solution is a game changer for us. We’ll check our BIOS version and try the Hypervisor Override setting as soon as possible.
Regarding your WIP kernel tree (v6.18.20-wip-lpass-cpu) — could you share a link to the repository or branch? We’d love to test it and provide feedback. We’re currently running Armbian with kernel 6.18.0-rc6-edge-qcs6490.
We have a working hardware setup ready for testing (Q6A + ADAU1467 + speakers), so we can provide real-world audio test results and help debug any lpass-cpu driver issues. If there’s anything specific you’d like us to test or any logs that would be useful, we’re happy to help.
Thanks again for taking the time — this is really appreciated.
Best regards
Hi,
Here’s the link to the WIP kernel tree:
-
Press F2 during boot to enter the BIOS setup, then go to
Radxa Platform Configuration → Hypervisor Settings
-
Set Hypervisor Override to Enabled.
I’m just curious: can this OS-specific option be dynamically adjusted based on the type of system being loaded? After all, whether it is enabled or disabled by default can cause certain hardware—such as the VPU (or audio hardware, as in this specific case)—to malfunction in either Linux or Windows environments.
All options on the Hypervisor Settings page are ignored when booting Windows, so they only affect non-Windows systems.
And yes, we already have some dynamic OS detection in the firmware after UEFI ExitBootServices() for various purposes.
Also, in this case the audio hardware is not actually malfunctioning. By default, the ADSP inside the SoC is responsible for controlling the LPASS audio hardware, and software is generally expected to use the ADSP audio path. Direct CPU access to LPASS is not the default design.
If you specifically want to bypass the ADSP and access LPASS directly from the CPU, then you need to adjust those BIOS settings manually.
1 Like
Hi Glotzkoffski,
I have managed to get HDMI audio, headphone output, and headset microphone input working with the lpass-cpu driver, and I am no longer seeing any errors.
I have not tested any I2S accessories yet, but I do not expect major issues there.
Still, you can find the kernel tree here:
And the alsa-ucm-conf changes for the lpass-cpu setup here:
