17aa443f8f860a63ab7e27da8dfd594e8b5e7d65
Phase 6 ran Steps 1-4 cleanly (vendor + adapt + UAPI header +
h265_set_controls wiring; 4 atomic commits f91c3f5..1a2c958 on
backend master, build green). Phase 6 Step 5 smoke test triggered
F1 falsifier per Phase 1 falsifier path.
Evidence:
- strace ioctl trace shows per-frame VIDIOC_S_EXT_CTRLS carries 5
controls (IDs 0xa40a90..0xa40a94 = standard HEVC SPS/PPS/SLICE/
SCALING/DECODE_PARAMS). The new 0xa40a98 (EXT_SPS_ST_RPS) and
0xa40a99 (EXT_SPS_LT_RPS) DO NOT appear in any S_EXT_CTRLS call.
- Probe-line still fires (has_hevc_ext_sps_rps_rkvdec=true confirmed
via vainfo log) — so the gate is fine, but the populate-and-add
code path doesn't reach v4l2_set_controls.
- OOPS register state identical across pre-iter2 + post-iter2:
x1 = 0x51a0 (small integer treated as pointer; pgd=0 confirms
invalid). The kernel reads this same garbage value regardless of
whether userspace tries to set the controls or not.
Hypothesis revision: Phase 0's 'UAPI-gap' reconstruction was
PARTIALLY refuted. Even when userspace doesn't populate the new
CIDs (pre-iter2) AND when it tries to (iter2 but the call doesn't
actually fire), the kernel ends up with run->ext_sps_st_rps=0x51a0.
The 0x51a0 is a deterministic kernel-side state — uninitialized
ctrl->p_cur.p or a confused offset-vs-pointer.
Three diagnostic next-steps for iter3 (kernel-side investigation):
1. Backend instrumentation: log h265_populate_ext_sps_rps_cache
return code + source_data SPS NAL search outcome
2. Backend code-path check: is h265.c::h265_set_controls really
the call site, or does picture.c dispatch via something else?
3. Kernel instrumentation: printk in rkvdec_hevc_prepare_hw_st_rps
dumping run->ext_sps_st_rps as read from ctrl->p_cur.p
Meta-campaign re-shuffle:
- iter2 closes F1 (this commit)
- iter3 was 'VP9 enablement' -> now bumped to 'HEVC kernel
investigation' (more urgent, has concrete evidence to pursue)
- iter4 = VP9 kernel enablement (was iter3)
Source code stays on backend master — iter2 infrastructure
(vendored parser, UAPI shim, runtime probe) is reusable for iter3+
regardless of whether the eventual kernel-side fix changes how
userspace integrates.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
ampere-kernel-decoders
Kernel-side sibling campaign to ampere-fourier (which validated the userspace libva backend on RK3588 at iter1 close, 3 codecs working) and fresnel-fourier (the RK3399 peer). Focuses on the kernel-side enablement required to unblock the three codec blockers iter1 of ampere-fourier surfaced:
- HEVC kernel OOPS in
rkvdec_hevc_prepare_hw_st_rps(__pi_memcmpfault, cascades tov4l2_mem2memwedge). Tracked atmarfrit/kernel-agent#11 [ka:experiment]. - VP9 not exposed on RK3588 rkvdec — kernel doesn't register
V4L2_PIX_FMT_VP9_FRAMEon the VDPU381/383 variant_ops. Tracked atmarfrit/kernel-agent#12 [ka:experiment]. - (AV1 backend iter39 is userspace work, not in this campaign's scope; tracked at
marfrit/libva-v4l2-request-fourier#2.)
Topology
| Property | Value |
|---|---|
| Working tree (substrate kernel) | boltzmann:~/src/linux-rockchip branch linux-rk3588-marfrit |
| Board patches | boltzmann:~/src/misc_patches/genbook/kernel/000*.patch (6 board DTS/config patches; the ampere baseline package consumes these) |
| Experiment target host | ampere (CoolPi CM5 GenBook, RK3588) |
| Baseline kernel for regression-checks | linux-ampere-fourier 7.0rc3.kafr1-1 (vanilla torvalds v7.0-rc3 + genbook/kernel/000* only — NO codec patches) |
| Patch destination | kernel-agent experiment branches per issue; promoted to linux-ampere-fourier only via explicit operator decision per feedback_characterize_before_change (campaign-experiment patches stay OUT of baseline) |
| Build host | boltzmann (primary aarch64 builder per kernel-agent README) + ampere as fallback secondary |
| Patch landing pad | marfrit/kernel-agent/patches/{soc,driver}/... scope-tagged per kernel-agent's tree convention |
Scope (in flux until Phase 0 close)
In scope (iter1 candidate):
- HEVC OOPS fix — minimal-blast-radius candidate patch for
rkvdec_hevc_prepare_hw_st_rps, validated on ampere by re-runningampere-fourierPhase 3 with HEVC added. - Survey upstream prior art (linux-rockchip, linux-media, linux-mm, Kwiboo, Bootlin, Collabora) before writing any code — there may already be a fix in v7.0-rc4+ or in an out-of-tree branch.
Out of scope (likely iter2+):
- VP9 enablement (broader work — VDPU381/383 variant_ops surface, DTS bindings, potentially backend codec table updates). Separate iteration.
- Multi-core support for rkvdec/hantro (the "missing multi-core support, ignoring this instance" lines in dmesg). Upstream work; out of fleet-scope.
Explicitly NOT in scope:
- Codec patches on the baseline
linux-ampere-fourierpackage. Per operator policy 2026-05-16, ampere baseline stays clean mainline + board DTS. Codec enablement = kernel-agent experiment branches only.
Process
8(+1)-phase loop per feedback_dev_process.md, same as ampere-fourier / fresnel-fourier. Notable for this campaign:
- Phase 0 includes an upstream prior-art survey (linux-rockchip + linux-media + linux-mm + Kwiboo + Bootlin). This is non-optional — writing a kernel patch without first checking whether the fix already exists upstream is the wrong workflow. Memory
feedback_no_upstreamsays no PR/MR/RFC from us by default; that's about publishing, not consuming. Consume aggressively. - Phase 5 review uses the sonnet-architect subagent pattern (
Planwithmodel: sonnet), same as ampere-fourier. Memory rulefeedback_review_empirical_over_theoreticalapplies — test-compile reviewer-suggested struct/field mappings before adopting amendments. - Phase 6 implementation produces kernel patches in
~/src/linux-rockchipon boltzmann + accompanying kernel-agent experiment branch entries. No patches land inmarfrit-packages/arch/linux-ampere-fourier/directly. - Phase 7 verification re-runs
ampere-fourieriter1's Phase 3 scripts with HEVC added to the codec list. Predicted outcome anchors against ampere-fourier iter1's baseline numbers.
Predecessor work this campaign builds on
../ampere-fourier/iter1 — the baseline floor this campaign regresses against. Re-anchoring to ampere-fourier's N=3 FPS numbers + per-codec SSIM floors for any codec that flips from "blocked" to "validated."marfrit/kernel-agent— the experiment-branch home + issue tracker.marfrit/kernel-agent/issues/11— HEVC bug ticket with the OOPS trace + reproducer.marfrit/kernel-agent/issues/12— VP9 enablement ticket.- Memory
feedback_rkvdec_patch_reachability— VDPU381/383 vs RK3399 legacy path boundary. - Memory
feedback_characterize_before_change— campaign-process rule from ampere-fourier iter1.
Operator-facing repo URL
git.reauktion.de/marfrit/ampere-kernel-decoders — to be created at iter1 close if there's something publish-worthy (matches the fresnel-fourier / ampere-fourier convention). Local-only at ~/src/ampere-kernel-decoders/ on noether for now.
Description
RK3588 decoder enablement on ampere (CoolPi CM5 GenBook). Sibling kernel-side campaign to marfrit/ampere-fourier (userspace consumer). Meta-campaign coordinating HEVC OOPS investigation (iter2: F1 negative-result), VP9 enablement (iter4), AV1 backend probe (sibling). Process: 8(+1)-phase loop.
Languages
Shell
100%