SoC Milkymist: le développement logiciel en pratique

1. Introduction

En plus de disposer de cœurs d'accélération graphique destinés à l'application prévue de rendu d'effets vidéo en direct, le SoC Milkymist comprend un ordinateur embarqué intégré sur la puce, lui permettant d'exécuter des logiciels complexes avec des performances tout à fait honorables dans le domaine de l'embarqué. Des tests réalisés avec MiBench montrent que Milkymist est plus rapide que son concurrent propriétaire Microblaze, en affichant une réduction du temps d'exécution des programmes de test (benchmarks) variant entre 15% et 35% selon le benchmark. Bien que Milkymist ne dispose pas encore de MMU, il est néanmoins capable de faire fonctionner une version un peu allégée du noyau Linux (souvent connue sous le nom de uClinux), et nous allons voir en détail comment la mettre en œuvre.

Bien que le SoC Milkymist soit assez stable à l'heure d'aujourd'hui, il n'en est pas de même pour son portage de GCC et de l'environnement Linux. Ceci est en partie à attribuer au manque voire à l'absence totale de documentation au sujet de certains aspects de GCC, ainsi qu'à une politique assez obscure de la FSF entourant son fonctionnement interne et un code particulièrement sale de la part de cette dernière. Ainsi, entre d'autres problèmes, il n'est pas rare de voir GCC planter avec un « internal compiler error », voire de générer du code corrompu qui détruira aléatoirement la pile lors de son exécution. Toutefois, avec le nombre croissant d'utilisateurs de l'architecture LatticeMico32 (sur laquelle se base Milkymist), les bugs de GCC commencent à être lentement corrigés. Et il est tout à fait possible de lancer dès maintenant un petit système Linux sur Milkymist et de compiler ses propres applications. Ce mois-ci, atelier bricolage !

2. Installation des outils de compilation

2.1 Installation à partir des sources

2.1.1 Binutils

L'installation de Binutils se déroule sans remarque particulière. Le support de LatticeMico32 est inclus dans les versions récentes.

2.1.2 GCC

Bien que l'architecture LatticeMico32 soit désormais incluse en standard dans GCC 4.5, cette inclusion s'est faite avec l'adjonction de bugs qui rendent impossible la compilation d'un noyau Linux. Ces derniers devraient être assez rapidement corrigés : le Bugzilla de GCC en répertorie la majorité, et plusieurs solutions sont connues. Cependant, pour simplifier les choses, nous resterons avec un GCC 4.4 patché. Récupérez le patch sur http://github.com/lekernel/milkymist-packaging (dossiers gcc-lm32-4.4.1, puis debian et patches).

Si le processus se déroule sans problème, vos outils de compilation LatticeMico32 sont à présent prêts.

2.2 Installation à partir des binaires

Pour plus de simplicité, vous pouvez également installer les outils de compilation à partir de binaires précompilés, au lieu de compiler les sources vous-même. Ils devraient fonctionner avec la majorité des distributions Linux.

2.2.1 Paquets Debian/Ubuntu

Il vous suffit d'ajouter la ligne suivante dans votre /etc/apt/sources.list :

Et de lancer ensuite :

Ces paquets fonctionnent avec plusieurs versions de Debian et Ubuntu.

2.2.2 Tarball

Si votre distribution n'est pas basée sur les paquets au format DEB, vous pouvez récupérer l'archive de binaires au format TAR sur http://www.milkymist.org/3rdparty/micotoolchain44.tar.bz2. Il vous suffira ensuite de la décompresser et d'ajouter dans votre PATH le répertoire contenant les binaires.

3. Compilation du noyau Linux

Une fois les outils de compilation (toolchain) installés par l'une ou l'autre des méthodes (binaires ou sources), vous êtes prêt pour compiler le portage du noyau Linux. Le portage en est au stade expérimental et souffre encore de problèmes de stabilité, de pilotes manquants ou mal codés et surtout, ainsi que nous allons le voir plus loin, d'un chargeur d'exécutables peu orthodoxe (la politesse m'interdisant d'employer un terme plus exact). Il ne sera donc pas inclus avant un certain temps dans les archives distribuées sur kernel.org et nous récupérerons par conséquent la branche de développement du projet Milkymist, hébergée sur Github et maintenue par Takeshi Matsuya. Elle est basée sur le portage effectué par Theobroma Systems pour le système LatticeMico32 original, dans lequel nous avons notamment corrigé de nombreux bugs et redéveloppé les pilotes de périphériques (pour correspondre aux périphériques présents sur le SoC Milkymist, qui sont totalement différents de ceux de Lattice).

