Swiss reported "failed to write file" then "Failed to setup the file (too
fragmented?)". The FSP device declares FEAT_READ|FEAT_WRITE|FEAT_BOOT_GCM|
FEAT_PATCHES, so booting a disc image from FSP is supported -- but Swiss
writes patch files to swiss/patches/ first, and deviceHandler_FSP_setupFile
returns failure when that write fails, which the UI reports as the fragment
message.
Implements CC_UP_LOAD (0x43), CC_INSTALL (0x44), CC_MAKE_DIR (0x49),
CC_DEL_FILE (0x45) and CC_DEL_DIR (0x46), all confined to --root. --writable
(aliased as --claim-owner) enables them and reports FSP_DIR_OWNER, so the two
can no longer be set inconsistently: previously --claim-owner told Swiss it
could write to a server with no write support, which is exactly the
combination that produced the error.
⚠️ CC_UP_LOAD CARRIES NO FILENAME. fsplib calls buildfilename() only on the
read branch, so the data field is RAW FILE BYTES at `pos` and CC_INSTALL names
the destination afterwards (temp-then-commit). Handling UP_LOAD after the
path/password parse rejects every chunk as a bad password, so it is handled
before it; the password is validated on INSTALL, which does carry the path.
`pos` must also be echoed, because fsp_transaction checks it for UP_LOAD.
Tests: MAKE_DIR creates the directory, two 1024-byte UP_LOADs plus INSTALL
commit byte-exact content, writes outside --root are refused, and GET_PRO
reports OWNER when writable. Mutation-tested: moving UP_LOAD back below the
password parse fails T11 with CC_ERR on every chunk.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The trace settled it: our reply satisfies EVERY check fsplib makes --
fsp_pkt_read's checksum (0x9a computed, 0x9a present), len <= recv_len,
(reply.seq & 0xfff8) == s->seq, cmd match, and fsp_getpro's pos ==
FSP_PRO_BYTES with the flags byte at buf[len]. Yet the console retried the
same transaction (seq 0x8ccb -> 0x8ccc, txn 0x8cc8 try 3 -> try 4).
The decisive evidence is the key: fsplib calls client_set_key(rpkt->key) on any
ACCEPTED reply, so the next request would carry our 0x1234. Every request
still carries 0x8022. No reply has ever been accepted -- so they are not
arriving, and the problem was never the protocol.
What differs from the thing that worked: mini-dhcpd.py replies over AF_PACKET
and got a DHCP lease immediately, while this server used a normal UDP socket,
whose reply depends on the kernel having a route to the console, an ARP entry
for it, and choosing the right source address. (AF_PACKET also never populates
the kernel ARP table, so DHCP succeeding tells us nothing about those.)
--iface <dev> now replies with raw ethernet frames that MIRROR the request's
own addresses -- MACs swapped, IPs swapped, ports swapped -- which removes
routing, ARP and source-address selection in one go. The UDP path is kept for
when it is not needed.
Frame construction is tested: the reply carries the console's MAC as
destination and ours as source, source IP 10.0.0.1 and destination 10.0.0.64
taken from the request, ports 21 -> 4096, a valid IP checksum, correct UDP
length, and padding to the 60-byte ethernet minimum.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Swiss is still stuck on "setting up device" and the log shows five identical
GET_PRO lines -- but there was no way to tell whether that is ONE transaction
being retried (our reply rejected or lost) or five separate transactions
(Swiss looping at a higher level). Those have completely different causes and
the log could not distinguish them.
fsp_transaction puts a random value in seq & 0xfff8 per transaction and the
retry counter in seq & 0x7:
p->seq = (s->seq) | (retry & 0x7);
so the split is the diagnostic. Every request now logs
seq=0x.... [txn 0x.... try N]: same txn with climbing try means our reply is
being rejected; different txn each time means the client gave up and restarted.
--trace additionally hexdumps every request and reply with key/pos/len/xlen,
so a reply can be verified by hand against fsp_pkt_read instead of trusted.
All replies now go through one reply() helper rather than scattered sendto
calls, which is what makes tracing them possible at all.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Swiss hung on "setting up device" while the server logged perfectly reasonable
GET_PRO replies. fsplib was dropping every one and retrying -- visible in the
log as the same request repeating with the low 3 sequence bits counting up,
since fsp_transaction encodes the retry number there.
FSP has TWO checksum formulas and they differ by the packet length:
fsp_pkt_write (what a client SENDS):
checksum = sum(bytes, sum byte zeroed) + used
sum_byte = checksum + (checksum >> 8)
fsp_pkt_read (what a client ACCEPTS):
mysum = sum(bytes) - sum_byte <- no length term at all
ok if ((mysum + (mysum >> 8)) & 0xff) == sum_byte
cube/patches/bba/tcpip.c matches the WRITE form (`sum = size` to start) and
never verifies replies, so the in-game path tolerated our packets; the menu's
fsplib did not. Replies are now built the way fsp_pkt_read verifies.
Incoming requests are accepted under either formula, since a tolerated request
is far easier to diagnose than a rejected one.
⚠️ The self-test passed throughout the bug, and that is the part worth
remembering: it verified replies with the SERVER'S OWN checksum function, so
the two agreed with each other and disagreed with Swiss. Identical in shape to
the RX descriptor format, where our writer, our readers and our tests were all
self-consistent and all wrong. The test now transcribes fsp_pkt_read literally
as fsplib_verify() and checks every reply against that, and mutating the server
back to the with-length formula fails it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Swiss sent CC_GET_PRO 'swiss/patches' and the server replied "unsupported".
Reply shape, from fsplib's fsp_getpro:
* pos MUST equal FSP_PRO_BYTES (1), or fsplib fails with ENOMSG
* the flags byte is at buf[len] -- the first byte of the EXTRA region,
after the echoed name, NOT inside the data field
* a missing directory must be CC_ERR so fsplib reports ENOENT, because
Swiss probes "swiss/patches", then "swiss", then "" and relies on that
fallback chain
Those bits are not cosmetic. deviceHandler-FSP.c does:
if ((pro & (MKDIR|ADD|DEL|GET)) == (MKDIR|ADD|DEL) || (pro & OWNER)) {
features |= FEAT_PATCHES; emulable |= EMU_ETHERNET;
} else { ... clears both ... }
so a plain read-only answer makes Swiss DISABLE patch support on this device.
Default is therefore the honest GET|LIST (0x50) with patches disabled, and
--claim-owner reports OWNER to turn them back on -- flagged in the help as
unsafe for now, because this server has no UP_LOAD or MAKE_DIR, so Swiss
believing it can write here would make a patch write fail rather than degrade.
Try without it first.
T9 checks pos == 1 and that the flags land at buf[len] with GET|LIST and
without OWNER; T10 checks a missing directory gives CC_ERR so the fallback
chain works.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
sudo ./scripts/fsp-server.py --root /workspace --password alltheroms
Swiss streams games over FSP/UDP rather than TCP, so hosting an image needs an
FSP server. Serves a directory read-only: VERSION, STAT, GET_DIR, GET_FILE,
BYE, with CC_ERR for anything else. Reports the achieved read rate every two
seconds, which is the measurement this was really built for -- the 850 KB/s
figure came from the menu's lwIP/TCP path and says nothing about streaming.
The protocol was taken from Swiss's own two clients rather than from memory,
because they disagree about nothing but exercise different commands:
cube/swiss/source/devices/fsp/fsplib.c (menu: browse, stat, read)
cube/patches/bba/tcpip.c (in-game streaming reads)
Details that are easy to get wrong, all verified against that source:
* checksum: sum = total_size + every byte with the checksum byte zeroed,
then sum += sum >> 8, low 8 bits.
* password: the data field is "path\npassword\0" -- the '\n' REPLACES the
path's terminating NUL (fsplib buildfilename), it is not appended after it.
* GET_DIR: entries are time(4) size(4) type(1) name(NUL) padded to 4 bytes;
the client reads blocks until one is shorter than the first, so the whole
listing then an EMPTY reply is what terminates it. dirpos % 4 != 0 is
rejected outright by fsplib, hence the alignment padding.
* STAT: the same 9-byte time/size/type prefix; type 0 means ENOENT.
* GET_FILE: sequence AND position must be echoed -- the in-game client
discards any reply where either differs.
* ⚠️ a GET_FILE reply must be a multiple of 32 bytes unless it is the tail,
because the in-game client does
data_size = MIN(requested, OSRoundDown32B(reply_len))
so a non-32-aligned reply is silently rounded DOWN and the stream stalls.
test-fsp-server.py runs a real server on 127.0.0.1 and drives it with a client
that packs requests exactly as Swiss does: checksums verify both ways, STAT
returns the true size, GET_DIR parses with fsplib's own walk and the second
page is empty, GET_FILE returns byte-exact data at three offsets with seq and
pos echoed, a 1024-byte request comes back 32-aligned, a wrong password gives
CC_ERR, and ../../etc/passwd is refused.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
./scripts/check-gcm.py dvd.iso
Checks the header (DVD magic, game/maker code, title, DOL/FST offsets,
apploader), parses the FST, then READS EVERY FILE -- because a dump that lost
data still has a perfect header, so structure alone proves nothing. Also
reports how much of the image the filesystem accounts for, which is where a
truncated or zero-filled tail shows up, and prints SHA-1 for comparison
against a reference or a second dump.
⚠️ The zero-run heuristic was wrong in its first form and the fix is the
interesting part. Flagging any zero run >= 32 KiB as a dropped transfer gave
7 false positives on a known-good Wind Waker dump, all in
Audiores/Stream/*.afc: streamed audio legitimately begins with silence right
after its 16-byte header.
What a dropped transfer actually looks like is a run ALIGNED to the transfer
granularity -- whole 2048-byte disc sectors, because nothing reads or writes a
fraction of a sector. Structural silence starts and ends wherever the audio
does. So alignment is the discriminator, not length. Sector-aligned runs are
now a failure; unaligned ones are reported as structural with that reasoning
spelled out.
.gitignore: *.iso and *.gcm, so a 1.4 GB dump sitting in the workspace cannot
be committed by accident.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The 850 KB/s dump measurement does not bound ROM streaming, and the tool could
not have measured streaming at all: it only counted TCP payload, so a
streaming capture would have reported ~zero throughput.
Swiss's ROM streaming runs in the game via the patch driver's own stack
(cube/patches/bba/tcpip.c), which contains no TCP whatsoever -- UDP + FSP,
plus ICMP and ARP. Reads are sized to the path MTU rather than 1024:
_fsp.data_length = MIN(length, env->pmtu - (fsp->data - eth->data));
so ~1446 B of payload per datagram at a 1500 MTU, with QUEUE_SIZE 2
outstanding and udp->checksum = 0x0000 (no payload checksum). None of the
menu path's TCP window, lwIP overhead or 1024-byte writes apply.
The analyser now counts UDP payload and picks the bulk direction by which way
the payload actually flows -- streaming is PC -> GC, the opposite of a disc
dump -- with --bulk to_gc to steer the gap analysis. Self-test H replays the
streaming shape (1446 B datagrams, 2 per request) and checks the bulk
direction is identified and the payload counted.
Recorded in the TODO that "can it stream?" is still OPEN, but open on the GC's
side: the dump established the adapter has headroom (zero retransmissions,
~17% W5100 bus utilisation, 26% of the EXI ceiling). The hard ceiling is
3375 KB/s and the GC's disc delivers ~2000-3100 KB/s, so full disc rate has no
margin -- but games read in bursts, not continuously at peak.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Swiss dumping a disc over the adapter measures 850 KB/s (6.97 Mbit/s, 25.8% of
the 27 Mbit/s EXI ceiling). The capture decomposes it completely:
18395 data frames / 9200 ACKs = 2.0 frames per ACK
18.84 MB / 9200 = 2048 B per round trip
22.78 s / 9200 = 2.48 ms per round trip
2048 B / 2.48 ms = 826 KB/s ~= the measured 850
So the flow is window x RTT bound and nothing else. Payload per frame is
exactly 1024 B (wire 1078 minus 54 of headers) against a 2920 B window, so two
segments fit in flight. Zero retransmissions means the 15-page ring never
overflowed; 0.2% stall time means nothing waits on the disc; our W5100 bus
engine sits at ~17% utilisation. The adapter is not the constraint.
Levers, and the first two are not ours: a larger lwIP TCP_SND_BUF (scales
almost linearly while window-bound), and full-MSS segments -- Swiss writes
1024 B at a time, so the same window and RTT at 1460 B would give ~1150 KB/s,
a 1.43x gain for free. Third is a shorter round trip, which is GC-side
interrupt dispatch plus lwIP, plus EXI lock contention: libogc2's
bba_event_handler defers when EXI_Lock fails, so RX queues behind TX on the
single channel.
⚠️ This REVERSES an earlier recommendation in the TODO. RX interrupt
coalescing (NCRB.RXINTC, RXINTT) was listed as a throughput lever; for a
window-bound flow it makes things worse, because delaying the ACK's interrupt
lengthens the round trip and throughput is bytes-per-round-trip / RTT. The
measurement showed the guess was backwards. Noted in item 3 as "implement for
fidelity, not for speed".
analyse-pcap.py now derives frames-per-ACK, bytes-per-round-trip and the
implied RTT itself, identifies a window-bound flow, quantifies the full-MSS
gain, and warns against coalescing -- so the next person gets the conclusion
rather than the raw numbers. Self-test G replays this exact shape.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Swiss dumps a disc over the adapter at 740-780 KB/s, which is ~23% of the
27 Mbit/s EXI ceiling (3375 KB/s), and no published real-BBA figure exists to
compare against. Rather than reason about where the rest goes, measure it.
./scripts/analyse-pcap.py /tmp/bba.pcap --gc-ip 10.0.0.64 reports, per
direction: throughput as a fraction of the EXI ceiling, MEAN FRAME SIZE,
retransmissions, the GC's advertised TCP window, zero-window spans, and the
largest gaps between data frames. Each one discriminates a different
bottleneck:
mean frame far below 1514 -> per-frame overhead (interrupts, EXI
transactions, socket bookkeeping) dominates
retransmissions -> we are dropping frames, e.g. the 15-page RX
ring overflowing (RBFI)
small advertised window -> capped at window/RTT regardless of the wire
zero-window spans -> the GC cannot drain: CPU/stack bound
large gaps, little sending -> the limit is upstream of the wire entirely
(disc read, CPU, stack), not the adapter
Classic pcap only, stdlib only, no root. pcapng is detected and refused with
a conversion hint rather than misparsed.
scripts/test-analyse-pcap.py synthesises captures with known properties and
checks each conclusion is reached: 1000 full frames in 2 s reports ~22% of the
ceiling, 200-byte payloads raise the overhead warning, a repeated seq counts 9
retransmissions, one 300 ms hole in 100 frames is found and attributed, a
zero-window span is called CPU/stack bound, and a pcapng header is rejected.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Swiss got a DHCP lease on hardware (10.0.0.64/24), but the script flagged
every ARP from the GC as "frame did NOT parse as DHCP ... this is what a
corrupted TX frame looks like". That was wrong and actively misleading: the
frames are valid lwIP duplicate-address probes (sender 0.0.0.0, target =
the offered address), sent to check the lease is free before accepting it.
The parser conflated "not DHCP" with "corrupted". A diagnostic that cries
wolf on normal traffic is worse than none, because 'malformed' then means
nothing. Now:
'info' from the client but not DHCP -- ARP decoded properly (probe vs
request vs reply, with addresses), other ethertypes named
'malformed' CLAIMED IPv4/UDP->67 and then failed to parse, i.e. what a
genuinely damaged TX frame would look like
So the corruption diagnostic still works -- that was the point of using a raw
socket -- but it only fires when it means something.
scripts/test-mini-dhcpd.py keeps the self-test, now including the exact
60-byte frame from the console (T6), a damaged DHCP packet that must still be
flagged (T7), and a raw ethertype (T8).
One note for anyone extending that test: the real frame goes in as ONE string
literal. Splitting the hex across two adjacent literals is how the first
version of T6 silently lost a byte and blamed the parser for decoding the
target as 0.10.0.0 -- the parser was correct.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
sudo ./scripts/mini-dhcpd.py enp0s31f6
Serves one address, logs every exchange, and does not touch the rest of the
system. Needed because the Swiss DHCP timeout proves nothing while there is no
server on the segment to answer.
Deliberately AF_PACKET rather than a UDP socket on port 67. A UDP socket only
sees frames the kernel accepts as well-formed IP/UDP, and one of the open
questions is whether the GC's frames arrive INTACT: libogc streams TX payload
with EXI_Dma and the GC's DMA-write engine is documented to have a 1-bit-shift
bug. A corrupted DISCOVER would never reach a UDP socket and the server would
look "fine, just no client". On a raw socket every frame from the adapter is
parsed by hand and anything that fails is reported as MALFORMED with the reason
and a hexdump -- which is exactly the evidence that would confirm or kill the
corruption hypothesis.
Replies go out as raw ethernet UNICAST to the client's MAC, so a successful
lease also demonstrates the new MACRAW MF filter accepts unicast to SHAR and
not just broadcast.
Self-tested without a network: a well-formed DISCOVER parses with the right
chaddr/xid, a corrupted magic cookie is reported as malformed rather than
ignored, frames from other MACs are skipped, and the generated OFFER is a valid
342-byte frame -- unicast to the client, correct IP checksum and total length,
ports 67->68, BOOTP padded to the 300-byte minimum, yiaddr as configured.
On-wire behaviour is NOT tested here; the devcontainer has only a veth.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Remaining after the bit-phase fix was a SPEED-DEPENDENT failure -- the GC read
correctly at 1/2/4/8/16 MHz and failed only at index 5 (27 MHz), returning
0B 80 = 0x17 late by exactly ONE bit. Opposite signature to the phase slip it
was hiding under, and this one really is propagation delay.
MISO is source-synchronous: driven on the falling edge, sampled by the GC on
the next rising edge, so the whole path must fit a HALF period -- 18.5 ns at
27 MHz -- minus global-buffer insertion, pad, connector and the GC's setup.
The failing build measured ~10.5 ns of that internally. Critical path:
clk-to-q 1.39 tx_shift (3,12)
routing 3.60 tx_shift[7] (3,12) -> (5,5) to the CS mux
logic 1.21 Mux(cs_n, 1, ...) LUT
routing 4.79 miso (5,5) -> (17,0) to the J4 MISO pad
10.99 ns (2.60 logic, 8.39 routing)
Two removals, both of things that were pure cost here:
1. EXI_J4 is GONE entirely (exi_j4.py, the resource, the AND merge, the docs
section, scripts/pi-exi-wirecheck.py) -- recoverable from git history. The
AND put a LUT in the CLOCK path, denying the EXI clock pad its dedicated
global-buffer route, and MISO fanned out to the J4 pad at die (17,0) which
was the far end of the critical output path: 4.79 ns of routing to a header
with nothing plugged into it. 10.2-11.5 ns -> 9.3-9.6 ns.
2. The Mux(cs_n, 1, ...) LUT is gone from the MISO data path. It only parked
MISO high when deselected, which the flop's own reset value does for free:
tx_shift now has init=0xFF and CS is that domain's async reset, so MISO is
tx_shift[7] with nothing in between. Removes 1.21 ns of logic plus the
3.60 ns route feeding it and lets the placer sit the flop by the pad.
synth.py now PARSES AND RANKS BY the MISO clock-to-pad delay. Ranking by fmax
was how a board that failed at 27 MHz passed every seed at >=1.29x margin --
fmax was never the binding constraint for this design.
--seeds 8: clk 28.7-32.5 MHz, EXI 49.6-62.1 MHz, MISO 8.38-10.22 ns, 8/8 PASS.
Best seed 8 (clk 30.35, EXI 49.56, MISO 8.38 ns), flashed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sets the PC to 10.0.0.50/24 so the GC test suite's RX test can pass: its TX
test ARPs for that address and the kernel answers ARP for an address it
actually holds, so no listener process is needed. Without it RX fails
legitimately for lack of traffic.
Handles the NetworkManager trap -- NM silently strips a hand-added address
within seconds, so the device is set unmanaged first and handed back on
'down'. Warns that this drops any existing connection on that NIC.
up / down / status / watch, with wired-interface auto-detection (prefers one
with a carrier) and a status readout that flags no-carrier along with the
likely cause: the W5100S rail is gated off GC_ON, so it is dead whenever the
console is off.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
First silicon proof of the EXI capture path. A Pi bit-banging EXI into J4
reads the device ID 04 02 02 00 21/21, NWAYS 0x17, HIPR 0x01, writes and reads
back PAR0-3, writes IMR, and sees NCRA's reset bit self-clear.
Fixes two host-side bugs found getting there:
- exi_devid_rpi.py sampled MISO just after the rising edge, racing the slave's
own update and landing one bit early (04 came back as 08). Sample in the
CLK-low phase, as the simulation does.
- pi-exi-wirecheck.py's bridge scan drove HIGH against pull-downs, but the
FPGA's SB_IO pull-up out-pulls the Pi's internal pull-down, so every pin
reported as bridged. The aggressor now drives LOW against pull-ups.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Verifies the harness before attempting a real EXI transfer. Keyed on the
EXI_J4 build's SB_IO pull-ups: an FPGA input with PULLUP=1 reads HIGH when
connected, follows the Pi's pull when open, and reads a hard 0 only when
shorted -- so all three cases are distinguishable from the Pi alone.
Includes a T0 control on known-unwired pins; without it a broken pull
mechanism would turn every 'connected' verdict into a false pass.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Reverts the 0x8000/0xC000 change from 162dbf7, which was WRONG and actively
broke transmission. The W5100S datasheet pseudo-code quotes 0x8000 (TX) /
0xC000 (RX) for the memory blocks, but the PARALLEL/indirect (IDM) interface
only decodes a 15-bit offset. Bench-proven with an address-aliasing probe:
writing distinct values to each candidate base and reading them back showed
0xC000 and 0x4000 are the SAME cell (0xC000 & 0x7FFF == 0x4000) while 0x6000
holds its own value.
Consequence of the bad base: every payload byte written to 0x9800+i aliased
down onto 0x0000+i, landing on SHAR (0x09-0x0E) and SIPR (0x0F-0x12) and
overwriting them with the payload. The chip then transmitted frames with a
garbage source MAC/IP, which the peer NIC drops without counting -- the
"SEND_OK but rx_packets=0" symptom, and the bogus SIPR0 readback (0x50 was
literally payload byte 15, 'P').
The NETLCKR unlock from 9c4bc7a is a genuine W5100S requirement and stays.
Also:
- w5100_udptest.py: self-contained configure+send+readback probe (and the
address-aliasing probe that found this), reports over UART.
- scripts/build-flash.sh: sweep N seeds and flash the best (capture timing is
seed-dependent, so the sweep is mandatory).
- scripts/uart-console.py: interactive UART console, plus --send/--read
one-shot modes for scripting.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Roflin