INFO-F-410 Conception de systèmes embarqués Installation d`un
Transcription
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