46 lines
3.5 KiB
Markdown
46 lines
3.5 KiB
Markdown
# Wiitek UF-RJ45-10G-100 (Marvell CUX3610)
|
||
|
||
Test-set module; lying fake-SR EEPROM (passes stock ixgbe qualification). Reached over RollBall ([../README.md](../README.md)).
|
||
|
||
## ⚠ DANGER: bricks permanently on certain reads
|
||
|
||
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 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.
|
||
- Rules for any Marvell/RollBall module:
|
||
- **Never sweep vendor register windows. Never read `*.0x??64` (high-byte ≥ 0x80).**
|
||
- Single targeted reads only, on registers with a documented 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.
|
||
|
||
The `rollball_ixgbe.py` client hard-guards the blacklist and raises *before* touching hardware — it structurally cannot repeat the kill.
|
||
|
||
## Safe register set
|
||
|
||
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:
|
||
|
||
| Registers | What |
|
||
|---|---|
|
||
| 1.0xC011/12 | Firmware version |
|
||
| 1.0xC050 | Boot status |
|
||
|
||
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)
|
||
|
||
Templates from kernel drivers for sibling parts — never a sweep, never near `*.0x??64`:
|
||
|
||
- **88Q2220 TDR recipe** (`marvell-88q2xxx.c`, same 0x002b0bXX family, cited from "the Marvell API"), all MMD 3:
|
||
|
||
| Register | Value / meaning |
|
||
|---|---|
|
||
| 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.
|
||
- **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.
|
||
- 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/`).
|
||
|
||
The Marvell 88E151x datasheet PDF in this directory is family reference material.
|