Hi — debugging the VPU (video codec) on a Dragon Q6A with the **260120** SPI firmware. The 7.0.11-5 and 7.0.11-6 (qcom) kernels fail to download the VPU firmware through the secure monitor, while 6.18.2-3 (qcom, Venus driver) initializes cleanly on the same board. Looking for guidance on the 7.x pairing. Cross-link from the [Video acceleration on QCS6490](/t/video-acceleration-on-qcs6490/29198) thread.
## Board / setup
- Radxa Dragon Q6A (QCM6490), **RadxaOS (Ubuntu 24.04)** — system updated via **rsetup** (all Radxa repo packages current; today’s rsetup update pulled the 7.0.11-6 kernel and the split `linux-firmware-*` packages, after which the boot default landed on 7.0.11-6)
- SPI NOR firmware: `6.0.260120.BOOT.MXF.1.0.1-00549-KODIAKWP-1`
- Kernels (Radxa repo, qcs6490-noble): `6.18.2-3-qcom` (built 2026-02-14), `7.0.11-5-qcom` (built 2026-08-20), `7.0.11-6-qcom` (built 2026-09-02)
- UEFI `HypervisorOverride` variable = **1 (enabled)** — verified via `/sys/firmware/efi/efivars`
## Symptom (7.0.11-5 and 7.0.11-6, identical)
```
qcom-iris aa00000.video-codec: error -22 initializing firmware qcom/vpu/vpu20_p1_gen2_s6.mbn
qcom-iris aa00000.video-codec: firmware download failed -22
qcom-iris aa00000.video-codec: core init failed
```
(repeats twice during boot; -22 = EINVAL, i.e. QCOM_SCM_EINVAL_ARG from the SMC firmware-download path). The v4l2 nodes exist (`/dev/video0,1`, names `qcom-iris-decoder`/`qcom-iris-encoder`) but the codec core is never initialized.
## 6.18.2-3 on the same board + same firmware
```
qcom-venus aa00000.video-codec: non legacy binding
```
No firmware errors; `venus_dec` / `venus_enc` / `venus_core` load.
This A/B happened naturally today — three consecutive boots (visible via `journalctl --list-boots`):
| Time | Kernel | VPU result |
|------|--------|------------|
| 15:26 | 7.0.11-5 | iris: `firmware download failed -22` |
| 15:27 | 6.18.2-3 | venus: clean, no errors |
| 15:53 | 7.0.11-6 | iris: `firmware download failed -22` |
## What I’ve ruled out
1. **Not a missing/corrupt firmware file.** Both candidate blobs are present, intact, and both are rejected:
-
`qcom/vpu/vpu20_p1_gen2_s6.mbn` → `vpu20_p1_gen2_s6.mbn.zst` (from `linux-firmware-qualcomm-graphics`; 2030620 B decompressed, sha256 `f061733f2f0c6442…`, `zstd -t` OK). Kernel has `CONFIG_FW_LOADER_COMPRESS_ZSTD=y`.
-
Fallback path `/lib/firmware/updates/qcom/vpu/vpu20_p1_gen2_s6.mbn` → symlink to `qcom/vpu-2.0/vpu20_1v.mbn` (linux-firmware-dragonwing 20260613; 2028340 B, sha256 `924da352608d82a2…`).
-
The 7.0.11-5 failure at 15:26 happened **before** `linux-firmware-qualcomm-graphics` was installed on this system, so it was already failing with the `vpu20_1v` blob. Both blobs fail.
2. **Not the Hypervisor Override**: UEFI variable is 1 (enabled).
3. **Not a DTB difference for the codec node**: same `aa00000.video-codec` node; 6.18 binds it to venus without issue, 7.x binds it to iris and fails at the secure download step.
## Questions
1. Is the qcom-iris driver in the 7.0.11-x line validated against the 260120 TZ? The 260120 release notes list 6.18.2 as the tested kernel for third-party images.
2. If this is a blob↔TZ pairing issue: which VPU blob is 260120 expected to accept (`vpu20_1v.mbn` or `vpu20_p1_gen2_s6`)? Is a newer firmware snapshot planned that pairs with the new blob and the 7.x kernels?
3. Any known fix/patch in the 7.x line for the iris SMC firmware download on QCS6490?
## Related 7.x regression (same board + firmware, for completeness)
On 7.0.11-6 the ASoC card also fails to instantiate:
```
qcom-apm gprsvc:service:2:1: ASoC error (-2): at snd_soc_component_probe()
snd-sc8280xp sound: ASoC: failed to instantiate card -2
```
→ no soundcards at all; on 6.18.2-3 the `q6apm` / `snd_q6dsp_common` / `snd_soc_hdmi_codec` stack loads and audio works. Happy to open a separate thread for that if preferred.
## Repro
Boot 7.0.11-5 or 7.0.11-6 with 260120 SPI firmware → `dmesg | grep qcom-iris`.
(Side note: the fastrpc/NPU path is healthy on 7.0.11-6 — the official `fastrpc_test -d 0 -U 0 -a v68` passes 3/3 on ADSP, 2/3 on CDSP, so the DSP side is fine and this is specific to the VPU secure-download path.)
-–
*Disclosure: this investigation and report were put together with the help of an AI agent (pi, running Claude) driving my board over SSH at my request. All quoted logs, hashes, and values are verbatim from the board.*