SoC Milkymist: le développement logiciel en pratique


Cet article a été publié dans Linux Magazine 130 (septembre 2010) et est disponible sous licence CC-BY-NC-ND. Depuis, la situation a évolué. Il existe un portage OpenWrt automatisant de nombreuses manipulations décrites dans l’article. Une partie du chargeur d’exécutable et de nombreux bugs Linux ont été corrigés. QEMU ne nécessite plus de patch et la version 0.15 supporte directement Milkymist. Enfin, les Milkymist One sont disponibles à la vente et viennent avec une version bien plus aboutie de Flickernoise ainsi que tout un “packaging”.

Le numéro 124 de février vous a donné une présentation générale et assez théorique du System-on-Chip (SoC) libre Milkymist. Maintenant, nous allons nous orienter vers la pratique en détaillant les différentes opérations nécessaires au développement de logiciels fonctionannt sur cette plate-forme: installation des outils de compilation, construction d’un noyau Linux compatible, compilation d’applications et utilisation de l’émulateur QEMU, pour finir avec la configuration d’une carte de développement FPGA permettant de prototyper le SoC et le déploiement du logiciel sur cette dernière.

1. Introduction
En plus de disposer de coeurs 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 oeuvre.

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 voir à 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.

export INSTDIR=/usr/mico32
mkdir -p $INSTDIR
export PATH=$PATH:$INSTDIR/bin
wget ftp://ftp.gnu.org/gnu/binutils/binutils-2.20.1.tar.bz2
tar xvjf binutils-2.20.1.tar.bz2
mkdir binutils-build
cd binutils-build
../binutils-2.20.1/configure --target=lm32-elf --prefix=$INSTDIR
make
make install

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).

wget ftp://ftp.gnu.org/gnu/gcc/gcc-4.4.1/gcc-core-4.4.1.tar.bz2
tar xvjf gcc-core-4.4.1.tar.bz2
cd gcc-4.4.1
patch -p1 < lm32-jbeniston-200812+debian4.4.1.patch
cd ..
mkdir gcc-build
cd gcc-build
../gcc-4.4.1/configure --target=lm32-elf --prefix=$INSTDIR --enable-languages="c" --disable-libssp
make
make install

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:

deb http://www.milkymist.org/debian/ ./

Et de lancer ensuite:

apt-get update
apt-get install gcc-lm32

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 ttp://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.

wget http://www.milkymist.org/3rdparty/micotoolchain44.tar.bz2
tar xvjf micotoolchain44.tar.bz2
export PATH=$PATH:`pwd`/mico32/bin

3. Compilation du noyau Linux
Une fois les outils de compilations (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).

git clone git://github.com/tmatsuya/linux-2.6.git
cd linux-2.6
ARCH=lm32 make ml401_vga_defconfig
ARCH=lm32 CROSS_COMPILE=lm32-elf- make vmlinux

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.

Ecran de configuration du noyau Linux pour Milkymist.

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:

git clone http://git.serverraum.org/git/mw/qemu-lm32.git
cd qemu-lm32
git branch --track milkymist origin/milkymist
git checkout milkymist
./configure --target-list=lm32-softmmu
make
make install

A 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:

qemu-system-lm32 -M milkymist -kernel vmlinux

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 utilisateur 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.

Lancement du noyau Linux dans QEMU.

5. Compilation d’applications utilisateur
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” si vous rencontrez des difficultés.

wget http://www.theobroma-systems.com/assets/downloads/mico32/lm32linux-20080206toolchains_linux.tar.gz
tar xvzf lm32linux-20080206toolchains_linux.tar.gz
export PATH=$PATH:`pwd`/lm32linux-20080206toolchains_linux/toolchains/installdir/bin

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:
mkdir -p /mnt/milkymist
dd if=/dev/zero of=mmroot.img bs=1M count=8
mkfs.ext2 mmroot.img
mount -t ext2 -o loop mmroot.img /mnt/milkymist

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:
wget http://www.busybox.net/downloads/busybox-1.16.1.tar.bz2
tar xvjf busybox-1.16.1.tar.bz2
cd busybox-1.16.1
make menuconfig

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.

