Your remotectl1 domains not supported line is new — I haven’t seen that specific message in any of the earlier reports, and I think it narrows things down considerably.
There’s a long parallel thread on this: Non-functional NPU Support on Dragon Q6A (QCS6490) under Ubuntu 24.04 (Noble). Short version of what came out of it: every working report so far came from getting the DSP firmware, the fastRPC shell binary and the skel libraries onto exactly matching versions. @Dual-O has it running on Armbian with CDSP.HT.2.5.c4-00004-KODIAK-1 / ADSP.HT.5.5.c9-00028-KODIAK-2 plus a version-matched fastrpc_shell_unsigned_3 and the full /usr/lib/dsp/cdsp/ tree. Whenever any one of those is out of step, the DSP rejects the session with exactly your 0x80000600 and no useful diagnostic.
My hypothesis for your case — and it is a hypothesis, worth checking rather than believing: remotectl1 is the newer domain-query interface in the fastRPC userspace library. “Domains not supported” is what you’d expect if the library is newer than the DSP-side shell it’s talking to. You’re on fastrpc/libcdsprpc1 1.0.7-1, which is two releases past the 1.0.6-3 in the other thread, but the shell binary may not have moved with it. If so, the version pairing problem people hit at the firmware↔shell layer has just shifted up to userspace↔shell.
This should confirm or kill it quickly:
strings /usr/lib/dsp/cdsp/fastrpc_shell_unsigned_3 | grep CDSP.HT | head -n1
strings /lib/firmware/qcom/qcs6490/radxa/dragon-q6a/cdsp.mbn | grep QC_IMAGE
dpkg -S /usr/lib/dsp/cdsp/fastrpc_shell_unsigned_3
dpkg -S /lib/firmware/qcom/qcs6490/radxa/dragon-q6a/cdsp.mbn
All three version strings — firmware, shell, and whatever the skel libs were built against — need to be identical. If the shell reports an older CDSP.HT version than cdsp.mbn, that’s your answer. The dpkg -S lines are worth running too: if anything other than radxa-firmware-qcs6490 owns those paths, a second package is overwriting them (linux-firmware ships to the same filenames).
Also useful to know which package pulled in your shell binary, given you have task-qualcomm-npu 0.1.0-7 installed — that metapackage is new since the earlier reports, and if it isn’t pinning the shell to the firmware version, that’s a packaging bug worth raising on its own.
If you want a working reference set, there’s a community script that assembles a matched set from the RadxaOS r2 rootfs: GitHub - vladisUl/npu_runtime_armbian: npu runtime for armbian Radxa Dragon Q6A · GitHub — it’s Armbian-oriented, but the file list tells you what has to be version-matched.
For context: I filed the original report back in April and returned my board, so I can’t test any of this myself. But your kernel 7.0.11 / firmware 0.2.41 / fastrpc 1.0.7 combination is the newest anyone has reported, and if it still fails on a fully updated official image, that’s a data point Radxa should have.