Travaux Pratiques Syst`emes embarqués ENSPS 3A 1 Introduction

Transcription

Travaux Pratiques Syst`emes embarqués ENSPS 3A 1 Introduction
1
TP ENSPS
Travaux Pratiques Systèmes embarqués
ENSPS 3A
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
Fig. 1 – Carte mère connex (Gumstix Inc).
TP ENSPS
1.2
2
Méthode de compilation croisée (cross-compilation)
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 impossible 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. L’ensemble de la toolchain est accessible sous le
répertoire /usr/local/gumstix-buildroot. Dans ce répertoire, le sous-répertoire build-arm_nofpu
contient tous les utilitaires nécessaires à la compilation croisée.
2
Système d’exploitation
2.1
Examen du contenu du système de fichiers
Démarrer le PC de développement sur la clé USB et connectez vous avec le login root et le mot
de passe ulp. Démarrer le serveur X avec la commande startx. Ouvrir une console. Mettez-vous
dans le répertoire de travail /home/ , seul répertoire sauvegardé lors d’un reboot.
Les fichiers nécessaires à la programmation de la mémoire flash sont les suivants :
– u-boot.bin : permet l’amorçage du système d’exploitation (boot loader).
– rootfs.arm_nofpu.jffs2 : le système de fichier.
– uImage : le noyau linux.
Ces fichiers sont disponibles à la racine du répertoire de la toolchain.
1. Copier ces 3 fichiers à la racine de votre répertoire de travail.
2. Ouvrir le script mount_jffs2.sh avec l’éditeur nedit. Pour comprendre le principe de ce
script, se reporter au pages web contenues dans les bookmarks du navigateur firefox sous la
section ((2.1 Examen du contenu du fs)).
3. Lancer le script.
4. Explorer l’arborescence du système de fichiers stocké dans rootfs.arm_nofpu.jffs2. Notez
la version de la distribution dans le fichier /etc/gumstix-release.
5. Démonter le système de fichier du gumstix en lançant le script umount_jffs2.sh.
2.2
Génération du fichier flash
Pour programmer la mémoire flash du 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. La taille totale de la mémoire flash et donc du fichier flash est de 16 Mo. La taille d’un
bloc de cette mémoire est de 1 Ko. Les données binaires contenues dans le fichier u-boot.bin sont
placées à l’offset 0 du fichier flash. Les données contenues dans rootfs.arm_nofpu.jffs2 sont
placées à l’offset 256 Ko. Enfin, les données contenues dans uImage sont placées à l’offset 15360
Ko.
1. Utiliser la commande dd of=flash bs=1k count=16k if=/dev/zero pour générer un fichier
flash vierge.
2. Utiliser la commande dd of=flash bs=1k conv=notrunc if=u-boot.bin pour y inscrire
les données du bootloader.
3. Suivant le même principe et en rajoutant l’option seek=xxx avec xxx à définir, y écrire le
contenu des 2 derniers fichiers. (Voir le manuel dd dans les bookmarks section 2.2)
2.3
Emulation du système d’exploitation
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.
TP ENSPS
3
1. Lancer la commande qemu-system-arm -M connex -pflash flash -nographic pour démarrer
le système d’exploitation que vous avez ((flashé)). Si le fichier flash a été correctement généré,
le processus de démarrage doit se terminer par un message de type Login:.
2. Ouvrez une session root avec le mot de passe gumstix.
3. Il est possible d’accéder au réseau depuis la machine virtuelle. Connectez-vous à la machine
hôte à l’aide de ssh. Vous pouvez obtenir l’adresse IP de la machine hôte à l’aide de la
commande ifconfig (Usage dans les bookmarks section 2.3).
4. Parcourez l’arborescence du système de fichiers et vérifier que le numéro de version dans le
fichier /etc/gumstix-release.
3
Compilation croisée
3.1
Hello World
1. Ecrire un programme de type Hello World.
2. Tester votre programme sur la machine hôte en utilisant gcc.
3. Compiler ce programme pour le gumstix avec la commande arm-linux-uclibcgnueabi-gcc -O2 -Os
-march=armv5te -mtune=xscale -Wa,-mcpu=xscale -o hello hello.c
4. Télécharger cette commande dans la machine virtuelle à l’aide de scp. (Usage dans les bookmarks section 3.1).
5. Lancer cette commande dans la machine virtuelle.
3.2
Test de la MMU
Le but de cette partie est de tester la présence de la MMU dans la machine virtuelle.
1. Ecrire un programme qui génère un Segmentation fault.
2. Compiler ce programme pour le gumstix et vérifier la présence de la MMU.
3.3
Compilation d’un projet
Dans cette partie, nous allons réaliser une compilation croisée typique d’un programme plus
complet : shed (editeur de fichier sous format binaire et hexa). La compilation de ce projet utilise
les outils GNU autoconf et automake (voir bookmarks) permettant une compilation portable avec
la chaı̂ne de commande classique ./configure, make,make_install.
1. Décompresser l’archive de shed (tar xf shed-1.13.tgz).
2. Consulter la documentation gumstix à l’adresse http://docwiki.gumstix.org/Programming.
(bookmarks section 3.3)
3. Configurer le projet avec l’option prefix pointant vers un répertoire temporaire du \home
et le compiler.
4. Télécharger et tester shed dans la machine virtuelle.
3.4
Compilation d’un module noyau
Il est possible de faire de la compilation croisée de module noyau pour le Gumstix. Le répertoire
/usr/local/gumstix-buildroot contient toutes les sources du noyau linux qui tourne sur le
système gumstix.
1. Aller dans le répertoire hello_module.
2. Compiler le module hello_module.c en lançant la commande make.
3. Télécharger ce module dans la machine virtuelle.
4
TP ENSPS
4. Insérer le module dans le noyau à l’aide de la commande insmod.
5. Retirer le module à l’aide de la commande rmmod.
6. Vérifier l’affichage des messages (une fonction permettant d’afficher les messages de dmesg
dans la console a été activée dans le noyau).
3.5
Erreur d’accès mémoire dans le noyau
Dans cette partie nous allons simuler une erreur d’accès mémoire dans le noyau.
1. Modifier le fichier hello_module.c de manière à faire une écriture à l’adresse virtuelle 0x0
(NULL).
2. Compiler, télécharger et insérer ce module dans la machine virtuelle.
3. Observer le résultat.
3.6
Simulation d’un blocage
Dans cette partie, on simule un blocage du système dû à une erreur de programmation dans
un noyau.
1. Reprogrammer hello_module.c de manière à lancer à l’insertion une boucle while( 1 )
contenant les instructions suivantes :
asm volatile(
"mov
r0,
"mov
r0,
"mov
r0,
"mov
r0,
2.
3.
4.
5.
6.
7.
8.
4
r0\n\t"
r0\n\t"
r0\n\t"
r0" );
Ces 4 instructions en langage machine ARM/Xscale sont l’équivalent d’un ((no-op)), c’est à
dire une opération nulle pour créer artificiellement un délai.
Compiler, télécharger et insérer ce module.
Le système se bloque. Passer en mode moniteur de qemu en pressant [CTRL-a c].
Examiner le contenu des registres avec info registers.
Le registre R15 est le compteur de programme contenant l’adresse virtuelle courante lorsque
l’émulation a été suspendue.
Utiliser la commande x/ pour examiner les octets à partir de l’adresse contenue dans le
registre R15.
Retrouver un séquence cyclique d’octets qui se reproduit 4 fois et qui correspond aux 4
instructions assembleur données plus haut.
Rechercher à l’aide de l’utilitaire shed sur la machine hôte cette même séquence. Attention :
l’ARM est big-endian ou little-endian ? (Le x86 est little-endian.)
Gestion du réseau
1. Consulter la documentation dans la section 4 des bookmarks.
2. Configurer qemu pour accéder au réseau de la machine virtuelle depuis la machine hôte.
Tester son bon fonctionnement en lançant firefox dans la machine hôte avec pour adresse
la machine virtuelle gumstix.
3. Dupliquer le fichier flash de la machine virtuelle. Lancer 2 instances de qemu dont le réseau a
été configuré pour pouvoir communiquer d’une machine virtuelle à l’autre (bridge ou NAT).
Tester le bon fonctionnement en faisant un transfert scp d’une machine à l’autre. Rem1 : il
est possible de spécifier une adresse MAC dans les options de qemu. Rem2 : si la mémoire est
insuffisante, sortir de X windows ou tenter de reduire l’empreinte de qemu.