Menu "Build Options" de Busybox.

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:

make LDFLAGS="-Wl,-q"

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:

make install LDFLAGS="-Wl,-q"
lm32-linux-strip --strip-unneeded --strip-debug --remove-section=.note \
--remove-section=.comment busybox_unstripped
cp busybox_unstripped /mnt/milkymist/bin/busybox

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

lm32-linux-readelf --relocs /mnt/milkymist/bin/busybox

Vous devriez obtenir quelque chose comme:

Relocation section '.rela.init' at offset 0x1eea4d4 contains 2 entries:
Offset Info Type Sym.Value Sym. Name + Addend
00000008 00000207 R_LM32_CALL 0000001c .text + d0
0000000c 00000207 R_LM32_CALL 0000001c .text + e24c0

Relocation section '.rela.text' at offset 0x1eea4ec contains 38719 entries:
Offset Info Type Sym.Value Sym. Name + Addend
00000080 00000904 R_LM32_HI16 00146568 .bss + 0
00000084 00000905 R_LM32_LO16 00146568 .bss + 0
00000090 00000804 R_LM32_HI16 00145f58 .data + 10
00000094 00000805 R_LM32_LO16 00145f58 .data + 10
...

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:

mkdir /mnt/milkymist/proc
umount /mnt/milkymist

Nous pouvons ensuite utiliser l’image comme ramdisk:

qemu-system-lm32 -M milkymist -kernel vmlinux -append "root=/dev/ram init=/bin/hush" -initrd mmroot.img

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.

Lancement du système Linux minimal dans QEMU.

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 coeur 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.

wget http://www.milkymist.org/dist/milkymist-0.5.1.tar.bz2
tar xvjf milkymist-0.5.1.tar.bz2
cd milkymist
SYNTOOL=synplify ./build_bitstream.sh
SYNTOOL=synplify ./flash_bitstream.sh

On ne peut que déplorer l’absence de toute solution libre permettant de programmer des FPGAs. 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 FPGAs 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 FPGAs.

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:

git clone git://github.com/lekernel/ml401-flasher.git
cd ml401-flasher
make
make install

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

./build_bios.sh
./flash_bios.sh

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:

libHPDMC SDRAM initialization runtime
(c) Copyright 2010 Sebastien Bourdeauducq, released under GNU LGPL version 3.
Version 0.5.1

Initialization sequence completed.
Autocalibration OK, testing memory...
All SDRAM initialization completed, boot continuing.

MILKYMIST(tm) v0.5.1 BIOS http://www.milkymist.org
(c) Copyright 2007, 2008, 2009, 2010 Sebastien Bourdeauducq

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, version 3 of the License.

I: BIOS CRC passed (4fba232e)
I: Running on Xilinx ML401 development board
I: SystemACE : Yes
I: AC'97 : Yes
I: PFPU : Yes
I: TMU : Yes
I: PS/2 Kbd : Yes
I: PS/2 Mouse: Yes
I: Ethernet : Yes
I: FML Meter : Yes
I: Displaying splash screen...OK
I: Press Q to abort boot
I: Attempting serial firmware loading
sL5DdSMmkekro
E: Timeout
I: Booting from network...
I: MAC : f8:71:fe:01:02:03
I: Local IP : 192.168.0.42
I: Remote IP: 192.168.0.14
E: Timeout
I: Booting from CF card...
E: Unable to initialize CF card driver
E: Unable to initialize filesystem
E: No boot medium found
BIOS>

Félicitations, votre système fonctionne! A 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:

lm32-elf-objcopy -O binary vmlinux vmlinux.bin

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:

root=/dev/ram init=/bin/hush

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:

apt-get install flterm

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).

flterm --port /dev/ttyUSB0 --kernel boot.bin --initrd initrd.bin \
--cmdline "root=/dev/ram init=/bin/hush"

7. 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.

Copie d'écran de Flickernoise (image CC-BY-SA).

Composants matériels présents sur Milkymist One (image CC-BY-SA).

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 “clefs 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). A 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…

Ben Nanonote (image CC-BY-SA, Sharism).

Prototype Milkymist One (image CC-BY-SA).

Comments are closed.