Premiers tests de la Cubieboard2

Carte expérimentale

Cubieboard2

Cubieboard2

La Cubieboard est un produit très prometteur mais dont certains aspects sembles encore assez expérimentaux. Cette carte à l’avantage de consommer très peu de courant pour fournir beaucoup de puissance (de calcul/affichage…) effective. Et la documentation principalement communautaire est plutôt limitée et en cours de développement. Il y a probablement besoin de l’organiser un peu pour s’y retrouver.

Cela me rappelle la sortie de l’eeePC 701, il y a quelques années, qui a apporté beaucoup de chose, mais qui a finalement montré qu’Intel était incapable de s’intégrer dans le marché du mobile faible consommation (et donc longue autonomie). Les prochains modèles d’Atom, malgré les effets d’annonce biaisés d’Intel pour leurs prochains processeurs ne semblent pas convaincants :
* Comparaison des CPU x86 de 2014 avec les SoC ARM de début 2013
* Comparaison de la consommation du processeur seul, avec un SoC qui intègre l’ensemble du système sur une puce. Sur les anciens ATOM déjà, les radiateurs étaient sur le North Bridge plutôt que le processeur lui même.
* Données de la consommation électrique non plus sur le TDP (consommation maximum), mais sur une utilisation dite classique (sans précision) nommée SDP pour l’occasion.

Du point de vue historique, la première version produite en série de la Cubieboard, l’a été le 10 septembre 2012, un peu moins d’un an (au moment où j’écris cet article) ce qui en fait un produit très jeune. Étant donné, les capacités, l’ouverture et le prix de la petite merveille, elle en est devenu un produit réellement atypique, qui peut plaire au bidouilleurs, électroniciens, informaticiens, libristes, simples utilisateurs ou un mélange de tout ça.

Qu’est ce donc ?

Elle reprend les avantages de la Raspberry Pi (ordinateur compact, consommant peu, orienté logiciel libre, et permettant la bidouille). Tout en réduisant les désavantages (très faible puissance et manque d’ouverture du processeur).

Elle reprend également, les bons aspects d’un terminal léger ARM ; très faible consommation électrique (le Cortex-A7 étant le CPU ARM consommant le moins) et bonne organisation matérielle de ce type d’architecture, permettant une bonne efficacité dans de nombreux domaines, bureautique, internet, voir même serveur léger.

Cubieboard2

Cubieboard2

Problème de la sortie HDMI

Je n’ai pas d’écran avec entrée HDMI, mais j’ai un convertisseur HDMI=>DVI. Il marche bien avec le boîtier de Freebox HD, mais moins bien avec la Cubieboard.

J’ai 2 écrans, un assez ancien, qui sert d’écran vidéo, et un plus récent, qui me sert pour mon poste informatique :

* Sur l’ancien, un LG, d’il y a presque 10 ans, avec DVI et VGA, la Cubieboard n’affiche rien (message « out of range »).
* Sur le plus récent (environ 3 ans) DELL à LED, toujours DVI et VGA uniquement. il affiche mais avec des couleurs un peu bizarres sur l’Android par défaut et mieux mais pas terrible sur un Lubuntu flashé sur la NAND. Il ne semble pas du tout fonctionner avec celui que j’ai gravé sur la carte SD.

Image un peu étrange avec le convertisseur HDMI-DVI sur la distribution Android par défaut.

Image un peu étrange avec le convertisseur HDMI-DVI sur la distribution Android par défaut.

Version Nand de Lubuntu 12.04, fourni en septembre 2013, couleurs un peu mieux

Version Nand de Lubuntu 12.04, fourni en septembre 2013, couleurs un peu mieux

L’alimentation de la bête

Le câble d’alimentation est un câble USB, j’ai donc essayé de l’alimenter lorsque branché avec le convertisseur sur l’écran en branchant en USB :
* Clavier
* Souris
* ethernet
* Câble HDMI + convertisseur DVI

Il faut savoir que si il n’y a pas assez de puissance à l’alimentation, vous pourrez avoir des crashs aléatoires. Il est donc très important de bien l’alimenter, en fonction de ce que vous y branchez. Cela m’a fait croire que le mauvais traitement de sa boite lors du transport aurait pu l’endommager, mais la boite à bien amortie le choc.

CubiBroyage

CubiBroyage

Pour information, on l’alimente en USB :
* Un câble USB => DC (prise comparable au transfo de la Sony PSP d’après linux-SunxI).
* Un câble USB mini B, c’est la même prise que sur une Wacom ou un disque dur externe. Les câbles de disque dur externe ayant en général 2 connecteurs USB à l’autre bout, c’est bien pratique pour avoir suffisamment d’alimentation.

Avec ces 2 câbles, ça fait déjà l’alimentation possible par 3 ports USB

