Carte expérimentale
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.
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.
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.
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.
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).
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.
Voila, cela semble donc très prometteur. Je donnerais des nouvelles de l’avancement et de mes différents tests de temps en temps.