Leggere e riscrivere l'EEPROM SFP sul bus I2C del Raspberry Pi invece di comprare un programmatore
Tengo a casa uno scaffale di SFP smontati e vorrei poter leggere la loro EEPROM, riparare un modulo il cui checksum si è rovinato, e ogni tanto ricodificarne uno per uno switch pignolo sulle stringhe vendor. Comprare un programmatore commerciale per una manciata di moduli l'anno qui non ha senso, quindi sto cercando di capire fin dove arriva davvero un rig fatto in casa.
Cosa c'è sul banco:
- Raspberry Pi con il bus I2C portato fuori a un alloggiamento SFP che ho cablato io stesso
- una scheda programmatore USB CH341A avanzata da un lavoro sul BIOS
- una pila mista di moduli SFP/SFP+ 1G e 10G, più due QSFP+ che vorrei guardare anche
Le letture funzionano almeno nel senso che qualcosa risponde sul 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 0x50Cosa ho fatto finora:
- ho dumpato A0h a mano e confrontato i byte con gli offset dei campi SFF-8472, il che è lento e facile da sbagliare
- ho scritto alcuni byte con il CH341A: arrivano, ma niente ricalcola i checksum per me, quindi il modulo torna come spazzatura finché non li sistemo da solo
- ho tenuto i moduli QSFP+ intoccati, perché l'alloggiamento che ho costruito accetta solo SFP
Quindi come si presenta davvero la strumentazione open per questo: c'è qualcosa che conosce il layout della memoria, verifica i byte di checksum dopo una scrittura, e può pilotare anche uno slot QSFP+? E dove smette di bastare un rig fatto in casa?
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 4
Per il lavoro SFP/SFP+ semplice il Pi basta. Il modulo è solo due dispositivi I2C, che è esattamente quello che mostra il tuo output di i2cdetect a 0x50 e 0x51, e non succede niente di magico oltre a quello. Quello che ti risparmia il conteggio dei byte è sfppi: pilota il bus I2C del Pi, decodifica i campi per te, e controlla CC_BASE e CC_EXT offrendosi di sistemarli dopo una scrittura. È esattamente il passo che il CH341A non fa per te. Il CH341A non è inutile, legge e scrive bene, semplicemente non ha idea di cosa significhino i byte, quindi ogni checksum resta un problema tuo.
Per QSFP+ il tuo alloggiamento saldato non aiuterà. Il progetto della community a cui la gente punta è Hubble, un programmatore aperto con uno slot QSFP accanto a quello SFP, quindi è quella la direzione se vuoi toccare quei due moduli. C'è anche una build essenziale di Reveltronics usata per il brute force delle password di scrittura sui moduli che rifiutano proprio le scritture. Non mi è mai servita personalmente, quindi trattala come un'indicazione e verificala su hardware che puoi permetterti di perdere.
Coincide con quello che vedo qui. Anche la seconda pagina è attiva, quindi entrambe le metà della memoria sono lì da leggere:
Rifarò il cablaggio dell'alloggiamento per bene e poi proverò il percorso del checksum su un modulo che non mi interessa prima di toccare qualcosa che voglio tenere. QSFP+ resta parcheggiato per ora, costruire un secondo alloggiamento per due moduli l'anno è difficile da giustificare, quindi quelli resteranno di sola lettura finché non deciderò se Hubble vale lo sforzo.
Aggiungo dall'altro estremo della fascia di prezzo, dato che non tutti si costruiscono il proprio: gli strumenti che si vedono in uso quotidiano sono lo SNR SFP Writer, la serie SFPTotal Plus, e vari dispositivi fatti in casa costruiti intorno a schede CH341, che è lo stesso chip che hai già sul banco.
La cosa da sapere prima di andare a fondo è che non ogni modulo è una semplice EEPROM. Alcuni portano un proprio microcontrollore che emula la memoria A0/A2 invece di esporre un chip vero, con un Medick SFP-10G-BX con dentro un C8051F392 come esempio che continua a saltare fuori. Quelli possono implementare password di scrittura o challenge vendor, e nessuna quantità di stuzzicare il bus li trasforma in un'EEPROM stupida. Il caso più ostico che la gente solleva è l'EEPROM interattiva HP/Aruba con chiavi.
Una nota pratica per il tuo alloggiamento: prendi bene il pinout o darai la caccia a fantasmi. TX_Disable è il pin 3, Mod_Abs è il pin 6, VeeR è il pin 9. Mod_Abs in particolare decide se qualcosa crede che un modulo sia presente.
E il lato del rischio, dato che raramente viene menzionato finché qualcuno non si ritrova con un modulo morto. Molti moduli vogliono una password di 4 byte prima di accettare una scrittura. La maggior parte di quelle password gira pubblicamente e non c'è un'utility universale, quindi finisci con una pila di strumenti specifici per vendor e immagini tirate fuori da database di firmware o dal produttore. Sbagliare anche solo uno di questi passi e hai brickato un modulo che costava più del programmatore.
Quindi prima di toccare l'EEPROM, dimostra che il modulo sia davvero rotto: leggi temperatura DDM, tensione, corrente di bias e potenza TX/RX da A0h/A2h, pulisci le levette, i contatti e le lenti, sostituisci con un modulo di funzionamento noto, e fai un load test del link con iperf3. Metà dei moduli che presumibilmente hanno bisogno di essere riflashati hanno solo bisogno di essere puliti.
Se preferisci pagare piuttosto che saldare, sappi che i box commerciali arrivano con le loro complicazioni. L'FS Box ricodifica bene, con quello la gente ha fatto funzionare moduli FS SFP-GE-BX su un Intel X710 con autoselect, ma programma solo moduli FS e inserire un modulo non-FS è costato agli utenti blocchi dell'account di una settimana.