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>
Roflin