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

Opens 2026-05-14 after iter9 PARTIAL close ([`phase8_iteration9_close.md`](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.