Contraintes mémoire

Optimisation logicielle par l'utilisation de Braiins OS (vs Firmware Stock)

Le micrologiciel d'origine de Bitmain applique des réglages électriques uniformes qui brident le potentiel du matériel. L'installation d'un système alternatif comme Braiins OS transforme l'exploitation de l'Antminer S9 grâce à quatre optimisations majeures :

• Autotuning par puce (Loterie du silicium) : Contrairement au firmware d'origine qui s'aligne sur la puce la plus faible d'une carte, Braiins OS ajuste la fréquence et la tension de chaque puce BM1387 individuellement. Cela permet d'exploiter le meilleur de chaque ASIC et d'optimiser l'efficience globale (Joules/TH).
• Power Target (Contrôle de la puissance) : Permet de fixer une limite de consommation stricte au watt près (ex: brider le S9 à 1000W au lieu de 1450W). Idéal pour réduire drastiquement le bruit des ventilateurs et la chaleur dégagée en usage domestique.
• Tolérance aux pannes : Si une puce fatigue et génère des erreurs, le firmware d'origine coupe souvent toute la carte de hachage (hashboard). Braiins OS isole chirurgicalement la puce défaillante pour maintenir le reste de la carte en production.
• Protocole Stratum V2 : Intègre la nouvelle génération de protocole réseau, offrant un chiffrement des données (sécurité contre le détournement de hashrate) et une réduction de la bande passante internet.

Fonctionnalité	Firmware Stock Bitmain	Braiins OS
Gestion des ASIC	Globale (par carte)	Individuelle (par puce)
Consommation	Profils fixes d'usine	Ajustable au Watt près
Gestion des erreurs	Arrêt de la carte complète	Isolation de la puce malade
Protocole Réseau	Stratum V1 (vulnérable)	Stratum V2 (chiffré, optimisé)

Mon choix c'est donc évidement porté sur l'utilisation d'une image BraiinOS.

Intégration de logiciels tierces

Pour interconnecter l'infrastructure de minage avec l'environnement domotique (notamment le thermostat connecté), le choix s'est porté sur une stack logicielle légère, moderne et directement embarquée sur la carte de contrôle.

Environnement d'exécution

• Python 3 & pip3 : Utilisation de Python 3 pour sa syntaxe de haut niveau, sa rapidité de développement et sa polyvalence. Le gestionnaire de paquets pip3 permet d'isoler et d'installer proprement les dépendances nécessaires directement sur l'OS embarqué.

Pilotage local du thermostat

• Librairie tinytuya : Cette bibliothèque Python permet de s'affranchir totalement du cloud officiel Tuya. Elle intercepte et émet les commandes directement sur le réseau local (LAN) vers le thermostat BEOK. Cela garantit une latence minimale, une indépendance vis-à-vis d'Internet et une confidentialité totale des données de chauffage.

⚠️ Contraintes matérielles & Dépendances (Architecture ARMv7l) L'installation de tinytuya sur la carte Xilinx (CPU ARM Cortex-A9) impose des contraintes de compilation spécifiques :

• pycryptodome (v3.6+) : Cette dépendance est indispensable pour gérer le chiffrement AES des paquets réseau Tuya (protocoles locaux v3.1/v3.3+).
• Compatibilité armv7l : Il existe dans le repo pycryptodome les paquets binaires pré-compilés (wheels) compatible avec cette architecture.

Conséquences sur la mémoire et le stockage

L'intégration de Python 3, de tinytuya et de pycryptodome a un impact considérable d'un point de vue mémoire et d'ailleurs impossible à installer en l'état actuel sur le mineur par manque de place sur la section overlay visualisable sur le retour de la commande df -h:

