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

Nothing lives outside the repo: the bench ixgbe driver source moves in tracked at kernel/ixgbe-sff/ (build artifacts gitignored, load-ixgbe repointed, module build verified from the new home — the reg_ops/ts_bench bench extras are finally versioned), the ice sff_i2c patch is vendored at docs/nics/e810/ice-sff-i2c.patch with its out-of-tree build recipe (TRACE_INCLUDE_PATH fixup, version-matched Makefile), the e810 NVM flash logistics land in the e810 README (exact package name, rollback -m B49691D578EC into the inactive bank, post-flash inventory failing until power cycle is the expected tell), and every ~/work/phydiag-work pointer becomes an inline statement; phydiag-work, ice-sff, e810nvm and the wiitekphy CLI (a duplicate of documented transport+protocol) are deleted

Browse Source
This commit is contained in:
flamingcow
2026-08-19 16:27:48 -07:00
parent c3569b5625
commit e3de27a251
54 changed files with 56360 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/nics/e810/README.md
+3 -3
View File
@@ -1,6 +1,6 @@
# Intel E810 (ice)
Out of the box. The measurement path was originally built against it — its datapath delivers per-packet MAC RX timestamps (`rx_filter=ALL`), which the committed rate design no longer needs ([../README.md](../README.md)). A patched ice + `sff_i2c` exists for read-side diagnostics work.
Out of the box. The measurement path was originally built against it — its datapath delivers per-packet MAC RX timestamps (`rx_filter=ALL`), which the committed rate design no longer needs ([../README.md](../README.md)). The `sff_i2c` ice patch for read-side diagnostics is vendored here as [ice-sff-i2c.patch](ice-sff-i2c.patch); to run it, apply to a copy of the kernel's ice source and build out of tree (`make -C /usr/lib/modules/$(uname -r)/build M=<dir> modules`, then `rmmod irdma ice; insmod`), with two out-of-tree fixups: `ice_trace.h` needs `TRACE_INCLUDE_PATH` set to the build dir's absolute path and `TRACE_INCLUDE_FILE ice_trace`, and the Makefile's object list must match the source snapshot's kernel version.
## Host notes (if it returns)
@@ -26,8 +26,8 @@ Read-side transport details (the patched ice exists for read-side work, so these
- No offset-less read mode exists, so the plain mdio-i2c clause-45 read phase (bcm84881-style at 0x56) cannot be formed. RollBall fits fully (≤4 B native multi-byte writes).
- Latency is the wire-truth judge on this transport: on 3.10 firmware, silently-dropped 1-byte writes completed in ~63 µs while real wire traffic ran ~103 µs/byte (reads) and multi-ms ack-polling (writes), and `ok` returns even for writes at an empty address — protocol-level readback is the only delivery confirmation.
Firmware on the card: NVM 5.01 (release 31.2.2, EETRACK 0x80021FA2). The update package and logs live in `~/work/e810nvm/`; `nvmupdate64e` needs `-AllowMissingCert` on this platform (harmless — nothing boots from the NIC), writes no file backup, and rollback lives in the card's inactive flash bank (`nvmupdate64e -r -m <MAC>`).
Firmware on the card: NVM 5.01 (release 31.2.2, EETRACK 0x80021FA2), flashed with `nvmupdate64e` 1.43.37.1a from Intel's `E810_NVMUpdatePackage_v5_01_Linux.tar.gz` (re-downloadable; nothing kept locally). Flash logistics: the tool needs `-AllowMissingCert` on this platform (the MS UEFI CA 2023 cert is absent — harmless, nothing boots from the NIC), writes no file backup even with `-b` ("Backup images created" means the card's inactive flash bank, where rollback lives: `nvmupdate64e -r -m B49691D578EC`), and the post-flash inventory fails until a power cycle activates the new bank — that failure is the expected tell, not an error.
## The bit-bang-below-the-AQ idea — retired with the timestamp requirement
The write block is at the **Admin Queue** (firmware) level — the `0x06E2/E3` topo-I2C commands are refused with EPERM. That is not the same as the module's SDA/SCL being unreachable: the 82599 reaches the module I2C **without firmware** by toggling SDA/SCL as GPIO bits in `I2CCTL` (the `~/work/ixgbe-sff/` patch bit-bangs arbitrary START…STOP from those primitives), and whether the E810 exposes an equivalent register-level / SDP-GPIO path below the AQ policy was never tested. The idea existed to marry all-packet stamps to raw I2C in one card; the smoothed-bucket rate plan ([../x520/README.md](../x520/README.md)) dissolves the stamps requirement, so the X520 covers everything and this investigation is not needed. It stays recorded as the E810's one open door if per-frame arrival times are ever wanted again — the investigation would start at the datasheet's SDP/GPIO and low-level I2C controller registers, asking whether the cage's SDA/SCL are host-addressable.
The write block is at the **Admin Queue** (firmware) level — the `0x06E2/E3` topo-I2C commands are refused with EPERM. That is not the same as the module's SDA/SCL being unreachable: the 82599 reaches the module I2C **without firmware** by toggling SDA/SCL as GPIO bits in `I2CCTL` (the `kernel/ixgbe-sff/` bench driver bit-bangs arbitrary START…STOP from those primitives), and whether the E810 exposes an equivalent register-level / SDP-GPIO path below the AQ policy was never tested. The idea existed to marry all-packet stamps to raw I2C in one card; the smoothed-bucket rate plan ([../x520/README.md](../x520/README.md)) dissolves the stamps requirement, so the X520 covers everything and this investigation is not needed. It stays recorded as the E810's one open door if per-frame arrival times are ever wanted again — the investigation would start at the datasheet's SDP/GPIO and low-level I2C controller registers, asking whether the cage's SDA/SCL are host-addressable.