VINO: IndyCam capture end-to-end on IRIX 6.5

[hanshuebner]

Makes vidtomem / Media Recorder capture a clean, correctly-coloured 640×480 frame from the IndyCam (or the test-pattern source) on IRIX 6.5.22 — previously the VL client never received a frame on 6.5.

Changes (src/):

• physical.rs — map the uncached 0x4000_0000 alias of low RAM, so the 6.5 driver's descriptor-ring polling resolves instead of flooding MC bus errors. Capture now engages and DESC/EOF fire.
• vino.rs — deliver + unscramble: defer the first interlaced field's STOP/DESC (EOF only) and complete on the second so the kernel's field-pairing wakes vinoGetFrame; report CH_DESC_TABLE_PTR at the kernel's field-boundary descriptor on the 2nd field so the buffer-completion check doesn't abort; 16-byte-align the jump-bug JUMP target so all 300 data pages land in order.
• camera.rs — read the nokhwa YUYV chroma straight (standard Cb/Cr order); the prior U/V swap had been masking the RGBA byte-order bug and caused red↔blue once that was fixed.

Plus tools/vino/ (guest-side debug helpers: vinograb, chaindump, chainwalk, mempeek, vinodump) and the full investigation writeup in rules/irix/.

Verified live on 6.5.22: test-pattern shows correct SMPTE bars; live camera shows correct colour. No 5.3 regression in the unit tests; the interlace/STOP changes are gated to the 6.5 path.

🤖 Generated with Claude Code

[techomancer]

wait, i noticed the errors in 0x4000_0000 range, but why. there is no alias of low ram there. we must be misunderstanding how the hw works somewhere. are these memory accesses coming from vino or vdma?

[hanshuebner]

You were right on both counts — there's no 0x40000000 RAM alias, and the accesses are vdma, not the CPU.

Source of the accesses: VINO's descriptor_fetch and DMA buffer writes go through the Physical bus (Vino::set_phys). When VINO drives an unmapped address, Physical routes it to CpuBusErrorDevice, which is what prints MC: CPU Error at 48621cf0 — the "CPU" label is just because every unmapped access funnels through that one sink. So it was VINO DMA the whole time.

Why bit 30 was set: the descriptor address field is only bits [29:4]; bit 31 is STOP, bit 30 is JUMP. The 6.5 driver encodes its pointers as JUMP_BIT | kvtophys(addr) (vinoBuildJumpBugDAPS), so 0x4861e000 is really JUMP_BIT | 0x0861e000. The actual bug: desc::PTR_MASK was 0xFFFF_FFF0, keeping bits 31/30, so the CH_NEXT_4_DESC / CH_DESC_TABLE_PTR register writes left bit 30 in next_desc_ptr/start_desc_ptr and VINO fetched at 0x4861e000. (The JUMP target path already masked 0x3FFF_FFF0 and was correct.)

Fix (pushed): narrowed desc::PTR_MASK to 0x3FFF_FFF0 so the pointer-register writes and the data-buffer write address strip the control bits and resolve to the real lomem address (0x0861e000, in RAM at 0x08000000). Reverted alias_phys() from physical.rs entirely — no bus alias needed. Indy RAM is 0x08000000..0x18000000 so a legitimate address never sets bits 31/30, and 5.3 descriptors carry no control bits so its path is unchanged. Added a regression test (desc_pointer_registers_strip_bit30_control_flag); all 12 vino tests pass.

[techomancer]

woohoo!