Filesystem	Size	Used	Available	Use%	Mounted on
/dev/root	16.8M	16.8M	0	100%	/rom
tmpfs	503.7M	804.0K	502.9M	0%	/tmp
/dev/mmcblk0p1	39.9M	20.1M	19.8M	50%	/tmp/mnt/boot
ubi0:rootfs	112.8M	22.4M	90.4M	20%	/tmp/mnt/antminer_rootfs
/dev/mmcblk0p2	58.0M	34.3M	19.2M	64%	/overlay
overlayfs:/overlay	58.0M	34.3M	19.2M	64%	/
tmpfs	512.0K	0	512.0K	0%	/dev

Afin de palier à ce problème, il est tout d'abord nécessaire d'étendre la section overlay afin de permettre l'utilisation des ressources logicielles.

Génération par extension de BraiinOS Custom

⚠️ Absence d'outils de redimensionnement sur BraiinOS

Sur les versions installées de BraiinsOS (OpenWrt), les outils nécessaires au redimensionnement à chaud des partitions (parted, resize2fs, fdisks) ne sont pas présents ou exploitables directement en ligne de commande depuis le Mineur (ASIC). Il était donc impossible d'agrandir la partition overlay directement depuis le système en cours d'exécution.

Afin de contourner cette limitation, j'ai décidé de travailler sur l'image système avant son déploiement sur une distribution Debian.

Partant d'une image officielle BraiinOS, j'ai utilisé la braiins-os_am1-s9_sd_2022-09-27-0-26ba61b9-22.08.1-plus, puis sur une Debian, exécuter la procédure suivante:

Installer parted:

apt install parted

Injecter de l'espace vide à la fin de l'image:

dd if=/dev/zero bs=1M count=1750 >> braiins-os_am1-s9_sd_2022-09-27-0-26ba61b9-22.08.1-plus.img

Monter l'image dans le loopback:

/usr/sbin/losetup -P /dev/loop0 braiins-os_am1-s9_sd_2022-09-27-0-26ba61b9-22.08.1-plus.img

Étendre la partition overlay par l'utilisation de l'outil parted:

/usr/sbin/parted /dev/loop0

Puis (supprimer la partition 3 et agrandir la partition 2) :

rm 3
resizepart 2 100%
quit

Forcer la mise à jour des partitions par Linux:

/usr/bin/partx -u /dev/loop0

Agrandir le système de fichier de la partition 2 :

/usr/sbin/e2fsck -f /dev/loop0p2
/usr/sbin/resize2fs /dev/loop0p2

Puis détacher le loop:

/usr/sbin/losetup -d /dev/loop0

Le repositionnement de la carte SD sur le Mineur à permit de constater l'extension de la partition overlay visualisable sur le retour de la commande df -h:

Filesystem	Size	Used	Available	Use%	Mounted on
/dev/root	16.8M	16.8M	0	100%	/rom
tmpfs	503.7M	804.0K	502.9M	0%	/tmp
/dev/mmcblk0p1	39.9M	20.1M	19.8M	50%	/tmp/mnt/boot
ubi0:rootfs	112.8M	22.4M	90.4M	20%	/tmp/mnt/antminer_rootfs
/dev/mmcblk0p2	1.7G	73.4M	1.5G	4%	/overlay
overlayfs:/overlay	1.7G	73.4M	1.5G	4%	/
tmpfs	512.0K	0	512.0K	0%	/dev

Conclusion

L'extension de la partition overlay est un indispensable pour permettre une parfaite maîtrise sur les ressources mémoires de la carte de contrôle Xilinx, et notamment sur l'installation de l'ensemble des packages nécessaire au fonctionnement.

⚠️ Néanmoins, l'utilisation de la mémoire NAND intégrée à la carte de contrôle est alors dépassée et ne peut donc pas satisfaire l'ensemble des packages.

L'utilisation d'une carte SD est donc nécessaire pour satisfaire son fonctionnement; qui pourrai même passer sur moins de 2Go, mais à quoi bon, pas sûr qu'il y en ai encore dans la nature.

Auteur : Sébastien DALIGAULT.