Projet avancé SE 2009

Transcription

Filière Electronique
3ère Année SE
Projet Avancé
Portage du noyau temps réel Linux
Xenomai sur le softcore NIOS II
Professeur encadrant :
Élèves :
M. KADIONIK
Azza LOUATI
Raphaël MIRAULT
Simon POLETTE
Vincent BASSI
1
Portage de Xenomai sur NIOS II
2
Table des matières
I- Introduction ............................................................................................................................ 4
II- Xénomai ................................................................................................................................ 6
1) Présentation ....................................................................................................................... 6
2) Structure ............................................................................................................................ 6
3) Étude et mise en œuvre de Xenomai sur processeur x86 ................................................ 8
III- NIOS II............................................................................................................................... 10
1) Présentation ..................................................................................................................... 10
2) Structure .......................................................................................................................... 10
3) Mise en œuvre ................................................................................................................. 10
IV- Portage .............................................................................................................................. 19
1) Méthodologie ................................................................................................................... 19
2) Modification du code ...................................................................................................... 21
3) Ce qu’il reste à faire ........................................................................................................ 22
V- Conclusion .......................................................................................................................... 23
3
I- Introduction
Dans le contexte industriel actuel, la demande en application nomade est en forte
augmentation (- téléphonie mobile, connectivité réseaux depuis un terminal mobile type PDA,
lecteurs de média portables - pour le grand public mais aussi chez les industriels – intégration
d’une caméra embarquée sur un aéronef, carte diagnostique communicante dans l’automobile
…). Les domaines d’applications sont nombreux et plusieurs contraintes apparaissent de
moins en moins négligeables comme la consommation et l’encombrement.
Pourquoi un FPGA ?
La solution la plus optimisée en terme de place, de vitesse et de consommation est la
conception de puce (ASIC) réalisant les fonctionnalités désirées. Seulement, ces puces sont
longues et couteuses à réaliser. Une solution intermédiaire est l’implémentation sur FPGA. Ce
composant est un bon compromis entre le logiciel (programmation haut niveau avec SystemC
par exemple) et le matériel (description au bit près et au cycle près des fonctions). De plus, ce
composant de masse est facile à se procurer, son coût est accessible même pour une PME et
ses paramètres sont connus ou prévisibles (consommation, vitesse, encombrement).
Pourquoi un OS ?
Dès lors que l’on traite des fonctionnalités ayant attrait au réseau, à la vidéo, au son,
au stockage de masse, aux périphériques classiques (USB, série), il devient très vite
intéressant de posséder un système d’exploitation où ces fonctionnalités sont implémentées et
où le bas niveau est masqué. On pourra alors via un système d’exploitation ouvrir une socket
réseau, un port usb ou lire un disque ATA. Sans entrer dans le débat des systèmes
d’exploitation (Windows, Linux, MacOS ? ou même VxWorks, µC/OS-II, QNX, RTOS,
RTAI...), il faut arrêter un choix sur l’OS à embarquer. Dans le cadre de ce projet, nous avons
choisi de travailler sur un noyau uCLinux (principalement du fait qu’il n’y avait pas de
licence à acquérir, le code source est ouvert, la communauté est très présente, sa maniabilité
permet de mettre dans notre carte que ce dont nous avons besoin et surtout qu’il est prévu
pour des processeurs sans MMU).
Comment mettre un OS sur un FPGA ?
Les systèmes d’exploitation fonctionnent de manière séquentielle, typiquement sur un
contrôleur séquencé dans le temps. Or, un FPGA n’est ni plus ni moins qu’un ensemble de
briques matérielles reliées entre elles de manière à réaliser une fonction. Les deux principaux
vendeurs de FPGA (Xillinx et Altera) proposent chacun une configuration de leur FPGA
décrivant un processeur (xBlaze chez Xillinx et NIOSx chez Altera). Ainsi, il est possible
d’assembler les briques matérielles du FPGA de manière à ce qu’il se comporte comme un
microprocesseur. Il est à noter que comme ces processeurs sont décrits logiciellement (on
parle de softcore), ils sont hautement configurables. Nous disposons maintenant d’un
processeur. En y ajoutant de la mémoire, il devient possible de faire tourner un système
d’exploitation. Nous travaillerons sur le NIOS II de chez Altera.
Pourquoi le temps réel ?
Ce terme n’est pas seulement un argument de vente vide de sens. Il ne désigne pas
plus un système rapide (bien que dans la pratique cela soit souvent le cas). Le temps réel fait
appel à deux notions : la prédictibilité et la validité des données. Concrètement, le premier
terme désigne le fait que le système doit être prédictible, c'est-à-dire que l’on doit pouvoir
toujours savoir comment le programme réagit et ce qu’il est en train d’exécuter. Cette
4
condition est nécessaire pour la seconde. Lorsque l’on parle de validité des données, c’est
dans le temps. En effet, on parle d’un système temps réel lorsque l’on peut garantir qu’une
donnée sera valide à une date précise. Concrètement, cela veut dire que le calcul s’effectuera
au maximum en tant de millisecondes après que la demande en ait été effectuée. On peut
facilement imaginer les applications de ce type de système d’exploitation. Par exemple dans
le domaine de l’automobile, si une information de freinage d’urgence arrive, il faut être sûr
que le système n’est pas perdu dans un calcul quelconque (de positionnement satellite par
exemple) et qu’il traitera l’information en une durée maximale.
Dans ce contexte industriel décrit plus haut, plusieurs sociétés et partenaires ont uni
leur expérience et leurs compétences afin de créer RTEL4I : un environnement de
développement permettant de simplifier la migration d'applications embarquées et temps réel
depuis un système d'exploitation embarqué temps réel propriétaire (exemples: VxWorks,
pSOS) vers un environnement Linux. Ce groupe rassemble les sociétés OpenWide[1], Sagem
Communications[2] et Mandriva[3], le laboratoire IMS[4] et l’école d’ingénieur ENSEIRB[5].
Ce projet s’inscrit dans le cadre dur RTEL4I, L’ENSEIRB s’étant vu offrir le lot de portage
sur softcores. L’objectif de ce projet est donc d’implémenter le noyau temps réel Xenomai sur
le processeur softcore NIOS II.
[1]
www.openwide.fr
www.sagem-communications.com
[3]
www.mandriva.com/fr
[4]
www.ims-bordeaux.fr
[5]
www.enseirb.fr
[2]
5
II- Xénomai
1) Présentation
Xenomai est une extension libre du noyau Linux. Ce Framework de développement temps
réel directement intégré dans l’environnement GNU/Linux et coopérant avec le noyau, fourni
un support temps réel dur, non dépendant d’une interface particulière, aux applications en
espace utilisateurs.
Le projet Xenomai a été fondé en 2001, dans le but de créer un système d’émulation de RTOS
traditionnel dans l’environnement GNU/Linux. Entre 2003 et 2005, Xenomai a étroitement
collaboré avec le projet RTAI, afin de construire une plate-forme d’aide au développement
d’applications temps réel de qualité industrielle, fortement intégrée au système Linux.
De cette collaboration naîtra la branche spéciale de développements dite « RTAI/Fusion »,
fondée sur le cœur de technologie du projet Xenomai. Depuis octobre 2005, Xenomai poursuit
seul cet objectif, avec l’aide renouvelée des contributeurs de tous horizons qui ont participé à
cet effort depuis son lancement.
Xenomai a été porté sur plusieurs architectures comme : x86, ARM, blackfin, i386, ia64,
powerpc32, powerpc64…
2) Structure
L'architecture de Xenomai repose un nano-kernel proposant une API générique « neutre »
utilisant les similarités sémantiques entre les différentes API des OS Temps Réel les plus
répandus (fonctions de création et gestion de thread, sémaphores, etc.). (Voir le schéma cidessous)
Figure 1: Architecture de Xenomai
ADEOS est une couche de virtualisation des ressources permettant la cohabitation sur la
même machine physique d'un noyau Linux et d'un système temps-réel.
Il apporte une approche symétrique entre programmation noyau (programmation dans
l’espace noyau) et programmation des applications système au niveau utilisateur
(programmation dans l’espace utilisateur) sous Linux. Ces espaces sont dus au noyau qui
6
implique une partition virtuelle de la mémoire vive physique en deux régions disjointes, l’une
étant réservée au noyau et l’autre aux applications (espace utilisateur).
Xenomai introduit le concept de machine virtuelle (création de plusieurs environnements
d'exécution sur un seul ordinateur) en programmation temps réel et permet ainsi de disposer
de plusieurs interfaces de programmation au choix du programmeur.
Xenomai permet de créer des tâches temps réel dans l’espace utilisateur et non plus
uniquement dans l’espace noyau avec RT linux ou RTAI.
Figure 2: Structure d'Adeos
ADEOS crée alors des entités multiples appelées skins. En première approximation on peut
considérer qu'un skin correspond à un OS (exemple: Linux et un RTOS). Les différents skins
sont concurrents vis à vis des évènements externes comme les interruptions. Ils réagissent en
fonction du niveau de priorité accordé à chacun d'eux.
Xenomai peut donc émuler des interfaces de programmation propriétaires en factorisant de
manière optimale leurs aspects communs fondamentaux, en particulier dans le cas d’OS
Temps Réel spécifiques (ou « maison ») très répandus dans l'industrie.
L’architecture de Xenomai est ainsi constituée d’un ensemble de skins, chacun d’entre eux
permettant d’émuler le comportement d’un OS temps réel en utilisant le coeur de Xenomai.
En plus du Skin native de Xenomai, on trouve des modes de compatibilité pour :
• POSIX (Portable Operating System Interface)
La Skin POSIX, issue du monde Unix, permet de bénéficier des appels classiques comme les
pthread et autres fonctions standard sur les fichiers.
• RTAI (RealTime Application Interface for Linux)
RTAI est une couche Temps Réel de Linux concurrente de Xenomai et originalement une
copie de RTLinux libre et non soumise aux brevets. Son principal problème est d’être peu
portable et généralement maintenu seulement sur les plateformes Intel x86.
• VRTX (Versatile Real-Time Executive)
C’est un système temps réel développé et maintenu par Mentor Graphics. Il est
principalement destiné aux systèmes embarqués et divers « System On Chip ».
• vxWorks
7
Son interface de programmation est très spécifique et le skin Xenomai émule une grande
partie de ses fonctionnalités, bien qu’il y ait des exceptions de comportement bien
déterminées.
Ces divers modes permettent d’utiliser les appels de ces systèmes, avec pour certains, des
contraintes bien spécifiées.
Ces couches permettent de porter des applications sous Linux Temps Réel en utilisant une
base consistante qui est Xenomai.
Concernant le portage d’applications depuis d’autres systèmes d’exploitation temps réel, les
développeurs de Xenomai fournissent une liste d’équivalence entre les fonctions natives et
plus documentées et les fonctions des skins spécifiques.
De plus, Xenomai a été spécifiquement développé pour faciliter le débogage avec GDB et
pour fournir une API en mode utilisateur ayant un temps de latence comparable au mode
noyau. Il est quand même nécessaire de revoir les besoins en temps réels du code avec les
skins, ceci pour améliorer ou mixer avec les appels natifs.
3) Étude et mise en œuvre de Xenomai sur processeur x86
Dans le but de porter Xenomai sur le NiosII, il est judicieux de s'intéresser dans un
premier temps à l'installation de Xenomai sur un PC x86.
Téléchargement des sources :
Il faut télécharger sources de Xenomai, disponibles sur le site
http://download.gna.org/xenomai
Télécharger également les sources du noyau Linux officiel sur http://ftp.kernel.org
Dans cet exemple nous avons utilisé la version 2.6.26.7.
Il faut créer un répertoire dans /usr/src/kernels qui contiendra les sources du noyau que nous
venons de télécharger.
Exemple :
$ mkdir /usr/src/kernels/linux-2.6.26.7-xenomai
Préparation des sources du noyau :
C'est à ce stade que nous allons patcher le noyau Linux grâce au script fourni avec les sources
de Xenomai :
$ scripts/prepare-kernel.sh --linux=<linux-srctree>
[--adeos=<adeos-patch>] [--arch=<targetarch>]
L'option --linux permet de renseigner le dossier contenant les sources que nous voulons
patcher.
L'option --adeos permet de renseigner l'architecture cible (i386 par défaut)
L'option --arch permet de renseigner quel patch adeos appliquer (adeos-ipipe-2.6.26.7-x862.0-16.patch par défaut)
Appliquons le patch à notre exemple :
8
$ scripts/prepare-kernel.sh –linux=/usr/src/kernels/linux2.6.26.7-xenomai/
Target architecture [default i686]: i386
Adeos patch [default /home/se01/Bureau/simon/xenomai2.4.6.1/ksrc/arch/x86/patches/adeos-ipipe-2.6.26.7-x86-2.016.patch]:
Maintenant que le noyau Linux a été préparé, nous pouvons procéder à la compilation
Compilation du noyau :
Configuration du noyau :
$ make menuconfig
(Remarque : Il est possible d'utiliser 'make xconfig' plutôt que 'make menuconfig' pour obtenir
une interface graphique permettant de configurer les options du noyau)
Figure 3: make menuconfig
Les options propres à Xenomai se trouvent dans 'Real-time sub-system'
Remarque : Pour une installation sur processeur x86, il est recommandé de :
 Désactiver APM
 Désactiver CPU_FREQ
