Reading and rewriting SFP EEPROM over the Raspberry Pi I2C bus instead of buying a programmer
I keep a shelf of pulled SFPs at home and I would like to be able to read their EEPROM, repair a module whose checksum got mangled, and occasionally recode one for a switch that is picky about vendor strings. Buying a commercial programmer for a handful of modules a year makes no sense here, so I am trying to work out how far a self-built rig actually gets.
What is on the bench:
- Raspberry Pi with the I2C bus broken out to an SFP cage I wired myself
- a CH341A USB programmer board left over from a BIOS job
- a mixed pile of 1G and 10G SFP/SFP+ modules, plus two QSFP+ ones I would like to look at as well
Reads work at least in the sense that something answers on the bus:
$ i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
$ i2cdump -y 1 0x50What I have done so far:
- dumped A0h by hand and compared bytes against the SFF-8472 field offsets, which is slow and easy to get wrong
- written a few bytes with the CH341A: they land, but nothing recalculates the checksums for me, so the module comes back as garbage until I patch them myself
- kept the QSFP+ modules untouched, because the cage I built only takes SFP
So what does the open tooling actually look like for this: is there something that knows the memory layout, verifies the checksum bytes after a write, and can drive a QSFP+ slot too? And where does a home-built rig stop being enough?
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 4
For plain SFP/SFP+ work the Pi is enough. The module is just two I2C devices, which is exactly what your i2cdetect output shows at 0x50 and 0x51, and nothing magic happens beyond that. What saves you the byte counting is sfppi: it drives the Pi's I2C bus, decodes the fields for you, and it checks CC_BASE and CC_EXT and offers to fix them after a write. That is precisely the step the CH341A does not do for you. The CH341A is not useless, it reads and writes fine, it simply has no idea what the bytes mean, so every checksum stays your problem.
For QSFP+ your soldered cage will not help. The community design people point at is Hubble, an open programmer with a QSFP slot next to the SFP one, so that is the direction if you want to touch those two modules. There is also a barebones Reveltronics build that gets used for brute-forcing write passwords on modules that refuse writes outright. I have never needed that one myself, so treat it as a pointer and check it on hardware you can afford to lose.
That lines up with what I see here. The second page is lie as well, so both halves of the memory are there to read:
I will redo the cage wiring properly and then try the checksum path on a module I do not care about before touching anything I want to keep. QSFP+ stays parked for now, building a second cage for two modules a year is hard to justify, so those will remain read-only until I decide whether Hubble is worth the effort.
Adding to that from the other end of the price range, since not everyone builds their own: the tools you see in daily use are the SNR SFP Writer, the SFPTotal Plus series, and various one-off devices built around CH341 boards, which is the same chip you already have on the bench.
The thing worth knowing before you go deep is that not every module is a plain EEPROM. Some carry their own microcontroller that eumlates the A0/A2 memory instead of exposing a real chip, a Medick SFP-10G-BX with a C8051F392 inside being the example that keeps coming up. Those can implement write passwords or vendor challenges, and no amount of poking the bus turns them into a dumb EEPROM. The nastiest case people raise is the HP/Aruba interactive EEPROM with keys.
One practical note for your own cage: get the pinout right or you will chase ghosts. TX_Disable is pin 3, Mod_Abs is pin 6, VeeR is pin 9. Mod_Abs in particular decides whether anything believes a module is present at all.
And the risk side of it, since it rarely gets mentioned until someone has a dead module. A lot of modules want a 4-byte password before they accept a write. Most of those passwords are floating around in public and there is no universal utility, so you end up with a pile of vendor-specific tools and images pulled from firmware databases or the manufacturer. Get any of that wrong and you have bricked a module that cost more than the programmer.
So before touching the EEPROM at all, prove the module is actually broken: read DDM temperature, voltage, bias current and TX/RX power out of A0h/A2h, clean the latches, contacts and lenses, swap in a known-good module, and load-test the link with iperf3. Half the modules that supposedly need reflashing just need cleaning.
If you would rather pay than solder, be aware the commercial boxes come with their own strings. The FS Box does recode nicely, people got FS SFP-GE-BX modules working on an Intel X710 with autoselect that way, but it programs FS modules only and inserting a non-FS module has earned users week-long account lockouts.