Si tout se passe bien, vous devriez obtenir un fichier nommé vmlinux, qui est l'image du noyau au format ELF. Vous pouvez également utiliser la commande ARCH=lm32 make menuconfig afin de choisir les options à inclure dans le noyau. Cependant, je vous conseille d'utiliser la configuration par défaut pour commencer, d'autant plus que certaines options (heureusement assez rares) provoquent des plantages de GCC.

4. Test dans l'émulateur QEMU

On ne présente plus l'excellent émulateur QEMU, dont une version modifiée permet d'émuler le System-on-Chip Milkymist. Cette contribution de Michael Walle est assez stable et complète, et il y a de fortes chances pour qu'elle rejoigne prochainement les versions officielles de QEMU. La compilation et l'installation sont relativement simples :

À noter que QEMU permet d'émuler rapidement l'accélération graphique présente sur le SoC Milkymist grâce à la bibliothèque OpenGL. Pour le moment, le noyau Linux ne tire pas parti de l'accélération graphique de Milkymist, mais si vous envisagez d'autres développements logiciels l'utilisant, assurez-vous que les en-têtes de développement OpenGL sont présents sur votre système avant de compiler QEMU. Par ailleurs, nous avons besoin des en-têtes SDL afin de pouvoir lancer QEMU en mode graphique, ce qui est nécessaire dans notre cas car le noyau Linux utilise le framebuffer.

Il existe également des paquets RPM de QEMU supportant Milkymist, qui sont maintenus par Gerard Braad. Vous les trouverez à l'adresse http://files.gbraad.nl/qemu-lm32/.

Une fois QEMU installé, vous pouvez booter votre noyau Linux fraîchement compilé grâce à la commande suivante :

Vous devriez voir le noyau démarrer dans la fenêtre de QEMU... et ne pas aller bien loin ! En effet, nous ne disposons pas, pour le moment, d'un système de fichiers racine et encore moins d'applications utilisateurs telles que /sbin/init, qui est le premier programme que le noyau cherche à démarrer lors du boot d'un système. Nous allons résoudre ces problèmes dans la section suivante.

5. Compilation d'applications utilisateurs

5.1 Outils de compilation et bibliothèque C

