Sommes de contrôle : CC_BASE, CC_EXT, CC_DMI, pages CMIS

Chaque spécification de gestion protège son bloc d’identité avec une ou plusieurs sommes de contrôle — un octet unique qui permet à l’hôte de détecter une EEPROM corrompue ou à moitié écrite avant de faire confiance à son contenu. Elles sont triviales à calculer et faciles à oublier : une somme de contrôle obsolète après une édition est la raison la plus courante pour laquelle un module fraîchement codé est signalé comme invalid.

L’algorithme

Toutes utilisent la même règle : additionner les octets de la plage couverte en valeurs non signées sur 8 bits et conserver les 8 bits de poids faible de la somme (somme modulo 256). Pas de CRC, pas de polynôme.

sum = 0
pour chaque octet b de la plage :
    sum = (sum + b) & 0xFF
checksum = sum

Exemple — les cinq premiers octets d’un SFP 10GBASE-SR : 03 04 07 10 00 → 3 + 4 + 7 + 16 + 0 = 30 = 1Eh. Continuez jusqu’à l’octet 62 et le résultat est CC_BASE.

Où vit chaque somme

Non couvertes par une somme de contrôle : les zones spécifiques au fournisseur (SFP A0h 96–127, QSFP 224–255, CMIS 223–255), l’EEPROM utilisateur, les moniteurs et indicateurs en direct, les seuils de la page 03h de QSFP, et les pages de voie CMIS. Les fournisseurs peuvent ajouter leurs propres champs d’intégrité dans l’espace fournisseur — ceux-ci ne font pas partie de la spécification.

Ce que font les hôtes avec elles

Un échec de somme de contrôle est signalé en même temps que l’identité, donc un module qui a aussi un problème de politique affiche un message qui en cache un autre — vérifiez d’abord les sommes de contrôle, c’est la correction la moins coûteuse. Carte des symptômes : Index des symptômes.

Quand il faut recalculer

• Après avoir édité n’importe quoi dans les plages couvertes — nom du fournisseur, numéro de pièce, numéro de série, code date, codes de conformité, longueur d’onde, longueurs, options, classe de puissance.
• Après avoir appliqué des seuils ou constantes d’étalonnage sur SFP (CC_DMI).
• Après avoir restauré une image partielle depuis un autre module.
• Pas nécessaire pour des changements dans l’espace fournisseur, l’EEPROM utilisateur ou les octets de contrôle A2h.

Ordre des opérations : éditer → recalculer chaque somme de contrôle affectée → écrire → relire → vérifier. Écrire l’octet de somme de contrôle avant les données qu’il couvre laisse une fenêtre où une coupure d’alimentation produit un module invalide.

Sommes de contrôle et verrouillages constructeur

Des sommes de contrôle correctes sont nécessaires, mais pas suffisantes. Une plateforme stricte vérifie aussi le bloc fournisseur et, sur les conceptions verrouillées, une signature propriétaire dans l’espace fournisseur dont les sommes de contrôle de la spécification ne savent rien. Passer CC_BASE avec une identité rejetée ressemble à un cas de verrouillage constructeur, pas à un cas de somme de contrôle — Verrouillage constructeur, Champs fournisseur.

Dans CodingBox

CodingBox recalcule automatiquement CC_BASE, CC_EXT, CC_DMI et les sommes de contrôle de page CMIS à chaque écriture, et signale une incohérence à la lecture d’un module — un champ de somme de contrôle en rouge sur Check transceiver ou dans l'EEPROM editor signifie que le module a été édité ailleurs sans correction, ou que l’EEPROM est corrompue.

Où se situe chaque somme de contrôle par rapport à ses voisines : SFF-8472 A0h (63, 95), A2h (95), SFF-8636 supérieure (191, 223), pages supérieures CMIS (222, 255), XFP (191, 223).