fresnel-fourier/phase0_findings_iter10.md

Iteration 10 — Phase 0 (substrate / motivation / inventory) → Phase 1 lock

Opens 2026-05-14 after iter9 PARTIAL close (phase8_iteration9_close.md, commit 5e2a228). User pointed me at Michael Bommarito's May 13, 2026 patch on linux-rockchip:

[PATCH] media: rkvdec: hevc: cap EXT SPS RPS control counts before descriptor assembly Message-ID: <20260513181922.2075438-1-michael.bommarito@gmail.com> Assisted-by: Claude:claude-opus-4-7

iter10 Phase 0 task: evaluate whether this kernel-side bounds-check patch fixes Bug 5 (HEVC libva all-zero) on fresnel.

Empirical reachability check

The patch adds rkvdec_hevc_validate_rps_ctrls() and calls it at the entry of rkvdec_hevc_assemble_hw_rps() in drivers/media/platform/rockchip/rkvdec/rkvdec-hevc-common.c:411.

Reachability on fresnel (RK3399, rockchip,rk3399-vdec):

$ grep -rn rkvdec_hevc_assemble_hw_rps drivers/media/platform/rockchip/rkvdec/
rkvdec-hevc-common.c:411  void rkvdec_hevc_assemble_hw_rps(...) { ... }     # definition
rkvdec-hevc-common.h:96   void rkvdec_hevc_assemble_hw_rps(...);            # header
rkvdec-vdpu381-hevc.c:609 rkvdec_hevc_assemble_hw_rps(...)                  # RK3576 caller
rkvdec-vdpu383-hevc.c:620 rkvdec_hevc_assemble_hw_rps(...)                  # RK3588 caller

The function is referenced only from the VDPU381 (RK3576) and VDPU383 (RK3588) variant glue. The RK3399 variant operations (rk3399_variant_ops in rkvdec.c:1657) bind to rockchip,rk3399-vdec (DT compatible at line 1752) and the RK3399 HEVC path lives in the older rkvdec-hevc.c, which does not call rkvdec_hevc_assemble_hw_rps.

Conclusion: Bommarito's patch is reachable on RK3588 / RK3576, not on RK3399. It does not fix Bug 5 on fresnel.

This matches Bommarito's own commit log:

"I don't have a RK3588 / RK3576 board to confirm this through a real /dev/videoN request path yet, but was convinced enough by [KUnit harness]."

The patch is real and load-bearing on the RK3588/3576 path — but irrelevant to our hardware.

Implications for the campaign

1. The May 13 patch is not an iter10 candidate for fresnel.
2. Bug 5 (HEVC libva all-zero) on fresnel is in a different code path: rkvdec-hevc.c (the RK3399 standalone HEVC handler). That's what would need to be investigated for a kernel-side Bug 5 fix.
3. The Bommarito patch is still useful as methodology reference: KUnit harness around the existing helper, KASAN-detect OOB writes, then add bounds check. Same shape could be applied to the RK3399 HEVC path in rkvdec-hevc.c if we suspect a similar OOB write is happening there.

iter10 candidate pivots

Three candidates after Bommarito unreachability is confirmed:

• α-10: Audit the RK3399 HEVC kernel path (rkvdec-hevc.c) for analogous bounds-check gaps. If libva's HEVC controls submit out-of-range count fields, we may be triggering a silent OOB write that explains Bug 5's all-zero output. Same KUnit/KASAN methodology as Bommarito.
• α-11: Apply Bommarito's patch anyway (no-op on RK3399 since unreachable, but ships hygiene). Skip — pure busywork.
• α-12: Stay on Bug 4 H.264 (iter9 close ranked: PPS deep diff, OUTPUT bitstream byte inspection, DPB ordering, slice-data encoding).

User directive carries: "consult kernel-agent for kernel work" → α-10 (if pursued) routes through kernel-agent for source / build / promote.

Substrate state at iter10 open

• Fork tip e0be4e6 (iter9 close) on noether + fresnel + gitea.
• Backend SHA a17e3c39… on fresnel (iter8+iter9 hygiene cleanups: γ + IMP-1 + α-2 + α-7).
• Kernel linux-fresnel-fourier 7.0-1 unchanged (mmind v7.0 + 3 PBP DTS).
• Kernel source on boltzmann: ~/src/kernel-agent-bootstrap/build/marfrit-packages/arch/linux-fresnel-fourier/src/linux-7.0/.
• All diagnostic instrumentation (γ + memset gate) preserved.

Locked research question (iter10, 2026-05-14)

Phase 0 conclusion: Bommarito patch is not the iter10 vehicle. iter10 PASS condition for this Phase 0 alone is simply "establish whether the Bommarito patch is reachable on fresnel: no." That's done.

iter10 continues by picking a fresh research question — defer to user direction or proceed with α-10 / α-12.

Phase 8 wrap (early)

This Phase 0 closes with a definitive negative finding. iter10 doesn't need a Phase 1-7 loop because the candidate was eliminated at Phase 0 by reachability analysis.

Net: eliminated one kernel-side hypothesis for Bug 5 cleanly without burning a kernel build cycle. Source-read on boltzmann's kernel-agent tree was sufficient.

Memory rule worth recording: before applying any upstream patch to fresnel's kernel, verify the patched code path is reachable from rockchip,rk3399-vdec. The mainline rkvdec tree has diverging per-variant code (VDPU381/383 vs RK3399 legacy) and patches targeting one variant don't apply to the other.

Next moves

Pending user direction. Default: continue with α-12 (Bug 4 H.264, the iter9 ranked candidates) until kernel work for Bug 5 is explicitly invoked.