Afin de pouvoir compiler des applications Linux, il nous faut une bibliothèque C (uClibc) et des outils de compilation utilisant cette bibliothèque et « configurant » correctement les exécutables générés. Malheureusement, la toolchain lm32-elf précédemment installée ne convient pas. La compilation de uClibc et d'une toolchain lm32-linux adéquate étant assez pénible, je vous conseille d'utiliser les binaires. Pour construire vous-même vos outils de compilation pour Linux et uClibc pour LatticeMico32, vous pouvez vous baser sur les sources modifiées publiées par Theobroma Systems. Si vous vous lancez dans cette aventure, n'hésitez pas à la documenter sur le wiki du projet Milkymist et à demander de l'aide sur la liste de diffusion « milkymist-devel » (http://lists.milkymist.org) si vous rencontrez des difficultés.

5.2 Système de fichiers

Nous allons maintenant créer l'image de système de fichiers EXT2 qui sera utilisée comme racine par le système, et la monter sur notre machine de développement à l'aide de la fonctionnalité « loopback » de Linux. Cela se fait de la façon habituelle:

5.3 Busybox

Busybox, « couteau suisse » du Linux embarqué, est un outil bien connu qui comprend toutes les fonctions nécessaires pour réaliser un système Linux de base. Parmi d'autres avantages, il est très facilement portable, y compris sur LatticeMico32, ce qui n'est pas le cas de la plupart des outils GNU utilisant Autoconf (comme le résume si bien Andrew S. Tanenbaum : [on uncommon platforms,] you type ./configure and it never works!). C'est donc Busybox que nous allons utiliser pour construire notre système utilisateur minimal.

Obtenons une copie des sources de Busybox et exécutons leur outil de configuration :

Allez dans le menu Busybox Settings puis sélectionnez Build Options. Cochez Build BusyBox as a static binary et Force NOMMU build. Dans Cross Compiler prefix, entrez lm32-linux-, et dans Additional CFLAGS, entrez -mmultiply-enabled -mdivide-enabled -mbarrel-shift-enabled -msign-extend-enabled.

Sélectionnez Exit pour retourner sur l'écran Busybox Settings. Dans le menu Installation Options, saisissez /mnt/milkymist dans BusyBox installation prefix.

Retournez au menu principal, et dans le menu Miscellaneous Utilities, désactivez la construction de tous les outils en rapport avec MTD (dont le nom commence par flash). Désactivez également readahead et taskset. Finalement, retournez au menu principal, sélectionnez Linux System Utilities et désactivez swaponoff.

Vous pouvez maintenant lancer la compilation avec :

La compilation devrait réussir à produire un fichier exécutable final. L'option -Wl,-q permet d'assurer la compatibilité avec le chargeur d'exécutable chaotique évoqué plus haut, en ajoutant des informations de relocation dans l'exécutable. Après l'installation, nous devrons lancer manuellement strip avec les options « adéquates » pour que ces informations de relocation ne soient pas effacées du binaire final.

Installez ensuite Busybox sur l'image EXT2 et lancez strip :

Enfin, vérifiez que tout s'est bien passé à l'aide de la commande suivante :

Vous devriez obtenir quelque chose comme :

Si la commande affiche à la place There are no relocations in this file, le binaire ne pourra pas fonctionner.

Toute contribution visant à réparer le chargeur d'exécutable et l'éditeur de liens (originellement développés par Theobroma Systems pour Lattice) afin d'éviter ces bricolages sera plus que bienvenue.

5.4 Essai dans QEMU

Avant de lancer l'émulateur, n'oublions pas de créer un point de montage pour /proc et de démonter notre image EXT2 :

Nous pouvons ensuite utiliser l'image comme ramdisk :

Cette fois, le système démarre correctement et lance un shell, depuis lequel vous pouvez monter /proc (mount -t proc none /proc), lancer les commandes Unix habituelles, etc.

Un système complet aurait toutes les fonctionnalités présentes dans les distributions (scripts de démarrage, login, gestionnaire de paquets, etc.). Pour le moment, aucune distribution embarquée ne supporte l'architecture LatticeMico32. Bien que cela ne soit pas particulièrement difficile à faire, nous n'avons pas eu le temps de nous en occuper. Cela pourrait être une contribution intéressante.

6. Exécution sur carte de développement FPGA

6.1 Matériel requis

Pour pouvoir lancer votre système Linux sur une implémentation FPGA du SoC Milkymist, vous aurez besoin d'une carte Xilinx ML401, d'un câble JTAG Xilinx Platform Cable USB, d'un câble null-modem RS232 et d'un port série.

Le design est très portable, cependant, certaines parties un peu spéciales sont délicates à adapter d'un FPGA à l'autre (voire simplement d'une carte à l'autre), notamment au niveau de l'interface avec la DDR SDRAM. Si vous n'êtes pas familier avec le développement FPGA bas niveau, je vous conseille donc d'essayer de trouver une ML401.

6.2 Construction et programmation du bitstream

Le « bitstream », dans le jargon, signifie le fichier (binaire) de programmation qui définit le circuit à charger dans le FPGA. Nous allons donc générer un bitstream correspondant au System-on-Chip Milkymist.

La seule étape délicate consiste à se procurer et installer les logiciels. En plus de Xilinx ISE, vous aurez besoin du synthétiseur Synplify. En effet, un bug dans la synthèse Xst pour Virtex-4 provoque une corruption assez subtile des caches du cœur du microprocesseur, qui se manifeste plus ou moins aléatoirement lors de l'exécution de logiciels complexes tels qu'un système Linux complet. Le problème a été rapporté à Xilinx il y a plusieurs mois, mais n'a toujours pas été corrigé. Une fois toutes les installations effectuées, il suffit d'exécuter les commandes suivantes pour construire et écrire (dans la Platform Flash) le bitstream. La construction du bitstream peut prendre une bonne quinzaine de minutes sur une machine rapide.

On ne peut que déplorer l'absence de toute solution libre permettant de programmer des FPGA. Certaines personnes justifient cela en se lamentant sur le fait que le format du bitstream est fermé. Ces personnes ne font que manifester leur méconnaissance des FPGA et leur manque de motivation. Premièrement, l'ingénierie inverse du format du bitstream, sans être facile, n'est pas non plus une tâche extrêmement difficile. Deuxièmement, la partie la plus complexe est probablement d'écrire le programme qui transformera le code VHDL ou Verilog en une « netlist » (suite de cellules FPGA connectées entre elles) optimisée. Pour cette partie, la documentation est largement disponible. Ce programme pourrait même être utilisable (et testé) immédiatement, sans avoir déjà tous les outils libres, en s'interfaçant (facilement) avec les outils propriétaires des fabricants de FPGA.

6.3 Compilation et programmation du BIOS

Le BIOS est exécuté au démarrage du système, alors que la SDRAM n'est pas encore opérationnelle. Il doit être placé dans la flash NOR de la carte, qui autorise facilement des accès aléatoires, ce qui permet l'exécution à la volée du code présent dans la flash sans copie préalable dans une RAM. En effet, avant le démarrage du contrôleur de SDRAM - ce qui est à la charge du BIOS - ce dernier ne dispose pour toute mémoire réinscriptible que des registres du processeur, qui ne représentent qu'une centaine d'octets !

Vous devez donc tout d'abord installer l'outil ml401-flasher permettant d'écrire dans la flash NOR de la carte à travers le port JTAG. Cet outil se compose de deux parties : un bitstream ajoutant une commande JTAG au FPGA permettant un accès relativement rapide à la flash (vous aurez donc besoin de Xilinx ISE pour le produire), et d'un outil basé sur libusb permettant d'écrire un binaire dans cette flash. Ce dernier n'est compatible qu'avec le câble Xilinx Platform Cable USB communément utilisé avec la ML401. Bien que Xilinx ait refusé de documenter publiquement le protocole de ce câble, un travail d'ingénierie inverse par un contributeur de l'outil libre UrJTAG a permis de le connaître. C'est cette contribution qui a été réutilisée pour développer ml401-flasher.

L'installation de l'outil est très simple :

Retournez ensuite dans le dossier milkymist et entrez (vous aurez notamment besoin des outils de compilation lm32-elf) :

L'écriture du BIOS dans la flash prend quelques dizaines de secondes.

Une fois toutes ces opérations effectuées, connectez un terminal série sur la carte et paramétrez-le en 115200bps 8-N-1. Vérifiez que tous les interrupteurs de droite de la ML401 sont positionnés vers le bas. Chargez le FPGA depuis la Platform Flash (en plaçant les trois interrupteurs MODE de la ML401 vers le bas et en appuyant ensuite sur son bouton PROG). Vous devriez voir ceci apparaître sur le terminal :

Félicitations, votre système fonctionne ! À noter, si vous souhaitez essayer le synthétiseur d'effets MilkDrop à partir de là, il vous suffit de lancer ./build_demo.sh (vous aurez notamment besoin d'installer Scilab, Lemon et RE2C), de copier le fichier software/demo/boot.bin ainsi que tout le contenu du dossier patches sur une carte Compact Flash et finalement de taper cardboot sur le terminal série. Connectez un microphone sur votre ML401 pour l'entrée son.