Parmi les possibilité :
* 1 port USB de PC sort dans les 500mA.
* Les transformateurs avec sortie USB des téléphones, vont en général de 750mA à 2A.
* On trouve également aujourd’hui (j’en ai vu un ce midi rue Montgallet, dans une boutique du côté de la station de métro) des transfo USB avec 2 ports USB (que ce soit avec prise secteur ou allume cigare (pour la voiture). Je n’ai pas eu le temps de demander la puissance.

Le démarrage de la bête

La séquence de démarrage se passe en plusieurs parties :

L’alimentation, lance le processeur qui contient lui même une séquence de démarrage :
* Il teste l’existence d’un système de démarrage sur la carte MMC ou microSD (µSD) en premier, si elle est présente
* Si ça n’est pas le cas il tente la mémoire flash NAND (ou eprom), les utilisateurs de PC appellent sont contenu BIOS, en général on appelle ça firmware. Comme ici on à 4 Go de NAND, on peut y mettre un système d’exploitation complet, mais léger.

En général sur l’un ou l’autre la séquence se passe ensuite comme suit :

* U-Boot(W) est un logiciel d’amorçage, équivalent de Lilo ou GRUB dans l’embarqué et dont les fonctions sont situés entre GRUB(W) et busybox(W). On peut lui donner quelques paramètres, il a un shell interactif bien pratique. Il est par contre très limité niveau des périphériques qu’il peut lire et sur lesquels il peut booter. Il fait ça en 2 étape :
* étape 1, le noyau
* étape 2, le montage du système racine et appelle du processus init

Pour le moment, parmi les périphérique géré dans la version Allwinner d’uboot :
* NAND flash
* MMC/microSD
* Netboot : TFTP pour le noyau, classiquement accompagné du NFS pour le système, mais peut être autrement.

Il gère VFAT et EXT2(/3/4) concernant les systèmes de fichier.

Les périphériques USB ne sont pas gérés ni le SATA, il faut donc dans ce cas :
* Charger le noyau sur une des 3 choses gérées précitées (NAND, mmc/microSD, netboot). Celui ci contiendra les pilotes adéquat.
* Monter et démarrer sur le système, en USB (clé usb, carte SD sur lecteur USB, disque externe), disque SATA, NFS, ou n’importe quel montage réseau imaginable, géré par Linux.

Premiers tests de démarrage

Une fois testé que tout marchait sur l’Android par défaut (sortie vidéo, USB, son (ATTENTION, par défaut le son est sur HDMI, il faut donc configurer dans les préférences, sortie jack audio plutôt que HDMI, sinon vous n’entendrez rien). J’ai voulu passer aux choses sérieuses.

J’ai trouvé une image Linux pour NAND que j’ai réussi à flasher avec l’outil fourni par Allwinner par Linux. Le résultat n’a pas été concluant, il s’agit de l’U-Boot 2011.09-rc1 d’AlWinner, déconseillé par Linux-Sunxi pour ces nombreux plantage, en raison d’une mauvais réglage d’alimentation électrique du CPU. Je n’ai pas trop compris pourquoi il est toujours utilisé dans les images.

Branchement du port série sur la Cubieboard

Branchement du port série sur la Cubieboard

J’avais donc de nombreux crash avec et j’ai du me brancher en port série pour comprendre pourquoi.

Vous aurez avec des erreurs comme ce qui suit, j’ai vraiment cru que ma Cubieboard avait des problèmes matériels :

PHY_PageRead : too much ecc err,bank 0 block d2,page 64
PHY_PageRead : too much ecc err,bank 0 block d2,page 64

U-Boot

Lorsque l’on se connecte en USB, on voit également toutes les informations de la séquence de boot. On peut l’arrêter en appuyant sur une touche lorsque s’affiche (attention, j’ai surligner en rouge, mais c’est en n&b :

--------fastboot partitions--------
-total partitions:11-
-name-        -start-       -size-
bootloader  : 8000          8000
env         : 10000         8000
boot        : 18000         8000
system      : 20000         100000
data        : 120000        100000
misc        : 220000        8000
recovery    : 228000        10000
cache       : 238000        a0000
private     : 2d8000        8000
databk      : 2e0000        80000
UDISK       : 360000        400000
-----------------------------------
bootcmd set setargs_nand
Hit any key to stop autoboot:  0
sunxi#

Sur l’Android installé par défaut, si cette séquence est passée, vous aurez des défilement en boucle de ???? comme ceci sur la console :

[   40.129430] 9fe0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
[   40.138536] a000: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
[   40.147642] a020: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
[   40.156747] a040: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
[   40.165853] a060: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????

Après être passé dans la console d’u-boot (si on ne veut pas finir le démarrage automatique), on a donc une liste de commande possible, on peut en avoir la liste à l’aide de si on demande la liste via la commande help ou ?

sunxi#help
?       - alias for 'help'
base    - print or set address offset
boot    - boot default, i.e., run 'bootcmd'
boota   - boota   - boot android bootimg from memory
bootd   - boot default, i.e., run 'bootcmd'
bootm   - boot application image from memory
cmp     - memory compare
cp      - memory copy
crc32   - checksum calculation
env     - environment handling commands
exit    - exit script
false   - do nothing, unsuccessfully
fastboot- fastboot- use USB Fastboot protocol
fatdown - download data to a dos filesystem
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls   - list files in a directory (default /)
go      - start application at address 'addr'
help    - print command description/usage
key_test- Test the key value and dump key registers
loop    - infinite loop on address range
md      - memory display
mm      - memory modify (auto-incrementing address)
mmc     - MMC sub system
mmcinfo - display MMC info
mtest   - simple RAM read/write test
mw      - memory write (fill)
nand    - NAND sub-system
nboot   - boot from NAND device
nm      - memory modify (constant address)
printenv- print environment variables
reset   - Perform RESET of the CPU
run     - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv  - set environment variables
showvar - print local hushshell variables
sunxi_flash- sunxi_flash sub-system
test    - minimal test like /bin/sh
true    - do nothing, successfully
version - print monitor, compiler and linker version

Et des variables d’environnement par défaut, présentées par la commande printenv :

boot_fastboot=fastboot
boot_normal=boota 40007800
boot_recovery=sunxi_flash read 40007800 recovery;boota 40007800
bootcmd=run setargs_nand boot_normal
bootdelay=1
console=ttyS0,115200
fastboot_key_value_max=0x8
fastboot_key_value_min=0x2
init=/init
loglevel=5
mmc_root=/dev/mmcblk0p7
nand_root=/dev/system
partitions=bootloader@nanda:env@nandb:boot@nandc:rootfs@nandd:UDISK@nande
recovery_key_value_max=0x13
recovery_key_value_min=0x10
setargs_mmc=setenv bootargs console=${console} init=${init} loglevel=${loglevel}
setargs_nand=setenv bootargs console=${console} init=${init} loglevel=${loglevel}
stderr=serial
stdin=serial
stdout=serial

Environment size: 681/131068 bytes

Pour modifier une variable, il faut utiliser la commande setenv, ne pas mettre de signe égal (=), mais un espace entre la variable et la valeur qu’on veut lui assigner :

setenv variable valeure

Image qui fonctionne (via bidouillage)

J’ai fini par trouver une image pour carte microSD qui fonctionnait mais dont le noyau plantait, et ai donc du remplacer noyau comme décrit dans ce document. Il s’agit de Lubuntu Quantal, (une vieille version, octobre 2010).

Vieux cantal

Vieux cantal

J’ai donc, à présent un lubuntu de base fonctionnel, mais rien ne s’affiche avec le convertisseur, j’utilise donc pour mes premiers test le forward de X11 via un tunnel SSH (argument -X de ssh) :

ssh -X linaro@cubiepop

Sur l’image utilisés, l’utilisateur et le mot de passe sont linaro / linaro. Je vais tenter de mettre à disposition une image de base qui fonctionne avec 2 trois outils graphiques sympa (facile à télécharger par synaptic sinon).

Pour lancer une application, il suffit ensuite de taper son nom, elle s’affichera sur votre écran.

firefox

Au passage la wacom y est gérée, le module noyau est préinstallé avec ma méthode, il faut par contre installer le paquet wacom pour X11, j’en profite pour charger une biblio apportant plus d’infos sur la tablette :

sudo apt-get install xserver-xorg-input-wacom libwacom2:armhf libwacom-common

Je vais d’abord en faire une en Saucy beta, celle ci apporte toutes les bases minimales pour un peu d’optimisation :
* Passage de GCC 4.7.2 à GCC 4.8.1, ajoutant une très bonne optimisation par l’auto-vectorisation du code en SIMD Neon (équivalent des MMX et autre SSE dans le monde x86.
* OpenSSL 1.0.1c à la dernière version, Les optimisations Neon ont été introduites dans la 1.0.1h.
* Un compilateur LLVM utilisant l’autovectorisation Neon.
* Un plus grand support de l’architecture ARM en général.

Au passage, Mplayer/ffmpeg et Cairo/libpixman ont déjà des optimisations NEON depuis plusieurs années.

Je me suis amuser à tester via le tunnel SSH :

* Inkscape (5 à 10 fois plus lent que sur core i7, mais via tunnel SSH (sans optimisation SSL), sans l’autovectorization du nouveau GCC) et surtout sans le support complet pour l’acceleration 2D (voir un ajout de décéleration 2d) on devrait être 10 fois plus rapide sur certains points. Ca semble utilisable pour des formes simples, vraiment trop lent pour du code complexe, comme le about d’inkscape (environ 10s pour l’image complète).
* Blender, très drôle, la cubieboard à essayé de charger le pilote du processeur graphique d’intel… qu’il n’a donc pas trouvé. OpenGL ne semble pas adapté au tunnel X11/SSH.

* Mypaint, il semble très utilisable, j’ai fait une petite vidéo de démonstration avec utilisation des CPU. Il s’agit de mypaint 1.0.0, monothread, la 1.1 qui est dans saucy est multithread.

Screencast mypaint Cubieboard tunnel X11/SSH

Screencast mypaint Cubieboard tunnel X11/SSH

Voila, cela semble donc très prometteur. Je donnerais des nouvelles de l’avancement et de mes différents tests de temps en temps.

Laisser un commentaire