RXFrameAssembler ignored RRP entirely, so it lapped the reader: a traffic
burst overwrote pages the GC had not read, and the "descriptor" the driver
then parsed was frame data from whatever had replaced it. That is where the
hardware's 00 00 00 01 came from -- not a dropped write.
This is a product bug, not just a netboot one. Until now ANY burst could
corrupt a frame Swiss was midway through reading, with nothing to indicate it
had happened.
The assembler now takes the GC's read pointer and computes free space as
(rrp - rwp - 1) mod 15. On a frame start with fewer than 6 free pages -- the
worst case for 1518 bytes plus a 4-byte descriptor -- it enters DROP_FRAME,
discards to EOF, and pulses rx_overflow, which sets IR[7] (RBFI). That is the
bit the GC's IMR = 0x86 already enables, so a driver that loses a frame is
told so instead of reading corruption.
Deliberate details:
- rx_ready stays HIGH while dropping. Stalling the ethernet master instead
would back-pressure into the W5100's own buffer and turn a dropped frame
into a wedged receiver.
- Six pages are reserved up front because a frame's length is not known
until EOF. Starting with less risks running into unread data partway
through, which is worse than refusing cleanly.
- have_room is REGISTERED, not combinational. Feeding a mod-15 subtract and
comparator into the FSM branch cost real depth in `sync`, the domain with
the least margin: clk fell 27.8-32.2 -> 27.0-28.0 MHz. Registering it
restored 28.4-31.4. One cycle of staleness is harmless -- rwp moves only
at end-of-frame and rrp only when the GC writes it.
T4 proves the property that matters, and the negative control REPRODUCES THE
HARDWARE FAULT IN SIMULATION: with the check removed the unread page reads
back as [245, 248, 251, 254, ...] -- frame data where a descriptor belongs.
First time one of today's RX faults has been reproducible on this side rather
than inferred from the console. T4 also checks the receiver un-latches once
RRP advances, so a full ring cannot kill RX permanently.
Fixed a test artifact in the same pass: rx_overflow fires on the very tick
that consumes the EOF byte, inside send_frame, so polling for a 1-cycle pulse
afterwards missed it and a correctly-dropped frame looked like a stall. Both
pulses are now latched in the tick helper.
netboot also clears IR (including RBFI) at init so a stale bit is not
inherited from an earlier run.
--seeds 8: clk 28.4-31.4 MHz, EXI 55.2-62.7 MHz, 8/8 PASS. Best seed 4
(clk 31.39, EXI 61.85), flashed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Hardware dump: "frame 1 (110 B) etype=6c86 at 12: 72 33 33 00 00 00 16 00".
33 33 00 00 00 16 is an IPv6 MLDv2 multicast MAC from the host, but it sits at
offset ONE, behind a leading 0x72 -- and 0x72 is 114, the low byte of the
W5100's MACRAW 2-byte length prefix. Hence 6c86 at offset 12: the last byte
of the source MAC and the first of 86DD, both one byte late.
An earlier dump in the SAME build read FF FF FF FF FF FF 00 2B, perfectly
aligned. Two frames, one build, different alignment -- that is a lapped read
of a partially overwritten page, not a systematic off-by-one. The alignment
fix is intact.
Two self-inflicted costs removed from the poll loop, whose speed is exactly
what decides whether the writer laps us:
- The 32-byte hex dump ran on EVERY frame, adding an EXI transaction per
iteration. The diagnostic was making the fault it was diagnosing worse.
It now runs only when a descriptor is actually rejected.
- RRP was re-read from the device every poll, costing another transaction
for a value we had just written ourselves. It is now tracked locally and
kept in step at the three places that move it.
That takes the per-frame cost from six EXI transactions to four. It does not
make the race winnable on a busy link -- the ring is 15 pages and has no
overflow protection -- but it stops me handing back a loop that is slower than
the one that produced the measurement.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The alignment bug is FIXED -- hardware now reports "frame 1 (342 B) etype=0800
at 12: FF FF FF FF FF FF 00 2B", i.e. broadcast dst at 0, host MAC at 6,
ethertype at 12. Perfectly aligned, correctly received, correctly skipped as
not ours.
So 00 00 00 01 was never a dropped write. It is frame data being read as a
descriptor, because the ring HAS NO OVERFLOW PROTECTION: nothing in the
gateware consumes RRP, so RXFrameAssembler keeps writing and laps the reader
(the real BBA has RBFI for exactly this). The poll loop costs ~5 EXI
transactions per frame (~200 us) while a 100 Mbit link delivers a 342-byte
frame every ~30 us, and the ring is 15 pages -- roughly 3 to 11 frames. Under
continuous traffic pages are reused before they are read. That is also why it
"worked once out of three tries": it is a race against the host's background
traffic.
ring_next() now returns -4 when the writer is more than two thirds of the ring
ahead, and the caller resyncs and continues instead of parsing bytes that
belong to a different frame. The timeout reports seen / bad-descriptor /
lapped counts so the three cases stay distinguishable.
Detection is not prevention, so the app and the README both now say to quiet
the link first with gc-testlink.sh, which sets a static address and takes the
interface out of NetworkManager -- stopping the DHCP client whose 342-byte
broadcasts are the main offender.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Pressing Z failed instantly, BEFORE the sender was started -- so the frames
in the ring were stray traffic from the host (mDNS, IPv6 RAs, ARP), and a
single descriptor we could not parse aborted the whole transfer. On a live
network that is guaranteed to happen.
A bad descriptor is now non-fatal: log the first few, resync RRP to the
gateware's RWP, and keep waiting. Capped at 200 so a genuinely broken ring
still terminates rather than spinning. This also removes the dependence on
the ring being quiet when Z is pressed, which was never a reasonable
assumption.
The descriptor 00 00 00 01 persists after fixing both dropped-write bugs, and
grep confirms no bare `ready` tests remain, so it is NOT that. Rather than
theorise a fourth time, the error path now dumps 32 bytes from the head of the
offending page. That distinguishes the two remaining possibilities outright:
an ethernet header at offset 4 means the descriptor length is simply wrong,
while a header at 3 or 5 -- or at 0 -- means we are reading the wrong place.
Also dumps the first frame whose ethertype does not match, with the ethertype
read at offset 12, because a body written at the wrong offset would show the
ethertype at 11 or 13. And the timeout now reports how many frames were seen
and how many descriptors were rejected, so "no match" is distinguishable from
"nothing arrived".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two separate problems, one of which was hiding the other.
1. The diagnostics were unreadable. do_netboot() printed them and returned,
and the caller's draw_main() redrew immediately and wiped the screen -- so
two consecutive failures were reported only as "a short flash" with no
detail, and the error code alone was not enough to act on. nb_pause() now
holds the screen until a button is pressed, on every failure path.
This cost two blind round trips, each of which needs a hand copy of the
.dol to the SD card. Printing a diagnosis and then erasing it is worse
than not printing one.
2. The default block was 1024 bytes, making ~1050-byte frames that span FIVE
of the SPRAM ring's 15 pages. The only multi-page frame ever proven on
this hardware is the 342-byte DHCP broadcast from bring-up, which spans
two. Five-page frames are untested territory, and a transfer is the wrong
place to discover a wrap bug.
Default is now 256 bytes -> ~296-byte frame -> two pages, deliberately
close to the proven case. --block raises it once small blocks work; the GC
still caps at NB_BLOCK_MAX = 1024.
ring_next() also keeps the four raw descriptor bytes and the page it read
them from, and the error path prints them. When a length is rejected those
bytes ARE the diagnosis: 00 00 xx xx tells us the assembler wrote a
descriptor and the length is simply unexpected, whereas garbage tells us we
are reading the wrong page.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Pressing Z returned "net-update failed (-2)" -- ring_next() rejecting an RRP
outside the ring (pages 1-15) before a single frame was read.
The pointer was never ours to assume. Swiss initialises the BBA before
launching us and writes RRP itself, and an NCRA reset does NOT restore the
register file's copy of either pointer: their init values only apply at FPGA
configuration. So RRP can legitimately be anything on entry, including 0,
and the previous code treated that as a fatal error instead of a state to
establish.
netboot_receive() now reads RWP and writes RRP = RWP after the reset, which
declares the ring empty and consistent whatever it was, so the first frame
read is genuinely the host's first block. RWP itself is still checked,
because that one IS the gateware's own pointer and an out-of-range value there
would be a real fault rather than inherited state.
The ring-error message now reports RRP and RWP and spells out which of the
three failures it was (EXI access, RRP out of range, implausible descriptor).
Each test costs an SD card copy by hand, so a bare error code is not worth the
round trip.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Pressing Z straight after launch is the normal case, and in that case NOTHING
has issued the NCRA reset that triggers the W5100's own init. MACRAW would
not be running, no frames would be stored, and the transfer would sit in
"timeout: no frames" for a reason with nothing to do with netboot -- the most
confusing possible first-run failure.
Swiss may have initialised the adapter, or an earlier test may have, or
neither. An NCRA reset here makes all three cases identical: poll until the
RESET bit self-clears, wait out the W5100's 60.3 ms settle (twice over, hence
400 ms), then set the SR bit so RXFrameAssembler actually writes the ring.
Resetting also clears the SPRAM ring pointers, which is wanted rather than
incidental: a clean ring with RRP == RWP == page 1 means the first frame we
see is genuinely the host's first block, not a leftover from a test.
PAR0-5 is now read AFTER the reset, so the source address in our ACKs is the
one the adapter is actually filtering on.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Without this, a successful transfer of a BROKEN build stranded you: the only
copy of a working test program had already been overwritten, so there was no
way to attempt another transfer without an SD card reader.
Write order is now temp -> verify -> rotate, and the ordering is the point:
- The image goes to "<name>.tmp" and is read back and compared BEFORE
anything existing is touched. If the transfer, the write or the verify
fails, the build you are running is still on the card untouched and you
can simply try again. Previously a failed write left the destination
half-overwritten.
- On success the existing build is rotated to "<name>.prev.dol" and the temp
file takes its place. So if the NEW build turns out to be broken, boot
the previous one from Swiss and transfer again from there. One generation
back is enough never to need a card reader.
The two extensions are chosen deliberately:
- the temp file has NO .dol extension, because Swiss lists .dol files and a
half-written image Swiss offers to boot is exactly what this avoids;
- the backup KEEPS .dol, because booting it from Swiss is the whole point of
keeping it.
remove()/rename() on a file that is not there is ignored -- that is just the
first update on a fresh card. If the final rename somehow fails, the message
names the .prev.dol path rather than leaving the user to guess where their
working build went.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Previous version launched the image it had just received, which is the one
thing that cannot be made safe: a broken build hangs the console and the
checks can only catch a truncated or non-DOL image, never a plausible but
broken one.
The flow is now receive -> write to SD -> boot /boot.dol:
- netboot_sd_write() mounts the card (auto-detecting SD2SP2, then SD Gecko
slot B, then slot A), writes the image to the path the host asked for,
and READS IT BACK AND COMPARES. A half-written .dol that still parses is
exactly the failure this design exists to avoid, and the card is the one
component here with no other integrity check.
- netboot_boot_file() then loads /boot.dol -- a known-good Swiss -- and
launches that instead.
So the only image this ever jumps into is one that was already known good. A
broken test build costs nothing: Swiss comes up and can load anything,
including the previous build. If the SD write or verify fails, nothing is
launched at all and the menu is still there.
The destination path travels in the DONE frame rather than being baked in, so
the host decides where the build lands (send-dol.py --dest, default
/gc_bba_test.dol).
libfat is unmounted before the jump: leaving the card mounted hands the next
image a filesystem libfat still thinks it owns, on an EXI channel it is about
to reinitialise.
Note the SD Gecko in memory-card slot A shares EXI channel 0 with the BBA
(channel 0, device 2). libogc arbitrates, but SD2SP2 is on its own channel
and avoids the question -- hence the detection order.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The launcher committed in b438960 would have hung the console, and reviewing
it against Dennis's suggestion to test with Swiss's boot.dol is what surfaced
it -- Swiss is known-good, so a hang could only have been the launcher, but I
would not have been able to tell that from "the transfer is broken".
Two distinct defects, both from the same oversight -- a DOL's sections load
from 0x80003100 upward, which is exactly where this program is running:
1. The copier was an ordinary C function in .text, so it overwrote its OWN
instructions partway through the copy.
2. The image was staged in a memalign'd buffer, which the destination sections
can overwrite while it is still being read from.
Fixes:
- netboot_stub.S: the copy/zero/cache-flush/jump sequence in position
independent assembly, copied into reserved memory and executed THERE. It
has no globals, no literal pool, no TOC references and no calls, because
any of those would read from the address it was LINKED at rather than the
one it is RUNNING at. It also does the dcbf/icbi pass the C version was
doing through DCFlushRange -- without it the CPU executes stale icache
lines at the entry point.
- netboot_reserve(): carves the top of MEM1 and hands it to
SYS_SetArena1Hi() so neither libogc nor malloc allocates there. Called
FIRST in main(), before the framebuffer.
- netboot_launch(): verifies every text/data section AND bss against the
reserved region and refuses (-3) if any would land on it, instead of
corrupting the staged image or the copier mid-flight. Also hands the new
image a stack inside the reserved tail.
The app now tells you on screen to send Swiss's boot.dol first, and the README
explains why: the launcher and the transfer can each be broken independently
and a hang looks identical, so the first send should be an image whose success
is unmistakable.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Copying to SD and rebooting is now the slowest part of the loop. Z in the
test app pulls a new .dol over the adapter and launches it.
Deliberately NOT built on an IP stack. Frames carry a private ethertype
(0x88B5, IEEE 802 local experimental 1) and a 12-byte header, so there is no
ARP, no IP, no checksums, and no libogc network driver competing with our raw
driver for the EXI channel. It reuses exactly the two paths the suite already
proves on hardware: bba_tx_bytes() for TX and the SPRAM ring at RRP for RX.
A side benefit is that each update is a few hundred round trips through that
path -- a soak test we did not have.
STOP-AND-WAIT is load-bearing, not laziness. The gateware does not consume
RRP, so RXFrameAssembler can overwrite ring pages the GC has not read yet;
there is no overflow protection. One block in flight means the ring never
holds more than one unread frame, so the missing protection cannot bite. Both
the header and the README say not to make this a sliding window without adding
RBFI-style protection first.
Failure behaviour, so a bad update never costs a power cycle:
- 30 s idle with no frames, or 5 s mid-transfer, aborts to the menu rather
than hanging.
- A duplicate block is RE-ACKed rather than ignored, because a duplicate
means our previous ACK was lost and re-ACKing is what lets the host move
on.
- netboot_receive() re-asserts the NCRA SR bit first: an earlier test may
have left receive disabled, and then this would wait forever for frames
the gateware is not storing.
- netboot_launch() refuses an image whose entry point or first text section
is not in MEM1 instead of jumping into a mis-parsed header.
The jump itself is the one unavoidable risk: once sections are copied and
interrupts are off, a bad image hangs the console hard enough to need a power
cycle. The MEM1 check is what stands between a truncated transfer and that.
Host side is scripts/send-dol.py (AF_PACKET, needs sudo). The GC's MAC is
discovered from its first ACK, so neither side needs an address configured.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
t_dma reported "descriptor len implausible (ring empty?)" and skipped on a
board that had just PASSED the RX test, so a frame had certainly arrived --
RWP advanced and RI fired. The test was looking in the wrong place.
RWP/RRP are PAGE pointers into the 15-page ring, so the next unconsumed
frame's descriptor lives at RRP*256. Reading SPRAM_BASE (0x0100)
unconditionally only works while nothing has been consumed and the ring has
not wrapped; once RRP has moved, 0x100 holds a stale or overwritten page.
t_dma now reads RRP, streams from RRP*256, and distinguishes the cases it used
to lump together:
- RRP == RWP -> genuinely empty, SKIP, and says to send it a frame
- page outside 1-15 -> FAIL, with the page number
- implausible len -> FAIL, and reports RWP too so it is diagnosable
The old message could not tell "no frame yet" from "looked in the wrong
place", which is exactly why the skip was mysterious.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The whole gc_bba_test suite now passes on a real GameCube: Identity (device
ID 04 02 02 00, HIPR, NWAYS), Registers, Reset/control, EXI integrity (speed
sweep ok=[1,1,1,1,1,1], per-speed dump clean at all six indices, raw reg dump
0x17 in slot 0), Ethernet, and SPRAM/DMA -- at the real 27 MHz EXI rate.
The one reported failure was t_raw_id, and it was not a fault: an earlier
suite had already issued the NCRA reset that clears id_phase, after which
address 0 correctly reads back NCRA. t_devid already guarded for this; t_raw_id
did not, so a full run cried wolf. It now returns SKIP like t_devid, and both
messages say reflash/reset the FPGA rather than power-cycle the console, which
is what actually restores id_phase.
CLAUDE.md records the device-ID fix and, importantly, that simulation CANNOT
reproduce the bug it fixed -- bba_top passed the ID at EXI_HALF=1 beforehand,
because sim's sync-to-EXI latency ratio does not match silicon closely enough
to miss a 296 ns window. Anyone "simplifying" the ID back into the register
file will keep a green suite and break hardware.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Removing ~9 ns from the MISO path (EXI_J4 merge, the CS mux, then the whole
fabric route via an SB_IO output register) left the hardware result BYTE
IDENTICAL: 0B 80 at index 5, ok=[1,1,1,1,1,0]. A ~9 ns reduction against an
18.5 ns half-period budget cannot change nothing if propagation were the
cause, so it is not, despite being speed-dependent.
t_raw_sweep reads the same 8 slots at EVERY speed index and reports the first
two bytes per index, so the shift can be seen as a curve rather than a single
point: a shift that appears or grows with clock rate is a timing problem, one
that is constant across indices is structural. Run against a PHASE_METER
bitstream it reads the bit engine's byte phase directly at each speed, with
the register file and both byte FIFOs out of the path.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Reading one byte and getting 0x00 cannot distinguish 'decode is wrong' from
'reply is late' -- a one-byte window has nowhere for a late answer to show up.
These two probes clock EIGHT data bytes and print every slot, so the position
of 0x17 (NWAYS) or 0x04 (device ID) gives the latency directly, the same way
bit-shift analysis turned 00 00 00 10 into 'correct, 22 bits late'.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
'highest good = 0' meant both 'only index 0 works' and 'nothing works', which
are opposite diagnoses -- the first says oversampling, the second rules it
out. Now reports the per-index map and says NONE explicitly.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Replaces the invented 2-byte header (addr split across both bytes, 2-bit
length field) with the protocol libogc and Swiss actually speak:
command (bit7=0, 6-bit reg) [reg, 00, 00, data] one 4-byte transfer
register (bit7=1, 16-bit reg) [0x80|w<<6, ah, al, 00] + data until CS
This was not an optimisation: the old decoder read Swiss's NWAYS read
(80 00 31 00) as 'write 0x31 to NCRA', and bit 0 of 0x31 is RESET, so every
register read would have reset the device.
Changes:
* 16-bit address; no length field -- register reads and writes now stream
until CS, like the SPRAM path already did
* RHDR_LO starts the SPRAM fetch as soon as the address completes, using
the trailing header byte as the prefetch window the protocol provides
* command space serves EXI regs 0x02/0x03 (interrupt mask/status), the only
two Swiss uses
* EXI_GetID gets its own path: it offers just ONE header byte of warning, so
the first ID byte is pushed the instant byte 0 identifies the query
Two timing subtleties, both found by simulation and commented in place:
* MISO is driven LIVE from the tx FIFO head, so a byte pushed while the pad
byte is on the wire appears in the pad slot. A filler byte is parked
there (MISO is don't-care through the header) so the first real response
lands in data slot 0.
* the prefetch must be one-shot; re-firing while waiting for the pad byte
consumed the register stream early and shifted reads by a byte.
All testbenches updated to the real format and passing: bba_register_file
(7), bba_top (8 incl. the full W5100->SPRAM->GC loop and TX), exi_j4,
exi_capture, spi_mode3_slave, tx_frame_drain, spram_arbiter,
rx_frame_assembler, w5100_parallel_master. gc_bba_test rebuilt against the
new protocol.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
First on-console run: the Identity suite failed with the device ID reading
00 00 00 10 instead of 04 02 02 00. Bit analysis shows that is an EXACT
match for the correct stream delayed by 22 bits -- the device answers
correctly, just too late for a 32-clock window to catch more than its first
set bit. Not corruption, and not a broken link: response latency.
At EXI index 5 (~27 MHz) 22 bit-times is ~815 ns, which is about what the CDC
chain costs (rx AsyncFIFO capture->exi, register-file decode, tx AsyncFIFO
exi->capture, SPI engine) at a 24 MHz exi clock. The design expects the GC to
hold the clock idle between the header write and the data read so the register
file can prefetch the response; libogc's inter-call overhead alone is not
enough at full speed.
Adds bba_gap_us (default 16 us, busy-waited with CS asserted since we hold the
EXI lock) and a Gap sweep test that reports the minimum clean gap at the
current speed -- which measures the latency rather than guessing at it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
libogc's EXI functions return '1 on success, <=0 on error', but every call
site tested '== 0'. A -1 error return therefore read as success, so a failed
EXI_Lock or EXI_Select would fall through and the subsequent transfer would
produce garbage reported as a misleading test failure rather than an EXI
error. All six call sites now test <= 0.
Also retries EXI_Lock for ~100 ms: it fails outright rather than blocking when
another subsystem holds the channel, and Swiss or a libogc driver may hold it
briefly -- without the retry a transient collision surfaces as a test failure.
Builds clean with devkitPPC 16.1.0 / GCC 16, no warnings: 172 KB .dol.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gc_bba_test/ builds a .dol that drives the adapter over raw EXI from the
console and reports pass/fail per test on the TV, navigable with the pad.
Uses libogc's EXI API against EXI0:2 (Serial Port 1) rather than its bba
network driver: driving the register file directly gives each check its own
verdict, so a failure points at a specific register instead of at
'networking'. Six suites - identity, registers, reset/control, EXI link
integrity (including an EXI clock-index sweep), ethernet TX/RX, SPRAM/DMA
streaming.
Encodes the hardware lessons from bring-up so the app cannot mislead:
* the device ID is a one-shot cleared by the first NCRA reset, so it is
reported SKIP on a re-run rather than FAIL
* TI means the frame reached the W5100, NOT the wire - the TX test says so
* register reads clock exactly the requested length (over-clocking
desynchronises the next transaction)
* TXDATA is written one byte per transaction (eff_addr auto-increments)
.devcontainer/Dockerfile gains the devkitPro gamecube-dev group. devkitPro
publishes no .deb on GitHub, so this uses their installer script against
apt.devkitpro.org -- which is 403 from inside the running container's egress
but reachable from a host-side docker build. Rebuild the container to get it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Roflin