Linux Embarque

Gilles Chanteperdrix
Imprime le 4 juin 2002
Resume
Ce document est la propriete dIDEALX S.A.S.
1
. Il est place sous licence de documentation
libre GNU (GNU Free Documentation License, voir http ://www.gnu.org/copyleft/fdl.html
ou http ://www.idealx.org/fr/licences/gfdl.html pour une traduction en fran cais non o-
cielle).
Ce document est le support dune formation `a lutilisation de Linux dans un contexte embarque.
La realisation concr`ete dun syst`eme embarque base sur Linux en est le l rouge.
1
http ://www.IDEALX.com
Table des mati`eres
Introduction 3
1 Demarrage dun syst`eme Linux par le reseau 4
1.1 Dynamique du demarrage par le reseau . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Etherboot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Conguration du serveur DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Conguration du serveur TFTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Preparation du noyau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.1 Param`etres de compilation du noyau . . . . . . . . . . . . . . . . . . . . . . 7
1.5.2 Options choisies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5.3 Preparation pour demarrage par le reseau . . . . . . . . . . . . . . . . . . . 9
1.6 Conguration du serveur NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Mise en place de lenvironnement dexecution 11
2.1 Structure dun repertoire racine type . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Decoupage du repertoire racine de la cible . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Contenu du repertoire partage sur le syst`eme hote . . . . . . . . . . . . . . . . . . 12
2.4 Biblioth`eques partagees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5 Busybox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6 Demarrage de la cible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.7 Scripts de demarrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.7.1 Demarrage de devfsd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.7.2 Montage des syst`emes de chiers . . . . . . . . . . . . . . . . . . . . . . . . 16
2.7.3 Conguration du reseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.7.4 Demarrage des journaux syst`eme . . . . . . . . . . . . . . . . . . . . . . . . 17
2.7.5 Demarrage du watchdog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Developpement dapplications embarquees avec GNU/Linux 18
3.1 Developpement dapplications natives . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.1 Le compilateur GCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.2 Liaison statique vs Liaison dynamique . . . . . . . . . . . . . . . . . . . . . 19
3.2 Adaptation dune application native . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Portage dune application ecrite pour un OS proprietaire . . . . . . . . . . . . . . . 21
3.3.1 Temps-reel ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.2 Portage de premier ordre . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.3 Xenomai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4 Finalisation du syst`eme 24
4.1 Partitionnement du disque ash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2 Copie des chiers sur le disque ash . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.1 Syst`eme de chiers racine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1
4.2.2 Syst`eme de chiers damor cage . . . . . . . . . . . . . . . . . . . . . . . . . 25
2
Introduction
Lutilisation dun syst`eme dexploitation generaliste pour un syst`eme embarque pourrait pa-
ratre saugrenue, mais elle a lenorme avantage de permettre deviter les longues iterations dun
processus de developpement croise. En outre, la exibilite et la modularite de Linux en font un bon
candidat pour lembarquement dans des syst`emes de taille (moderement) reduite. Enn, les sources
de nombreux composants logiciels ecrits pour Linux sont disponibles gratuitement, ce qui permet
de concentrer reellement leort de developpement sur la partie specique dune application.
An de tirer le plus grand parti des avantages de Linux, un processus de developpement rai-
sonnable pourrait comprendre les etapes suivantes :
developpement de lapplication sur machine hote,
test sur cible avec syst`eme de chiers distribue,
test sur cible avec memoire de masse embarquee.
Le demarrage dune cible avec un syst`eme de chiers distribue nous semble etre un atout
determinant pour faciliter la mise au point dun syst`eme embarque base sur Linux. Cependant il
necessite un minimum de preparation du syst`eme hote que nous exposons donc dans le premier
chapitre de ce document. Dans le deuxi`eme chapitre, nous creons un syst`eme de chier minimal
permettant au syst`eme de demarrer compl`etement. Dans le troisi`eme chapitre, nous exposons les
probl`emes rencontres et les outils necessaires au developpement dapplications embarquees sous
Linux. Enn, dans le quatri`eme chapitre, nous nalisons le syst`eme pour quil puisse fonctionner
en utilisant sa memoire de masse embarquee.
3
Chapitre 1
Demarrage dun syst`eme Linux
par le reseau
Avant de plonger dans les r`egles de conguration des serveurs, il est necessaire de comprendre,
au moins superciellement, comment demarre une machine sous Linux dans le cas particulier dun
demarrage par le reseau, cest donc ce que nous ferons dans une premi`ere section.
Ensuite, nous congurerons les serveurs de la machine hote. Les explications quant aux noms
des repertoires utilises pour cette conguration seront donnees dans le chapitre 2 page 11.
1.1 Dynamique du demarrage par le reseau
Lors du demarrage dun syst`eme Linux par le reseau, un certain nombre de protocoles sont
utilises dont nous allons donner une br`eve description avant de detailler le processus du demarrage :
DHCP permet la conguration de linterface reseau dune machine cible `a partir de param`etres
reseaux fournis par une machine hote.
BOOTP est une extension du protocole DHCP qui permet `a une machine de charger un noyau
par le reseau, la machine cible recoit par le reseau lemplacement de telechargement de son
noyau en plus des param`etres reseau.
TFTP est un protocole de transfert de chiers par le reseau qui est utilise par la cible pour
telecharger son noyau.
NFS est un syst`eme de chiers distribue.
Le processus de demarrage comprend les etapes suivantes :
4
Sur la cible Sur lhote
Le syst`eme demarre sur une disquette conte-
nant le programme Etherboot, le charge et
lexecute.
Le programme Etherboot congure son inter-
face reseau, puis emet une requete BOOTP.
Le serveur DHCP fournit `a la machine cible
ses param`etres reseau et lemplacement de son
noyau.
Le programme Etherboot telecharge le noyau
en utilisant le protocole TFTP.
Le serveur TFTP fournit le noyau du syst`eme
cible.
Le programme Etherboot passe le controle au
noyau (les param`etres de conguration de lin-
terface reseau sont alors perdus).
Le noyau emet une requete DHCP pour obte-
nir ses param`etres reseau
Le serveur DHCP fournit ses param`etres re-
seau `a la machine cible.
Le noyau monte son repertoire racine en utili-
sant le syst`eme de chiers NFS.
Le serveur NFS accorde lacc`es au repertoire
partage `a la machine cible, `a qui il sert alors
de repertoire racine.
Le demarrage de la cible se poursuit en utili-
sant les chiers qui sont sur le repertoire par-
tage.
Dans la suite de ce chapitre, nous allons congurer les serveurs de la machine hote dans lordre
dans lequel ils sont utilises au cours du processus que nous venons de decrire. Cet ordre nest pas
imperatif, mais il permet, apr`es chaque etape, de verier quelle a ete correctement eectuee.
1.2 Etherboot
Etherboot est le programme qui eectue le telechargement en memoire vive du noyau, prepare
son execution puis lexecute. An quune machine puisse demarrer en utilisant ce programme, il
doit etre stocke sur le secteur damorce dune disquette, dun disque IDE, dun CDROM, ou meme
sur la ROM dune carte reseau.
Etherboot peut-etre telecharge (voir [1]), puis compile. Mais il est aussi possible de telecharger
une image de disquette prete `a lemploi (cf [2]). Il sut alors de choisir la version dEtherboot, le
type de carte reseau, le format de sortie (normalement, disquette de demarrage).
Apr`es avoir telecharge limage, la disquette peut etre creee avec la commande :
dd if=eb-(version)-(carte reseau).lzdsk of=/dev/fd0
Pour tester la validite de la disquette Etherboot ainsi generee, elle peut etre utilisee comme
disquette damorce du syst`eme cible. Si tout se passe bien, le type de carte reseau du syst`eme cible
doit etre reconnu, son adresse MAC doit sacher, puis le syst`eme doit echouer quand il essaie de
contacter le serveur DHCP.
1.3 Conguration du serveur DHCP
Le paquet Red-Hat correspondant au serveur DHCP doit dabord etre installe sur la machine
hote, cest le paquet dchp. Le serveur DHCP contenu dans ce paquet a lavantage detre aussi
serveur pour le protocole BOOTP.
5
Nous allons congurer le serveur DHCP en utilisant ladresse MAC de la carte reseau de la
cible. Ladresse MAC de la carte se presente sous la forme de 6 entiers de 2 caract`eres en notation
hexadecimale. Elle est ecrite sur la carte elle-meme ou sache `a lecran lors du demarrage avec
la disquette Etherboot.
Le chier de conguration du serveur DHCP est le chier /etc/dhcpd.conf dont voici un
exemple :
option broadcast-address 192.168.0.255;
subnet 192.168.0.0 netmask 255.255.255.0
{
use-host-decl-names on;
host vnt-alf {
hardware ethernet 00:e0:98:33:e0:86;
fixed-address 192.168.0.117;
filename "/tftpboot/192.168.0.117/zImage";
}
}
Lorsque la machine dont ladresse MAC est 00:e0:98:33:e0:86 eectuera une requete BOOTP,
le serveur lui fournira ladresse IP 192.168.0.117, le nom vnt-alf comme nom dhote, et lui trans-
mettra /tftpboot/192.168.0.117/zImage comme nom de noyau `a telecharger pour demarrer.
Apr`es avoir edite ce chier de conguration, il faut demarrer le serveur, en tapant :
# /etc/init.d/dhcpd start
An de tester le serveur DHCP, redemarrer la cible, dont la requete BOOTP doit maintenant
etre satisfaite, mais qui ne doit pas arriver `a charger son noyau. Le chier de journal de la machine
hote (/var/log/messages), doit contenir les lignes :
DHCPDISCOVER from 00:e0:98:33:e0:86 via eth0
DHCPOFFER on 192.168.0.117 to 00:e0:98:33:e0:86 via eth0
Il est `a noter que lexemple propose ici est simple, car il suppose quun seul serveur DHCP
est present sur le reseau, ce qui est facilement realisable (en reliant lhote et la cible par un cable
croise, par exemple). Toutefois, il est aussi possible davoir plusieurs serveurs DHCP sur un meme
reseau, mais la conguration est un peu plus compliquee. La solution la plus radicale consiste `a
utiliser les vendor encapsulated options, la documentation dEtherboot (voir [1]) est compl`ete `a
ce sujet.
1.4 Conguration du serveur TFTP
Le paquet Red-Hat qui doit etre installe sur la machine hote est le paquet tftp-server. Le
demon tftpd est un demon tr`es simple lance par le gestionnaire de services reseau inetd ou
xinetd. Le demon TFTP ne necessite pas ledition de chiers de conguration, en revanche inetd
ou xinetd doivent etre congures pour lancer tftpd.
6
Si le serveur inetd est utilise, cest le chier /etc/inetd.conf qui doit etre edite. Il doit contenir
la ligne :
tftp dgram udp wait root /usr/sbin/tcpd in.tftpd /tftpboot
Si le serveur xinetd est utilise, cest le chier /etc/xinetd.d/tftp qui doit etre edite :
#/etc/xinitd.d/tftp
service tftp
{
protocol = udp
socket_type = dgram
wait = yes
user = root
log_on_success += USERID
log_on_failure += USERID
server = /usr/sbin/in.tftpd
server_args = /tftpboot
disable = no
}
Les champs quil est important de modier sont le champ disable qui doit etre positionne `a
no et le champ server_args qui doit contenir exclusivement /tftpboot.
Apr`es avoir modie la conguration, il faut redemarrer le gestionnaire de services internet ; en
tapant :
/etc/init.d/inetd restart pour redemarrer inetd,
ou /etc/init.d/xinetd restart pour redemarrer xinetd.
An de tester que ce service fonctionne bien, redemarrer la cible. Le processus de demarrage
par Etherboot devrait aller plus loin quau precedent essai, mais si le chier correspondant au
param`etre filename de la conguration de dhcpd nexiste pas, le processus Etherboot echoue.
1.5 Preparation du noyau
La prochaine etape du processus de demarrage par Etherboot est le chargement du noyau. Nous
nembarquons pas un noyau standard car certaines options du noyau doivent etre activees pour
permettre lutilisation dun syst`eme de chiers distribue comme repertoire racine. Cette section
fournit donc une bonne occasion pour detailler un peu les options de compilation qui peuvent
presenter un certain interet pour des syst`emes embarques.
1.5.1 Param`etres de compilation du noyau
Pour lancer linterface de conguration de la compilation du noyau, taper :
# cd /usr/src/linux
# make xconfig
Une fenetre apparat achant plusieurs sections contenant chacune un certain nombre doptions
de compilation. Les sections suivantes nous ont semble contenir des options interessantes :
7
Loadable module support Certaines fonctionnalites du noyau peuvent etre compilees sous for-
me de modules. Ces modules peuvent alors etre charges, utilises et decharges `a loisir pendant
le fonctionnement du noyau. Alors que cette fonctionnalite est interessante pour les noyaux
generalistes fournis par des distributions ou pour ne pas payer en permanence le co ut en
occupation memoire de fonctionnalites occasionnelles sur une station de travail, elle lest
beaucoup moins sur un syst`eme embarque. Lactivation de loptionEnable module support
necessite linstallation doutils pour charger et decharger les modules.
Processor type and features Cette section contient des options qui permettent dadapter le
noyau `a sa plate-forme dexecution. Loption Processor family, notamment, permet de
choisir exactement le processeur present sur la plate-forme dexecution.
Memory Technology Device Cette section donne acc`es `a toute une serie de pilotes pour peri-
pheriques ash.
Networking Options Cest dans cette section que se trouvent les options qui permettent au
noyau de determiner automatiquement sa conguration reseau au moment du demarrage.
Watchdog cards Cette section se trouve dans la sectionCharacter devices, et permet dactiver
la gestion de syst`emes de surveillance materiel ou logiciel.
File systems Cette section permet de selectionner les syst`emes de chiers qui seront reconnus
par le noyau genere. Parmi ces syst`emes de chiers notons :
le syst`eme de chiers EXT2, standard et classique sous Linux, que nous utiliserons sur la
partition de demarrage de la cible ;
le syst`eme de chiers NFS (dans la sous-section Network File systems) qui permet de
partager un repertoire entre plusieurs machines par le reseau;
le syst`eme de chiers TMPFS, est un syst`eme de chiers stocke en memoire vive, ideal
pour le stockage des chiers temporaires ;
le syst`eme de chiers JFFS2, journalise, compresse et adapte `a une utilisation optimale
des peripheriques ash.
1.5.2 Options choisies
Nous selectionnons ici tous les param`etres que nous utiliserons par la suite. Si la presence de
certaines options devrait dej`a paratre evidente, dautres, en revanche, ne le deviendront que plus
tard, notamment lorsque nous aurons vu comment et pourquoi le syst`eme de chier racine est
decoupe, section 2.2 page 11.
An de demarrer en utilisant un syst`eme de chiers distribue, les options `a activer sont :
dans la section Networking Options, IP : kernel level autoconguration et IP : BOOTP
support
dans la sectionFilesystems, sous-sectionNetwork File systems, NFS le system support
et Root le system on NFS
Pour eviter davoir `a creer des chiers speciaux pour les peripheriques, dans la section File
systems, activer les options
/dev le system support
et Automatically mount at boot.
Pour gerer les syst`emes de chiers sur disque compact ash, dans la sectionMemory Technology
Devices (MTD), activer
Memory Technology Devices (MTD) support,
Caching block device access to MTD devices,
Readonly block device access to MTD devices.
Dans la sous-section Self-contained MTD device drivers, activer MTD emulation using block
8
device. Enn, dans la section File systems, activer loption Journalling Flash File System v2
(JFFS2) support.
Pour utiliser la memoire vive comme moyen de stockage des chiers temporaires, dans la section
File systems activer loption Virtual memory le system support (former shm fs).
Pour un syst`eme embarque, il peut etre utile davoir syst`eme de surveillance (watchdog) qui
redemarre le syst`eme sil est bloque. Pour pouvoir selectionner un watchdog, activer Watchdog
Timer Support, puis selectionner le watchdog materiel si vous en avez un, ou le watchdog logiciel
(moins able) si aucun watchdog materiel ne convient.
Apr`es avoir ni la selection doption, valider en selectionnant Save and Exit. Les options
selectionnees sont sauvees dans le chier /usr/src/linux/.config.
Pour lancer la compilation, taper :
make dep; make clean; make bzImage
Limage generee est alors le chier /usr/src/linux/arch/i386/bzImage, avant de demarrer le
syst`eme en utilisant cette image, il convient de la preparer pour etre demarree par le reseau.
Pour compiler, puis installer les modules, taper :
make modules; make INSTALL_MOD_PATH=/tftpboot/192.168.0.117/flash modules_install
Il est `a noter que la valeur de la variable INSTALL_MOD_PATH peut etre stockee dans le chier
/usr/src/linux/Makefile.
1.5.3 Preparation pour demarrage par le reseau
Le programme permettant de preparer un noyau pour son demarrage par le reseau est mknbi,
il doit etre installe sur le serveur. Le paquet Red-Hat pour mknbi peut etre telecharge `a la meme
adresse quEtherboot ([1]).
Linvocation de mknbi est susamment penible et frequente pour quil soit avantageux den
faire un script :
#!/bin/sh
IMAGE="/usr/src/linux/arch/i386/boot/bzImage"
NBI_IMAGE="/tftpboot/192.168.0.117/zImage"
NFS_ROOT="192.168.0.61:/tftpboot/192.168.0.117/flash"
OTHER_PARAM="ro blkmtd_device=/dev/hda2"
mknbi-linux --rootdir="$NFS_ROOT" --output="$NBI_IMAGE" --ip=bootp \
--append="$OTHER_PARAM" "$IMAGE"
Loption --rootdir permet de fournir au noyau lemplacement du repertoire racine sur un
syst`eme de chiers distribue. Cet emplacement est donne sous la forme :
<adresse IP du serveur>:<chemin du repertoire sur le serveur>
9
Loption --output permet de specier le nom du noyau au format necessaire `a Etherboot.
Loption --ip permet de specier la methode de conguration automatique du reseau (on ne
peut pas compter sur les scripts de demarrage pour congurer le reseau, necessaire bien plus tot
lors du demarrage).
Loption --append permet dajouter des param`etres au noyau qui ne sont pas connus direc-
tement par mknbi. Ici les param`etres passes sont ro, qui permet de demander le montage du
repertoire racine en lecture seul, et blkmtd_device=/dev/hda2, qui permet de specier quelle
partition IDE (la deuxi`eme partition du premier disque IDE, en loccurrence) sera utilisee comme
disque ash `a travers la couche demulation.
Pour une description plus detaillee des options de mknbi-linux, se reporter `a sa page de manuel.
Apr`es execution de ce script, pour verier que limage generee est correcte, redemarrer la cible.
La cible doit arriver `a charger le noyau par tftp, commencer le demarrage, puis sarreter au moment
de monter le repertoire racine par le reseau.
1.6 Conguration du serveur NFS
Pour installer le serveur NFS, installer le paquet Red-Hat nfs-utils. Le chier de conguration
du serveur NFS est /etc/exports. Pour que la cible puisse monter son repertoire racine, ce chier
doit contenir la ligne :
/tftpboot/192.168.0.117 192.168.0.117(rw,no_root_squash)
Les options rw et no_root_squash permettent `a toute personne qui utilise ce repertoire `a travers
le reseau deectuer nimporte quelle operation.
Apr`es la modication du chier /etc/exports, il faut demarrer le serveur NFS en tapant :
# /etc/init.d/nfs start
Pour tester le fonctionnement du serveur NFS, redemarrer la cible. Le montage du repertoire
racine doit fonctionner, mais lorsque le noyau essaie dexecuter le chier /sbin/init, il doit
echouer.
`
A ce point, la conguration des serveurs sur la machine hote est terminee. Le syst`eme cible
na plus besoin que de quelques chiers pour etre capable de demarrer. Cest ce que nous nous
proposons de faire dans le chapitre suivant.
10
Chapitre 2
Mise en place de lenvironnement
dexecution
Le but de ce chapitre est de mettre en place, en plus du noyau que nous avons compile dans la
premi`ere partie, un ensemble delements supplementaires an de permettre le demarrage complet
de la cible, et de simplier lajout dautres elements. Ce sera pour nous aussi loccasion de toucher
du doigt les probl`emes lies `a ladaptation dapplications Linux `a un environnement embarque que
nous verrons plus en details dans le chapitre 3 page 18.
2.1 Structure dun repertoire racine type
Voici un minimum raisonnable de repertoires que doit contenir le repertoire racine dun syst`eme
Linux :
/boot : chiers utilises pour la creation dun secteur damorce ;
/dev : chiers speciaux dacc`es aux peripheriques ;
/proc : repertoire de base necessaire au syst`eme de chiers proc, permettant le controle et
lobservation dynamique du noyau;
/etc : chiers de conguration et scripts de demarrage ;
/sbin, /bin : chiers executables, utilitaires syst`emes ;
/lib : biblioth`eques partagees necessaires `a lexecution des programmes ;
/mnt : points de montage pour dautres syst`emes de chiers ou dautres peripheriques ;
/usr : utilitaires et applications supplementaires ;
/tmp : chiers temporaires ;
/var : journaux syst`emes, chiers syst`emes temporaires.
2.2 Decoupage du repertoire racine de la cible
Les chiers du repertoire racine de la cible suivront le decoupage suivant :
les chiers speciaux, qui se resument aux repertoires /proc et /dev, puisque nous avons choisi
loption dutiliser devfs lors de la conguration du noyau, ne seront que des points de montage
sur le syst`eme cible ;
les chiers destines `a etre accessibles en lecture seule au cours du fonctionnement nominal
(executables, biblioth`eques, scripts de demarrage, chiers de conguration) seront stockes sur
11
le repertoire partage de lhote pendant le developpement, puis sur le disque ash du syst`eme
cible pour son fonctionnement autonome ;
les chiers temporaires (stockes dans les repertoires /tmp et /var) seront stockes sur un
syst`eme de chiers TMPFS, an deviter des cycles decriture frequents sur la memoire ash,
il est `a noter que lon devra sauver periodiquement les journaux syst`emes sur le disque ash
si lon veut en disposer pour deboguer des crash du syst`eme ;
le repertoire /boot (en fait seulement limage du noyau) ne peut etre stocke dans un syst`eme
de chiers JFFS2, il necessitera donc la creation dune partition supplementaire (utilisant le
syst`eme de chiers EXT2) sur le disque ash.
2.3 Contenu du repertoire partage sur le syst`eme hote
Sur le syst`eme hote, le repertoire partage (/tftpboot/192.168.0.117) contiendra donc :
le noyau Linux prepare pour le demarrage par Etherboot : zImage ;
un repertoire flash, contenant limage du syst`eme de chier racine de la cible ;
un repertoire boot, correspondant au repertoire du meme nom sur le syst`eme cible.
An que les repertoires /tmp et /var du syst`eme cible soient stockes en memoire vive, ces
repertoires seront des liens symboliques qui ne deviendront valides quapr`es lexecution dun script
de demarrage qui montera un syst`eme de chier TMPFS.
Dans le repertoire /tftpboot/192.168.0.117, nous lan cons donc les commandes suivantes :
# mkdir flash
# cd flash
# mkdir bin boot dev etc proc lib usr usr/bin usr/lib mnt mnt/tmpfs
# ln -s mnt/tmpfs/tmp .
# ln -s mnt/tmpfs/var .
Dans la suite de ce chapitre, nous allons peupler le repertoire flash pour permettre le demarrage
complet du syst`eme.
2.4 Biblioth`eques partagees
La biblioth`eque standard du langage C (libc) fournie par une distribution de Linux `a usage
general peut sembler un peu imposante. Suivant lencombrement vise, elle sera embarquee telle
quelle, ou elle sera remplacee par une libc reduite (donc `a laquelle il manque potentiellement
certaines fonctionnalites) comme clibc (voir [4]) ou newlib (voir [5]).
Ici nous conservons la libc fournie par la distribution de Linux de lhote, ce qui a pour prin-
cipal avantage de pouvoir eviter la problematique de la compilation croisee, cest-`a-dire que la
compilation dune application pour la cible ne necessite aucune astuce particuli`ere et quune ap-
plication compilee sur lhote pour la cible peut etre executee sur lhote. Dautre part, nous pouvons
reprendre toutes les applications dej`a compilees de lhote pour les embarquer sur la cible.
La libc GNU comprend plusieurs composants sous forme de biblioth`eques partagees. Comme
cette biblioth`eque est fournie sous forme de biblioth`eque partagee, nous devons aussi installer le
chargeur de biblioth`eques partagees. Au nal, nous embarquons donc les trois chiers :
/lib/ld-linux.so.2
12
/lib/libc.so.6
/etc/ld.so.conf
Lors de son fonctionnement, la biblioth`eque de chargement de biblioth`eques partagees utilise le
chier /etc/ld.so.cache. Ce chier indexe lensemble des biblioth`eques partagees stockees dans
les repertoires dont le nom gure dans le chier /etc/ld.so.conf. Il doit donc etre regenere apr`es
lajout ou la suppression de biblioth`eques partagees dans lun de ces repertoires, en tapant :
ldconfig -r /tftpboot/192.168.0.117/flash
2.5 Busybox
Busybox est un programme dont lutilisation simplie le peuplement du repertoire racine du
syst`eme cible. Il regroupe, `a lui seul, les fonctionnalites de beaucoup dutilitaires GNU, et doutils
syst`eme Linux en un seul executable de taille reduite.
Busybox existe sous forme de paquet pour les distributions Red-Hat version 7.2 et Red-Hat
version 7.3. Toutefois, pour une version 7.1 ou pour pouvoir adapter Busybox nement `a ses
besoins, il vaut mieux telecharger (voir [3]) ses sources et le compiler.
La conguration de Busybox se trouve dans le chier Config.h (situe dans le repertoire de
ses sources) , il sut dediter ce chier pour garder seulement les composants necessaires. Par
exemple, pour lutilisation dun watchdog, decommenter la ligne de Config.h :
//#define BB_WATCHDOG
Ensuite, pour compiler, taper :
# make
Enn, pour installer Busybox dans le repertoire partage :
# make PREFIX=/tftpboot/192.168.0.117/flash install
Il est `a noter, que la methode que nous venons dutiliser pour compiler Busybox le lie `a la meme
libc que celle du syst`eme hote. Tous les noms de chiers donnes dans la suite de ce chapitre sont
relatifs au repertoire racine du syst`eme cible, i.e. /tftpboot/192.168.0.117/flash.
2.6 Demarrage de la cible
`
A la n de la phase dinitialisation du noyau, celui-ci execute le programme /sbin/init. Busy-
box contient une version simpliee du chier /sbin/init System V, dont le chier de conguration
est /etc/inittab. La version de /sbin/init de Busybox a un comportement par defaut si ce -
chier est absent.
Le chier /etc/inittab par defaut est le suivant :
13
::sysinit:/etc/init.d/rcS
::askfirst:/bin/sh
::ctrlaltdel:/sbin/reboot
::shutdown:/sbin/swapoff -a
::shutdown:/bin/umount -a -r
::restart:/sbin/init
tty2::askfirst:/bin/sh
tty3::askfirst:/bin/sh
tty4::askfirst:/bin/sh
Une ligne de conguration prend la forme :
<console>::<moment>:<action>
Elle decrit une action qui doit etre executee `a un moment precis. La console permet au syst`eme
dutiliser les consoles virtuelles de Linux, si aucune console nest specie, la premi`ere console
(/dev/tty1) est utilisee. Les dierents valeurs qui nous interessent pour le champ <moment> sont :
sysinit permet dindiquer le nom dun programme qui sera execute `a linitialisation du syst`eme,
init attend la n de son execution avant dexecuter quoi que ce soit dautre, cest lempla-
cement ideal pour lancer les scripts de demarrage ;
respawn permet dindiquer le nom dun programme qui sera execute apr`es la n de linitialisation
puis automatiquement relance chaque fois quil se termine ;
askrst fonctionne comme respawn `a la dierence pret quil demande `a lutilisateur dappuyer
sur entree avant de provoquer laction associee.
Le chier inittab que nous allons utiliser est `a peu pr`es le meme :
::sysinit:/etc/init.d/rcS start
::askfirst:/bin/sh
::ctrlaltdel:/sbin/reboot
::shutdown:/etc/init.d/rcS stop
::restart:/sbin/init
2.7 Scripts de demarrage
Comme nous venons de le voir, par defaut, le chier /sbin/init fourni avec Busybox execute
le script /etc/init.d/rcS. Ici, deux approches peuvent etre utilisees pour lancer les demons et
initialiser les dierents services dont nous avons besoin :
lancer tous les demons dans /etc/init.d/rcS,
creer un script de demarrage par demon `a lancer.
Si la premi`ere solution a lavantage detre simple, la deuxi`eme permet de creer une notion de pa-
quet pour notre syst`eme embarque, et sadapte plus facilement `a lajout de nouveaux programmes.
Comme pour une distribution classique, nous allons creer un script par demon ou service qui sera
lance avec loption start ou stop suivant que lon veut le demarrer ou larreter.
En resume, le chier /etc/init.d/rcS contient :
#! /bin/sh
for file in /etc/rc$1.d/*
14
do
$file "$1"
done
`
A chaque demon est associe un script de demarrage /etc/init.d/daemon construit en suivant
le mod`ele :
#! /bin/sh
DAEMON="/sbin/daemon"
PARAMS=""
case "$1" in
start)
$DAEMON $PARAMS
;;
stop)
kill pidof $DAEMON
;;
*)
echo unknown parameter: $1
;;
esac
Dautre part, les repertoires /etc/rcstart.d et /etc/rcstop.d contiennent chacun des liens
symboliques vers les scripts contenus dans /etc/init.d. Linteret dutiliser des liens symboliques
est de permettre de contr oler lordre dexecution des scripts au moment du demarrage en prexant
leur nom par un numero dordre, mais deviter tout desagrement avec ce numero dordre si lon
veut editer un script de demarrage ou demarrer ou arreter un service manuellement. Dans la suite
de cette section les scripts apparaissent dans lordre o` u ils doivent etre lances sur le syst`eme cible
(et normalement, lordre inverse de celui dans lequel ils doivent etre arretes).
2.7.1 Demarrage de devfsd
Puisque nous avons choisi dutiliser devfs, nous devons demarrer le demon devfsd. Le role de
devfsd est detablir les liens entre les chiers speciaux du repertoire /dev dans leur ancienne
denomination (cest-`a-dire dans leur version anterieure `a lapparition de devfsd), et leur nouvelle
denomination. Cela pourrait sembler inutile, mais la plupart des programmes utilisent les anciens
noms de chiers speciaux.
Dautre part, devfsd doit etre le premier programme lance et le dernier programme arrete an
davoir une chance que les autres programmes puissent etre lances. Le script de lancement de
devfsd commence comme suit :
#! /bin/sh
DAEMON="/sbin/devfsd"
PARAMS="/dev"
...
Pour que devfsd fonctionne correctement, il faut aussi embarquer son chier de conguration
(/etc/devfsd.conf ou /etc/devfs/devfsd.conf).
15
2.7.2 Montage des syst`emes de chiers
Les syst`emes de chiers qui sont montes au demarrage et leurs points de montage sont stockes
dans le chier /etc/fstab. Un contenu minimal pour ce chier et pour le syst`eme qui nous
interesse pourrait etre :
proc /proc proc defaults 0 0
tmpfs /mnt/tmpfs tmpfs size=10m 0 0
/dev/hda1 /boot ext2 defaults,noauto 0 0
/dev/hda2 / jffs2 defaults,rw,noauto 0 0
/dev/fd0 /floppy auto defaults,noauto 0 0
Ce chier fstab demande le montage dun syst`eme de chiers TMPFS au demarrage, les entrees
associees aux partitions /dev/hda1 et /dev/hda2 ont ete mises en prevision, mais ne peuvent pas
fonctionner tant que le disque ash na pas ete partitionne et que le repertoire racine est un
repertoire NFS.
Le script de demarrage correspondant est le suivant :
#! /bin/sh
case "$1" in
start)
mount -a
cd /mnt/tmpfs
for dir in \
tmp \
var \
var/log \
var/run \
; do
mkdir $dir
done
;;
stop)
umount -a -r
;;
*)
echo unknown parameter: $1
;;
esac
Ce script cree aussi les sous repertoires du syst`eme de chier TMPFS an que les liens symbo-
liques /tmp et /var deviennent valides.
2.7.3 Conguration du reseau
Le script de conguration du reseau ne presente aucune particularite, il nest utile que si la
cible a une autre interface reseau que linterface conguree par DHCP.
#! /bin/sh
16
IFACE=eth1
IPADDR=192.168.0.117
NETMASK=255.255.255.0
GATEWAY=""
case "$1" in
start)
ifconfig lo 127.0.0.1 up
ifconfig "$IFACE" "$IPADDR" netmask "$NETMASK" up
test -n "$GATEWAY" && route add default gw "$GATEWAY"
;;
stop)
ifconfig "$IFACE" down
ifconfig lo down
;;
*)
echo unknown parameter: $1
;;
esac
2.7.4 Demarrage des journaux syst`eme
Les programmes charges de gerer respectivement le journal syst`eme et le journal du noyau sont
/sbin/syslogd et /sbin/klogd. Leurs scripts de demarrage nont aucune particularite.
2.7.5 Demarrage du watchdog
Le demon associe au watchdog est le chier /usr/sbin/watchdog, lance sans param`etre. Son
script de demarrage est tout `a fait habituel.
Apr`es lecriture de tous ces scripts de demarrage, le syst`eme devrait pouvoir enn demarrer
normalement. Apr`es le demarrage du syst`eme, celui-ci demande `a lutilisateur dappuyer sur la
touche entree pour activer la console. Lappui sur la touche entree provoque le demarrage dun
interpreteur de commandes. Lutilisateur peut alors taper des commandes comme ls ou ps, qui
doivent fonctionner.
`
A ce point, la cible demarre compl`etement. Cel`a devrait nous permettre de tester lajout de
nouvelles applications, ou de tester une application specique que nous developpons. Le travail `a
realiser pour embarquerun application depend des contraintes de cette operation (temps imparti,
performance, taille visee), cest pourquoi, dans le chapitre suivant, nous essayons de conserver une
approche dans les grandes lignes.
17
Chapitre 3
Developpement dapplications
embarquees avec GNU/Linux
Comme nous lavons mentionne dans lintroduction du present document, un des interets duti-
liser un syst`eme dexploitation generaliste sur une plate-forme embarquee est la compatibilite entre
lhote et la cible qui permet deviter les probl`emes du developpement croise.
Si lon essaie detre plus precis, le developpement dapplications embarquees comprend trois
problematiques :
le developpement dapplications natives,
ladaptation dapplications natives `a un environnement embarque,
le portage dune application ecrite pour un OS proprietaire.
Ces trois problematiques constituent les sections du present chapitre.
3.1 Developpement dapplications natives
Dans cette section, nous allons decrire lutilisation des outils de developpement standard sous
langle des developpements embarques.
3.1.1 Le compilateur GCC
GCC est en meme temps le compilateur C et le frontal de toute la suite de compilation. Cest-
`a-dire quil pilote le pre-processeur, le compilateur, lassembleur et lediteur de liens. Lors de la
compilation dun programme pour un environnement embarque, deux types de contraintes peuvent
etre rencontrees.
Contrainte memoire
Il sagit ici de generer des chiers executables qui occupent peu de place sur la memoire de
masse de la plate-forme embarquee. Les moyens daction sont :
Certaines optimisations du code peuvent permettre de generer un code occupant moins despace.
18
Loption de GCC qui permet doptimiser un code pour la taille est loption -Os. Malheureusement,
il est rare de gagner beaucoup de place par cette methode.
Loption -g permet dajouter aux objets generes des symboles de debug. Cette option peut etre
supprimee au cours de la compilation pour generer des executables occupant moins de place. La
commande strip permet aussi de supprimer ces symboles dexecutables et de biblioth`eques apr`es
leur compilation.
Contrainte de performance
Il sagit ici de generer une application qui respecte une certaine contrainte de performance.
Comme pour les contraintes de taille, lon peut agir sur les options doptimisation de code
(loption -O3 de gcc permet de generer du code tr`es optimise), mais comme pour les contraintes
de taille, leet de ces options sont faibles, sauf dans des cas tr`es particuliers.
Lautre option est danalyser les performances du programme `a laide de gprof. An que gprof
fonctionne, le programme (et tous ses composants) `a analyser doit etre compile avec loption -pg.
`
A lexecution dun programme compile avec loption -pg, celui-ci enregistre les temps dexecution
de chacun de ses blocs de base dans un chier, que gprof est ensuite capable danalyser pour
determiner dans quelle partie du programme le temps CPU est consomme.
3.1.2 Liaison statique vs Liaison dynamique
Le developpement dapplication embarquees necessite de minimiser `a la fois la memoire de
masse occupee par les programmes et les biblioth`eques embarques.
Il existe deux types de biblioth`eques, qui apportent deux solutions distinctes au probl`eme de
la contrainte memoire, solutions qui sont applicables dans des cas distincts.
Biblioth`eques statiques
Les biblioth`eques statiques sont un regroupement de modules (au sens unite de compilation
du langage C) sous forme dune archive. Lors de ledition de liens entre cette biblioth`eque et le
reste dune application, les modules qui sont necessaires au fonctionnement de lapplication et
seulement ceux-ci sont inclus dans le binaire resultant.
Lorsquune meme biblioth`eque statique est liee `a plusieurs executables, certaines parties de la
biblioth`eques sont donc incluses dans plusieurs executables.
Biblioth`eques partagees
Les biblioth`eques partagees sont aussi un regroupement de modules, mais contrairement au cas
des biblioth`eques statiques, leur contenu nest jamais inclus dans une application qui les utilise,
les applications generees sont donc de taille inferieure `a celles generees avec une edition de liens
statique, mais lon embarque alors la biblioth`eque toute enti`ere.
19
Quelle solution?
Lorsquune biblioth`eque est relativement imposante et utilise par peu dapplications, il vaut
probablement mieux proceder `a une edition de liens statique.
Loutil libopt (voir [7]) permet de combiner les avantages des deux types dedition de liens
en regenerant des biblioth`eques partagees ne contenant que ceux de leurs composants qui sont
eectivement utilises par un ensemble de chiers executables. Malheureusement, lutilisation de
cet outil induit un co ut de developpement qui nest pas forcement rentable.
3.2 Adaptation dune application native
La problematique est ici dintegrer dans un syst`eme embarque une application qui na pas
ete ecrite pour. Le probl`eme se reduit en fait `a determiner avec le compromis temps/precision
satisfaisant les dependances de lapplication `a embarquer. Suivant loccupation visee, lon peut :
se contenter des dependances par paquet, i.e. embarquer tous les chiers (biblioth`eques par-
tagees, chiers executables, chiers de conguration) du paquet (au sens des chiers .rpm ou
.deb) contenant lapplication `a embarquer et de tous les paquets dont ce paquet depend;
se contenter des dependances par chier, i.e. analyser quels sont exactement les biblioth`eques
partagees et les chiers de conguration dont depend le chier executable que lon veut
embarquer ;
modier les options de compilation oertes par le compilateur ou lauteur de lapplication `a
embarquer an den diminuer la taille ou les dependances ;
en dernier ressort, modier les sources de lapplication.
Pour determiner le contenu dun paquet dune distribution et ses dependances envers dautres
paquets, utilisez votre gestionnaire de paquets (dpkg pour les distributions Debian et rpm pour les
distributions Red Hat).
Loutil qui permet de determiner de quelles biblioth`eques partagees depend un chier executable
est ldd. Par exemple :
# ldd /bin/ls
libc.so.6 => /lib/libc.so.6 (0x40019000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Tous les chiers qui utilisent des biblioth`eques partagees sont lies `a la biblioth`eque partagee
/lib/ld-linux.so.2, cest elle qui permet de charger les autres biblioth`eques partagees. Mais un
programme peut aussi, grace aux appels syst`eme dlopen, dlsym et dlclose, charger et utiliser
une biblioth`eque partagee, sans que celle-ci apparaisse pour autant dans la liste fournie par ldd.
Par exemple :
# ldd /usr/X11R6/bin/XF86_SVGA
libz.so.1 => /usr/lib/libz.so.1 (0x40019000)
libm.so.6 => /lib/libm.so.6 (0x40029000)
libdl.so.2 => /lib/libdl.so.2 (0x40046000)
libc.so.6 => /lib/libc.so.6 (0x4004a000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Ici, le programme /usr/X11R6/bin/XF86_SVGA utilise les appels syst`eme dlopen, dlsym ou
dlclose, car il est lie au chier libdl.so.2. Pour obtenir une photographie des chiers charges
20
dynamiquement `a un moment donne par ce programme, il est possible dutiliser le repertoire /proc.
Par exemple, si le processus 19437 est une instance du programme /usr/X11R6/bin/XF86\_SVGA :
# cat /proc/19437/maps
08048000-082fa000 r-xp 00000000 03:03 209343 /usr/X11R6/bin/XF86_SVGA
082fa000-0833a000 rw-p 002b1000 03:03 209343 /usr/X11R6/bin/XF86_SVGA
0833a000-08761000 rwxp 00000000 00:00 0
40000000-40012000 r-xp 00000000 03:03 163204 /lib/ld-2.1.3.so
40012000-40014000 rw-p 00011000 03:03 163204 /lib/ld-2.1.3.so
40019000-40025000 r-xp 00000000 03:03 241582 /usr/lib/libz.so.1.1.3
40025000-40028000 rw-p 0000b000 03:03 241582 /usr/lib/libz.so.1.1.3
40028000-40029000 rw-p 00000000 00:00 0
40029000-40045000 r-xp 00000000 03:03 163618 /lib/libm-2.1.3.so
40045000-40046000 rw-p 0001b000 03:03 163618 /lib/libm-2.1.3.so
40046000-40048000 r-xp 00000000 03:03 163523 /lib/libdl-2.1.3.so
40048000-4004a000 rw-p 00001000 03:03 163523 /lib/libdl-2.1.3.so
4004a000-4011f000 r-xp 00000000 03:03 163208 /lib/libc-2.1.3.so
4011f000-40123000 rw-p 000d4000 03:03 163208 /lib/libc-2.1.3.so
40123000-40127000 rw-p 00000000 00:00 0
40127000-4012f000 r-xp 00000000 03:03 164078 /lib/libnss_files-2.1.3.so
4012f000-40130000 rw-p 00007000 03:03 164078 /lib/libnss_files-2.1.3.so
40130000-401ab000 r-xp 00000000 03:03 483328 /usr/X11R6/lib/modules/pex5.so
401ab000-401b0000 rw-p 0007a000 03:03 483328 /usr/X11R6/lib/modules/pex5.so
401b0000-40220000 r-xp 00000000 03:03 483321 /usr/X11R6/lib/modules/xie.so
40220000-4022f000 rw-p 0006f000 03:03 483321 /usr/X11R6/lib/modules/xie.so
4022f000-40230000 rw-p 00000000 00:00 0
40230000-40430000 rw-s f4400000 03:03 454556 /dev/mem
40430000-40440000 rw-s 000a0000 03:03 454556 /dev/mem
40440000-40840000 rw-s f5000000 03:03 454556 /dev/mem
40840000-409c1000 rw-p 00000000 00:00 0
bffd9000-c0000000 rwxp fffda000 00:00 0
3.3 Portage dune application ecrite pour un OS proprie-
taire
Le probl`eme du portage dans le cas general est un probl`eme vaste, dont nous ne pretendons pas
aborder tous les aspects dans la presente section. Nous aimerions cependant presenter quelques
questions que doit se poser qui essaie deectuer le portage sous Linux dune applications ecrite
pour un OS proprietaire. Puis nous presenterons un outil qui facilite cette migration.
3.3.1 Temps-reel ?
Certains syst`emes dexploitation dedies aux applications embarquees sont dits temps-reel ou
deterministes, i.e. adaptes `a lecriture dapplications temps-reel. Linux ne fait pas partie de cette
classe de syst`emes dexploitation, notamment `a cause des latences dinterruption quil induit.
Mais lors dun portage, il se peut que le determinisme en lui-meme ne soit pas lobjectif. Dans ce
premier cas, lon peut eectuer le portage en accedant `a lensemble des fonctions de lAPI POSIX
like de Linux, sachant quil est tout de meme possible de reduire les latences dinterruption de
Linux `a laide dun patch du noyau.
21
Si le comportement deterministe est une absolue necessite, il est possible dutiliser RTAI (voir
[8]). RTAI est un ordonnanceur temps-reel dont Linux est la tache de fond. Lutilisation de RTAI
induit une separation claire entre les elements temps-reel (qui utilisent lAPI de RTAI) et les
elements qui ne le sont pas (qui utilisent lAPI de Linux). Cette architecture a lavantage de
permettre lutilisation sans modication des applications Linux dans un syst`eme temps-reel, mais
linconvenient que les applications temps-reel, executees en mode noyau, ne peuvent benecier de
la richesse et de la facilite de debug dun environnement POSIX like.
3.3.2 Portage de premier ordre
Pour un portage de premier ordre, larchitecture de lapplication `a porter sera conservee, en
faisant correspondre une tache de lapplication dorigine `a un processus ou un thread POSIX sous
Linux, en sacriant le determinisme et potentiellement le comportement de lOS dorigine.
Dans le cas o` u lon choisit dutiliser les processi Linux, les appels syst`eme de communication
entre taches de lOS dorigine doivent etre remplaces par les appels syst`eme de communication
inter-processi de Linux. Le choix est alors tr`es large, lon peut utiliser au choix, les pipe, les
socket ou les appels syst`eme System V.
Dans le cas o` u lon choisit dutiliser les threads POSIX (plus legers que les processi en termes
de temps de creation et de vitesse de changement de contexte) les appels syst`eme disponibles et
conseilles sont ceux de lAPI des thread POSIX.
3.3.3 Xenomai
Que lon veuille faire un portage du premier ordre en utilisant les thread POSIX, ou utiliser
lAPI temps-reel de RTAI, le probl`eme reste de remplacer tous les appels syst`eme de lOS dorigine,
par des appels syst`eme ressemblant mais qui nont pas forcement le meme comportement.
Xenomai est un outil qui permet de se liberer de ce probl`eme. Xenomai est base sur un nanoker-
nel qui implemente le comportement dun noyau temps-reel generique en utilisant au choix RTAI,
les threads POSIX ou un simulateur permettant un debogage graphique. Ce nanokernel permet
de reconstruire une version emulee des appels syst`eme dOS temps-reel `a partir des services de
base du nanokernel. Xenomai est fourni avec les emulateurs de certains OS temps-reel proprie-
taires populaires, sachant que lecriture dun nouvel emulateur ou API temps-reel est relativement
simple.
Pour plus de details sur Xenomai, consulter [9].
3.4 Conclusion
Nous avons essaye, dans ce chapitre, de donner des pistes quant aux methodes `a suivre et aux
outils `a utiliser pour mener ecacement `a bien le developpement dune application embarquee. Il
est dicile detre plus precis sans entrer dans les details de telle ou telle application.
`
A ce point, nous supposons que vous avez pu utiliser le syst`eme de chiers partage mis en place
lors des deux premiers chapitres pour developper une application embarquee, comprenant even-
tuellement un module temps-reel. Nous supposons que vous avez teste, optimise cette application
ou son occupation disque.
22
Dans le chapitre suivant, nous allons enn creer les syst`emes de chiers sur la memoire de masse
du syst`eme cible, an de pouvoir le tester en vraie grandeur.
23
Chapitre 4
Finalisation du syst`eme
4.1 Partitionnement du disque ash
Nous allons utiliser le syst`eme de chiers JFFS2 pour le repertoire racine. Dautre part, comme
le syst`eme de chiers JFFS2 est compresse, nous ne pouvons pas stocker le noyau sur le syst`eme
de chiers racine. Nous allons donc creer deux partitions sur le disque ash : une petite partition
utilisant le syst`eme de chiers EXT2 pour stocker le noyau et une partition utilisant le syst`eme
de chiers JFFS2 pour stocker le repertoire racine.
Sur la cible, utiliser cfdisk ou fdisk pour partitionner le disque compact ash.
4.2 Copie des chiers sur le disque ash
4.2.1 Syst`eme de chiers racine
Un syst`eme de chiers JFFS2 est cree `a partir dun repertoire en copiant le contenu de ce
repertoire dans le syst`eme de chiers. Malheureusement, le repertoire ne peut etre le repertoire
racine de la cible, car il comprend, en plus des chiers qui seront presents sur le disque compact
ash, tous les chiers qui sont sous des points de montage, comme /proc et /dev. Nous devons
donc creer limage du syst`eme de chiers JFFS2 sur lhote, puis le copier sur le disque compact
ash.
La creation, sur lhote, de limage du syst`eme de chiers JFFS2, seectue `a laide du programme
mkfs.js2. Une version executable de mkfs.js2 peut etre telechargee `a ladresse [6].
# cd /tftpboot/192.168.0.117
# mkfs.jffs2 -o flash.img -r flash
# mv flash.img flash
Sur la cible, cette image doit etre copiee sur la deuxi`eme partition du disque compact ash, en
tapant :
# dd if=/flash.img of=/dev/mtdblock/0
Le processus peut prendre un peu de temps. Ensuite, pour monter limage JFFS2, taper :
24
# mount -t jffs2 /dev/mtdblock/0 /mnt/flash
L`a encore, le processus peut prendre plusieurs minutes. En outre, un certain nombre de messages
derreur est ache, car limage JFFS2 que nous avons faite na pas la meme taille que le disque.
4.2.2 Syst`eme de chiers damorcage
Le repertoire /tftpboot/192.168.0.117/boot de la machine hote doit contenir les chiers
necessaires `a un demarrage avec LILO, pour cela, taper :
# cd /tftpboot/192.168.0.117/boot
# cp /boot/boot.b .
# cp /usr/src/linux/arch/i386/boot/bzImage .
Sur la machine cible, ce repertoire doit etre monte, en tapant :
# mount -t nfs 192.168.0.61:/tftpboot/192.168.0.117/boot /boot
Sur la machine cible, pour formater, monter la partition /boot et copier les chiers, taper :
# mke2fs /dev/hda1
# mount -t ext2 /dev/hda1 /mnt/flash/boot
# cp /boot/* /mnt/flash/boot/
Enn, pour creer le secteur de demarrage, taper :
# lilo -r /mnt/flash
Pour tester, redemarrer la cible sans disquette Etherboot. Le syst`eme embarque fonctionne.
25
Bibliographie
[1] http://freshmeat.net/projects/etherboot
[2] http://rom-o-matic.net
[3] http://freshmeat.net/projects/busybox
[4] http://freshmeat.net/projects/uclibc
[5] http://sources.redhat.com/newlib
[6] http://sources.redhat.com/jffs2
[7] http://sourceforge.net/projects/libraryopt/
[8] http://www.aero.polimi.it/~rtai/
[9] http://www.xenomai.org/
[10] http://freshmeat.net/projects/e2fsprogs/
26