6.4 Boot

Le BIOS ne permettant pas (encore) de charger des binaires ELF, convertissez tout d'abord votre noyau Linux en binaire brut :

Vous pourrez ensuite le charger par l'une des trois méthodes supportées : via le réseau par TFTP (Trivial File Transfer Protocol), via une carte Compact Flash ou via le port série. Le BIOS essaye automatiquement ces trois méthodes lors du démarrage, et vous pouvez ensuite les relancer avec les commandes netboot, cardboot et serialboot, respectivement.

Une fois le noyau chargé, il utilisera la sortie VGA de la carte pour l'affichage et un clavier PS/2 branché sur le port prévu à cet effet pour entrer les commandes.

6.4.1 En utilisant le réseau (netboot)

C'est certainement la meilleure méthode, car elle offre rapidité (les images chargées sont assez volumineuses) et flexibilité. Il vous suffit de connecter votre ML401 sur le réseau Ethernet, installer un serveur TFTP sur votre machine et configurer cette dernière pour utiliser l'adresse IP 192.168.0.14. La carte utilisera l'IP 192.168.0.42.

Placez à la racine du serveur TFTP votre image du noyau (au format brut) nommée boot.bin, votre image EXT2 nommée initrd.bin et un fichier cmdline.txt contenant le texte :

