Roflin 83a62d60a0 Reset the register file's ring pointers on an NCRA reset
An NCRA reset returns RXFrameAssembler's write pointer to page 1, but the
register file's COPY of RWP was never reset -- it kept whatever the last frame
left.  So after any reset the GC reads a stale RWP pointing at a page the
assembler is not using, and its first RX after a reset reads the wrong page.

CLAUDE.md has stated the intent all along ("NCRA = 0x01 ... resets W5500 +
SPRAM ptrs"); the register file simply never did it.

This is NOT only a netboot problem.  Any driver that resets and then trusts
RWP hits it, Swiss included.  It stayed invisible because the suite's RX test
only checks that RWP CHANGES, never that it points at the right page, and
t_dma used to read a hardcoded 0x100 so it never consulted RWP either.  It
surfaced through netboot, whose RRP = RWP sync landed on a stale page and
found garbage where a descriptor should be.

T1c covers it, and BOTH halves have teeth.  My first version did not: RWP read
[1] with or without the fix because nothing in the testbench had moved it.  It
now drives the assembler's RWP update path to page 9 and writes RRP to 7
first, so the negative control fails on both:

    T1c RWP after NCRA reset: expected [1], got [9]
    T1c RRP after NCRA reset: expected [1], got [7]

A test that passes whether or not the fix is present is worse than no test.

Gateware only -- the test app needs no change and the existing .dol is
compatible: after its reset it reads RWP, now gets 1, and writes RRP = 1.

--seeds 8: clk 28.5-32.2 MHz, EXI 51.3-63.4 MHz, 8/8 PASS.  Best seed 2
(clk 32.19, EXI 63.23), flashed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-10-09 11:44:03 +02:00
2026-06-13 19:02:58 +02:00
2026-08-28 10:29:41 +02:00
2026-06-16 14:59:18 +02:00
2026-08-28 10:29:41 +02:00
S
Description
No description provided
60 MiB
Languages
Python 84.9%
C 12.4%
Shell 1.1%
Dockerfile 0.7%
Makefile 0.4%
Other 0.5%