diff --git a/docs/modules.md b/docs/modules.md index 20a0e5b..8f19d3a 100644 --- a/docs/modules.md +++ b/docs/modules.md @@ -27,6 +27,21 @@ Proven on the CUX3610 before they died, and on the Fibergaga oracle — all IEEE Not available in safe space: pre-FEC counter, cable length. Those live in the µC vendor space that killed the modules. +## What the FS/BCM gives +All via the SMI bridge + command handler (transports.md carries the codes and the invocation traps). Proven on the X520: +- **Per-pair SNR** — CMD_GET_SNR 0x8030 invoked bare: DATA2–5 = absolute receiver SNR in 0.1 dB (bench ≈ 27–32 dB; the 10GBASE-T operating point is ≈ 26.5 dB, so margin ≈ value − 26.5). The IEEE registers 1.133–1.140 stay at 0x8080 — handler only. +- **Die temperature** (0x8031) and **supply rails** (0x802F) — module health. +- **Standard PCS 3.32/3.33** — block lock, latched errored-block/BER counters, clear-on-read: the noise-stress error proxy. +- **Retrain** — IEEE AN restart `7.0 |= bit9`, relinks in ~6 s. + +Documented in the handler table, not yet exercised: +- **CMD_GET_PAIR_SWAP 0x8000** — MDI wiring/crossover/polarity report. +- **GET_LIMITED_REACH_MODE 0x8006** — DATA3 = "currently linked in limited-reach mode": the only handler-visible consequence of the DSP's internal cable-length estimate, a single short/long bit, and only meaningful when LR mode is enabled (a config change — measure-only by default). +- **GET_EEE_MODE 0x8008 / GET_EEE_STATISTICS 0x801B** — verify EEE is off before trusting loss numbers. +- **GET_SUB_LF_RF_STATUS 0x800D** — local/remote fault detail. + +**No cable length.** The handler catalog is complete (§1.25.1.1–45: pair swap through WOL) and contains no ECD, length, or skew command. Cable length, opens/shorts, pair skew, and polarity live in the separate ECD register mechanism whose chapter FS hasn't sent — still the one outstanding ask. Until it lands, FS-side length comes only from the NIC timestamp path — in contrast to the Aquantia oracle, whose `1E.C884` length register is fully documented. + ## Marvell cable-length register candidates (unverified, single-shot only) From kernel drivers for sibling parts — templates for a *future* single targeted probe on a sacrificial module, never a sweep, never near `*.0x??64`: diff --git a/docs/open-questions.md b/docs/open-questions.md index dba69b3..11da9fb 100644 --- a/docs/open-questions.md +++ b/docs/open-questions.md @@ -53,10 +53,9 @@ If route 1 validates, the X520 delivers honest buckets after all — its disqual Decide which is the product path vs. nice-to-have. -- **A fourth path exists in pure standard registers — no vendor docs at all.** The Clause 45 10GBASE-T PMA group we already read (1.133–1.140) also carries the negotiated TX power backoff / short-reach fields (~1.131 — verify the exact address in 802.3 Table 45–3 before use; all low-address space, nowhere near the `??64` trap). Power backoff is derived from measured channel insertion loss in 2 dB steps → a coarse length bucket on any compliant module. And SNR margin itself falls monotonically with insertion loss on a healthy cable: a small calibration table (known-length cables → margin per pair) likely satisfies goals.md's "sanity check" outright, leaving ECD needed only for fault *localization*. -- **BCM fallback, checked:** OpenBCM's `phy8481.c` covers the copper XGPHY family only through BCM8488x — no 84891, and no ECD code in the retrievable portion — and the kernel's Broadcom ECD (`bcm-phy-lib`) is the BCM54xx GbE register model; neither transfers. SDK/patent mining looks low-yield. FS delivering the ECD chapter stays the primary route, with the standard-register proxy above as the hedge. +- **BCM fallback, checked:** OpenBCM's `phy8481.c` covers the copper XGPHY family only through BCM8488x — no 84891, and no ECD code in the retrievable portion — and the kernel's Broadcom ECD (`bcm-phy-lib`) is the BCM54xx GbE register model; neither transfers. SDK/patent mining looks low-yield. FS delivering the ECD chapter stays the primary route. - **The Aquantia-based oracle gets a fully documented path the Wiiteks can't have.** The Fibergaga's PHY family register reference is now vendored in this folder (`aquantia-aqr107-aqr109-datasheet.pdf`, see item 5), and it delivers the DSP estimate outright: **`1E.C884` "Global Status" bits 7:0 = estimated cable length in meters, ±1 m, RO, "estimated from the cable diagnostic engine."** Plus full TDR results: per-pair fault verdicts (open/short/mismatch/cross-pair) at `1E.C800`, distances of the four worst reflections per pair (±1 m) at `1E.C801–C807`, reflection impedance/magnitude at `1E.C880–C883`. Bench question: whether C884 is continuously valid on a linked cable or only after an explicit diag run. This also proves at least one vendor exposes the DSP length in a plain register — useful precedent for the FS/Broadcom ECD ask. The CUX3610 stays sacrificial-unit-only. -- **Proposed decision:** product path = standard-register proxy (SNR margin + power backoff) for length sanity; BCM ECD if/when FS delivers = adds fault localization; timestamp path-delay = pursue only if the item-2 retrain-stability experiment passes. +- **Proposed decision:** product path = the PHY's own length machinery — BCM ECD if/when FS delivers, the documented `1E.C884` estimate on the Aquantia oracle; NIC timestamp path-delay = the module-independent fallback, pursued only if the item-2 retrain-stability experiment passes. ## 4. Two-master I2C safety + correctness of the untested clients The `ixgbe` driver polls the SFP EEPROM (DOM/qualification) on its own; our `sff_i2c` transactions share the bus. The swfw semaphore *should* serialize us, but verify the reasoning. Also scrutinize framing assumptions we couldn't test: