theater/cabletest
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Correct Wiitek danger analysis: whole 3.0x8000+/31.0xF000+ window is lethal, not just *.??64 -- 88Q2220 recipe is IN the danger zone; record live baseline and no-safe-VCT-path finding

Browse Source
This commit is contained in:
flamingcow
2026-08-12 19:50:15 -07:00
parent ad9bc9fae4
commit 910379e614
1 changed files with 23 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/modules/wiitek/README.md
+23 -20
View File
@@ -7,39 +7,42 @@ Test-set module; lying fake-SR EEPROM (passes stock ixgbe qualification). Reache
Both original Wiiteks were bricked **permanently** by register exploration — the death survives cold power cycles and reseats. Both original Wiiteks were bricked **permanently** by register exploration — the death survives cold power cycles and reseats.
- The CUX3610's integrated microcontroller (Marvell Alaska-M, PHY ID 0x002B0BF4, firmware 12.1.5.0) boots from onboard non-volatile storage. The high vendor register windows (3.0x8000+, 31.0xF000+) reached over RollBall are **µC-mapped peripheral space, not PHY-core MDIO**. A read of a trapped peripheral crashes the µC mid-operation and corrupts its persistent boot state; it comes up FATAL forever after. - The CUX3610's integrated microcontroller (Marvell Alaska-M, PHY ID 0x002B0BF4, firmware 12.1.5.0) boots from onboard non-volatile storage. The high vendor register windows (3.0x8000+, 31.0xF000+) reached over RollBall are **µC-mapped peripheral space, not PHY-core MDIO**. A read of a trapped peripheral crashes the µC mid-operation and corrupts its persistent boot state; it comes up FATAL forever after.
- **The trap: any register whose low byte is 0x64 in a high window (register high-byte ≥ 0x80), on any devad.** Module 1 died reading 3.0x8064, module 2 reading 31.0xF064. The mailbox writes the address bytes, then the µC dies executing the access — the command never needs to complete. 3.0x8064 is a known QCA808x CDT status register; the ODM firmware appears to emulate/intercept a CDT block there and crash on a cold read. A sloppy `(reg & 0xFF) == 0x64` decode explains both deaths with one bug. - **The confirmed kill: any register whose low byte is 0x64 in a high window (register high-byte ≥ 0x80), on any devad.** Module 1 died reading 3.0x8064, module 2 reading 31.0xF064. The mailbox writes the address bytes, then the µC dies executing the access — the command never needs to complete. 3.0x8064 is a known QCA808x CDT status register; the ODM firmware appears to emulate/intercept a CDT block there and crash on a cold read. A sloppy `(reg & 0xFF) == 0x64` decode is one hypothesis that fits both deaths — but it is the *confirmed* pattern, not proof the danger stops there. The whole `3.0x8000+` / `31.0xF000+` space is µC-mapped peripheral space; treat all of it as lethal-until-proven, `??64` merely most-proven.
- Rules for any Marvell/RollBall module: - Rules for any Marvell/RollBall module:
- **Never sweep vendor register windows. Never read `*.0x??64` (high-byte ≥ 0x80).** - **Never sweep vendor register windows.** Treat every `3.0x8000+` / `31.0xF000+` access as potentially lethal, not just `*.0x??64`.
- Single targeted reads only, on registers with a documented reason. - Single targeted reads only, on registers with a documented, verified-safe reason.
- Recovery needs a vendor firmware image + the boot-download protocol (1.0xC050 boot status, 1.0xD0F0–D0F3 download) — we have no CUX3610 image, so bricks are effectively dead. A ghost I2C device at 7-bit 0x57 (returns zeros) is the ROM bootloader waiting for a download. - Recovery needs a vendor firmware image + the boot-download protocol (1.0xC050 boot status, 1.0xD0F0–D0F3 download) — we have no CUX3610 image, so bricks are effectively dead. A ghost I2C device at 7-bit 0x57 (returns zeros) is the ROM bootloader waiting for a download.
The `rollball_ixgbe.py` client hard-guards the blacklist and raises *before* touching hardware — it structurally cannot repeat the kill. The `rollball_ixgbe.py` client hard-guards the blacklist and raises *before* touching hardware — it structurally cannot repeat the kill.
## Safe register set ## Safe register set — proven live
The shared IEEE 802.3an set ([../README.md](../README.md)) — SNR margin (offset-0x8000 encoding; saw A 9.1 / B 7.1 / C 7.7 / D 8.9 dB), PCS latches, AN status, retrain. Plus, proven safe in vendor space: The shared IEEE 802.3an set ([../README.md](../README.md)) plus two safe vendor reads. Verified on the current replacement unit (SNR [8.8, 7.0, 7.3, 8.9] dB, matching the dead originals' A 9.1 / B 7.1 / C 7.7 / D 8.9 — a representative module):
| Registers | What | | Registers | What | Reading |
|---|---| |---|---|---|
| 1.0xC011/12 | Firmware version | | PMA 1.133–1.136 / 1.137–1.140 | Per-pair SNR margin (offset-0x8000, 0.1 dB) | [8.8, 7.0, 7.3, 8.9] dB |
| 1.0xC050 | Boot status | | PCS 3.32 / 3.33 | Errored-block / block-lock latches | 0x1001 / 0x7f00 |
| AN 7.33 | Master/slave, link partner | 0x3c62 |
| 1.0xC011 / 12 | Firmware version | 0x0c01 / 0x0500 (12.1.5.0) |
| 1.0xC050 | Boot status | 0x087e |
`rb_forensic.py` in phydiag-work performs this baseline and logs every sff_i2c op (PRE line fsync'd before each op, POST after) to `wiitek-ops.log` — a PRE with no POST names whatever killed the µC. `rollball_ixgbe.py` hard-guards the `*.0x??64` blacklist and raises before touching hardware.
Not available in safe space: pre-FEC counter, cable length — those live in the µC vendor space that killed the modules. Not available in safe space: pre-FEC counter, cable length — those live in the µC vendor space that killed the modules.
## VCT/TDR candidates (unverified; single-shot, sacrificial unit only) ## VCT/cable length: no confirmed-safe path
Templates from kernel drivers for sibling parts — never a sweep, never near `*.0x??64`: The problem is real (if both loop ends become Wiiteks, this PHY is the only length source), but every known VCT candidate lands in the exact danger zone, and the safe-looking option is a documentation error corrected here:
- **88Q2220 TDR recipe** (`marvell-88q2xxx.c`, same 0x002b0bXX family, cited from "the Marvell API"), all MMD 3: - **The 88Q2220 TDR recipe is NOT safe.** Its registers (MMD 3, 0xFECA/0xFED9/0xFEDA/0xFEDE/0xFEDD) sit at `3.0xFExx` — inside the `3.0x8000+` µC-mapped window this doc identifies as the space that bricked both modules. Low-byte ≠ 0x64 does **not** make them safe; the whole high window is µC-intercept space, and the brick was a µC crash on access, not specifically the 0x64 decode. (The 0x64 pattern is the one *confirmed* kill; it is not the boundary of the danger.) Treat the entire `3.0x8000+` / `31.0xF000+` space as lethal-until-proven, not the `*.??64` addresses alone.
- **The QCA-style CDT block** (`qcom/qcom.h`: 3.0x8064 status, 3.0x8065–0x8068 per-pair results, 3.0x8074–0x807E thresholds) is the most likely *intended* VCT — the ODM firmware emulates it — but it is centered on `3.0x8064`, the precise register that killed both originals. Hypothesis: the kill was a *cold* status read before running the test, and the real protocol is write-start → wait → read-status/results. Plausible, unproven, and not worth a live module.
- **No usable public reference exists.** The kernel 10G Marvell driver (`marvell10g.c`) implements no cable test; `gtVct.c` in the qd-dsdt GPL dumps is legacy clause-22 1000M paged access (wrong architecture for this clause-45 part); no public datasheet documents the Alaska-M VCT register map.
| Register | Value / meaning | Routes that do not risk the module:
|---|---|
| TDR_RESET 0xFECA | init 0x0D90, clear 0x1D90 |
| 0xFED9 / 0xFEDA / 0xFEDE | Calibration: 0x010E / 0x00EB / 0x0058 |
| TDR_STATUS 0xFEDD | Write 0x0002 to start; ~500 ms test. Read: bits[1:0]=01 done; [7:4] verdict (0x7 OK / 0xE open / 0x3 short / 0x5 noise); [15:8] distance in meters |
Single-pair on the Q2220; the 4-pair CUX3610 likely has per-pair variants nearby. Low bytes nowhere near the 0x64 trap. 1. **NIC timestamp path-delay** for length — module-independent, works whatever modules are at the ends ([../../open-questions.md](../../open-questions.md) §2). This directly answers the same-module-both-ends case; prioritize the X710 retrain-stability experiment.
- **QCA-style CDT** (`qcom/qcom.h`): 3.0x8064 CDT_STATUS, 3.0x8065–0x8068 per-pair results, 3.0x8074–0x807E thresholds. **This IS the trap address** — only ever entered via the full start sequence, never a cold status read; treat as off-limits absent strong evidence. 2. **The real VCT register map** from Marvell/Wiitek under NDA — the only route to a *confirmed*-safe sequence.
- Doc-mining lead for the 4-pair pattern: `gtAdvVct.c` in the Marvell qd-dsdt GPL dumps (e.g. github.com/andy928/xpenology `arch/arm/plat-feroceon/mv_hal/qd-dsdt/`). 3. **Deliberate sacrifice** of a spare to test the QCA-CDT-start hypothesis, `rb_forensic.py` running — only if the capability is judged worth a module.
The Marvell 88E151x datasheet PDF in this directory is family reference material. The Marvell 88E151x datasheet PDF in this directory is family reference material.