Le BIOS devrait alors télécharger ces trois fichiers, et lancer votre système Linux.

6.4.2 En utilisant une carte Compact Flash (cardboot)

De la même façon que pour le boot par le réseau, vous pouvez placer les trois mêmes fichiers à la racine d'une carte Compact Flash. Celle-ci devra être formatée en FAT16.

6.4.3 En utilisant le port série (serialboot)

Cette méthode est déconseillée, car assez lente à cause de la taille volumineuse des images à envoyer.

Si vous souhaitez tout de même l'utiliser, vous aurez besoin de l'outil de chargement flterm. Celui-ci se trouve dans le sous-dossier tools du dossier milkymist. Si vous avez configuré le dépôt Debian Milkymist, vous pouvez également l'installer d'un simple :

Lancez ensuite l'outil grâce à la commande suivante, et redémarrez la carte FPGA (ou tapez serialboot dans flterm, ce dernier faisant également office de terminal série).

En guise de conclusion...

Cet article a montré les aspects pratiques de la compilation de Linux et d'applications pour Milkymist. Comme il a été dit, l'environnement Linux souffre encore de plusieurs problèmes liés au logiciel (chargeur d'exécutable problématique, plantages de GCC, code « sale », pilotes instables ou manquants - pour l'accélération graphique notamment). S'ils ne sont pas insurmontables, ils prendront néanmoins un temps important à corriger, d'autant plus qu'il faut régulièrement plonger dans les arcanes obscures et non documentées (mais libres !) de la toolchain GNU ou du noyau, ce qui est parfois assez décourageant. En partie pour cette raison, au moins les premières versions de la station VJ interactive Milkymist One seront basées sur le système d'exploitation POSIX temps réel RTEMS et non Linux. RTEMS dispose d'une communauté plus réactive et accueillante vis-à-vis de l'architecture LatticeMico32, est moins « lourd » que Linux et son code plus simple provoque moins de problèmes liés à GCC. Le portage de RTEMS vers Milkymist est développé par Yann Sionneau à l'occasion du Google Summer of Code 2010.

Le projet Milkymist ne développe pas uniquement un System-on-Chip libre, même si c'est ce qui le distingue des autres projets de « matériel libre ». Le projet consiste en une solution libre la plus complète possible pour réaliser des effets visuels en direct, composée non seulement de Milkymist SoC, mais aussi de Flickernoise (logiciel de VJ) et de Milkymist One (station VJ interactive « clés en main » utilisant les composants précédents). La station Milkymist One est réalisée en collaboration avec l'entreprise Sharism at Work Ltd., connue pour le Ben Nanonote (mini ordinateur portable sous Creative Commons). À l'heure où ces lignes sont écrites, une poignée de cartes pour les premiers prototypes Milkymist One (sans logiciel, qui mettra encore un certain temps à développer) ont été produites, et sont actuellement testées et utilisées par les développeurs FPGA et logiciel...

Références

Site du projet : http://www.milkymist.org

Site et blog de l'auteur : http://lekernel.net

MiBench : http://www.eecs.umich.edu/mibench

QEMU : http://www.qemu.org

Busybox : http://www.busybox.net

Portage de Linux par Theobroma Systems : http://www.theobroma-systems.com/uclinux-lm32

Ingénierie inverse des bitstreams Xilinx : http://www.ulogic.org

UrJTAG : http://urjtag.org

Scilab : http://www.scilab.org

Lemon : http://www.hwaci.com/sw/lemon

RE2C : http://re2c.org

RTEMS : http://www.rtems.org

Sharism at Work Ltd. : http://www.sharism.cc