Dans Power Management Options
Compilation :
$ make
$ make modules_install install
9
III- NIOS II
1) Présentation
Le Nios II est processeur softcore sans MMU. Il est développé par Altera, fabricant de
FPGA (Field-programmable gate array).
Comme les processeurs généraux, le Nios II est un processeur RISC de 32-bits.
L'architecture prend en charge les instructions et les données distinctes, il est basé sur
une architecture de Harvard.
Figure 4: Architecture du NIOS II
2) Structure
Les périphériques suivants peuvent être ajoutés à la demande :
 Bus Avalon
 JTAG
 UART
 Mémoire
Figure 5: Bus Avalon et périphériques associés
3) Mise en œuvre
Sa mise en œuvre est simplifiée grâce à Quartus et NIOS IDE.
Pour s’initier à l’utilisation du NIOS II, on peut suivre le tutoriel d’Altera
Lancement de Quartus II.
Ouvrir le projet ‘’.qpf’’
10
Dans Tools->SOPC Builder
Figure 6: SOPC Builder d'Altera
Comme vu sur le wiki de nios pour la gestion d’Ethernet il faut changer ne niveau de l’IRQ
pour qu’elle soit prise en compte. Donc mettre la valeur a 6 de l’IRQ et vérifier que l’adresse
de base est bien à 0x00800000 voir image suivant :
Figure 7: Instanciation des périphériques
Génération du .ptf :
11
C’est la description matérielle que l’on a construit avec SOPC builder. Il nous permet de faire
la relation entre hardware et software.
Figure 8: Génération du .ptf
Compilation et synthèse :
Cette étape permet de synthétiser, optimiser et créer le .sof qui est la configuration matérielle
du FPGA.
Figure 9: Synthèse du NIOS
Chargement dans la carte du .sof par le jtag.
Il faut aller chercher le .sof généré par Quartus
12
3
2
1
Figure 10: Chargement du NIOS sur la cible
Compilation du noyau :
Tout d'abord, on doit convertir le .ptf en .h pour que la compilation du noyau l’inclue dans ses
sources.
./gohwselect :
--- Please select which CPU you wish to build the kernel against:
(1) cpu - Class: altera_nios2 Type: s Version: 6.0
Selection: 1
--- Please select a device to execute kernel from:
(1) ext_flash
Class: altera_avalon_cfi_flash
Size: 8388608 bytes
(2) onchip_ram_64_kbytes
Class: altera_avalon_onchip_memory2
Size: 65536 bytes
(3) ext_ram
Class: altera_nios_dev_kit_stratix_edition_sram2
Size: 1048576 bytes
(4) sdram
Class: altera_avalon_new_sdram_controller
Size: 16777216 bytes
Sélection : 4
Pour lancer un scripte au démarrage a ajouter dans le rc pour configurer automatiquement la
connexion Ethernet.
/home/nios/uClinux-dist/vendors/Altera/nios2/rc
hostname uClinux
13
mount -t proc proc /proc
mount -t sysfs sysfs /sys
mount -t usbfs none /proc/bus/usb
mkdir /var/tmp
mkdir /var/log
mkdir /var/run
mkdir /var/lock
mkdir /var/empty
ifconfig lo 127.0.0.1
route add -net 127.0.0.0 netmask 255.0.0.0 lo
# dhcpcd -p -a eth0 &
cat /etc/motd
ifconfig eth0 hw ether 00:00:00:00:00:01
ifconfig eth0 192.168.4.221
Configuration du kernel :
Make xconfig
Vendor vérifié que nios2 est bien choisit :
Figure 11: Configuration du noyau
Ajout de busybox pour avoir les commandes de basse d’un terminal, et les autres commandes
à sélectionner pour nos tests:
14
Figure 12: Ajout de Busybox
chmod, ifconfig, ping, route wget pour pouvoir charger le programme de teste sur la carte
cible.
Ensuite, fermer et enregistrer la configuration, puis faire un make, ce qui va créer au final le
zImage.
[nios@linux01 images]$ pwd
/home/nios/uClinux-dist/images
[nios@linux01 images]$ ls -l
total 1292
-rw-rw-r-- 1 nios nios 2208 2009-01-16 11:46 romfs-inst.log
-rwxrwxr-x 1 nios nios 1311278 2009-01-16 11:46 zImage
Chargement du noyau .zImage lancé SOPC builder et entrer ./go.
Figure 13: Chargement du noyau sur la carte
Après avoir chargé le zImage sur la cible il se décompresse automatiquement pour lancer le
noyau uClinux.
Et on peut communiquer avec la carte cible grâce à minicom, tout comme telnet ou d’autres
logiciels de communication qui prennent en charge les communications séries.
On retrouve donc sur la cible un terminal où l’on peut exécuter librement les commandes de
base de linux et celle dont on avait choisi avec le make xconfig.
Figure 14: Interface de communication avec uCLinux
15
Au chargement du kernel on obtient ceci :
Figure 15: Démarrage du noyau
Récupération du programme de test faisant appel a la norme POSIX pour les niveaux des
threads créés et des contraintes temporelles.
Programme de teste :
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <signal.h>
//#include <sys/io.h>
timer_t my_timer;
struct itimerspec new, old;
int nibl=0x01;
int loop_prt = 100;
int test_loops = 0;
/* print every 100 loops: 5 s */
/* outer loop count */
short *led=(short *) 0x00810880;
int sens=0;
char tmp=0xFF;
int tempo;
void got_sigint (int sig)
{
printf ("Got SIGINT\n");
if (timer_delete (my_timer) < 0) {
perror ("timer_delete");
exit (1);
16
}
exit (0);
}
void got_sigalrm (int sig)
{
struct itimerspec current;
if (timer_gettime(my_timer, &current) < 0) {
perror ("timer_gettime");
exit (1);
}
printf("%d\n",tmp);
*led=tmp;
tmp=~tmp;
test_loops++;
if ((test_loops % loop_prt) == 0)
printf ("Loop= %d t= %ld %ld\n", test_loops, current.it_value.tv_sec,
current.it_value.tv_nsec);
}
main (int argc, char *argv[])
{
signal (SIGALRM, got_sigalrm);
signal (SIGINT, got_sigint);
if (timer_create (CLOCK_REALTIME, NULL, &my_timer) < 0) {
perror ("timer_create");
exit (1);
}
new.it_value.tv_sec = 0;
new.it_value.tv_nsec = 5000000LL;
new.it_interval.tv_sec = 0;
new.it_interval.tv_nsec = 5000000LL;
if (timer_settime (my_timer, 0, &new, &old) < 0) {
perror ("timer_settime");
exit (1);
}
while (1)
pause ();
}
On charge le programme grâce à la connexion Ethernet.
/> cd /home
/home> ls
ftp httpd
/home> mkdir test
/home> cd test
/home/test> ls
/home/test>
/home/test> wget http://192.168.4.201/rt ./
Connecting to 192.168.4.201 (192.168.4.201:80)
rt
100% |*******************************| 110k --:--:-- ETA
/home/test> chmod 777 ./rt
/home/test>
17
Visualisation de la gigue avec l’oscilloscope : on voir très bien que la contrainte de temps des
5ms n’est pas bien respectée donc dans une application temps réel on ne répond pas a la
contrainte.
Figure 16: gigue avec uClinux sans patche
18
IV- Portage
1) Méthodologie
Le noyau Xenomai est construit par l’application d’un patch sur un noyau standard. Ce
patch est différent suivant les architectures cibles. Afin de connaître les fichier impactés par
ce patch, nous avons d’abord contacté l’auteur qui nous a conseiller de nous pencher sur les
cibles ARM et powerpc.
Une fois les différents patches appliqués (sur le noyau standard pour l’ARM et sur le noyau
DENX pour le powerpc), nous avons pu comparer un noyau standard et un noyau patché.
Cette comparaison a été automatisée grâce au script suivant qui utilise la fonction DIFF de
GNU Tools.
#!/bin/sh
fic="/usr/src/kernels/comparaison.txt"
for x in $(ls -R) ; do
if (echo $x | grep -E "/" > /dev/null);
then
rep=$(echo ${x:1})
rep=$(echo ${rep%%:*})
echo $rep
else
if (echo $x | grep ".c$" > /dev/null);
then
if test -f $1$rep/$x ;
then
echo $rep/$x >> $fic
diff $(pwd)$rep/$x $1$rep/$x >> $fic
else
echo $1$rep/$x "fichier inexistant" >> $fic
fi
fi
fi
done
On extrait des fichiers de sortie le nom des fichiers impactés par le patch. Cela donne une fois
synthétisé:
19
Noyau linux standard 2.6.26.7 patché pour arm - Liste des fichiers modifiés par le patch
 /arch/nios/*
 /arch/arm/kernel/fcse.c
 /arch/arm/kernel/ipipe.c
 /arch/arm/kernel/irq.c
 /arch/arm/kernel/process.c
 /arch/arm/kernel/ptrace.c
 /arch/arm/kernel/smp.c
 /arch/arm/kernel/sys_arm.c
 /arch/arm/kernel/traps.c
 /arch/arm/mm/alignment.c
 /arch/arm/mm/context.c
 /arch/arm/mm/copypage-v4mc.c
 /arch/arm/mm/copypage-xscale.c
 /arch/arm/mm/context.c
 /arch/arm/mm/flush.c
 /arch/arm/mm/pgd.c
 /arch/arm/vfp/vfpmodule.c
 /arch/arm/xenomai/hal.c
 /drivers/pci/htirq.c
 /drivers/serial/8250.c
 /drivers/xenomai/*
 /include/asm-nios/*
 /include/xenomai/*
 /init/main.c
 /kernel/exit.c
 /kernel/lockdep.c
 /kernel/panic.c
 /kernel/printk.c
 /kernel/sched.c
 /kernel/signal.c
 /kernel/spinlock.c
 /kernel/timer.c
 /kernel/ipipe/*
 /kernel/irq/chip.c
 /kernel/irq/handle.c
 /kernel/power/disk.c
 /kernel/time/tick-common.c
 /kernel/time/tick-sched.c
 /kernel/xenomai/*
 /lib/bust_spinlocks.c
 /lib/ioremap.c
 /lib/smp_processor_id.c
 /lib/spinlock_debug.c
 /mm/memory.c
20
 /mm/mlock.c
 /mm/vmalloc.c
Noyau linux Denx 2.4 patché pour ppc - Liste des fichiers modifiés par le patch
 /arch/nios/*
 /arch/ppc/kernel/idle.c
 /arch/ppc/kernel/ipipe-core.c
 /arch/ppc/kernel/ipipe-root.c
 /arch/ppc/kernel/irq.c
 /arch/ppc/kernel/ppc_ksyms.c
 /arch/ppc/kernel/traps.c
 /arch/ppc/mm/fault.c
 /arch/ppc/xenomai/hal.c
 /drivers/xenomai/*
 /include/asm-nios/*
 /include/xenomai/*
 /init/main.c
 /kernel/exit.c
 /kernel/fork.c
 /kernel/printk.c
 /kernel/signal.c
 /kernel/sched.c
 /kernel/ipipe/*
 /kernel/xenomai/*
On distingue trois catégories de fichiers:
 Les fichiers propres à Xenomai (/kernel/xenomai/* par exemple)
 Les fichiers du noyau communs à toutes les architectures (/kernel/sched.c par
exemple)
 Les fichiers propres à l'architecture cible (/arch/arm/traps.c par exemple)
2) Modification du code
Étant donné que nous travaillons avec uCLinux, le noyau le plus proche est le vanilla kernel
patché pour ARM. Les modifications qui seront faites sur uCLinux seront donc inspirées par
le noyau patché pour cette architecture. Le point de départ est un noyau uCLinux standard 2.6
que l'on enrichira de nos modifications.
Nous avons dans un premier temps ajouté les fichiers propres à Xenomai. Il s'agit en fait de
liens symboliques pointant vers le dossier contenant le patch Xenomai.
Nous avons ensuite modifié les fichiers du noyau communs à toutes les architectures. Ce
travail a été effectué avec l'outil graphique de comparaison de fichiers Meld. Il permet de faire
la comparaison entre trois fichiers: un fichier issu d'un noyau non patché, ce même fichier issu
du noyau patché et enfin le même fichier issu de uCLinux. Comme le noyau standard et
21
uCLinux sont différents, la comparaison avec un noyau non patché permet de savoir si les
différences proviennent bien du patch.
Figure 17: Exemple d'utilisation de Meld
Pour les fichiers ayant attrait à l’architecture, nous avons repris ceux présents dans le noyau
uCLinux. En effet, l'architecture NIOS n'existe pas pour un noyau standard. Cependant, ces
fichiers n’ont pas pu être entièrement traités.
3) Ce qu’il reste à faire
Faute de temps, les fichiers spécifiques à l'architecture du NIOS n'ont pas pu être traités. Il
faut donc modifier les fichiers contenus dans le répertoire /arch/nios2nommu. On pourra pour
cela s'inspirer des fichiers patchés pour une architecture Blackfin dont le portage de Xenomai
a été réalisé sur uCLinux.
Une fois les fichiers modifiés et le noyau correctement compilé, il faut tester le bon
déroulement du système d'exploitation puis vérifier que les temps de latence sont bien bornés.
Pour cela on pourra utiliser le programme d'écriture sur les leds mais cette fois parallèlement
à un script qui permet de "stresser" le processeur:
#!/bin/sh
22
while [ 1 ]
do
echo "Creating file..."
dd if=/dev/zero of=foo bs=1M count=50
sync
echo "Removing file..."
rm -f foo
sync
done
(script proposé par P. Ficheux)
V- Conclusion
Avec la demande croissante de systèmes embarqués, il faut faire face à des problèmes
d’encombrement et de connectivité. Le fait de pouvoir implémenter un processeur sur un
FPGA permet un gain de place et une meilleure interaction entre l’exécution des programmes
et l’accélération matérielle. L’ajout d’un système d’exploitation permet de s’abstraire des
couches matérielles et de piloter les périphériques logiciellement. Le temps réel permet de
garantir des temps de traitement. Tous ces paramètres convergent vers un système
d’exploitation temps réel implémenté dans un FPGA.
23
VI] Bibliographie
www.altera.com
www.nioswiki.com
www.uclinux.org
www.xenomai.org
http://home.gna.org/adeos/index.fr.html
www.enseirb.fr/~kadionik
http://pficheux.free.fr
Linux Embarqué P.Ficheux (Eyrolles 2005)
24

Projet avancé SE 2009

Transcription

Documents pareils

CV Expert Linux embarqué

guide d`utilisation de xenomai sur processeur - Enseirb

Télécharger programme en format pdf

BNPSI porté par la crise

CV Version PDF - Na

logiciel libre - Open Wide Ingénierie

Description du poste - Ingénieur Linux Embarqué

Le noyau Linux - Stéphane Gill

Fiche produit Chaise Loom Marco