Il programmatore restituisce WRITE FAIL su un SFP+ che si dumpa senza problemi: EEPROM morta o qualcosa blocca le scritture?
La maggior parte dei mesi ricodifichiamo un piccolo lotto di moduli per gli host dei clienti, niente di esotico: leggi la pagina originale, scrivi la stringa vendor che l'host vuole, metti il modulo nello switch e vai avanti. Un modulo del lotto attuale rifiuta ogni scrittura pur rileggendo perfettamente, e prima di buttarlo vorrei sapere se c'è ancora qualcosa da provare.
Banco di lavoro:
- programmatore USB classe CH341 con scheda breakout per SFP
- modulo SFP+, con diagnostica, legge bene a freddo e dopo un power cycle
- lo stesso rig ha scritto altri tre moduli dello stesso vassoio un'ora prima
Quello che stampa lo strumento nel momento in cui lancio la scrittura:
WRITE FAILRileggendo subito dopo ottengo indietro la pagina originale byte per byte, quindi non è arrivato niente, nemmeno parzialmente.
Cosa ho provato:
- ho reinserito il modulo e sostituito la scheda breakout con una di scorta
- ho scritto un solo byte in una zona che non mi interessa invece della pagina intera, stesso risultato
- ho confermato che la lettura è stabile attraverso diversi power cycle, quindi il cablaggio non è al limite
Un modulo che legge pulito ma non accetta mai una scrittura è semplicemente usurato, o c'è qualcosa nel modulo stesso che può rifiutare le scritture di proposito?
Comments 5
Legge pulito, scritture rifiutate, pagina originale intatta dopo. Non è così che si comporta normalmente un'EEPROM usurata. Le celle morte ti danno una rilettura sbagliata o una pagina che ha preso metà della scrittura, non un rifiuto ordinato con tutto intatto.
E dato che anche quel singolo byte fuori dall'area vendor è rimbalzato, non è una zona guasta del chip, è il componente che respinge le scritture in blocco. Due cose da chiarire prima di decidere qualsiasi cosa. Primo, chi ha effettivamente costruito il modulo: guarda la stringa vendor nella pagina che hai già dumpato, non quello che c'era scritto sul vassoio. Secondo, se una scrittura arriva a segno se la lanci nel momento in cui arriva l'alimentazione, prima che qualsiasi altra cosa sul bus abbia parlato con il modulo. La spiegazione probabile cambia a seconda di quelle risposte, e una delle due non è affatto un guasto.
Sembra più protezione da password che danno. SFF-8472 permette a un modulo con diagnostica di richiedere una password di 4 byte prima di accettare qualsiasi scrittura. Non mandarne nessuna, o mandane una sbagliata, e il modulo risponde alla scrittura con un errore mentre le letture restano completamente aperte, che è esattamente il tuo WRITE FAIL con la pagina che torna invariata. È una caratteristica del componente, non il sintomo di uno morente.
Cosa significa per il tuo banco: un programmatore che lo sa ti permette di inserire una password manufacturer o host, e i migliori fanno il brute force di una sconosciuta e ricalcolano i checksum per te dopo la scrittura. Un rig classe CH341 non ha automazione dei checksum, quindi anche dopo aver superato la password devi sistemare i checksum da solo, altrimenti finisci con un modulo la cui pagina ti sembra giusta e che l'host continua a rifiutare.
Avvertenza solita: mi è capitato su una manciata di moduli e lì la strada della password ha funzionato, quindi provala sul tuo pezzo prima di dare qualcosa per spacciato.
Ad aggiunta di questo: per alcuni vendor le password non sono poi così segrete. Circolano raccolte condivise di password per transceiver Ubiquiti con voci come 0x00001011 e stringhe semplici come SFPX e QSFP, quindi se il modulo viene da quell'ecosistema ti costa cinque minuti provare quelle note prima di avvicinarti anche solo al brute force.
E se vuoi uno strumento che conosce già tutto il flusso invece di lottare con un programmatore generico, l'UACC-SFP-WIZARD è l'opzione economica a cui la gente ricorre. Non è uno strumento da laboratorio, ma gestisce bene il lato modulo.
Cosa collegata, dalla ricodifica di moduli per host Huawei S5731 e S6730 e un vecchio HP 6120XG. Quando l'anello debole è l'alloggiamento o il breakout piuttosto che il modulo, la gente salda direttamente sui pin 4 e 7 del modulo, che sono le linee I2C SDA e SCL, e pilota l'EEPROM con l'alloggiamento completamente fuori dai giochi. Brutto da vedere, e lo fai solo su pezzi che sei pronto a perdere, ma elimina un'intera classe di problemi di contatto.
Pezzi passati di qua per quello: Finisar FTLX8571D3BCV e FTLX8574D3BCV, moduli Intel SFP+ LR e SR, SNR-SFP+W73-3 e SNR-SFP+W37-3, più un HP J9150A.
Nel tuo caso la lettura è già solidissima attraverso i power cycle, quindi il contatto non è il tuo problema. Insegui prima la pista della password.
La password è la risposta probabile, ma non fermarti a «digiti la password e hai finito», perché due cose mordono la gente subito dopo.
Primo, su alcuni pezzi l'inserimento è richiesto di nuovo dopo che il modulo è stato spento, quindi uno script che scrive più pagine in sequenza deve essere pronto a reinserirla invece di dare per scontato che uno sblocco copra tutta la sessione.
Secondo, i checksum. Con un programmatore classe CH341 li ricalcoli a mano. Lasciali non aggiornati e il modulo continua a leggere bene, il tuo strumento segnala successo, e l'host rifiuta comunque il modulo in silenzio, a quel punto tutti tornano a dare la colpa all'hardware. Rileggi la pagina e verifica le somme prima che quel modulo finisca nello switch di un cliente.