Somas de verificação: CC_BASE, CC_EXT, CC_DMI, páginas CMIS

Toda especificação de gerenciamento protege seu bloco de identidade com uma ou mais somas de verificação — um único byte que permite ao host detectar uma EEPROM corrompida ou parcialmente gravada antes de confiar no conteúdo. Elas são triviais de calcular e fáceis de esquecer: uma soma de verificação desatualizada depois de uma edição é o motivo mais comum de um módulo recém-gravado ser reportado como inválido.

O algoritmo

Todas seguem a mesma regra: somar os bytes do intervalo coberto como valores de 8 bits sem sinal e manter os 8 bits menos significativos da soma (soma módulo 256). Sem CRC, sem polinômio.

sum = 0
for each byte b in range:
    sum = (sum + b) & 0xFF
checksum = sum

Exemplo — os cinco primeiros bytes de um SFP 10GBASE-SR: 03 04 07 10 00 → 3 + 4 + 7 + 16 + 0 = 30 = 1Eh. Continue até o byte 62 e o resultado é o CC_BASE.

Onde cada soma de verificação fica

Não cobertos por nenhuma soma de verificação: as áreas específicas do fabricante (SFP A0h 96–127, QSFP 224–255, CMIS 223–255), a EEPROM de usuário, os monitores e sinalizadores em tempo real, os limiares da page 03h do QSFP, e as lane pages do CMIS. Os fabricantes podem acrescentar seus próprios campos de integridade no espaço do fabricante — eles não fazem parte da especificação.

O que os hosts fazem com elas

Uma falha de soma de verificação é reportada junto com a identidade, então um módulo que também tem um problema de política mostra uma mensagem escondendo a outra — verifique as somas de verificação primeiro, elas são o conserto barato. Mapa de sintomas: Índice de sintomas.

Quando você precisa recalcular

• Depois de editar qualquer coisa nos intervalos cobertos — nome do fabricante, número de peça, serial, código de data, códigos de conformidade, comprimento de onda, comprimentos, opções, classe de potência.
• Depois de aplicar limiares ou constantes de calibração em um SFP (CC_DMI).
• Depois de restaurar uma imagem parcial de outro módulo.
• Não é necessário para mudanças no espaço do fabricante, na EEPROM de usuário ou nos bytes de controle do A2h.

Ordem das operações: editar → recalcular cada soma de verificação afetada → gravar → reler → verificar. Gravar o byte da soma de verificação antes dos dados que ela cobre deixa uma janela em que uma queda de energia produz um módulo inválido.

Somas de verificação e bloqueios do fabricante

Somas de verificação corretas são necessárias, mas não suficientes. Uma plataforma rigorosa também verifica o bloco do fabricante e, em projetos travados, uma assinatura proprietária no espaço do fabricante que as somas de verificação da especificação desconhecem por completo. Passar no CC_BASE com uma identidade rejeitada parece um caso de bloqueio do fabricante, não um caso de soma de verificação — Bloqueio do fabricante, Campos do fabricante.

No CodingBox

O CodingBox recalcula o CC_BASE, o CC_EXT, o CC_DMI e as somas de verificação de página do CMIS automaticamente em cada gravação, e destaca uma divergência ao ler um módulo — um campo de soma de verificação em vermelho na tela Check transceiver ou no EEPROM editor significa que o módulo foi editado em outro lugar sem corrigi-la, ou que a EEPROM está corrompida.

Onde cada soma de verificação fica entre seus vizinhos: SFF-8472 A0h (63, 95), A2h (95), SFF-8636 superior (191, 223), páginas superiores CMIS (222, 255), XFP (191, 223).