Coder du QSFP28 et du QSFP-DD : où se trouve le bloc d'identité une fois qu'on quitte le SFF-8472 A0h/A2h
Je fais de petits lots de recodage de modules pour des intégrateurs, et jusqu'ici tout sur mon banc avait la forme d'un SFP : lire les 256 octets à A0h avec l'ID série dans la première moitié, lire A2h pour les diagnostics et les seuils, écrire le bloc d'identification, terminé. Un client s'est maintenant présenté avec des pièces 100G et 400G et mon montage est clairement dépassé.
- modules à recoder : un plateau de QSFP28, quelques QSFP-DD et un échantillon OSFP
- programmateur actuel : simple I2C, lit et écrit A0h et A2h, aucune sélection de page
- les hôtes en face vérifient le vendor name, le part number et le numéro de série avant d'allumer le port
Mes notes de travail sur la disposition de la mémoire, ce que je veux vraiment faire vérifier :
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 7FhCe que j'ai essayé :
- dumper un QSFP28 avec mon profil SFP, ce qui me donne la moitié basse plus quelle que soit la page sélectionnée sur le moment
- prendre deux dumps du même module coup sur coup pour voir quels octets bougent tout seuls
Cette carte est-elle correcte, et quels champs dois-je réellement écrire pour le codage constructeur une fois que la mémoire est paginée et bancarisée ?
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
La carte est correcte sur le fond. Ce qui manque à votre montage, c'est que sur le SFF-8636 il n'y a qu'une seule adresse et les 128 octets hauts forment une fenêtre : vous écrivez le numéro de page dans l'octet 7Fh, puis vous lisez la moitié haute et vous obtenez cette page. La page 00h est celle obligatoire et elle contient le bloc d'identification, donc pour le codage vous avez rarement besoin d'aller ailleurs. Le CMIS ajoute une banque par-dessus - 7Eh sélectionne la banque, 7Fh la page, et les 128 octets bas restent fixes et toujours lisibles. Sans sélection de page, votre outil continue de vous donner quelle que soit la page sur laquelle le module était resté, ce qui correspond exactement au comportement que vous décrivez.
Les champs qui comptent pour le codage constructeur sont les mêmes partout : vendor name, part number, révision, numéro de série, l'OUI et les sommes de contrôle. Faites une erreur de somme de contrôle et un hôte pointilleux rejette le module même si toutes les chaînes semblent parfaites dans un dump hexadécimal. Encore une chose à anticiper : certains modules protègent les fonctions constructeur derrière des mots de passe fabricant et hôte alors que les lectures simples restent ouvertes, donc vous pouvez très bien dumper une pièce que vous ne pouvez pas écrire.
Les sommes de contrôle sont exactement ce qui m'a piégé à la première tentative - les chaînes correspondaient octet pour octet à un module connu bon et l'hôte refusait quand même la pièce. Bon à savoir que la page 00h suffit pour le bloc d'identification, ça limite bien la portée du travail.
Le résumé honnête est alors que mon programmateur ne peut absolument pas faire ça, parce qu'il n'a aucun moyen d'écrire l'octet 7Fh avant une lecture. Je préfère acheter une carte plutôt que d'ajouter la sélection de page à un montage fait maison pour une seule commande. Y a-t-il quelque chose sur le marché qui gère correctement les banques CMIS, ou est-ce plutôt une fonctionnalité de fiche technique ?
Les cartes du commerce l'annoncent bien - le SFPTotal Plus X, le matériel Reveltronics (REVELPROG-IS), les programmateurs EDGE et Flexoptix mettent tous le QSFP-DD et l'OSFP sur leur liste de fonctionnalités, et ils ajoutent aussi une base de codes constructeur. SFPTotal revendique plus de 25 000 codes, Cisco, Huawei et HPE inclus.
Dans quelle mesure cela correspond aux pièces précises sur votre banc est une autre question, et je ne prendrais pas ma parole pour argent comptant non plus. Si vous le pouvez, mettez un échantillon du QSFP-DD du client devant la carte avant de vous engager sur l'achat. Le support d'un format sur une fiche technique n'est pas la même chose que le support du module particulier que vous avez en main, et c'est sur les pièces bancarisées que cet écart apparaît.
Pour contraste, le travail sur SFP simple reste aussi rudimentaire qu'avant : seuls les 128 premiers octets du dump de 256 octets comptent vraiment, le reste est réservé au fabricant, et les gens écrivent depuis des années des images GLC-LX ou GLC-BX-D/GLC-BX-U sur des pièces CWDM génériques pour les faire accepter par un Catalyst 3560, un HP J8692A ou un EX4200-24F. Des schémas de programmateurs faits maison circulaient pour ça, le serp-0.3 étant celui que j'ai construit, et des dumps d'un Finisar FCMJ-8521-3, d'un HP J4858C ou J4859C, ou d'un D-Link DEM-310GT étaient les références habituelles.
Bête différente, mais bon à savoir au cas où des clés GPON atterriraient sur votre banc : là, on ne code pas du tout depuis l'extérieur. Sur un FS GPON-ONU-34-20BI, apparenté au Nokia G-010S-A, on obtient un shell sur la clé elle-même - fibre branchée, elle répond sur 192.168.1.10 en tant qu'ONTUSER - on règle le numéro de série et la MAC avec uci, et on réécrit les chaînes constructeur de l'EEPROM depuis l'intérieur avec sfp_i2c.
Les QDD et OSFP ont une structure CMIS et ne contiennent qu'un seul octet de somme de contrôle en Page 0.