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.