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

Dissolve resolved analyses into standalone device docs; open-questions.md keeps only the four live problems; discard NIC-timestamp length path (BCM ECD is proven) and Aquantia length trivia (30m part, oracle-only)

Browse Source
This commit is contained in:
flamingcow
2026-08-12 21:30:16 -07:00
parent 8b021d186b
commit 65b1e18004
13 changed files with 67 additions and 142 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/modules/wiitek/README.md
+3 -4
View File
@@ -33,7 +33,7 @@ Not available in safe space: pre-FEC counter, cable length — those live in the
## VCT/cable length: no confirmed-safe path
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:
This PHY offers no length capability the product needs (the length strategy lives in [../README.md](../README.md)); every known VCT candidate lands in the exact danger zone, and the safe-looking option is a documentation error corrected here:
- **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.
@@ -41,8 +41,7 @@ The problem is real (if both loop ends become Wiiteks, this PHY is the only leng
Routes that do not risk the module:
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.
2. **The real VCT register map** from Marvell/Wiitek under NDA — the only route to a *confirmed*-safe sequence.
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.
1. **The real VCT register map** from Marvell/Wiitek under NDA — the only route to a *confirmed*-safe sequence.
2. **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.