Remove the device-ID one-shot: it made Swiss see no adapter at all

id_phase was set at reset and cleared permanently by the GC's first NCRA reset,
after which a command-space read of register 0 returned 0x00000000.  Swiss
calls EXI_GetID from bba_exists() AND again from bba_requires_init(), long
after init, and matches the result against EXI_MX98730EC_ID -- so with the
one-shot spent no case matched and Swiss reported NO ADAPTER, not a broken one.
Running gc_bba_test was enough to spend it, so the adapter would "disappear"
after any test session.

The justification in the comment was wrong.  It claimed the fast path would
otherwise hijack address 0 so the GC could never read NCRA back -- but NCRA is
REGISTER space (0x80/0xC0 header) while the fast path requires byte 0 == 0x00,
i.e. COMMAND space.  They were never ambiguous, and no driver reads command
register 0 for anything else (libogc2 reads 0x01/0x03/0x0B/0x0F, Swiss 0x03).
Real hardware answers EXI_GetID whenever asked; that is how EXI enumerates
devices.

id_arm is now tied high, and the id_phase output, the FFSynchronizer that
crossed it into the pin domain, and the BBATop wiring are all gone.  The port
stays only so the PHASE_METER build can disarm the fast path, which would
otherwise send ID bytes instead of its constant 0x80.

bba_top T1b reads the device ID AFTER an NCRA reset, which T1 (before any
reset) structurally cannot catch.  Mutation-tested: disarming the fast path
returns 00 00 00 00 for both, exactly what Swiss saw.

gc_bba_test: the ID tests no longer skip.  A wrong ID is a FAILURE again, with
no iface_alive() discrimination and no ordering requirement between suites --
the ID is readable at any point in a run.  g_ncra_reset_done and iface_alive()
are removed outright rather than left as a dead flag.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-10-10 14:33:12 +02:00
parent 991342c0b5
commit 90a583dd46
6 changed files with 104 additions and 99 deletions
+9 -11
View File
@@ -83,11 +83,6 @@ class ExiCapture(Elaboratable):
self.spi_cs_n = Signal(init=1)
self.spi_miso = Signal()
self.miso_next = Signal(init=1) # for an SB_IO output register
# Register-file id_phase (sync domain). Crossed into exiclk so the
# bit engine can answer the device-ID query itself -- see the fast
# path in SPIMode3Slave.
self.id_phase = Signal(init=1)
# Core-facing RX read side
self.rx_data = Signal(8)
self.rx_rdy = Signal()
@@ -133,12 +128,15 @@ class ExiCapture(Elaboratable):
]
spi = SPIMode3Slave(phase_meter=self._phase_meter)
# id_phase is a slow single bit: it starts set and clears once, on the
# GC's first NCRA reset, which happens inside a register-space
# transaction with the clock running -- so it propagates well before
# the next transaction needs it.
m.submodules.id_sync = FFSynchronizer(self.id_phase, spi.id_arm,
o_domain="exiclk", init=1)
# The device-ID fast path is ARMED PERMANENTLY. It used to be gated
# by the register file's `id_phase`, a one-shot cleared on the GC's
# first NCRA reset and crossed in here with an FFSynchronizer -- so
# after init the device stopped identifying itself and Swiss's
# EXI_GetID returned 0x00000000, i.e. "no adapter". Real hardware
# answers EXI_GetID whenever asked. `id_arm` stays a port because
# the PHASE_METER diagnostic build needs to turn the fast path off
# (it would otherwise send ID bytes instead of the constant 0x80).
m.d.comb += spi.id_arm.eq(0 if self._phase_meter else 1)
m.submodules.spi = spi
# RX bytes cross exiclk -> sync; TX bytes cross sync -> exififo_r.