Travaux Pratiques Syst`emes embarqués ENSPS 3A

TP ENSPS 3A/MASTER
1
Travaux Pratiques Systèmes embarqués
ENSPS 3A et MASTER
Emulation et compilation croisée pour ≪Gumstix≫
1
1.1
Introduction
Gumstix et émulation via qemu
Gumstix est une compagnie qui dessine et vend des PCs miniatures et les extensions associées
pour réaliser des systèmes embarqués. La plateforme matérielle est basée sur une architecture
ARM/Xscale. Toutes les cartes mères sont pré-équipées avec un système d’exploitation linux minimaliste tenant sur environ 8 Mo. Les cartes-mère ont une dimension de 80x20 mm, comparable
à la dimension d’une tablette de chewing-gum (d’où son nom).
Les entrées-sorties sont accessibles au moyen de cartes d’extensions telles que USB, ethernet,
bluetooth, ...
Le tableau suivant donne les principales caractéristiques de la carte-mère.
Processeurr
fréqence
memoire
consommation
alimentation
dimension
poids
PXA255 with Xscale (ARM architecture)
200 ou 400 MHz
16M FLASH et 64M RAM
<250mA (<50 mA en attente d’une entrée)
standard 4.5V ou 5.0V (transformateur, batteries..)
80mm x 20mm x 5.9mm
8g
Figure 1 – Carte mère connex (Gumstix Inc).
TP ENSPS 3A/MASTER
1.2
–
–
–
–
–
1.3
2
Installation de la chaı̂ne de compilation croisée
Utiliser les PCs HP ou le PC Terra avec adaptateur usb→serie.
Se loguer sous Ubuntu en tant que projet et avec le mot de passe habituel.
Decompresser l’archive VERDEX.tgz
Renommer le répertoire créé en VERDEX_ref (histoire de liens symboliques pas sympa).
Descendre dans ce répertoire.
Connexion par Liaison Série
– Connecter le port du milieu de la carte d’extension série du gumstix, sur le câble série du
PC.
– Ne pas connecter l’alimentation, sur la carte série, via la prise mini-jack.
– Utiliser le client kermit pour configurer la liaison série, s’y connecter, alimenter le gumstix, se
loguer en root et attendre. Pour cela se référer au document OE_Setting_up_a_serial.html
(ou en ligne) contenu dans doc_hmtl/serial. Le fichier kermit-setup à utiliser se trouve à
la racine de VERDEX_ref/.
– Une fois logué sur le gumstix, stopper ce linux embarqué avec la commande halt.
– Débrancher délicatement l’alimentation.
– Se déconnecter de la liaison série avec [ctrl-\] suivi de c (sur un clavier français : touches
ctrl+AltGr+8 en même temps puis c ). On se retrouve dans l’interface de kermit, de là on
peut se reconnecter avec connect ou sortir avec exit
1.4
Flasher la mémoire partie 1 : Remplacer l’arborescence de fichiers
Buildroot est un environnement permettant de générer relativement facilement un système
embarqué complet :
– u-boot.bin : permet l’amorçage du système d’exploitation (boot loader).
– rootfs.arm_nofpu.jffs2 : l’image du système de fichiers de type JFFS2, contenant l’arborescence du système Gumstix
– uImage : le noyau linux compressé.
– une chaı̂ne de compilation croisée : un gcc et une libc, qui produisent du code pour ARM.
La nouvelle version de ces fichiers sont disponibles à la racine du répertoire gumstix-buildroot (ont
été obtenus en lançant la commande make de buildroot).
On se propose de les installer sur le gumstix en copiant ces fichiers sur la mémoire Flash du
gumstix via la liaison série et l’utilitaire de boot u-boot :
1. démarrer la liaison série comme précédemment : kermit -l /dev/XXX.
2. la configurer avec c-kermit> take ./kermit-setup et se connecter.
3. se préparer à appuyer sur une touche dans les 2 secondes qui suivent l’alimentation du
Gumstix.
4. brancher le Gumstix et appuyer sur une touche dans les 2 secondes pour obtenir le prompt
de u-boot et empêcher le boot du noyau Linux.
5. une fois devant l’invite GUM>, commencer la procédure avec l’instruction GUM> loadb a2000000,
qui prépare la réception à l’adresse 0xa2000000 d’un fichier. Attention aux nombre de zéros ! !
On recommande de faire un copier coller de cette instruction à partir du document
oe_replace_file_system.html du répertoire doc_hmtl/flashing.
6. suivre les indications du document précédent pour envoyer le nouveau système de fichier en
RAM du gumstix avec kermit.
Note : il faut adapter les noms des fichiers que l’on envoie sur le Gumstix par rapport
à la doc : gumstix oe/.../gumstix-basic-image-gumstix-custom-verdex.jffs2 devient gumstixbuildroot/rootfs.arm nofpu.jffs2.
7. pendant les 8 minutes nécessaires à la copie de l’arborescence de fichiers JFFS2, nous allons
travailler sur un émulateur.
TP ENSPS 3A/MASTER
1.5
3
Emulation du système d’exploitation : création de la Flash
Afin d’accélérer la procédure de développement, le système d’exploitation est émulé au moyen
de l’émulateur multi-plateforme qemu. L’émulation permet d’accélérer les phases de tests et offre
des possibilités intéressantes de déboguage.
Pour émuler le Gumstix VERDEX, il nous faut en premier lieu un fichier image de la mémoire
flash installé sur le gumstix. Il est nécessaire de générer un fichier unique que l’on nommera flash
ayant une structure particulière et contenant les données des 3 fichiers précédents : u-boot, uImage
et rootfs.arm nofpu.jffs2.
1. ouvrir un nouveau terminal.
2. descendre dans le répertoire VERDEX ref/qemu.
3. y copier les 3 fichiers nécessaires à la création de la flash.
4. exécuter le script shell build_qemu_flash.sh soit avec sh build_qemu_flash.sh, soit en
lui donnant le droit d’exécution et .\build_qemu_flash.sh. Celui-ci crée le fichier flash
à partir des 3 fichiers précédents. Note : On regardera l’aide de la seule commande utilisée
dans ce script, dd, pour en comprendre le fonctionnement.
1.6
Emulation du système d’exploitation : Utilisation
Une fois la flash créé, on souhaite démarrer l’émulateur et plus tard y accéder de manière
similaire au système réel via une liaison série émulé. Pour cela :
– ouvrir un nouveau terminal.
– exécuter ./qemu-0.13.0/arm-softmmu/qemu-system-arm -M verdex -pflash flash -nographic
pour démarrer l’émulateur. -M indique la machine à émuler, -pflash le fichier flash à utiliser
et -nographic que le système fonctionne en mode console, sans mode graphique VGA.
– si le fichier flash a été correctement généré, le processus de démarrage doit se terminer par
un message de type Login: au bout de quelques dizaines de secondes.
– ouvrez une session root avec le mot de passe gumstix.
– parcourir un peu l’arborescence de fichier et regarder la version du système/buildroot installé
dans /etc/gumstix-release.
– arrêter le système Linux émulé avec halt
– arrêter l’émulateur avec [ctrl-a] suivi de x.
On souhaite répéter l’opération mais en utilisant kermit pour se connecter au système :
– exécuter ./qemu-0.13.0/arm-softmmu/qemu-system-arm -M verdex -pflash flash
-nographic -serial pty -S pour démarrer l’émulateur. -serial pty indique que l’on
veut rediriger la liaison série vers un pseudo-terminal, -S indique que l’on veut démarre
l’émulateur mais sans démarrer le CPU émulé (le ARM).
Note : il sera peut-être nécessaire de mettre sudo devant la commande pour passer root et
autoriser la création d’un pseudo-terminal.
– au démarrage, qemu vous indique le pseudo-terminal où il connecte la sortie du Gumstix
émulé.
– dans un autre terminal ou de préférence dans un onglet du terminal courant (FILE− >Open
tab), lancer sudo kermit -l /dev/X avec X le pseudo-terminal proposé par qemu.
– configurer kermit avec sa commande take ../kermit-setup puis se connecter.
– Maintenant, nous allons démarrer le cpu/système émulé dans qemu : retourner dans l’autre
onglet/terminal et taper la touche ’c’. Dans le terminal, où tourne kermit, apparaı̂t les
messages de boot du gumstix émulé jusqu’à l’invite de login.
– vous loguer.
– En résumé, nous avons donc :
1. un terminal où tourne l’émulateur et un prompt de commande pour le monitorage de
qemu
2. un terminal avec kermit permettant de communiquer avec le gumstix émulé
TP ENSPS 3A/MASTER
1.7
4
Flasher la mémoire partie 2 : Remplacer le Noyau Linux
– Retourner dans le premier terminal, celui connecté à la liaison série du Gumstix réel.
– Attendre la fin de la copie du système de fichier si ce n’est déjà fini.
– Suivre la procédure du document oe_replace_file_system.html et les explications indiquées dans le document , mais attention à l’instruction suivante :
GUM> protect on 1:0-1
Protect Flash Sectors 0-1 in Bank 1 .. done
qui doit obligatoirement apparaı̂tre avant la commande d’effacement complet
de la mémoire flash CUM> erase all pour protéger les 2 secteurs où est installé
u-boot sous peine de rendre le Gumstix INUTILISABLE.
– A la fin de la procédure, vous loguer sur votre nouveau système Linux gumstix.
1.8
Compilation croisée : échange de fichiers via la liaison série
La mémoire flash embarquée étant de taille très réduite et la puissance du processeur étant
limitée font qu’il est difficile de compiler les applications directement sur le gumstix. On a alors
recours à de la compilation croisée. Une toolchain, c’est à dire tous les exécutables nécessaires à
la compilation, est installée sur une machine de développement puissante. Elle permet de générer
du code objet pour la plateforme cible gumstix. Dans le répertoire buildroot, le sous-répertoire
build-arm_nofpu contient tous les utilitaires nécessaires à la compilation croisée.
La compilation croisée implique donc la possibilité de copier des fichiers et exécutables entre le
PC de développement et le GUMSTIX via la liaison série.
1/Essayons d’abord dans l’émulateur.
1.8.1
GUMSTIX− >PC
– dans le terminal où kermit est connecté au gumstix émulé/qemu, revenir au prompt de
kermit avec [ctrl-\] suivi de c.
– configurer le protocole de transmission pour la liaison série en zmodem :
C-Kermit> set protocol zmodem
C-Kermit> connect
– créer un fichier vide d’un nom quelconque avec la commande touch [filename] dans le
répertoire courant du gumstix émulé.
– envoyer ce fichier avec la commande sz [filename], sz pour send zmodem.
– vérifier que dans le répertoire courant du PC où s’exécute kermit le fichier est présent.
1.8.2
PC− >GUMSTIX
– connecté au gumstix émulé, utiliser la commande rz pour mettre le gumstix émulé en mode
réception d’un fichier.
– revenir au prompt de kermit avec [ctrl-\] suivi de c.
– configurer le protocole de transmission pour la liaison série en zmodem (si ce n’est déjà fait) :
C-Kermit> set protocol zmodem
– envoyer le petit fichier de votre choix en utilisant les commandes cd et send dans kermit.
– se reconnecter au gumstix émulé avec connect
– constater la présence du nouveau fichier dans l’arborescence du gumstix émulé.
2/Reproduire l’opération avec le gumstix réel.
TP ENSPS 3A/MASTER
1.9
5
Compilation croisée : l’exemple du helloworld
On souhaite compiler le classique helloworld en faisant appel à arm-linux-gcc, le crosscompilateur créé par le buildroot. Pour cela un makefile est déjà proposé.
– dans un terminal, se déplacer dans le répertoire VERDEX ref/program exple/Helloworld.
– exécuter make clean pour effacer les anciens fichiers
– compiler
– essayer d’exécuter sur le PC. Résultat ?
– copier cet exécutable par le biais de kermit dans le gumstix émulé et le gumstix réel.
– Exécuter à nouveau.
1.10
Compilation croisée : l’exemple du module noyau helloworld
Il est possible de faire de la compilation croisée de module noyau pour le Gumstix. Le répertoire
/gumstix-buildroot/build armnofpu/ contient tous les sources du noyau linux qui tourne sur le
système gumstix.
1. Aller dans le répertoire program_exple/hello_module.
2. Compiler le module hello_module.c en lançant la commande make.
3. Utiliser l’utilitaire file sur ce fichier pour avoir des détails
4. Télécharger ce module dans la machine virtuelle.
5. Insérer le module dans le noyau à l’aide de la commande insmod.
6. Retirer le module à l’aide de la commande rmmod.
7. Vérifier l’affichage des messages (une option permettant d’afficher les messages de dmesg dans
la console a été activée dans le noyau linux ARM du gumstix, pas besoin de dmesg).
1.11
Simulation d’un blocage
Dans cette partie, on simule un blocage du système dû à une erreur de programmation dans le
noyau dans l’émulateur.
1. Reprogrammer hello_module.c de manière à exécuter à l’insertion une boucle while( 1 )
contenant les instructions suivantes :
asm volatile(
"mov
r0,
"mov
r0,
"mov
r0,
"mov
r0,
r0\n\t"
r0\n\t"
r0\n\t"
r0" );
Ces 4 instructions en langage machine ARM/Xscale sont l’équivalent d’un
dire une opération nulle pour créer artificiellement un délai.
no-op≫, c’est à
≪
2. Compiler, télécharger dans l’émulateur et insérer ce module.
3. Le système se bloque. Passer dans le terminal où s’exécute le moniteur de qemu.
4. Examiner le contenu des registres avec info registers.
5. Le registre R15 est le compteur de programme contenant l’adresse virtuelle courante lorsque
l’émulation a été suspendue.
6. Utiliser la commande x/ pour examiner les octets à partir de l’adresse contenue dans le
registre R15. Cette commande permet d’afficher les octets (ou les instructions) à partir d’une
adresse en mémoire virtuelle (pagination) à l’opposée de xp/ qui utilise des adresses en
mémoire physique. Voir la documentation qemu en ligne ou dans les bookmarks de firefox
pour la syntaxe de x/. .
TP ENSPS 3A/MASTER
6
7. Retrouver la séquence cyclique d’octets qui se reproduit 4 fois et qui correspond aux 4 instructions assembleur données plus haut dans la mémoire de l’émulateur. Rechercher ensuite
à l’aide de l’utilitaire objdump -d sur la machine hôte cette même séquence dans le binaire
du module hello_module.ko. La commande objdump -i vous donne la liste des architectures supportés pour désassembler le code. Si l’architecture arm n’est pas supporté, utiliser
l’exécutable objdump dans le sous-répertoire build-arm_nofpu de la toolchain.