Lire et réécrire l'EEPROM d'un SFP via le bus I2C d'un Raspberry Pi plutôt que d'acheter un programmateur
Je garde à la maison une étagère de SFP récupérés et j'aimerais pouvoir lire leur EEPROM, réparer un module dont la somme de contrôle s'est corrompue, et de temps en temps recoder l'un d'eux pour un commutateur pointilleux sur les chaînes constructeur. Acheter un programmateur du commerce pour une poignée de modules par an n'a pas de sens ici, donc j'essaie de déterminer jusqu'où un montage fait maison peut réellement aller.
Ce qu'il y a sur le banc :
- un Raspberry Pi avec le bus I2C sorti vers une cage SFP que j'ai câblée moi-même
- une carte programmateur USB CH341A récupérée d'un job de BIOS
- un tas hétéroclite de modules SFP/SFP+ 1G et 10G, plus deux QSFP+ que j'aimerais aussi examiner
Les lectures fonctionnent au moins au sens où quelque chose répond sur le 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 0x50Ce que j'ai fait jusqu'ici :
- dumpé A0h à la main et comparé les octets aux décalages de champs du SFF-8472, ce qui est lent et source d'erreurs faciles ;
- écrit quelques octets avec le CH341A : ils s'inscrivent, mais rien ne recalcule les sommes de contrôle pour moi, donc le module revient comme des données incohérentes jusqu'à ce que je les corrige moi-même ;
- laissé les modules QSFP+ intacts, parce que la cage que j'ai construite ne prend que du SFP.
Alors, à quoi ressemble réellement l'outillage ouvert pour ça : existe-t-il quelque chose qui connaît la carte mémoire, vérifie les octets de somme de contrôle après une écriture, et peut aussi piloter un emplacement QSFP+ ? Et où un montage fait maison cesse-t-il d'être suffisant ?
Comments 4
Pour du simple travail SFP/SFP+, le Pi suffit. Le module n'est jamais que deux périphériques I2C, exactement ce que montre votre sortie i2cdetect à 0x50 et 0x51, et rien de magique ne se passe au-delà. Ce qui vous évite de compter les octets, c'est sfppi : il pilote le bus I2C du Pi, décode les champs pour vous, et vérifie CC_BASE et CC_EXT en proposant de les corriger après une écriture. C'est précisément l'étape que le CH341A ne fait pas pour vous. Le CH341A n'est pas inutile, il lit et écrit correctement, il n'a simplement aucune idée de ce que signifient les octets, donc chaque somme de contrôle reste votre problème.
Pour le QSFP+, votre cage soudée ne vous aidera pas. La conception que la communauté recommande est Hubble, un programmateur ouvert avec un emplacement QSFP à côté de celui pour SFP, donc c'est la direction à prendre si vous voulez toucher à ces deux modules. Il existe aussi un montage minimaliste Reveltronics utilisé pour la force brute sur les mots de passe d'écriture des modules qui refusent carrément les écritures. Je n'en ai jamais eu besoin moi-même, donc considérez ça comme une piste, à vérifier sur du matériel que vous pouvez vous permettre de perdre.
Ça correspond à ce que je vois ici. La deuxième page est là aussi, donc les deux moitiés de la mémoire sont disponibles en lecture :
Je vais refaire proprement le câblage de la cage, puis essayer la piste des sommes de contrôle sur un module dont je n'ai rien à faire avant de toucher à quoi que ce soit auquel je tiens. Le QSFP+ reste de côté pour l'instant, construire une deuxième cage pour deux modules par an est difficile à justifier, donc ceux-là resteront en lecture seule tant que je n'aurai pas décidé si Hubble vaut l'effort.
Pour compléter depuis l'autre bout de la gamme de prix, puisque tout le monde ne construit pas son propre matériel : les outils qu'on voit utilisés au quotidien sont le SNR SFP Writer, la série SFPTotal Plus, et divers appareils faits maison construits autour de cartes CH341, la même puce que vous avez déjà sur le banc.
Ce qui vaut la peine d'être su avant d'aller plus loin, c'est que tous les modules ne sont pas de simples EEPROM. Certains embarquent leur propre microcontrôleur qui émule la mémoire A0/A2 au lieu d'exposer une vraie puce, un Medick SFP-10G-BX avec un C8051F392 à l'intérieur étant l'exemple qui revient constamment. Ceux-là peuvent implémenter des mots de passe d'écriture ou des défis constructeur, et aucune manipulation du bus ne les transforme en une simple EEPROM. Le cas le plus vicieux qu'on cite est l'EEPROM interactive HP/Aruba avec des clés.
Une note pratique pour votre propre cage : ayez le bon brochage ou vous allez courir après des fantômes. TX_Disable est la broche 3, Mod_Abs la broche 6, VeeR la broche 9. Mod_Abs en particulier décide si quoi que ce soit croit même qu'un module est présent.
Et le côté risque, puisqu'on en parle rarement avant que quelqu'un ait un module mort. Beaucoup de modules exigent un mot de passe de 4 octets avant d'accepter une écriture. La plupart de ces mots de passe circulent publiquement et il n'existe pas d'utilitaire universel, donc on se retrouve avec un tas d'outils et d'images spécifiques à chaque constructeur, tirés de bases de données de firmwares ou du fabricant. Faites une erreur là-dedans et vous avez briqué un module qui a coûté plus cher que le programmateur.
Donc avant de toucher à l'EEPROM, prouvez d'abord que le module est réellement défectueux : lisez la température, la tension, le courant de polarisation et la puissance TX/RX du DDM dans A0h/A2h, nettoyez les loquets, les contacts et les lentilles, remplacez par un module connu bon, et testez le lien en charge avec iperf3. La moitié des modules soi-disant à reflasher n'ont besoin que d'être nettoyés.
Si vous préférez payer plutôt que souder, sachez que les boîtiers du commerce viennent avec leurs propres contraintes. Le FS Box recode bien, des gens ont fait fonctionner des modules FS SFP-GE-BX sur une Intel X710 avec autoselect de cette façon, mais il ne programme que des modules FS, et insérer un module non-FS a valu à des utilisateurs des blocages de compte d'une semaine.