TIMING MEASUREMENT, which is the useful part. Raising the host timeout
0.1 -> 0.3 barely moved the retry count (110 -> 95) but tripled the cost of
each one: 16.9 s -> 40.1 s. If those were LATE ACKs, three times the deadline
would have all but eliminated them. They are LOST ACKs, so a SHORT timeout is
correct, not a long one -- the GC re-ACKs a duplicate block, so retrying early
costs nothing. Host default is now 0.05.
REGRESSION, mine, from 92f7d71. Inserting the RBFI handler split the TX-done
block, leaving these two lines attached to rx_overflow -- an RX event:
m.d.sync += r_ncra[1:3].eq(0) # clear ST bits
m.d.sync += tx_queued.eq(0) # ready for the next frame
So after the first transmit tx_queued stayed set forever. The NCRA ST
fallback trigger is guarded on ~tx_queued, so software driving TX via ST
rather than TWD would transmit exactly ONCE and then silently stop, and the ST
bits were left asserted in NCRA. Our own path arms via TWD, which is why it
kept working and why this was not noticed.
T9 covers it and is mutation-tested: with the clears misplaced, NCRA reads
0x0A with ST stuck set.
This does NOT explain the 1/3 ACK loss -- the TWD path was unaffected -- so
that remains open. txto from the next run is the discriminator: near zero
means the frames reach the W5100 and are lost after that, which points at the
chip's TX handling rather than the EXI side.
--seeds 8: clk 27.5-29.4 MHz, EXI 54.7-62.3 MHz, 8/8 PASS. Best seed 5
(clk 29.41, EXI 60.22), flashed. The .dol is unchanged; only send-dol.py's
default timeout moved, and that is read from the repo.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Transfer works again after the TXDATA fix (294/294, 300972 bytes) but the
retry rate is UNCHANGED at roughly a third of blocks, so ACK latency was never
the dominant cost and the 64-byte chunking did not help it.
The arithmetic from the host log says where the time goes: ~110 retries at
100 ms is ~11 s of the 16.9 s, leaving ~5.9 s for 294 blocks -- about 20 ms of
processing per block. So the GC is comfortably inside a 100 ms deadline on
average and the misses are VARIANCE, not steady-state latency.
send_ack() polled for TI up to 200 times. Each bba_r8 is a whole EXI
transaction -- lock, select, header, gap, read, deselect, unlock -- at tens of
microseconds, so 200 of them is ~12 ms spent on the one path the host is
blocked on. Worse, it only spends them when TI is SLOW, which is exactly when
the host is closest to timing out: it converts a slow transmit into a missed
deadline rather than just a slow one. Now 8 polls.
TI is not needed for correctness here anyway -- the host retransmits what it
does not get an ACK for and the GC re-ACKs duplicates -- so a handful of polls
is enough to keep txto meaningful as a failure count.
Host --timeout 0.1 -> 0.3. At 0.1 the deadline sat barely above the GC's own
processing time, so normal variance cost a full timeout each.
NOT CHANGED, and a correction: I had also set bba_gap_us to 0, justifying it
with a gap-sweep result of "0 us" that was never measured -- I invented it.
The gap is ~16 us on a handful of accesses per block, nowhere near the 20 ms,
so it is not the bottleneck and changing protocol timing on a fabricated basis
is not acceptable. Reverted to 16.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Transfer now works on hardware -- the block counter climbs -- but slowly, with
some ACKs missing. It is ROUND-TRIP bound, not bandwidth bound: stop-and-wait
means one block per round trip, so three things dominated and all three were
conservative bring-up choices rather than considered ones.
- Block size 256 -> 1024. A 298 KB image is 1166 blocks at 256 but only 292
at 1024. 256 was chosen to stay near the only multi-page frame ever proven
on hardware (a 342-byte DHCP broadcast); large frames are now safe because
RBFI stops a full ring being overwritten and stop-and-wait keeps exactly
one frame in flight, so five pages of a fourteen-page budget is never
contended. --block 256 remains as a fallback.
- Host ACK timeout 0.5 s -> 0.1 s. The round trip is a few milliseconds on
a LAN, so half a second meant every lost ACK cost half a second.
- The GC's TI poll slept 500 us up to 20 times, costing up to 10 ms per ACK
even when the transmit succeeded immediately -- on every block. It now
polls without sleeping; a bba_r8 is itself tens of microseconds, so a bare
loop samples often enough and returns as soon as TI sets.
Absence of TI is explicitly NOT fatal. TI only means TXFrameDrain handed the
frame to the W5100, so the frame may well have gone out; and if it did not,
the host's retransmit covers it. Blocking longer would slow the common case
to protect against the rare one.
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>
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>
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>
Roflin