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

BCM bridge tolerates MCIA offset-write-then-read framing, proven on hardware via bcm_mcia_emu.py; MCIA question narrows to firmware acceptance of 0x56 and offset/framing details

Browse Source
This commit is contained in:
flamingcow
2026-08-12 21:39:46 -07:00
parent 4e5ba0bccf
commit a00f2216b7
3 changed files with 17 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/open-questions.md
+3 -3
View File
@@ -6,9 +6,9 @@ The genuinely open, thinking-worthy problems — nothing here is resolved. Analy
The decisive unknown for product diagnostics coverage ([nics/connectx-5/](nics/connectx-5/README.md)):
- Does firmware MCIA accept **arbitrary I2C device addresses**? The register format allows it (8-bit field, per-access status — verified in `mlx5_ifc.h`); firmware acceptance is the unknown.
- Does the BCM bridge **tolerate an offset write before its SMI read phase**? MCIA has no raw-read encoding, so this module-side property is the whole question — and it is testable on the X520 before the card arrives.
- If no to either: product diagnostics via the Marvell/Aquantia modules only.
- Does firmware MCIA accept **arbitrary I2C device addresses**? The register format allows it (8-bit field, per-access status — verified in `mlx5_ifc.h`); firmware acceptance is the unknown. The module side is settled: the BCM bridge tolerates MCIA's offset-write-then-read framing, proven on hardware ([nics/connectx-5/](nics/connectx-5/README.md)).
- Does MCIA emit **one offset byte per write** (which would let SMI command frames be synthesized exactly), and STOP-separated or repeated-START reads?
- If firmware says no: product diagnostics via the Marvell/Aquantia modules only.
## 2. ECD run disturbance