cabletest/docs/modules/wiitek

Wiitek UF-RJ45-10G-100 (Marvell CUX3610)

Test-set module; lying fake-SR EEPROM (passes stock ixgbe qualification). Reached over RollBall (../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) — 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.