QSFP28 und QSFP-DD codieren: Wo der ID-Block sitzt, sobald man SFF-8472 A0h/A2h verlässt
Ich mache kleine Batches Modul-Umcodierung für Integratoren, und bisher war auf meiner Werkbank alles SFP-förmig: die 256 Bytes bei A0h lesen, mit der Serial-ID in der ersten Hälfte, A2h für Diagnose und Schwellenwerte lesen, den Identification Block schreiben, fertig. Jetzt ist ein Kunde mit 100G- und 400G-Teilen aufgetaucht, und mein Aufbau ist damit eindeutig überfordert.
- umzucodierende Module: ein Tray QSFP28, ein paar QSFP-DD und ein OSFP-Sample
- aktueller Programmer: reines I2C, liest und schreibt A0h und A2h, gar kein Page Select
- Hosts auf der Gegenseite prüfen Herstellername, Teilenummer und Seriennummer, bevor sie den Port zünden
Meine Arbeitsnotizen dazu, wie der Speicher aufgebaut ist, und genau die möchte ich gegengeprüft haben:
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 7FhWas ich versucht habe:
- ein QSFP28 mit meinem SFP-Profil gedumpt, was mir die untere Hälfte plus die gerade zufällig gewählte Seite liefert
- zwei Dumps desselben Moduls direkt hintereinander gemacht, um zu sehen, welche Bytes sich von selbst ändern
Stimmt diese Karte, und welche Felder muss ich für die Herstellercodierung tatsächlich schreiben, sobald der Speicher in Pages und Banks organisiert ist?
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
Die Karte stimmt in der Substanz. Was deinem Aufbau fehlt: Bei SFF-8636 gibt es nur eine Adresse, und die oberen 128 Bytes sind ein Fenster: Man schreibt die Seitennummer in Byte 7Fh, liest dann die obere Hälfte und bekommt diese Seite. Page 00h ist die Pflichtseite und enthält den Identification Block, für die Codierung muss man also selten woanders hin. CMIS setzt noch eine Bank obendrauf - 7Eh wählt die Bank, 7Fh die Seite, und die unteren 128 Bytes bleiben fest und immer lesbar. Ohne Page Select liefert dein Tool immer weiter die Seite, auf der das Modul zufällig geparkt war, genau das Verhalten, das du beschrieben hast.
Die für die Herstellercodierung relevanten Felder sind überall dieselben: Herstellername, Teilenummer, Revision, Seriennummer, die OUI und die Prüfsummen. Eine Prüfsumme falsch, und ein pingeliger Host wirft das Modul raus, obwohl jeder String im Hex-Dump perfekt aussieht. Noch etwas, worauf man gefasst sein sollte: Manche Module schützen die Herstellerfunktionen hinter Manufacturer- und Host-Passwörtern, während einfache Lesezugriffe offen bleiben, man kann also munter ein Teil dumpen, das man nicht beschreiben kann.
Prüfsummen sind genau das, was mich beim ersten Versuch gebissen hat - die Strings stimmten Byte für Byte mit einem bekannt guten Modul überein, und der Host hat das Teil trotzdem abgelehnt. Gut zu wissen, dass Page 00h für den Identification Block reicht, das hält den Umfang des Jobs klein.
Die ehrliche Zusammenfassung ist dann, dass mein Programmer das gar nicht kann, weil er keine Möglichkeit hat, Byte 7Fh vor einem Lesevorgang zu schreiben. Ich würde lieber ein Board kaufen, als für eine Bestellung Page Select an einen selbstgebauten Aufbau anzuflanschen. Handhabt irgendetwas auf dem Markt CMIS-Banks tatsächlich richtig, oder ist das eher ein Datenblatt-Feature?
Die kommerziellen Boards werben tatsächlich damit - SFPTotal Plus X, das Reveltronics-Gerät (REVELPROG-IS), die EDGE-Programmer und Flexoptix führen alle QSFP-DD und OSFP auf der Feature-Liste, und sie liefern noch eine Vendor-Code-Datenbank dazu. SFPTotal beansprucht über 25.000 Codes, Cisco, Huawei und HPE eingeschlossen.
Wie viel davon zu den konkreten Teilen auf deiner Werkbank passt, ist eine andere Frage, und darauf würde ich mich auch nicht verlassen. Wenn möglich, ein Sample des QSFP-DD vom Kunden vor das Board bekommen, bevor man sich auf den Kauf festlegt. Unterstützung für einen Formfaktor auf dem Datenblatt ist nicht dasselbe wie Unterstützung für das konkrete Modul in der Hand, und bei den gebankten Teilen zeigt sich genau diese Lücke.
Im Gegensatz dazu ist der reine SFP-Job so simpel geblieben, wie er immer war: Von den 256 Bytes des Dumps zählen wirklich nur die ersten 128, der Rest ist Manufacturer Reserved, und Leute schreiben seit Jahren GLC-LX- oder GLC-BX-D/GLC-BX-U-Images auf generische CWDM-Teile, um sie von einem Catalyst 3560, einem HP J8692A oder einem EX4200-24F akzeptiert zu bekommen. Dafür kursierten selbstgebaute Programmer-Schaltpläne, serp-0.3 ist der, den ich gebaut habe, und Dumps von einem Finisar FCMJ-8521-3, einem HP J4858C oder J4859C oder einem D-Link DEM-310GT waren die üblichen Referenzpunkte.
Andere Baustelle, aber gut zu wissen, falls GPON-Sticks auf deiner Werkbank landen: Dort codiert man von außen überhaupt nicht. Bei einem FS GPON-ONU-34-20BI, einem Verwandten des Nokia G-010S-A, bekommt man eine Shell auf dem Stick selbst - mit angeschlossener Faser antwortet er auf 192.168.1.10 als ONTUSER -, setzt Seriennummer und MAC mit uci und schreibt die EEPROM-Herstellerstrings von innen mit sfp_i2c neu.
QDD und OSFP haben CMIS-Struktur und enthalten nur ein Prüfsummenbyte in Page 0.