Coding QSFP28 and QSFP-DD: where the ID block lives once you leave SFF-8472 A0h/A2h
I do small batches of module recoding for integrators, and until now everything on my bench has been SFP-shaped: read the 256 bytes at A0h with the serial ID in the first half, read A2h for the diagnostics and thresholds, write the identification block, done. A customer has now turned up with 100G and 400G parts and my rig is clearly out of its depth.
- modules to recode: a tray of QSFP28, a few QSFP-DD and one OSFP sample
- current programmer: plain I2C, rads and writes A0h and A2h, no page select at all
- hosts on the far end check vendor name, part number and serial before they light the port
My working notes on how the memory is laid out, which is really what I want checked:
SFP/SFP+/SFP28 (SFF-8472): A0h 256B, serial ID in first 128B; A2h 256B diagnostics + thresholds, optional 128B pages
QSFP+/QSFP28 (SFF-8636): single A0h, 128B pages selected by byte 7Fh, page 00h mandatory
XFP (INF-8077i): byte 7Fh picks the active table, with serial ID in table 01h and user EEPROM in 02h
OSFP/QSFP-DD/SFP-DD (CMIS 5.x): lower 128B fixed, upper memory by bank and page via 7Eh and 7FhWhat I have tried:
- dumping a QSFP28 with my SFP profile, which hands me the lower half plus whatever page happened to be selected
- taking two dumps of the same module back to back to see which bytes move on their own
Is that map right, and which fields do I actually have to write for vendor coding once the memory is paged and banked?
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
The map is right in substance. What your rig is missing is that on SFF-8636 there is only one address and the upper 128 bytes are a window: you write the page number into byte 7Fh, then read the upper half and you get that page. Page 00h is the mandatory one and it holds the identification block, so for coding you rarely need to go anywhere else. CMIS puts a bank on top of that - 7Eh selects the bank, 7Fh the page, and the lower 128 bytes stay fixed and always readable. Without page select your tool keeps handing you whatever page the module was parked on, which is exactly the behaviour you described.
The fields that matter for vendor coding are the same everywhere: vendor name, part number, revision, serial, the OUI and the checksums. Get a checksum wrong and a picky host throws the module out even though every string looks perfect in a hex dump. One more thing to be ready for: some modules protect the vendor functions behind manufacturer and host passwords while plain reads stay open, so you can happily dump a part that you cannot write.
Checksums are exactly what bit me on the first attempt - the strings matched a known-good module byte for byte and the host still refused the part. Good to know that page 00h is enough for the identification block, that keeps the scope of the job small.
The honest summary then is that my programmer cannot do this at all, because it has no way to write byte 7Fh before a read. I would rather buy a board than bolt page select onto a home-made rig for one order. Is aything on the market handling CMIS banks properly, or is that more of a datasheet feature?
The commercial boards do advertise it - SFPTotal Plus X, the Reveltronics gear (REVELPROG-IS), the EDGE programmers and Flexoptix all put QSFP-DD and OSFP on the feature list, and they throw in a vendor code database as well. SFPTotal claims north of 25,000 codes, Cisco, Huawei and HPE included.
How much of that lines up with the specific parts on your bench is another question, and I would not take my word for it either. If you can, get a sample of the customer's QSFP-DD in front of the board before you commit to the purchase. Support for a form factor on a datasheet is not the same thing as support for the partcular module in your hand, and the banked parts are where that gap shows up.
For contrast, the plain SFP job is as crude as it ever was: only the first 128 bytes of the 256-byte dump really matter, the rest is manufacturer reserved, and people have been writing GLC-LX or GLC-BX-D/GLC-BX-U images onto generic CWDM parts for years to get them accepted by a Catalyst 3560, an HP J8692A or an EX4200-24F. Home-made programmer schematics were passed around for that, serp-0.3 being the one I built, and dumps from a Finisar FCMJ-8521-3, an HP J4858C or J4859C or a D-Link DEM-310GT were the usual reference points.
Different animal, but worth knowing in case GPON sticks land on your bench: there you do not code from outside at all. On an FS GPON-ONU-34-20BI, which is a relative of the Nokia G-010S-A, you get a shell on the stick itself - with the fibre attached it answers on 192.168.1.10 as ONTUSER - set the serial and MAC with uci, and rewrite the EEPROM vendor strings from inside with sfp_i2c.
QDD and OSFP have CMIS structure and contain only one checksum byte in Page 0.