🛠 Construire sa propre image Armbian pour la PINE A64 (armbian/build)

Objectifs

Ne plus dépendre des images binaires : compiler toi-même le système de la PINE A64 avec le framework armbian/build, dont la config board pine64 est toujours maintenue (family sun50iw1, KERNEL_TARGET="current,edge,legacy"). Tu verras la chaîne de boot complète propre à Allwinner — BROM du SoC → U-Boot (mainline, defconfig pine64_plus_defconfig) → noyau + DTB, le tout lu depuis la microSD (pas de SPI NOR sur cette carte) — et le firmware ARM Trusted Firmware remplacé ici par CRUST (a64_defconfig), le port mainline du BSP ARM Trusted d'Allwinner.

Matériel

• 1 × PC x86-64 sous Linux (ou Docker, mode recommandé par Armbian) avec ~35 GB libres
• 1 × PINE A64/A64+ + microSD pour tester l'image produite
• Console série EXP (115200 8N1) pour observer le U-Boot maison
• Réseau (le framework clone noyau, U-Boot, CRUST, paquets Debian)

Code complet

# Cloner le framework de build Armbian
git clone --depth=1 https://github.com/armbian/build
cd build

# Compiler une image CLI Debian Bookworm, noyau mainline LTS (BRANCH=current)
# Le framework lit config/boards/pine64.conf :
#   BOOTCONFIG=pine64_plus_defconfig   (U-Boot mainline)
#   CRUSTCONFIG=a64_defconfig          (ARM Trusted Firmware pour A64)
#   KERNEL_TARGET="current,edge,legacy"
./compile.sh BOARD=pine64 BRANCH=current DISTRIBUTION=bookworm \
             BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no

# Image produite :
ls -lh output/images/   # Armbian_*_Bookworm_current_pine64.img.xz

# Graver et booter (console EXP 115200 8N1 pour voir le U-Boot custom) :
xzcat output/images/Armbian_*_Bookworm_current_pine64.img.xz | sudo dd of=/dev/sdX bs=4M
sync

Vérification attendue

En fin de build, output/images/ contient l'image .img.xz avec le noyau current, U-Boot u-boot-sunxi-with-spl.bin et le DTB sun50i-a64-pine64*.dtb. Sur la console série, le banner U-Boot s'affiche puis le noyau démarre sur serial0:115200n8 (le chosen stdout-path du device tree mainline). uname -a sur la carte confirme la version du noyau que tu viens de compiler — et tu peux désormais patcher le noyau ou le DTS, rebuilder, et voir ton changement au boot suivant.

Erreurs fréquentes

• Compiler avec le mauvais defconfig U-Boot : c'est pine64_plus_defconfig (utilisé y compris pour la carte de base dans la config Armbian) — un autre defconfig sun50i donne un bootloader qui ne parle pas à cette carte.
• Confondre les branches noyau : current/edge = mainline (recommandé, le wiki officiel dit que la majorité des distros du board tournent sur mainline) ; legacy = le vieux BSP 3.10 « lichee » d'Allwinner, qui tournait Android 5.1 en noyau 32 bits sur un SoC 64 bits — à éviter.
• Manquer de place ou de RAM sur le PC hôte : le build télécharge et compile noyau + U-Boot + CRUST + racine Debian ; prévoir large et de la bande passante.
• S'étonner qu'il n'y ait rien à flasher « dans la carte » : la chaîne de boot est BROM → microSD uniquement ; pas de SPI NOR, pas de recovery eMMC par défaut — une image cassée se répare en regravant la carte (ou en FEL, voir le tuto dédié).
• Oublier CRUST : sans le firmware ARM Trusted (ici CRUST a64_defconfig), le A64 ne démarre pas le noyau en mode EL2/EL1 correctement — le framework s'en occupe, mais un build manuel U-Boot+noyau sans ATF est un puits sans fond.
• Parser les logs en diagonale : le framework écrit aussi dans output/log/ — en cas d'échec de compilation d'un composant, c'est là que se trouve la vraie erreur.