Référence EEPROM des hashboards Antminer : familles d’analyseurs, disposition, et pourquoi les cartes ne sont pas interchangeables

Chaque hashboard d’Antminer porte une petite EEPROM I²C qui répond à une seule question pour la carte de contrôle : quelle est cette carte, et comment a-t-elle été calibrée? Quand cette puce ne peut pas être lue — ou que son contenu ne correspond pas à ce que le firmware attend — le mineur signale une « erreur EEPROM » et refuse de faire hacher la carte. Cette référence explique ce que contient réellement cette EEPROM à travers les générations S19 et S21, pourquoi les données sont chiffrées, pourquoi les cartes ne sont pas librement interchangeables, et ce que cela signifie lors d’un diagnostic de réparation.

Le détail structurel présenté ici provient de notre propre rétro-ingénierie des analyseurs d’EEPROM embarqués, recoupée avec des relevés de cartes réels sur notre banc. Nous publions la disposition et la structure des champs — pas les clés de chiffrement ni les routines de dérivation de clé, qui restent la propriété de leurs auteurs. Crédit là où il est dû : cette compréhension s’appuie sur l’écosystème open-source du firmware de minage (la lignée BraiinsOS et la communauté élargie qui a documenté ces cartes).

Ce que stocke l’EEPROM — et ce qu’elle ne stocke pas

Le fait le plus utile pour un technicien : les chiffres vedettes affichés dans l’interface d’un mineur — type de puce, tension, fréquence, hashrate — ne sont pas stockés tels quels dans l’EEPROM. Ce que l’EEPROM contient, c’est l’identité de la carte et sa calibration d’usine; le firmware calcule les paramètres de fonctionnement en cherchant le nom de la carte dans une table de SKU interne et en appliquant une courbe tension/fréquence.

Les champs qui sont stockés (variant légèrement selon la génération) comprennent :

• Numéro de série — le numéro de série ASCII de 17 caractères.
• Nom de la carte (B-NAME) — p. ex. un désignateur de série BHB qui correspond à une génération de puces.
• Identité de la puce — révision du die, marquage de puce et grade de bin d’usine.
• Chaîne de fonction/calibration (FT) et un descripteur de courbe V/F — la calibration propre à la carte.
• Version du PCB et version du BOM.
• Code de lot d’usine — le lot de fixture dans lequel la carte a été testée.
• Sur les cartes de classe S19j, des rangées de capteurs explicites : types de capteurs de température et leurs adresses I²C, y compris le capteur à base de PIC.

Parce que la calibration est propre à chaque carte, deux hashboards visuellement identiques ne sont pas interchangeables côté données — un point qui rejoint directement le rôle de l’EEPROM dans les appareils Antminer et le microcontrôleur PIC qui co-stocke la calibration sur les cartes de série S19.

Quatre familles d’analyseurs, par génération

Les EEPROM de hashboards Antminer ne suivent pas un format unique — c’est une famille qui a évolué avec le silicium. Le firmware aiguille vers l’un de quatre analyseurs selon un court préambule au début de la puce :

Deux choses ont changé au fil du temps : le chiffrement (les cartes de l’ère S19 utilisent XXTEA; les S19k Pro et la génération S21 sont passées à l’AES-128) et la structure (le format S19j et suivants scinde les données en deux sections protégées par CRC indépendamment — infos de carte et infos de paramètres — plutôt qu’un bloc plat unique).

L’aiguillage par préambule

Le premier octet (ou les deux premiers) de l’EEPROM sélectionne l’analyseur. En pratique : une carte de génération S19 débute par un octet de disposition 0x04, tandis que la génération S19k Pro / S21 débute par 0x05. Les cartes propres à Braiins portent un préfixe magique distinct. C’est ainsi que le firmware distingue une carte BM1398 d’une carte BM1370 avant même de déchiffrer un seul champ — la famille est lisible dès l’en-tête.

Pourquoi deux sections protégées par CRC (S19j et suivants)

Sur les cartes de classe S19j et plus récentes, la charge utile porte deux régions protégées par somme de contrôle : une section infos de carte (identité, capteurs, données de puce) et une section infos de paramètres (la calibration). Chacune a son propre CRC et sa longueur attendue. Une conséquence pour la réparation en découle : une corruption localisée à une section produit une panne différente d’une corruption dans l’autre, et un clone valide exige que les deux sections soient correctes — pas une simple copie octet par octet qui inclurait un CRC périmé.

Ce qui déclenche réellement une « erreur EEPROM »

Le firmware rejette l’EEPROM d’une carte pour plusieurs raisons distinctes, chacune menant à une réparation différente :

• Échec de lecture sur le bus I²C — la puce ne répond pas du tout. Suspectez l’EEPROM elle-même, son rail d’alimentation ou les lignes I²C. Cela recoupe la famille « carte non reconnue » de notre guide de correction des erreurs EEPROM.
• Version/disposition incohérente — l’octet de préambule n’est pas celui que l’analyseur attend (une carte flashée avec les mauvaises données, ou une génération réellement différente).
• Échec de déchiffrement / mauvais magic — la charge utile chiffrée ne se décode pas, indiquant en général un contenu corrompu ou mal écrit.
• Échec de CRC — les données se déchiffrent mais une somme de contrôle de section est fausse; signe classique d’une écriture partielle ou incohérente.
• Incohérence de nom de carte — le B-NAME stocké ne correspond pas à la famille SKU attendue par le firmware, exactement ce qui arrive quand on mélange des cartes de mineurs différents.

Les enseignements pour l’atelier

Trois choses que cette architecture vous apprend au banc. Un : les données EEPROM sont propres à la carte — vous ne pouvez pas simplement déplacer un hashboard entre deux mineurs et espérer qu’il hache; l’identité et la calibration stockées doivent être cohérentes avec l’ensemble. Deux : une « erreur EEPROM » est une invitation au diagnostic, pas un verdict : elle se scinde en pannes I²C/matérielles, corruption d’écriture et incohérence — traitées différemment. Trois : parce que les paramètres de fonctionnement sont calculés à partir de l’identité stockée plutôt que stockés directement, une carte à calibration corrompue peut quand même s’énumérer tout en tournant mal — c’est là que la mesure des domaines de tension et la méthode de la fixture de test de hashboard font leurs preuves.

Une note sur l’outillage et l’éthique : lire et réécrire ces EEPROM sur du matériel que vous possédez est un travail de réparation ordinaire. Redistribuer les clés de chiffrement d’un fabricant ou son code de dérivation de clé ne l’est pas, et nous ne le faisons pas — nos références publiées couvrent la structure et la méthode seulement. Pour le contexte plus large des cartes, voyez notre référence des cartes de contrôle ASIC et notre guide de la chaîne de démarrage NAND.

Si une carte lance une erreur EEPROM et que vous préférez ne pas la traquer vous-même sur le bus I²C, c’est du travail quotidien à notre atelier de réparation à Montréal — EEPROM, PIC et diagnostic complet au niveau de la carte inclus.

Bitaxe GT" width="80" height="80" loading="lazy" style="width:80px;height:80px;object-fit:contain;border-radius:6px;background:#1A1A1A;flex-shrink:0;">

The Bitaxe GT 269.99 $ CAD

Acheter le Bitaxe GT →