Programador retorna WRITE FAIL em um SFP+ que faz dump limpo: EEPROM morta ou algo bloqueando as escritas
Na maioria dos meses recodificamos um lote pequeno de módulos para hosts de clientes, nada exótico: lê a página original, grava a vendor string que o host quer, coloca o módulo no switch e segue. Um módulo do lote atual recusa toda escrita enquanto lê de volta perfeitamente, e antes de jogar fora eu gostaria de saber se ainda sobra algo para tentar.
Bancada:
- programador USB classe CH341 com uma breakout board de SFP
- módulo SFP+, com diagnóstico, lê bem a frio e depois de um power cycle
- a mesma bancada gravou três outros módulos da mesma bandeja uma hora antes
O que a ferramenta imprime no momento em que mando gravar:
WRITE FAILRelendo logo em seguida recebo a página original de volta byte a byte, então nada foi gravado, nem parcialmente.
O que tentei:
- reencaixei o módulo e troquei a breakout board por uma sobressalente
- gravei um único byte em uma região que não me importa em vez da página inteira, mesmo resultado
- confirmei que a leitura é estável em vários power cycles, então a fiação não está no limite
Um módulo que lê limpo mas nunca aceita uma escrita está simplesmente gasto, ou existe algo no próprio módulo que pode recusar escritas de propósito?
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
Lê limpo, recusa escrita, página original intacta depois. Não é assim que uma EEPROM gasta costuma se comportar. Células mortas dão uma releitura ruim ou uma página que recebeu metade da escrita, não uma recusa arrumadinha com tudo intocado.
E já que até aquele byte único fora da área de vendor foi recusado, não é uma região ruim do chip, é a peça recusando escritas por atacado. Duas coisas valem a pena confirmar antes de decidir qualquer coisa. Primeiro, quem realmente fabricou o módulo: vá pela vendor string na página que você já dumpou, não pelo que a bandeja tinha escrito. Segundo, se uma escrita pega quando disparada no exato momento em que a energia sobe, antes de qualquer outra coisa no barramento ter falado com o módulo. A explicação provável muda dependendo dessas respostas, e uma delas nem é defeito.
Isso tem cara de proteção por senha, não de dano. O SFF-8472 permite que um módulo com diagnóstico exija uma senha de 4 bytes antes de aceitar qualquer escrita. Não mande nada, ou mande a errada, e o módulo responde a escrita com erro enquanto a leitura continua totalmente aberta, que é exatamente o seu WRITE FAIL com a página voltando sem mudança. É um recurso da peça, não sintoma de uma agonizando.
O que isso significa para a sua bancada: um programador que conhece isso deixa você digitar uma senha de fabricante ou de host, e os melhores fazem brute force de uma desconhecida e recalculam os checksums para você depois da escrita. Uma bancada classe CH341 não tem nenhuma automação de checksum, então mesmo depois de passar da senha você tem que corrigir os checksums na mão, senão acaba com um módulo cuja página parece certa para você e que o host continua recusando.
Ressalva de sempre: eu já esbarrei nisso em um punhado de módulos e o caminho da senha funcionou lá, então tente na sua própria peça antes de descartar qualquer coisa.
Para completar: em alguns vendors as senhas não são lá muito secretas. Circulam coleções compartilhadas de senhas de transceiver Ubiquiti com entradas como 0x00001011 e strings simples como SFPX e QSFP, então se o módulo veio desse ecossistema custa cinco minutos tentar as conhecidas antes de chegar perto de brute force.
E se você quer uma ferramenta que já conhece o fluxo inteiro em vez de brigar com um programador genérico, o UACC-SFP-WIZARD é a opção barata que as pessoas costumam pegar. Não é um instrumento de laboratório, mas cuida bem do lado do módulo.
Relacionado, de recodificar módulos para hosts Huawei S5731 e S6730 e um HP 6120XG velho. Quando a gaiola ou a breakout board é o elo fraco em vez do módulo, tem gente que solda direto nos pinos 4 e 7 do módulo, que são as linhas I2C SDA e SCL, e comanda a EEPROM com a gaiola totalmente fora da jogada. Feio, e você só faz isso em peças que está disposto a perder, mas tira do caminho uma classe inteira de problema de contato.
Peças que já passaram por isso aqui: Finisar FTLX8571D3BCV e FTLX8574D3BCV, módulos Intel SFP+ LR e SR, SNR-SFP+W73-3 e SNR-SFP+W37-3, mais um HP J9150A.
No seu caso a leitura já está sólida como rocha entre power cycles, então contato não é o seu problema. Persiga primeiro o ângulo da senha.
Senha é a resposta provável, mas não fique só em "digita a senha e pronto", porque duas coisas mordem logo depois disso.
Primeiro, em algumas peças a entrada é exigida de novo depois que o módulo é desenergizado, então um script que grava várias páginas em sequência precisa estar pronto para digitar de novo, em vez de assumir que um unlock cobre a sessão inteira.
Segundo, os checksums. Com um programador classe CH341 você os recalcula na mão. Deixe-os desatualizados e o módulo ainda lê bem, sua ferramenta reporta sucesso, e o host recusa o módulo em silêncio mesmo assim, e nesse ponto todo mundo volta a culpar o hardware. Releia a página e verifique as somas antes de esse módulo ir para o switch de um cliente.