INFO-F-410 Conception de systèmes embarqués Installation d`un

INFO-F-410 Conception de systèmes embarqués
Installation d’un système Linux enfoui sur une platte-forme
ARM Versatile
Gilles Geeraerts
Année académique 2008–2009
1
Introduction
Le but de cette séance est de donner aux participants une bonne idée du processus d’installation du
système d’exploitation Linux sur une platte-forme typique des systèmes embarqués. La platte-forme
choisie ici est l’ARM Versatile, et ce pour plusieurs raisons :
– Elle est bien distribuée et couramment utilisée dans l’industrie
– Le processeur ARM est bien supporté par Linux, mais n’est pas non plus un processeur i386,
ce qui permet d’expérimenter la compilation croisée.
– Cette plate-forme est simulée par QEmu, un émulateur de processeurs distribué en GPL. On
l’utilisera pendant la séance pour expérimenter.
– Ce type de platte-forme est également bien supporté par différents outils qui permettent de
générer automatiquement des chaînes de compilation croisée.
– Les ressources disponibles sont représentatives d’un système embarqué Linux typique : suffisantes que pour supporter l’OS (un MMU est disponible), mais malgré tout plus limitées qu’un
système de bureau contemporain.
La version de cette carte qui est supportée par QEmu comprend notamment les périphériques
suivants1 :
– Un processeur ARM926E (ou ARM 1136 ou Cortex-A8)
– Une carte Ethernet SMC 91c111
– Un contrôleur pour écran LCD PL110
– La possibilité d’avoir clavier et souris PS/2
– Un Bus PCI (support partiel)
– Un contrôleur USB OHCI
– Un contrôleur SCSI LSI53C895A
– Un contrôleur permettant l’accès à une carte SD
Pour émuler cette platte-forme, il faut lancer QEmu avec la commande qemu-system-arm2 avec
l’option -M versatilepb
Au final, les participants à cette séance devraient obtenir un système Linux fonctionnel (noyau,
système de fichier et applications de base) qui tourne sous QEmu, et être à même de faire fonctionner
sur ce système une petite application typique d’un système embarqué qui collecte des données (à
l’aide d’un capteur quelconque), et qui publie des statistiques sur ces données via un serveur web afin
1
2
D’après la documentation de QEmu disponible en ligne le 15 janvier 2009
La commande qemu-arm permet de lancer un programme compilé pour processeur ARM, et non pas tout un système.
1
qu’on puisse les consulter à distance. En pratique, on se contentera de lire sur la console une série de
nombre entiers, et de générer une page web qui indiquera le nombre de valeurs lues et la moyenne de
ces valeurs. Si l’application est triviale, elle illustre pourtant de manière réaliste une application des
systèmes embarqués utilisant un OS.
Les différentes étapes sont détaillées dans les sections qui suivent et sont librement inspirées de
l’ouvrage Building Embedded Linux Systems, 2e édition, Philippe G ERUM, Karim YAGHMOUR, Jon
M ASTERS et Gilad B EN -YOSSEF, O’Reilly, 2008 et du projet Linux from scratch3
Remarque Certaines commande à taper sont parfois fort longues. . . Dans ce document, nous avons
donc adopté la convention habituelle qui consiste à séparer en plusieurs ligne une seule et unique
commande à l’aide du caractère \. Ainsi :
Ah-ca-c-est-vraiment-une-longue-commande argument1 argument2 argument3 ca-n-arrete-pas
pourra être écrite :
Ah-ca-c’est-vraiment-une-longue-commande \
argument1 argument2 argument3 \
ca-n-arrete-pas
Remarquez les espaces en fin de ligne, avant les \. Ne les oubliez pas si vous tapez tout sur une ligne,
et n’en ajoutez pas s’il n’y en a pas dans la version avec \.
1.1
Mise en place
On supposera que la variable PRJROOT contient la racine du répertoire de travail. Comme les
quotas sont limités sur les comptes des salles du NO4, créez ce répertoire de travail dans /tmp, qui
est propre à la machine sur laquelle vous travaillez.
Attention ! !
Le contenu du répertoire /tmp est effacé à chaque logout. Faites des sauvegardes
(clef USB,. . .) si vous voulez conserver une trace de l’intégralité de votre travail.
On commence par créer les répertoires suivants dans notre répertoire de travail :
Nom
build-tools
images
kernel
rootfs
fsimages
sysapps
tmp
tools
Contenu
Tout ce qui est nécessaire pour construire
la chaîne de compilation croisée
Les images du noyau
Les sources du noyau
Le système de fichiers du système embarqué
Les images du système de fichiers
Les applications qu’on va installer sur le système embarqué
Tout ce qu’on ne sait pas mettre ailleurs. . .
Les outils de compilation croisée
Comme on utilisera couramment les outils qui se trouve dans tools et build-tools, il sera utile
d’exécuter la commande
3
http ://www.linuxfromscratch.org/
2
export PATH=$PRJROOT/build-tools/bin:$PRJROOT/tools/bin:$PATH
pour ajouter ces dossiers dans le path.
Enfin, on exécute la commande suivante :
export LD_lIBRARY_PATH=""
afin de supprimer de la variable LD_lIBRARY_PATH les valeurs qui, dans les salles du NO4, empêchent de compiler la libc.
2
Chaîne de compilation croisée
La chaîne de compilation sera contruite de façon automatique à l’aide de ptxdist4 . Cet outil se
charge de télécharger les sources et patches nécessaires pour une chaîne donnée. Il « suffit » de lui
préciser l’architecture cible.
On commence par se procurer la version 1.0.2 de ptxdist : les fichiers ptxdist-1.0.2.tgz
et ptxdist-1.0.2.patches.tgz, qu’on place dans notre répertoire build-tools. On les
décompresse et on compile le programme
tar xvzf ptxdist-1.0.2.tgz
tar xvzf ptxdist-1.0.2-patches.tgz
cd ptxdist-1.0.2
./configure --prefix=$PRJROOT/build-tools
make
make install
ptxdist est maintenant installé dans build-tools/bin. Il faut maintenant le configurer à l’aide
de la commande ptxdist setup et indiquer où l’on veut que la chaîne de compilation soit placée
une fois qu’elle est construite. Il faut entrer ${PRJROOT}/tools pour l’option Project SearchPath
et on peut utiliser ${PRJROOT}/build-tools/src pour Source directory.
Ensuite, il faut télécharger un projet ptxdist qui donne les détails de la chaîne de compilation
qu’on veut construire. Pour notre platte-forme, il en existe une qui fonctionne très bien dans le fichier
OSELAS.Toolchain-1.1.1.tar.bz2, qu’on place dans le répertoire build-tools. On le
décompresse et on s’y positionne pour exécuter ptxdist.
tar xvjf OSELAS.Toolchain-1.1.1.tar.bz2
cd OSELAS.Toolchain-1.1.1/
Le répertoire ptxconfigs contient les fichiers de configuration en question. Celui que nous utiliserons se nomme :
arm-xscale-linux-gnueabi_gcc-4.1.2_glibc-2.5_linux-2.6.18.ptxconfig
En visualisant son contenu, vous verrez que la chaîne que nous allons construire aura notamment les
caractéristiques suivantes :
– Compilateur gcc 4.1.2 supportant C et C++
– Bibliothèque libc 2.5 basé sur les en-têtes du noyau 2.6.18 (elle devrait donc fonctionner avec
les noyaux récents).
4
Voir www.pengutronix.de/software/ptxdist
3
Malheureusement, ce fichier nécessite quelques adaptations. À fin du fichier, remplacez la ligne :
PTXCONF_CONFIGFILE_VERSION="1.0"
par :
PTXCONF_CONFIGFILE_VERSION="1.0.2"
car ces fichiers ont été faits avec la version 1.0 de ptxdist, mais nous utilisons la 1.0.2.
Par ailleurs le fichier contient également des informations sur les répertoires où placer les chaînes
de compilation, qui interfèrent avec la configuration de ptxdist. On remplace donc :
PTXCONF_PREFIX_FIRST="/opt/${PTXCONF_PROJECT}"
par :
PTXCONF_PREFIX_FIRST="${PRJROOT}/tools"
On peut alors dire à ptxdist d’utiliser ce fichier modifié :
ptxdist select \
ptxconfigs/arm-xscale-linux-gnueabi_gcc-4.1.2_\
glibc-2.5_linux-2.6.18.ptxconfig
Cette chaîne peut encore être adaptée en tapant ptxdist menuconfig. Vous aurez alors accès
aux options que nous avons observées dans le fichier de configuration, mais sous forme de menu. Afin
d’accélérer le processur, on évitera de compiler gdb qu’on n’utilisera pas dans cette séance. Il faut
donc le décocher dans le menu principal.
On lance la compilation de la chaîne à l’aide de ptxdist go (toujours depuis le répetoire
OSELAS.Toolchain-1.1.1/). Le processus prend une petite vingtaine de minutes. . . pensez
donc à lire la suite de ce document en attendant5 . Certaines des étapes qui suivent peuvent déjà être
partiellement réalisées (notamment la réalisation du système de fichiers).
Une fois la chaîne prête, elle se trouve dans le répertoire :
tools/arm-xscale-linux-gnueabi/\
gcc-4.1.2-glibc-2.5-kernel-2.6.18/bin
Comme vous le verrez, ce répertoire contient tous les outils de compilation (gcc, ld, g++), mais
avec un nom qui commence par arm-xscale-linux-gnueabi-. C’est cette caractéristique qui
nous permettra plus tard d’indiquer facilement à make de faire de la compilation croisée, quand nous
voudrons compiler des outils qui devront s’exécuter sur le système embarqué.
En pratique, la plupart des outils GNU sont fournis sous forme de sources, soit accompagnés d’un
Makefile, soit d’un script configure qu’il faut exécuter pour générer les Makefiles. Une fois le
Makefile obtenu, il suffit en général de l’invoquer en ajoutant des paramètres supplémentaires pour
obtenir la compilation croisée, à savoir :
– ARCH=arm Cette définition a pour effet d’activer et de désactiver certaines parties du code du
programme à compiler qui dépendent du processeur utilisé.
– CROSS_COMPILE=$PRJROOT/tools/arm-xscale-linux-gnueabi/\
gcc-4.1.2-glibc-2.5-kernel-2.6.18/bin/arm-xscale-linux-gnueabiaura pour effet de préfixer toutes les commandes de compilation par cette chaîne. Ainsi, au lieu
d’exécuter la commande gcc par exemple, ce qui aurait pour effet d’appeler le gcc standard du
système, Make va exécuter la commande qui correspond à notre compilateur croisé, à savoir :
$PRJROOT/tools/arm-.../arm-xscale-linux-gnueabi-gcc.
5
Si le processus est trop long, décompressez le fichier embsys-cross-comp.tar.bz2 qui contient la hiérarchie
évoquée ci-dessus avec le compilteur croisé déjà compile.
4
Par ailleurs, le répertoire
tools/arm-xscale-linux-gnueabi/\
gcc-4.1.2-glibc-2.5-kernel-2.6.18/\
sysroot-arm-xscale-linux-gnueabi
est lui aussi bien intéressant ! Il contient un embryon de système de fichier pour notre système embarqué, avec, entre autres choses, un répertoire lib qui contient la libc déjà compilée pour notre système
(ptxdist a utilisé le compilateur croisé pour cette tâche).
3
Compilation du noyau
La première étape pour obtenir un système fonctionnel consiste à compiler le noyau Linux. Nous
avons choisi d’utiliser la dernière version à la date de l’écriture de ce document, à savoir la 2.6.28. On
commence donc par placer le fichier linux-2.6.28.tar.bz2 dans le répertoire kernel, et on
le décompresse.
Les sources du noyau pèsent 50 Mo compressées. Pour compiler un noyau fonctionnel, il faut
configurer le Makefile afin qu’il ne compile que les pilotes utiles à notre système. La sélection des
pilotes est un exercice de haut vol qui demande en général de nombreux essais-erreurs. Il est donc
recommandé de se procurer un fichier de configuration tout fait sur le net, ou via le site du fabricant.
Dans le cadre de ces exercices, nous vous fournissons le fichier linux-kernel-config qui est
adapté au « matériel virtuel » que nous allons utiliser. Il faut copier ce fichier dans le répertoire des
sources du noyau et le renommer .config (il devient donc un fichier caché).
cp linux-kernel-config $PRJROOT/kernel/linux-2.6.28
cd $PRJROOT/kernel/linux-2.6.28
mv linux-kernel-config .config
Ceux que cela intéresse peuvent voir (et modifier. . . à leurs risques et périls) les options choisies en
laçant make menuconfig. On peut maintenant lancer la compilation croisée du noyau en tapant :
make ARCH=arm \
CROSS_COMPILE=$PRJROOT/tools/arm-xscale-linux-gnueabi/\
gcc-4.1.2-glibc-2.5-kernel-2.6.18/bin/arm-xscale-linux-gnueabiRemarquons que le fichier de configuration qu’on a utilisé n’active pas les modules du noyau. On a
donc un noyau monolithique qui contient tous les pilotes nécessaires, mais pas plus.
Une fois la compilation terminée, le noyau (compressé) se trouve dans :
$PRJROOT/kernel/linux-2.6.28/arch/arm/boot
Il s’appelle zImage et ne pèse que 1,3 Mo, ce qui est assez approprié pour un système embarqué.
On va stocker ce noyau dans images/linux-2.6.28, ce qui nous permettra de la retrouver facilement et d’expérimenter avec d’autres noyaux si nécessaire.
mkdir $PRJROOT/images/linux-2.6.28
cp $PRJROOT/kernel/linux-2.6.28/arch/arm/boot/zImage \
$PRJROOT/images/linux-2.6.28
On peut déjà tester ce noyau en utilisant QEmu :
5
F IG . 1 – Premier démarrage, sans système de fichiers.
qemu-system-arm -M versatilepb \
-kernel $PRJROOT/images/linux-2.6.28/zImage
Normalement, on devrait assister à un démarrage en règle du noyau, qui se termine par un kernel
panic, le noyau n’arrivant pas à monter de système de fichiers root (voir Fig. 1)
Il est intéressant de remarque que QEmu est capable de lancer le noyau directement à partir de
son image. Sur un véritable système, cette image est présente sur le système de fichiers, et on utilise
un programme d’amorçage (bootloader) pour le récupérer et le charger en mémoire. Nous pourrons
donc nous en passer ici (QEmu fait office de bootloader).
4
Constitution du système de fichiers
Comme nous l’avons dit, nous allons constituer le système de fichiers de notre système embarqué
dans le répertoire rootfs. Sur un véritable système embarqué, le contenu de ce répertoire devra être
copié sur le medium (disque dur, carte de mémoire flash,. . .) qui, une fois inséré dans le système, fera
office de racine. Dans notre cas, nous allons transformer ce répertoire en une image de disque, que
nous passerons ensuite à QEmu pour qu’il la fasse apparaître comme le premier disque dur (rappelezvous que notre carte Versatile dispose d’un contrôleur SCSI).
6
4.1
Création d’un système de fichiers minimaliste
Nous allons commencer par copier les répertoires créés par ptxdist et qui contiennent la libc :
cd $PRJROOT/tools/arm-xscale-linux-gnueabi\
/gcc-4.1.2-glibc-2.5-kernel-2.6.18/\
sysroot-arm-xscale-linux-gnueabi
cp -R * $PRJROOT/rootfs
Ensuite, nous allons ajouter les répertoires manquants :
cd $PRJROOT/rootfs
mkdir bin dev proc sbin sys tmp var etc/rc.d etc/network
Il doit être possible d’écrire et lire dans tmp pour tous les utilisateurs :
chmod 1777 tmp
Il faut également créer des sous-répertoires à usr et var :
mkdir usr/sbin var/lib var/lock var/log var/run var/tmp
chmod 1777 var/tmp
4.2
Création de l’image
Avant de créer l’image du système de fichier, il faut encore décider quel système choisir. Nous
avons choisi ici d’utiliser ext2fs qui est le système de fichiers classique sous Linux6 . Rappelons que
Linux supporte bien d’autre possibilité, comme FAT, NTFS, des systèmes compressés (ce qui peut
être utile dans ce cadre), chiffrés, et d’autres choses plus exotiques.
Pour générer une image de la hiérarchie de fichiers très minimaliste que nous avons créée, et
l’organiser en système de fichier ext2fs, nous allons utiliser l’utilitaire genext2fs. En effet, celui-ci
permet d’automatiser une partie de la tâche. Il se charge notamment de créer toute une série d’entrées
nécessaires dans /dev qu’il serait fastidieux de créer à la main avec les bonnes permissions (de plus,
cela requiert un accès root sur la machine de développement).
On va donc placer les sources de genext2fs dans $PRJROOT/tools/src par exemple, le
compiler7 et l’installer dans $PRJROOT/tools :
cp genext2fs-1.4.1.tar.gz $PRJROOT/tools/src
cd $PRJROOT/tools/src
tar xvzf genext2fs-1.4.1.tar.gz
cd genext2fs-1.4.1
./configure --prefix=$PRJROOT/tools
make
6
7
Bien qu’il se fasse détrôné par ext3. . .
Attention, pas de compilation croisée cette fois !
7
make install
Pour indiquer à genext2fs quels fichiers spéciaux il doit générer dans le système de fichiers (en
plus de ce qui se trouve déjà dans rootfs), il faut lui passer un fichier de configuration. Celui qui est
donné à titre d’exemple avec les sources convient parfaitement. Il s’appelle device_table.txt.
Parcourez-le brièvement pour vous rendre compte du travail qui vous est épargné !
On peut maintenant créer l’image du système de fichiers dans fsimages :
cd $PRJROOT
genext2fs -b 100000 -d rootfs \
-D tools/src/genext2fs-1.4.1/device_table.txt \
-e 0 fsimages/hd.img
Les options utilisées fonctionnent comme suit :
– -b est la taille en blocs de 1Ko (donc, ici, une image de 100 Mo à peu près).
– -d donne le répertoire où se trouvent les fichiers à partir desquels il faut créer l’image.
– -D indique où se trouve la description des fichiers spéciaux à utiliser.
– -e 0 indique que les parties non-occupées de l’image doivent contenir des 0.
– Le dernier paramètre est l’endroit où créer l’image.
On peut dès lors tester notre système, qui va démarrer, monter le périphérique /dev/sda (premier disque dur SCSI) et puis lancer la commande init. . . que nous n’avons pas encore créée (voir
section suivante).
qemu-system-arm -M versatilepb \
-kernel $PRJROOT/images/linux-2.6.28/zImage \
-hda $PRJROOT/fsimages/hd.img -append "root=/dev/sda rw"
Remarquez l’option -append qui permet de passer des paramètres au noyau. À nouveau, sur un
système « réel », c’est le bootloader qui passe ces paramètres au noyau. Ici, QEmu fait de nouveau
office de bootloader. Les options sélectionnées indiquent que c’est /dev/sda qui doit faire office
de racine (comme nous l’avons déjà dit) et que ce périphérique doit être monté en lecture et écriture
(read/write).
5
BusyBox
Afin d’avoir à notre disposition les outils de base nécessaires au bon fonctionnement d’un système
Linux, nous allons utiliser BusyBox8 , qui, en un seul exécutable de 750 Ko, implémente plusieurs
dizaines d’utilitaires9 . BusyBox implémente même une version simplifiée de init10 (sans runlevels).
5.1
Installation
Nous allons l’installer sur notre système. Voici les étapes nécessaires :
8
http ://www.busybox.net
Voyez http ://www.busybox.net/downloads/BusyBox.html
10
Pour rappel, init est la première commande exécutée par le noyau une fois que le démarrage de celui-ci est terminé.
C’est init qui est alors responsable de gérer les logins, de lancer des shells, etc. Tous les processus du système sont donc des
descendants d’init.
9
8
– Copie les sources busybox-1.10.1.tar.bz2 dans $PRJROOT/sysappas/src.
– Décompresser les sources.
– Compiler BusyBox à l’aide du compilateur croisé et l’installer dans $PRJROOT/rootfs (lisez le fichier INSTALL pour savoir comment faire, et utilisez les options ARCH et CROSS_COMPILE
pour utiliser le compilateur croisé). Attention, lors de la phase de configuration de BusyBox
(make menuconfig), il faut veiller à décocher toutes les options dans la section Linux module utilities. En effet, ces utilitaires servent à gérer les modules du noyau, mais nous avons
opté pour un noyau sans modules.
– Compiler à l’aide du compilateur croisé et installer.
– Regénérer l’image disque à l’aide de genext2fs.
Il est ensuite intéressant d’observer, dans $PRJROOT/rootfs, les fichiers qui ont été installés,
et comment les commandes classiques comme ls par exemple sont réalisées à l’aide de BusyBox.
À ce point, vous pouvez regénérer l’image disque et essayer de démarrer le système, car BusyBox
fournit un init, que nous allons maintenant configurer.
5.2
Configuration de init
Par défaut, la commande init implémentée dans BusyBox exécute les actions qui correspondent
au fichier inittab11 suivant :
::sysinit:/etc/init.d/rcS
::askfirst:/bin/sh
::ctrlaltdel:/sbin/reboot
::shutdown:/sbin/swapoff -a
::shutdown:/bin/umount -a -r
::restart:/sbin/init
Nous allons créer un fichier inittab (dans $PRJROOT/rootfs/etc/inittab) qui convient
mieux à notre système. On peut donc utiliser un fichier comme ceci :
::sysinit:/etc/rc.d/rcS
tty1::askfirst:/bin/sh
::restart:/sbin/init
::ctrlaltdel:/sbin/reboot
::shutdown:/bin/umount -a -r
Au démarrage du système, cet inittab lance le script /etc/rc.d/rcS. Nous devons encore
le créer en n’oubliant pas de lui donner les permissions d’exécution :
cd $PRJROOT/rootfs/etc/rc.d
touch rcS
chmod a+x rcS
On édite alors ce script pour y insérer simplement la ligne #!/bin/sh. Dans l’état, ce script ne fait
donc rien. Nous y ajouterons des commandes pour configurer la carte réseau et les points de montage.
11
Le format du fichier inittab utilisé par BusyBox est différent du format classique, et est détaillé à l’adresse :
http ://www.busybox.net/downloads/BusyBox.html.
9
5.3
Points de montage
Grâce à BusyBox nous disposons maintenant d’une commande mount. Le paramètre que nous
passons au noyau via QEmu, permet déjà de monter la racine. Par contre, le répertoire /proc, qui
contient normalement une hiérarchie de fichiers virtuelle donnant des informations sur le noyau (processus en cours, tables de routage, etc) est toujours vide. Pour qu’il contienne les bonnes informations,
il faut monter le système de fichiers virtuel proc (qui pointe vers les tables appropriées du noyau)
dans le répertoire /proc.
La façon la plus élégante de procéder est de spécifier dans un fichier spécial, /etc/fstab la
liste de tous les systèmes de fichiers qui peuvent être montés, et où ils doivent être montés. Ensuite,
il suffit d’appeller la commande mount -av pour monter automatiquement tout ce qui est spécifié
dans fstab.
On crée donc le fichier ${PRJROOT}/rootfs/etc/fstab avec le contenu suivant :
proc
/proc
proc
rw,nosuid,noexec
0
0
Puis, on ajoute la commande mount -av au fichier /etc/rc.d/rcS.
On peut alors redémarrer le système embarqué, et observer que le répertoire /proc contient bien
des informations pertinentes.
5.4
Configuration de la carte réseau
Notre système embarqué devra être connecté au réseau, car nous allons y exécuter un serveur
http qui donnera des informations sur l’état du système à l’aide d’une page web. Par défaut, QEmu
implémente un serveur DHCP virtuel, auquel le système embarqué dans la machine virtuelle peut
accéder pour se configurer correctement (ce qui est une situation tout à fait réaliste). Plus précisément,
il faut lancer QEmu avec les options -net user -net nic, et la machine virtuelle est alors
connectée aux trois « machines » suivantes :
1. Un serveur DHCP qui fait aussi office de pare-feu, et de passerelle vers le monde extérieur,
avec l’adresse 10.0.2.2. Le serveur DHCP fournit des adresses à partir de 10.0.2.15.
2. Un serveur DNS, à l’adresse 10.0.2.3.
3. Un serveur SMB, à l’adresse 10.0.2.4.
Nous devons donc configurer notre carte réseau pour qu’elle utilise la configuration donnée par le
serveur DHCP. Voici les étapes nécessaires :
1. Créer un fichier $PRJROOT/rootfs/etc/network/interfaces qui décrit les interfaces réseau et la manière de les configurer :
auto lo eth0
iface lo inet loopback
iface eth0 inet dhcp
La première ligne indique que les interfaces peuvent être configurées automatiquement grâce à
ifup. Les lignes suivantes correspondent aux deux interfaces : lo pour le loopback, et eth0
pour la carte réseau principale, qui sera configurée en DHCP.
2. Créer un script pour activer ces interfaces au démarrage du système. Par soucir de faciliter,
on crée un script spécial appelé etc/rc.d/rc.inet. Ce script fait appel à la commande
ifup, qui va elle-même consulter le fichier etc/network/interfaces. On met donc
dans le fichier etc/rc.d/rc.inet :
10
#!/bin/sh
ifup lo
ifup eth0
3. Modifier le script /etc/rc.d/rcS pour qu’il appelle rc.inet. Attention, ne pas oublier
de rendre exécutable le script rc.inet !
4. Ajouter un script qui sera automatiquement exécuté par udhcpc, le client DHCP fourni par
BusyBox. Ce script a pour but de récupérer les informations fournies par le serveur DHCP, et
de lancer les commandes qui configurent le système en fonction de ces informations. Pour ce
faire, on peut simplement récupérer le fichier d’exemple fourni par BusyBox et le copier, sous
le nom default.script dans /usr/share/udhcpc/ (en n’oubliant pas de le rendre
exécutable si nécessaire).
mkdir $PRJROOT/rootfs/usr/share/udhcpc
cd $PRJROOT/sysapps/src/busybox-1.10.1/examples/udhcp
cp simple.script $PRJROOT/rootfs/usr/share/udhcpc/
cd $PRJROOT/rootfs/usr/share/udhcpc/
mv simple.script default.script
chmod a+x default.script
Après avoir reconstruit l’image disque, on peut redémarrer le système (ne pas oublier les nouveaux paramètres pour QEmu), et constater qu’on a bien une adresse IP et tapant, par exemple
ifconfig eth0.
5.5
Configuration du serveur http
BusyBox contient également un serveur http très simple. Pour s’en servir, il suffit de configurer et
d’activer le démon httpd. On commence par créer une répertoire www dans notre système de fichier.
Ce répertoire contiendra les pages web servies par notre système embarqué :
mkdir $PRJROOT/rootfs/var/www
chmod a+rx $PRJROOT/rootfs/var/www
Pour les besoins du test, on peut se contenter de mettre une simple page index.html dans le répertoire $PRJROOT/rootfs/var/www :
<HTML>
<BODY>
Hello World (Wide Web) !
</BODY>
</HTMl>
Ensuite, on active le démon httpd au démarrage, simplement en ajoutant la ligne :
httpd -h /var/www
au script inet.d.
Malheureusement, notre machine virtuelle ne possède une adresse IP que dans le réseau local
virtuel auquel elle est connectée. Dans la réalité, on pourrait tester notre système en connectant un
11
PC portable, par exemple, au réseau local et en se connectant au système embarqué. Dans le cas qui
nous occupe, on peut utiliser une option fort pratique de QEmu qui nous permet d’accéder à certains
ports du sysyème embarqué, en les redirigeant vers des ports de la machine de développement. En
l’occurrence, nous allons rediriger le port 80 du système embarqué vers le port 5000 de la machine
hôte, en ajoutant :
-redir tcp:5000::80
à notre commande QEmu. On peut alors, après avoir regénéré l’image disque et redémarré notre système embarqué, lancer un navigateur web sur la machine hôte, et visiter http://localhost:5000
pour voir apparaître la page web que nous avons créée.
6
Notre application
Comme dit dans l’introduction, nous aimerions installer sur notre système embarqué une application qui lit en boucle des valeurs entières sur la console et qui génère une page web qui affiche le
nombre de valeurs lues et leur moyenne.
Pour ce faire, créez dans le répertoire $PRJROOT/sysapps/src un répertoire pour vos sources
(par exemple : $PRJROOT/sysapps/src/simplecount) et créez-y les sources de l’application. Celle-ci devra écrire ses résultats dans le fichier /var/www/index.html. Pour vous simplifier la vie, vous pouvez éviter de mettre des balises HTML, le contenu du fichier sera affiché de
manière brutte dans le navigateur web.
Une fois votre application terminée, compilez-la avec le compilateur croisé et installez-la dans
un répertoire approprié (par exemple $PRJROOT/rootfs/usr/bin/. Enfin, modifiez le script
/etc/rc.d/rcS pour qu’elle soit lancée automatiquement au démarrage. Recréez l’image disque
et relancez QEmu. Vous pouvez maintenant entrer des valeurs dans la console et consulter les résultats
en cliquant sur reload dans le navigateur web. . .
12