QSFP28 en QSFP-DD coderen: waar het ID-blok zit zodra je SFF-8472 A0h/A2h verlaat
Ik doe kleine batches modules hercoderen voor integrators, en tot nu toe was alles op mijn bank SFP-vormig: de 256 bytes op A0h lezen met de serial ID in de eerste helft, A2h lezen voor de diagnostics en thresholds, het identification block schrijven, klaar. Nu is er een klant opgedoken met 100G- en 400G-onderdelen en mijn rig schiet daar duidelijk tekort.
- te hercoderen modules: een lade QSFP28, een paar QSFP-DD en één OSFP-sample
- huidige programmer: gewone I2C, leest en schrijft A0h en A2h, helemaal geen page select
- hosts aan de andere kant controleren vendor name, part number en serial voordat ze de poort laten branden
Mijn werkaantekeningen over hoe het geheugen is ingedeeld, wat eigenlijk is wat ik gecontroleerd wil hebben:
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 7FhWat ik geprobeerd heb:
- een QSFP28 dumpen met mijn SFP-profiel, wat me de onderste helft geeft plus welke pagina er toevallig geselecteerd was
- twee dumps van dezelfde module vlak na elkaar nemen om te zien welke bytes vanzelf bewegen
Klopt die kaart, en welke velden moet ik daadwerkelijk schrijven voor vendor coding zodra het geheugen gepaged en gebanked is?
Show original (English)
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
De kaart klopt inhoudelijk. Wat jouw rig mist is dat er op SFF-8636 maar één adres is en de bovenste 128 bytes een venster zijn: je schrijft het paginanummer in byte 7Fh, leest dan de bovenste helft en krijgt die pagina. Page 00h is de verplichte en bevat het identification block, dus voor coding hoef je zelden ergens anders heen. CMIS zet daar een bank bovenop - 7Eh selecteert de bank, 7Fh de pagina, en de onderste 128 bytes blijven vast en altijd leesbaar. Zonder page select blijft jouw tool je geven welke pagina de module toevallig geparkeerd stond, precies het gedrag dat je beschreef.
De velden die ertoe doen voor vendor coding zijn overal hetzelfde: vendor name, part number, revision, serial, de OUI en de checksums. Doe een checksum fout en een kieskeurige host gooit de module eruit, ook al ziet elke string er in een hex dump perfect uit. Nog iets om op voorbereid te zijn: sommige modules beschermen de vendor-functies achter manufacturer- en host-passwords terwijl gewone reads open blijven, dus je kunt vrolijk een onderdeel dumpen dat je niet kunt schrijven.
Checksums waren precies wat me bij de eerste poging te grazen nam - de strings kwamen byte voor byte overeen met een bekend goede module en de host weigerde het onderdeel toch. Goed om te weten dat page 00h genoeg is voor het identification block, dat houdt de scope van de klus klein.
De eerlijke samenvatting is dan dat mijn programmer dit helemaal niet kan, omdat hij geen manier heeft om byte 7Fh te schrijven voor een read. Ik koop liever een board dan dat ik page select op een zelfgemaakte rig plak voor één order. Is er iets op de markt dat CMIS-banks echt goed afhandelt, of is dat meer een datasheet-feature?
De commerciële boards adverteren er wel mee - SFPTotal Plus X, de Reveltronics apparatuur (REVELPROG-IS), de EDGE programmers en Flexoptix zetten allemaal QSFP-DD en OSFP op de feature list, en ze gooien er ook een vendor code database bij. SFPTotal claimt ruim 25.000 codes, Cisco, Huawei en HPE inbegrepen.
Hoeveel daarvan overeenkomt met de specifieke onderdelen op jouw bank is een andere vraag, en ik zou ook mijn eigen woord daarvoor niet zomaar aannemen. Krijg als het kan een sample van de QSFP-DD van de klant voor het board voordat je de aankoop vastlegt. Ondersteuning voor een formfactor op een datasheet is niet hetzelfde als ondersteuning voor de specifieke module in jouw hand, en bij de gebankte onderdelen komt dat gat naar boven.
Ter vergelijking, de gewone SFP-klus is nog even bot als altijd: alleen de eerste 128 bytes van de 256-byte dump doen er echt toe, de rest is manufacturer reserved, en mensen schrijven al jaren GLC-LX of GLC-BX-D/GLC-BX-U images op generieke CWDM-onderdelen om ze geaccepteerd te krijgen door een Catalyst 3560, een HP J8692A of een EX4200-24F. Daarvoor gingen zelfgemaakte programmer-schema's rond, serp-0.3 is degene die ik gebouwd heb, en dumps van een Finisar FCMJ-8521-3, een HP J4858C of J4859C of een D-Link DEM-310GT waren de gebruikelijke referentiepunten.
Ander beestje, maar de moeite waard om te weten mocht er een GPON-stick op je bank belanden: daar codeer je helemaal niet van buitenaf. Op een FS GPON-ONU-34-20BI, familie van de Nokia G-010S-A, krijg je een shell op de stick zelf - met de fiber aangesloten antwoordt hij op 192.168.1.10 als ONTUSER - stel het serienummer en MAC in met uci, en herschrijf de EEPROM vendor strings van binnenuit met sfp_i2c.
QDD en OSFP hebben CMIS-structuur en bevatten maar één checksum-byte in Page 0.