H96 Pro+ : Armbian sur l'eMMC et les 3 Go qu'il fallait débloquer

La H96 Pro+ est la box de la série qui s’est laissé faire le plus proprement : un vrai SoC Amlogic S912 à 8 cœurs, 3 Go de RAM physiques, et un démarrage autonome depuis l’eMMC, sans carte SD. Mais deux choses ont demandé du travail : faire voir les 3 Go à Linux, et finir une copie de rootfs que la mémoire interdisait.

Ce que la carte contient

SoC	Amlogic S912, 8 × Cortex-A53 à 1,5 GHz
RAM	3 Go physiques
eMMC	environ 32 Go
USB	2.0 uniquement (480 Mb/s)
Réseau	Ethernet gigabit
Système	Armbian (ophub), Debian trixie, noyau 6.18

Tous les ports USB passent par un hub interne à 480 Mb/s : inutile de chercher le « bon » port pour un SSD, il n’y en a pas de plus rapide.

Installer sur l’eMMC depuis la carte SD

La méthode : démarrer un Armbian qui tourne sur carte SD, puis lancer l’installeur d’ophub (armbian-install) en choisissant le profil de la box, ici l’identifiant 203 (H96-Pro-Plus), avec un rootfs ext4.

Première surprise : la copie du rootfs s’est arrêtée sur un manque de mémoire (OOM). La box copiait environ 1,8 Go de données avec 2 Go de RAM visibles et aucun swap. Deux réglages ont suffi pour relancer : ajouter un swap, et abaisser vm.dirty_bytes pour que le noyau écrive plus tôt au lieu d’accumuler des pages sales.

Le point clé : 2 Go ou 3 Go

Au premier démarrage, Linux ne voyait que 2 Go. Je pensais d’abord au fichier DTB, mais ce n’était pas lui. La différence vient du u-boot :

• le u-boot d’origine fait un booti direct et plafonne à 2 Go ;
• ophub ne charge pas de u-boot supplémentaire par défaut, parce que le noyau embarque déjà le correctif nécessaire pour le démarrage direct ;
• un u-boot « mainline » (fichier u-boot-zyxq.bin) lit la vraie taille de la mémoire, 3 Go, et la passe au noyau.

La solution a été de le chaîner : copier u-boot-zyxq.bin en /boot/u-boot.emmc. Le script de démarrage emmc_autoscript charge ensuite ce fichier avec une commande de la forme :

fatload mmc 1 u-boot.emmc; go

La chaîne complète devient : ROM, bootloader d’usine dans la zone utilisateur de l’eMMC, u-boot d’usine, emmc_autoscript, u-boot.emmc, noyau.

La contre-épreuve est parlante : avec la même DTB, le démarrage sans u-boot chaîné donne 2 Go, avec lui 2,8 Gio (3 Go). La DTB n’a aucun rôle dans la taille de la RAM sur cette carte.

TODO(nico) : joindre la sortie de free -h avant et après le chaînage.

Mémoire effective et swap

Avec 3 Go, on est vite juste. Le choix : un SSD USB de 8 Go partitionné en GPT, avec 4 Go de swap et 3,4 Go de données (volumes Docker, logs). Dans fstab, l’option nofail évite qu’un SSD débranché bloque le démarrage.

Devant ce swap, zswap compresse les pages en RAM (compresseur zstd, pool à 33 %). Il est intégré au noyau, donc rien à installer, et il limite les écritures sur l’eMMC. Les paramètres noyau sont fixés dans un fichier sysctl :

vm.swappiness=100
vm.vfs_cache_pressure=50
vm.dirty_ratio=10
vm.dirty_background_ratio=5
vm.page-cluster=0
vm.min_free_kbytes=32768

Côté services, rpcbind et nfs-blkmap sont inutiles sur une box sans écran et ont été coupés. chrony, le watchdog (redémarrage automatique en cas de blocage), unattended-upgrades et vnstat restent actifs.

Réseau : DHCP et adresse MAC stable

Première idée : figer une IP statique. Mauvaise idée, parce que la box a d’abord été configurée sur un réseau partagé par le PC (partage de connexion Windows), dans un sous-réseau différent de celui du switch. Une statique choisie là casse dès qu’on change de réseau. La bonne approche est le DHCP avec une adresse MAC fixe (cloned-mac-address=stable dans NetworkManager), puis une réservation sur le routeur si une IP garantie est nécessaire.

Ce que je retiens

• La RAM visible dépend de la chaîne de démarrage, pas seulement du matériel : vérifiez avec free -h plutôt que de croire une fiche technique.
• Une copie qui s’arrête en OOM n’est pas un échec de l’installeur : réglez le swap et les écritures différées, puis relancez.
• Un swap sur SSD plus zswap donne de la marge sans user l’eMMC.