[Mise à jour du 30/09/2014 – Cet article a été mis à jour, notamment pour permettre d’utiliser la totalité des 1 Go de RAM embarqués sur la carte Cubieboard – Pour une procédure d’installation actualisée, consulter : Arch Linux ARM sur Cubieboard 1 (Allwinner A10, 1Go RAM)]
J’ai fait l’acquisition au début du mois de juillet d’une carte Cubieboard 1. Il s’agit d’un mini-ordinateur mono-carte basé sur un système sur puce (SoC) Allwinner A10 embarquant un processeur ARM Cortex-A8 cadencé à 1 GHz et doté entre autres d’1 Go de mémoire vive, de 4 Go de mémoire flash NAND, d’une interface SATA et d’une sortie HDMI (depuis, un second modèle est sorti, la Cubieboard 2, qui est basé sur un SoC Allwinner A20 embarquant un processeur double coeur ARM 2xCortex A7 à 1 GHz).
Contrairement à la carte Raspberry Pi, la Cubieboard n’est pas (encore ?) suivie par une communauté importante d’utilisateurs. La documentation et le support sont basiques et encore balbutiants, pour ne pas dire inexistants.
« il est plus facile à un bidouilleur débutant d’installer Arch Linux ARM sur la carte CubieBoard qu’à un chameau de passer par le chas d’une aiguille, surtout s’il porte quatre danseuses mandchouriennes sur ses flancs. » Source : Gallica.bnf.fr.
C’est toujours bon à savoir pour qui envisagerait d’acheter cette carte : pour l’utiliser, il faut aller chercher les informations disséminées un peu partout, et à la fois celles qui traitent spécifiquement de la Cubieboard et celles qui portent sur des machines dotées du même SoC, comme par exemple les cartes Gooseberry, Hackberry A10, ODROID-U2 ou encore Mele A1000.
L’installation des distributions embarquées par Berryboot, qui devrait être simple, ne m’a pas convaincue. Pour une raison que j’ignore, l’utilisation de Berryboot s’est traduite par un échec dans la plupart des cas, la Cubieboard ne démarrant pas ou démarrant sur la mémoire NAND Flash. De plus, l’installation d’Arch Linux avec Berryboot n’est pas vraiment possible (en tous cas, je n’ai jamais réussi à y arriver sur le Raspberry Pi).
J’ai donc opté pour une installation « à la main », à partir du guide disponible sur le site Web dédié à Arch Linux.
Comme j’ai eu beaucoup de mal à m’en dépatouiller et que j’ai finalement obtenu le résultat souhaité, voici, pour mémoire, pour référence et parce que d’autres pourraient être intéressés, un relevé commenté des étapes de l’installation d’Arch Linux sur la carte Cubieboard que j’ai réalisée.
Les sources utilisées et digérées pour cette installation sont indiquées à la fin de ce billet.
Pré-requis pour l’installation d’Arch Linux ARM sur la carte Cubieboard (boot sur la carte micro-SD)
L’installation décrite ici a été réalisée de manière à faire démarrer (boot) la Cubieboard sur la carte micro-SD. Je n’ai pas tenté de réaliser cette opération sur la mémoire Flash, sur laquelle j’ai préféré laisser Android intégrant XBMC que j’avais testé précédemment. Lorsqu’une carte micro-SD correctement configurée est insérée dans la Cubieboard, elle démarre sur cette carte. Pour démarrer sur la mémoire NAND Flash, il suffit de retirer la carte micro-SD.
Disposer d’une machine tournant sous Linux et pourvue d’une interface permettant d’accéder à la carte micro-SD
Comme je n’ai pas 36 machines tournant sous Linux et que j’aime les complications, j’ai utilisé… une carte Raspberry Pi tournant elle même sous Arch Linux ARM (il s’agit de la carte dont j’ai décrit la configuration en client Bittorent il y a quelques semaines), sur laquelle j’ai branché un lecteur de cartes multi-formats acquis pour la modique somme de 1 € 86 (frais de port compris) chez un marchand chinois
Partitionner et formater la carte micro-SD pour préparer l’installation
C’est là que j’ai, paradoxalement, rencontré le plus de difficultés.
Pour préparer l’installation, il faut partitionner puis formater la carte micro-SD en y créant :
- une partition de 16 Mo formatée en FAT pour y placer le bootloader ;
- une partition occupant l’espace restant sur la carte micro-SD, formatée en ext4, pour le système de fichiers.
Je me suis donc muni d’une carte micro-SD de classe 10 et d’une capacité de 32 Go, et j’ai tourné en rond sans parvenir à formater la seconde partition en ext4. J’ai tenté ma chance avec GParted depuis une machine tournant sous Xubuntu, avec fdisk depuis ma carte Raspberry, mais rien à faire : au moment du formatage, ma partition ne voulait pas se formater en ext4 et la commande mkfs.ex4, si elle ne renvoyait pas d’erreur, ne formatait rien du tout.
J’ai finalement changé de carte micro-SD pour une carte premier prix de classe 4 d’une capacité de 4 Go, et j’ai tout refait à la main en m’inspirant des (bons) conseils trouvés dans un billet d’un blog découvert par hasard, billet qui porte sur l’installation d’une distribution Debian sur la Cubieboard (mais l’étape « formatage de la carte micro-SD » est sensiblement la même sous Arch Linux ARM).
Pour partitionner et formater la carte micro-SD, il faut se connecter à la machine dans laquelle elle est insérée avec des droits d’administrateur (root).
Remise à zéro des premiers secteurs de la carte
Les cartes micro-SD sont vendues préformatées. La mienne avait cependant déjà fait l’objet de tentatives de formatage inabouties…
Pour déterminer le nom de périphérique de stockage de la carte micro-SD sur la machine dans laquelle elle est insérée, on commence par utiliser fdisk :
# fdisk -l
[...]
Disk /dev/sdb: 3965 MB, 3965190144 bytes, 7744512 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0xf57554a0
Device Boot Start End Blocks Id System
/dev/sdb1 2048 67584 32768+ e W95 FAT16 (LBA)
/dev/sdb2 69632 7744511 3837440 83 Linux
Ma carte est le périphérique (device) /dev/sdb, elle a une taille de 3965 Mo répartis en 7744512 secteurs de 512 octets chacun. Elle a déjà été formatée et comprend deux partitions (sdb1 et sdb2).
Pour partir d’une carte micro-SD « propre et nette » il faut « nettoyer » les premiers secteurs de la carte (les 2048 secteurs qui se trouvent avant le début de sdb1 qui commence au secteur 2048 (ce qui veut dire qu’il y a 2048*512/(1024²) = 1 Mo avant le début de sdb1 – pour rappel, 1 Mo contient 1024 Ko qui contiennent chacun 1024 octets). Ce premier Mo est en fait réservé au Master boot record (MBR ou en bon français, la zone d’amorçage), qui contient la table des partitions et le bootloader.
Pour le faire, on utilise la commande dd (destroy disk) pour remettre à zéro cette partie de la carte. Comme son nom l’indique, la commande dd peut faire des dégâts : attention notamment à bien repérer le nom du device qui correspond à la carte micro-SD (/dev/sdb dans mon cas, comme expliqué plus haut).
# dd if=/dev/zero of=/dev/sdb bs=1M count=1
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.111078 s, 9.4 MB/s
Préparation et écriture de la table de partitions sur la carte micro-SD
Puis on lance fdisk :
# fdisk /dev/sdb
Welcome to fdisk (util-linux 2.23.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Device does not contain a recognized partition table
Building a new DOS disklabel with disk identifier 0x776cd483.
On crée une nouvelle partition (commande n).
Command (m for help): n
De type primaire :
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p): p
Qui porte le numéro 1 :
Partition number (1-4, default 1): 1
Qui commence, on a vu plus haut pourquoi, au secteur 2048 :
First sector (2048-7744511, default 2048): 2048
Et dont la taille est de 16 Mo :
Last sector, +sectors or +size{K,M,G} (2048-7744511, default 7744511): +16M
Partition 1 of type Linux and of size 16 MiB is set
On liste les partitions pour vérifier que tout est correct :
Command (m for help): p
Disk /dev/sdb: 3965 MB, 3965190144 bytes, 7744512 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x776cd483
Device Boot Start End Blocks Id System
/dev/sdb1 2048 34815 16384 83 Linux
Et on crée la seconde partition :
Command (m for help): n
Qui est primaire et porte le numéro 2 :
Partition type:
p primary (1 primary, 0 extended, 3 free)
e extended
Select (default p): p
Partition number (2-4, default 2): 2
Et que l’on fait démarrer juste après la partition 1 créée précédemment, qui se terminait au secteur 34815 dans mon cas (proposé par défaut) et s’achever au dernier secteur (proposé par défaut lui aussi) :
First sector (34816-7744511, default 34816):
Using default value 34816
Last sector, +sectors or +size{K,M,G} (34816-7744511, default 7744511):
Using default value 7744511
Partition 2 of type Linux and of size 3.7 GiB is set
La Cubieboard ne pourra booter que sur une partition formatée en FAT. Il faut donc changer le type de partition pour sdb1 (Linux, par défaut et comme le montre le résultat de la commande p passée plus haut).
Command (m for help): t
Partition number (1,2, default 2): 1
Hex code (type L to list all codes): L
[...]
e W95 FAT16 (LBA)
[...]
Le code hexadécimal pour FAT16 est e :
Hex code (type L to list all codes): e
WARNING: If you have created or modified any DOS 6.xpartitions, please see the fdisk manual page for additionalinformation.
Changed type of partition 'Linux' to 'W95 FAT16 (LBA)'
Et voilà le travail achevé pour ma partition sdb1 qui est indiquée comme étant de type FAT16.
Je liste les partitions pour m’assurer que tout est bon :
Command (m for help): p
Disk /dev/sdb: 3965 MB, 3965190144 bytes, 7744512 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x5b0864a3
Device Boot Start End Blocks Id System
/dev/sdb1 2048 34815 16384 e W95 FAT16 (LBA)
/dev/sdb2 34816 7744511 3854848 83 Linux
Ma partition 2 (sdb2) est bien de type Linux.
C’est quasiment fini, mais rien n’a encore été réellement écrit sur la carte micro-SD. J’achève le partitionnement en passant la commande w :
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
Formatage des partitions 1 et 2 en FAT et en ext4
La table des partitions est au point, il reste maintenant à formater ma partition 1 en FAT et ma partition 2 en ext4 en utilisant la commande mkfs.
Pour la partition 1 :
# mkfs.vfat /dev/sdb1
mkfs.fat 3.0.22 (2013-07-19)
Pour la partition 2 :
# mkfs.ext4 /dev/sdb2
mke2fs 1.42.8 (20-Jun-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
240960 inodes, 963712 blocks
48185 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=989855744
30 block groups
32768 blocks per group, 32768 fragments per group
8032 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736
Allocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done
Une petite vérification :
# lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT
[...]
sdb
├─sdb1 vfat 8919-F4BC
└─sdb2 ext4 dead6087-3b4d-413c-bf7b-6d03655ca31a
[...]
La préparation de la carte est terminée ! On peut passer à l’installation proprement dite.
Installation d’Arch Linux ARM sur la Cubieboard (avec démarrage sur la carte micro-SD)
Téléchargement et installation du bootloader sur la partition 1 de la carte micro-SD
Le bootloader est spécifique à la carte. Il faut le télécharger. Mon installation étant réalisée depuis un Raspberry Pi, j’ai créé un répertoire temporaire cubie pour y ranger mes affaires dans /home/root/ et je m’y suis déplacé :
# cd ~
# mkdir cubie
# cd cubie
Puis j’ai téléchargé la dernière version du bootloader :
# wget http://archlinuxarm.org/os/sunxi/cubieboard-bootloader.tar.gz
[...]
2013-09-11 21:51:59 (684 KB/s) - ‘cubieboard-bootloader.tar.gz’ saved [127367/127367]
J’ai décompressé l’archive et « écrit » le bootloader sur la patition 1 de ma carte micro-SD :
# tar xzf cubieboard-bootloader.tar.gz
# dd if=cubieboard/sunxi-spl.bin of=/dev/sdb bs=1024 seek=8
19+1 records in
19+1 records out
19968 bytes (20 kB) copied, 0.0300145 s, 665 kB/s
# dd if=cubieboard/u-boot.bin of=/dev/sdb bs=1024 seek=32
168+1 records in
168+1 records out
173052 bytes (173 kB) copied, 0.0760237 s, 2.3 MB/s
Téléchargement et installation du système de fichiers root sur la partition 2 de la carte micro-SD
Il faut maintenant aller récupérer le système de fichiers et l’écrire sur la partition 2 précédemment formatée en ext4. Pour préparer l’écriture, je crée deux répertoires temporaires pour pouvoir monter la partition de boot et la partition du système de fichiers.
# mkdir /tmp/boot
# mkdir /tmp/arch
Je monte ma parition 1 sur /tmp/boot et ma partition 2 sur /tmp/arch
# mount /dev/sdb1 /tmp/boot
# mount /dev/sdb2 /tmp/arch
Je télécharge la dernière version du système de fichier :
# wget http://archlinuxarm.org/os/ArchLinuxARM-sun4i-latest.tar.gz
[...]
2013-09-11 22:09:23 (580 KB/s) - ‘ArchLinuxARM-sun4i-latest.tar.gz’ saved [157803839/157803839]
Je décompresse l’archive et j’écris le système de fichiers sur la partition 2 de la carte (montée sur /tmp/arch) :
# tar -zxf ArchLinuxARM-sun4i-latest.tar.gz -C /tmp/arch
Je copie uImage présent dans le répertoire /boot/ du système de fichiers vers la parition 1 montée précédemment sur /tmp/boot :
# cp /tmp/arch/boot/uImage /tmp/boot/uImage
Je copie pour finir le fichier FEX compilé et le fichier uEnv.txt vers la partition 1 de la carte :
# cp cubieboard/cubieboard*.bin /tmp/boot/
# cp cubieboard/uEnv.txt /tmp/boot/uEnv.txt
On reviendra plus loin sur ce à quoi servent ces fichiers et comment les manipuler.
Une petite synchronisation et je démonte mes deux partitions :
# sync
# umount /dev/sdb1
# umount /dev/sdb2
Il me reste à extraire la carte micro-SD de mon lecteur de cartes, à l’insérer dans la Cubieboard et à brancher l’alimentation de la Cubieboard préalablement raccordée par uhn cable ethernet à un port de mon routeur.
Comme je vise une installation avec administration à distance, je n’ai pas prévu de brancher d’écran à la Cubieboard. SSH étant activé par défaut, il me suffit de déterminer, en consultant la table DHCP, l’IP que le routeur a assigné à la Cubieboard (le nom d’hôte par défaut est alarm).
Le login de l’administrateur est root
Le mot de passe par défaut est root.
Depuis un client SSH (sous Linux en mode console dans mon cas), je me connecte à la Cubieboard :
ssh root@192.168.X.X
et je saisis le mot de passe root.
Et si tout s’est bien passé, je dois obtenir dans mon terminal :
[root@alarm ~]#
L’installation à proprement parler est terminée. Il me reste quelques compléments pour que le système soit à jour.
Pour achever l’installation d’Arch Linux
Changement du mot de passe de l’administrateur
# passwd
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Mise à jour de la distribution
pacman -Syu
Compléments et optimisations de l’installation d’Arch Linux sur la Cubieboard
Définir le bon fichier FEX dans l’environnement U-Boot
Mais qu’y-a-t-il dans la partition de boot (/dev/mmcblk0p1) ?
Pour explorer la partition de boot, montons-la sur le répertoire temporaire créé précédemment :
# mount /dev/mmcblk0p1 /mnt/tmp
et regardons ce qu’il y a dedans :
# cd /mnt/tmp
# ls
On trouve à la racine de la partition de boot les fichiers suivants :
cubieboard_512.bin
cubieboard.bin
uEnv.txt
uImage
Les fichiers .bin correspondent aux fichiers de configuration de la carte Cubieboard. Comme pour tous les équipements basés sur le SoC Alwinner A10, ces fichiers de configuration sont des binaires FEX. Pour les éditer, il faut utiliser deux utilitaires qui permettent de convertir un binaire en fichier FEX lisible et vice versa : il s’agit de fex2bin et bin2fex. Ces utilitaires sont disponibles dans le paquet sunxi-tools disponible dans le dépôt alarm.
Nous les utiliserons tout à l’heure, aussi allons-nous monter dès maintenant le paquet sunxi-tools :
pacman -S sunxi-tools
Introduire les bons paramètres dans le fichier uEnv.txt
Le fichier uEnv.txt contient de manière lisible les paramètres de l’environnement U-Boot. Le nom du fichier binaire FEX utilisé au démarrage de la carte y est défini. Par défaut, c’est cubieboard_512.bin, qui est dédié à la première version de la Cubieboard 1, qui n’était équipée que de 512 Mo de RAM. Pour la dernière révision de la Cubieboard 1, dotée d’1 Go de RAM, il faut utiliser cubieboard.bin.
Pour que le bon FEX binaire soit utilisé au démarrage, il faut éditer le fichier uEnv.txt
# nano uEnv.txt
et remplacer :
fexfile=cubieboard_512.bin
par :
fexfile=cubieboard.bin
Affecter une adresse MAC fixe à la Cubieboard
Problème : par défaut, l’adresse MAC de la Cubieboard change à chaque démarrage
Comme je souhaite administrer la Cubieboard à distance (installation headless, il faut, pour me connecter à la machine en SSH, que je connaisse son adresse IP dans le réseau local. Il est possible de configurer le routag statique du routeur et d’attribuer à la carte une IP fixe, mais je préfère que l’IP soit attribuée dynamiquement, comme pour mes autres machines connectées au routeur, par le serveur DHCP, en réservant une adresse à la Cubieboard, ce qui revient au même puisqu’elle se verra attribuer toujours la même adresse IP.
Mais il y a un petit problème à résoudre : pour déclarer une réservation DHCP, il faut que l’adresse MAC de la Cubieboard soit toujours la même, et par défaut, ce n’est pas le cas. Comme expliqué en anglais ici, le système sur puce (Soc) Allwinner A10 qui équipe la Cubieboard est doté d’une unité MAC appelée EMAC dont le pilote attribue par défaut à la carte une adresse MAC aléatoire. A chaque démarrage, l’adresse MAC de la carte change donc, ce qui est incompatible avec la réservation DHCP.
Solution : éditer le fichier de configuration FEX
Pour corriger ce comportement, la méthode que j’ai utilisée (il y en a d’autres) consiste à modifier le fichier binaire FEX qui contient les paramètres de configuration du démarrage.
Il est de bonne pratique de faire une copie de précaution des fichiers que l’on va manipuler, pour pouvoir revenir en arrière si on fait une bourde :
# cp cubieboard.bin cubieboard.bin.bak
Pour lire et éditer le fichier de configuration, il faut convertir le binaire en FEX avec l’utilitaire bin2fex installé précédemment avec le paquet sunxi-tools :
# bin2fex cubieboard.bin cubieboard.fex
Une petite copie de précaution avant de bidouiller le fichier FEX :
# cp cubieboard.fex cubieboard.fex.bak
On édite le fichier FEX :
# nano cubieboard.fex
et, à la fin du fichier, on rajoute les deux lignes suivantes :
[dynamic]
MAC = "XXXXXXXXXXXX"
où XXXXXXXXXXXX correspond à l’adresse MAC fixe que présentera désormais la Cubieboard. Il paraît préférable d’utiliser l’une des adresses attribuées au hasard par EMAC, repérable par exemple dans la table des clients DHCP du routeur (il s’agit de 6 paires de caractères sans les : entre chaque paire).
On sauvegarde cubieboard.fex et on le convertit en binaire avec l’utilitaire fex2bin :
# fex2bin cubieboard.fex cubieboard.bin
Un petit coup de synchronisation, on démonte la partition de boot :
# sync
# cd ~
# umount /dev/mmcblk0p1
On redémarre ( shutdown -r now ) , et oh, stupeur ! ;-) , l’adresse MAC de la Cubieboard est la même que celle indiquée précédemment sous [dynamic] dans cubieboard.fex. il ne reste qu’à définir une réservation DHCP pour que la même IP lui soit affectée à chaque connexion au routeur.
C’est fini : la Cubieboard est opérationnelle et Arch Linux ARM installé.
- Le guide d’installation fourni sur le site Web d’Ach Linux ARM
- Pour le partitionnement et le formatage de la carte micro-SD : Interstellar Overdrive : Installing a customized Debian on the Cubieboard.
- Pour la solution au problème de l’adresse MAC aléatoire : André’s blog : Installing ArchLinux ARM on the CubieBoard et la page consacrée à EMAC sur le Wiki linux-sunxi.org.
N’hésitez pas à faire part de vos remarques et commentaires, ou à me signaler les inévitables erreurs qui se sont glissées dans ce relevé d’installation.