Lendo e regravando EEPROM de SFP pelo barramento I2C do Raspberry Pi em vez de comprar um programador
Guardo uma prateleira de SFPs retirados em casa e gostaria de conseguir ler a EEPROM deles, consertar um módulo cujo checksum bagunçou, e de vez em quando recodificar um para um switch chato com vendor strings. Comprar um programador comercial para um punhado de módulos por ano não faz sentido aqui, então estou tentando descobrir até onde uma bancada caseira realmente chega.
O que está na bancada:
- Raspberry Pi com o barramento I2C levado até uma gaiola SFP que eu mesmo fiei
- uma placa programadora USB CH341A sobrando de um trabalho de BIOS
- uma pilha misturada de módulos SFP/SFP+ de 1G e 10G, mais dois QSFP+ que eu também gostaria de olhar
As leituras funcionam pelo menos no sentido de que algo responde no barramento:
$ 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 0x50O que já fiz até agora:
- dumpei A0h na mão e comparei os bytes contra os offsets de campo do SFF-8472, o que é lento e fácil de errar
- gravei alguns bytes com o CH341A: eles pegam, mas nada recalcula os checksums para mim, então o módulo volta como lixo até eu corrigir na mão
- deixei os módulos QSFP+ intocados, porque a gaiola que construí só aceita SFP
Então como é de fato a ferramenta aberta para isso: existe algo que conhece o layout de memória, verifica os bytes de checksum depois de uma escrita, e também consegue comandar um slot QSFP+? E onde uma bancada caseira para de ser suficiente?
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
Para trabalho simples de SFP/SFP+ o Pi basta. O módulo é só dois dispositivos I2C, que é exatamente o que a sua saída do i2cdetect mostra em 0x50 e 0x51, e nada de mágico acontece além disso. O que te poupa de contar byte é o sfppi: ele comanda o barramento I2C do Pi, decodifica os campos para você, e checa o CC_BASE e o CC_EXT e se oferece para corrigi-los depois de uma escrita. Esse é exatamente o passo que o CH341A não faz por você. O CH341A não é inútil, ele lê e grava bem, só que não tem ideia do que os bytes significam, então todo checksum continua sendo problema seu.
Para QSFP+ sua gaiola soldada não vai ajudar. O design que a comunidade indica é o Hubble, um programador aberto com um slot QSFP ao lado do SFP, então é essa a direção se você quer mexer nesses dois módulos. Também existe uma montagem simples da Reveltronics usada para brute force de senhas de escrita em módulos que recusam gravação de vez. Eu mesmo nunca precisei dessa, então trate como uma indicação e teste em hardware que você pode se dar ao luxo de perder.
Isso bate com o que vejo aqui. A segunda página também está lá disponível, então as duas metades da memória estão presentes para leitura:
Vou refazer a fiação da gaiola direito e depois tentar o caminho do checksum em um módulo que não me importa antes de tocar em qualquer coisa que eu queira manter. QSFP+ fica estacionado por enquanto, construir uma segunda gaiola para dois módulos por ano é difícil de justificar, então esses vão continuar somente leitura até eu decidir se o Hubble vale o esforço.
Complementando pelo outro extremo da faixa de preço, já que nem todo mundo constrói o próprio: as ferramentas que se vê em uso diário são o SNR SFP Writer, a série SFPTotal Plus, e vários dispositivos avulsos construídos em torno de placas CH341, que é o mesmo chip que você já tem na bancada.
A coisa que vale saber antes de se aprofundar é que nem todo módulo é uma EEPROM simples. Alguns carregam seu próprio microcontrolador que emula a memória A0/A2 em vez de expor um chip de verdade, sendo o Medick SFP-10G-BX com um C8051F392 dentro o exemplo que sempre volta a aparecer. Esses podem implementar senhas de escrita ou challenges de vendor, e nenhuma quantidade de cutucar o barramento transforma eles em uma EEPROM burra. O caso mais chato que as pessoas trazem é a EEPROM interativa com chaves da HP/Aruba.
Uma nota prática para a sua própria gaiola: acerte o pinout ou você vai caçar fantasmas. TX_Disable é o pino 3, Mod_Abs é o pino 6, VeeR é o pino 9. Mod_Abs em particular decide se alguma coisa acredita que existe um módulo presente.
E o lado do risco, já que raramente é mencionado até alguém ter um módulo morto. Muitos módulos querem uma senha de 4 bytes antes de aceitar uma escrita. A maioria dessas senhas está circulando por aí publicamente e não existe utilitário universal, então você acaba com uma pilha de ferramentas específicas de vendor e imagens puxadas de bases de firmware ou do fabricante. Erre qualquer coisa disso e você emparedou um módulo que custou mais que o programador.
Então antes de sequer tocar na EEPROM, prove que o módulo está realmente quebrado: leia temperatura, tensão, bias current e potência TX/RX do DDM em A0h/A2h, limpe as travas, contatos e lentes, troque por um módulo comprovadamente bom, e faça teste de carga no link com iperf3. Metade dos módulos que supostamente precisam de reflash só precisam de limpeza.
Se você prefere pagar a soldar, saiba que as caixas comerciais vêm com seus próprios pesares. O FS Box recodifica bem, gente conseguiu módulos FS SFP-GE-BX funcionando em um Intel X710 com autoselect desse jeito, mas ele só programa módulos FS e inserir um módulo não-FS já rendeu a usuários bloqueios de conta de uma semana.