NAND des Antminer : chaîne de démarrage, symptômes de corruption et récupération

Quand un Antminer refuse de démarrer — aucune interface web, aucun hachage, parfois même pas de témoin réseau — le diagnostic se résume souvent à deux mots : NAND corrompue. La mémoire NAND de la carte de contrôle contient tout ce dont le mineur a besoin pour devenir un mineur : le chargeur d’amorçage, le bitstream FPGA, le noyau Linux, le système de fichiers racine et votre configuration. Quand l’une de ces partitions se dégrade, la machine n’est plus qu’une brique ventilée tant qu’on ne les réécrit pas.

Ce guide explique ce qui se trouve réellement sur cette puce, le fonctionnement de la chaîne de démarrage étape par étape, quels symptômes pointent vers quelle étape défaillante, et la voie de récupération pour chaque famille de cartes de contrôle — Zynq, BeagleBone et Amlogic. Il s’appuie sur l’expérience de notre atelier de réparation et sur les travaux open-source qui ont cartographié ces cartes, notamment polprog/antminer_zynq, braiins/zynq-io et skot/amlogic-cb-tools.

Ce que contient la NAND : la table de partitions Zynq

Sur les cartes de contrôle Xilinx Zynq (C55/C71 — les cartes classiques de l’ère S9 à S19), la NAND est une Winbond W29N02GZ de 256 Mo (certaines révisions portent 512 Mo), divisée en huit partitions MTD :

Deux détails de cette table décident de la plupart des récupérations. D’abord, la partition critique au démarrage (mtd0) est vérifiée par RSA contre des clés gravées dans les eFuses du SoC — impossible de substituer votre propre chargeur ou bitstream sur une carte verrouillée. Ensuite, le système de fichiers racine (mtd1) n’est vérifié que par SHA256 contre des hachés stockés dans mtd3 — c’est pourquoi les développeurs de firmware (y compris notre propre travail sur DCENT_OS) peuvent remplacer le ramdisk tout en laissant intacte la façade de démarrage vérifiée.

La chaîne de démarrage, étape par étape

Connaître l’ordre des opérations transforme un mineur mort en liste de vérification. Sur une carte Zynq, la séquence est :

1. BootROM — codé en dur dans le silicium. Lit les broches de mode de démarrage et choisit entre NAND et carte SD.
2. FSBL (First Stage Boot Loader) — chargé depuis BOOT.bin, vérifié par RSA, initialise la mémoire DDR et les horloges.
3. Bitstream FPGA (soc_system.rbf) — vérifié par RSA, programme la logique FPGA qui gère toute la communication avec les hashboards.
4. U-Boot — vérifié par RSA, charge le noyau, l’arbre de périphériques et le ramdisk depuis la NAND.
5. Noyau Linux — vérifié par U-Boot.
6. Ramdisk — contrôlé par SHA256 contre la partition de signatures mtd3, puis monté comme racine.
7. Init — charge les deux modules noyau du FPGA (bitmain_axi.ko et fpga_mem_driver.ko), démarre bmminer/cgminer, l’interface web lighttpd sur le port 80 et le DHCP.

Associer les symptômes à l’étape défaillante

• Rien du tout — aucune activité Ethernet, aucun signe de vie au-delà des ventilateurs. La défaillance est précoce : la BootROM ne trouve pas de FSBL valide dans mtd0, ou la carte a un problème d’alimentation. Si une carte SD de récupération réputée bonne ne donne rien non plus, suspectez le matériel de la carte plutôt que la NAND.
• Démarre, mais l’interface web et le DHCP n’arrivent jamais. Le début de chaîne a fonctionné; c’est l’étape du noyau ou du ramdisk qui échoue. Un ramdisk qui échoue à son contrôle SHA256 contre mtd3 arrête le démarrage net à l’étape 7.
• Démarre, l’interface web répond, mais les réglages disparaissent à chaque redémarrage. Corruption classique de mtd2 (configs/UBI) — le mineur tourne depuis son ramdisk en lecture seule mais ne peut plus conserver vos réglages de pool.
• Les mises à niveau échouent en boucle, mais le mineur fonctionne. Regardez les partitions de préparation (mtd5/mtd6) — des blocs défectueux y cassent la mise à niveau sans toucher au fonctionnement normal.

Avant d’accuser la NAND, écartez les suspects faciles : un bloc d’alimentation défaillant peut produire des boucles de démarrage qui imitent une corruption de mémoire. Notre guide de dépannage PSU et notre guide de lecture des kernel logs couvrent ce triage, et la bibliothèque de dépannage ASIC cartographie les codes d’erreur.

Les voies de récupération par famille de cartes

Zynq (C55/C71) — la plus accommodante

Ces cartes exposent un cavalier (J3) qui sélectionne la source de démarrage : ouvert, démarrage depuis la NAND (par défaut); court-circuité, démarrage depuis la carte SD. La récupération est donc directe : écrivez une image de récupération sur une carte SD, court-circuitez le cavalier, démarrez, et laissez l’environnement de récupération réécrire les partitions NAND. Notre guide de flashage et récupération par carte SD détaille la procédure — c’est le même mécanisme qui permet d’installer DCENT_OS sur le S9.

BeagleBone (BBB) — toujours sur SD

Les cartes TI AM335x apparues fin 2021 dans les S19j/S19j Pro n’ont pas de FPGA et démarrent depuis une carte SD logée sous le couvercle du boîtier. Reflasher, c’est réimager cette carte — aucun cavalier à chercher.

Amlogic (C76/C81/C83) — la verrouillée

Les cartes Amlogic A113D des S19 récents, S19 XP, S21 et T21 n’ont aucun lecteur de carte SD — la seule source de démarrage est la NAND interne. La récupération passe par le port micro-USB OTG avec un adaptateur OTG et une clé USB. De plus, les unités expédiées après mars 2024 portent des verrous de firmware qui exigent une procédure de déverrouillage spécifique avant qu’une image tierce ne s’exécute. Si votre mineur Amlogic boucle au démarrage et que la procédure OTG ne prend pas, c’est un travail d’atelier, pas de terrain.

Quand s’arrêter et nous l’envoyer

Reflasher corrige la corruption; cela ne répare ni une puce NAND en fin de vie, ni une carte verrouillée par eFuse qui rejette toutes les images, ni une carte dont le vrai problème est un régulateur de tension mort en amont du SoC. Si une image de récupération propre ne tient pas — ou si les mêmes partitions se corrompent encore — la puce ou son alimentation exige une intervention au niveau de la carte. C’est exactement le travail quotidien de notre atelier de réparation à Montréal, cartes de contrôle comprises. En cas de doute sur la panne, envoyez-nous les symptômes et nous vous dirons franchement si l’envoi en vaut la peine.

La souveraineté sur votre matériel de minage commence par comprendre ce qui se trouve réellement sur la puce. Cartographiez les partitions, suivez la chaîne de démarrage, et la plupart des Antminer « briqués » ne sont qu’à une carte SD de se remettre à hacher.