Sometimes, when debugging some firmware or hardware, it is necessary to see how the internal state of a chip changes in response to external signals.

With microcontrollers, this can be accomplished by adding code that toggles some pin that is then used for debugging, and watching that pin with an oscilloscope. Such a pin can also serve as sophisticated trigger, e.g., to capture some input signal only when an error is detected.

With M1, we can do the same, e.g., make LM32 or Navre toggle an I/O under software control. But we can do better: we can also route “hardware” signals directly, without involving software.

Here are three ways to do this:

1. Change the Verilog to properly route the signal to the output pad. This is nice and clean but has the following disadvantages:
   • need to run the full build process for each change of taps,
   • need to edit the sources (and remember to undo all the changes once the problem is fixed),
   • the signals need to be propagated step by step up the module hierarchy (*), which means a lot of small changes in many files,

     (*) Verilog should support also direct references that “jump” the hierarchy, but this doesn’t seem to be properly implemented in the Xilinx tools.

2. The pros just edit the FPGA with a WYSIWYG editor (Part three shows how to route signals to a pad). What I don’t like about this is that it’s not script-friendly. I’d also suspect that the changes are lost or at least in danger when re-synthesizing.
3. Like above, but edit non-interactively. This is an experimental hack I’ve now implemented.

Read the rest from the Milkymist mailing list…

Updating is easy – just connect the M1 to the Internet (booting it with the Ethernet cable connected to a network with DHCP should do, or use the system settings to configure the network) and then press the first push button (labeled L) for a few seconds. It should display this:

Update in progress

Then, power off and on again your M1. The “About” dialog box will display the new versions (Flickernoise 1.0 + SoC 1.0.1):

New versions

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

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

You haven’t really seen what the Milkymist One (M1) really can do if you haven’t used it with some MIDI controls.

Here’s how it’s done:

• first, you need some MIDI controller. For now, it has to be one that has the old-style MIDI connectors, not USB-MIDI. I used a Korg Kaossilator Pro.
• next, you need to define which of the controller functions you want to map to variables for your patch. This is done in the M1′s control panel, Interfaces > MIDI > Controller mapping.

  “midi1″ through “midi8″ are the variables you can set. The value on the right side is the controller number. E.g., for my Kaossilator, I assigned:
  

  midi1	12	touch pad, X axis
  midi2	13	touch pad, Y axis
  midi3	91	gate arpeggiator slider
  midi4	94	program volume knob

  This is for using the Kaossilator both as an instrument and as a MIDI controller. If I had switched it to be only a controller, I would have had more controls to play with and some of the numbers would have changed.

• you can now use Patches > Variable monitor to see how the controls affect the midi1 … midi4 variables. Each gets assigned a value between 0 to 1, corresponding to the setting of the control. (MIDI transmits values from 0 to 127.)
• finally, you need to modify a patch to use the MIDI variables. I took a simple one, “Geiss – Tornado”, and made the following tweaks:
  1. per_frame=t=time+midi2*100;

     and then changed all the wave_
     settings to use “t” instead of “time”. This way, I can modulate the color by moving along the Y axis on the pad.

  2. per_frame=rot=midi1*2;

     I put this after the last assignment to “rot”, effectively overriding it. Now rotation is entirely under my control, with no rotation when touching the pad on the left edge, and rapid spinning on the right edge.

  3. per_frame=move_x=0.5+midi3/5;

     This controls the distance of the point being drawn from the center. With rotation, this becomes the radius at which things appear. I assigned it to the slider.

  4. per_frame=zoom=0.9+midi4/5;

     This controls how quickly we “travel into” the image. I assigned it to the volume knob.

• these settings are lost when powering down or restarting the M1. To keep them, save with Performance > Save and, after booting, load with Performance > Load. Be careful to save under the directory /ssd/, not the root directory. The latter is also lost when booting.

Here is a video:

In this case, I didn’t use the Kaossilator’s sound. Also, some of the controls aren’t very nicely mapped for the effects I was trying to make. That’s why I often had a hard time getting from an all-green screen to something more interesting.

The first step was to build a variable high voltage power supply, since I’m under-equipped enough not to have one laying around. So I used a 20V power supply transformer connected to a 120V variable autotransformer scavenged from a 70′s American-built X-ray machine that happened to have a permanent tap within the first turns, allowing it to step-up the voltage to a nice 180V. For turning it into DC, I simply took the switching power supply PCB from a discarded fax machine, cut it right after the filtering capacitor, and hooked it to the variac. There are easier options, but I did with what I found in my pile of junk

The grid voltage is provided by a 9V battery and a potentiometer, and the filament voltage by my (single!) lab power supply. I then used cheap DMMs to measure anode voltage, anode current and grid voltage.

This resulted in this little kludge:

Experimental setup

Schematics of the above little mess

Emission tests
The first test was to see how many electrons the hot filament is capable of sending into the tube. I connected together the anode and the grid and brought them to a 176V potential, while I varied the filament voltage.
This led to this plot:

Cathode emission versus filament voltage

The second test was to see how much the anode potential influenced the anode current. I set the grid to the ground potential, and varied the anode voltage. The plot shows a quite linear dependence:

Anode current versus anode voltage

Amplification test
Now, let’s see how good this triode is at doing its job: amplifying signals! With the anode potential set to 176V and a filament voltage of 4V, I sweeped the grid voltage and plotted the anode current:

Anode current versus grid voltage

STEP 1: Install a TFTP server
Install the TFTP server package for your distribution, and configure it.

STEP 2: Prepare the boot image
Take the Flickernoise FBI (Flash Boot Image) file from the MSD archive, and remove its FBI header.
$ dd if=flickernoise.fbi of=boot.bin bs=1 skip=8
Then, move it to the TFTP server directory:
$ mv boot.bin /var/lib/tftpboot

STEP 3: Boot the board from the network
Set up your computer to have the IP address 192.168.0.14, and connect it to the board. Boot the board (press the middle pushbutton) with a USB keyboard connected to it, and when you see the BIOS splash screen, press the F8 key to boot from the network.

BIOS splash screen

STEP 4: Erase the old flash filesystem
Flickernoise 0.1 uses a read-only FAT filesystem on the flash, while Flickernoise 0.2 introduced full YAFFS2 support. You will therefore need to format (erase) the flash disk partition.

For this, you will need to obtain a shell on the board. This can be simply done by enabling the telnet server and connecting to it. You need to set up a login and password to enable telnet access. Click the “Settings” button at the bottom of the control panel, and enter a login and password in the dialog box.

System settings dialog box

Once this is done, you can use telnet to connect to the board:
telnet 192.168.0.42
Enter the following commands at the RTEMS shell prompt:
# unmount /flash
# erase /dev/flash5
# mount -t yaffs /dev/flash5 /flash

Telnet session

STEP 5: Transfer the new flash images to the board
Simply use an FTP client to connect to the board (192.168.0.42), and upload the contents of the MSD archive, e.g. in the /ramdisk folder. Use the login and password you just set up to authenticate to the FTP server.

STEP 6: Flash
In the control panel, click “About”, then “Flash”. Select the images you have just uploaded, and click the “Program flash” button.

Flickernoise flash programmer

You’re done! If you have upgraded the bitstream, you need to select “Shutdown” (in the control panel), then “Power off” and then power the board on again. Since a disk cache is used by the RTEMS operating system, always use “Shutdown” to turn off the board to prevent data loss.

And while you have the FTP connection open, you can also use it to upload the default Flickernoise patches to the flash…