Projet avancé SE 2009
Transcription
Projet avancé SE 2009
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 Portage de Xenomai sur NIOS II 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 Portage de Xenomai sur NIOS II 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 Portage de Xenomai sur NIOS II 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 Portage de Xenomai sur NIOS II 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 Portage de Xenomai sur NIOS II 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 Portage de Xenomai sur NIOS II 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 Portage de Xenomai sur NIOS II $ 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 Portage de Xenomai sur NIOS II 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 Portage de Xenomai sur NIOS II 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 Portage de Xenomai sur NIOS II 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 Portage de Xenomai sur NIOS II 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 Portage de Xenomai sur NIOS II 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 Portage de Xenomai sur NIOS II 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 Portage de Xenomai sur NIOS II 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 Portage de Xenomai sur NIOS II } exit (0); } void got_sigalrm (int sig) { struct itimerspec current; if (timer_gettime(my_timer, ¤t) < 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 Portage de Xenomai sur NIOS II 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 Portage de Xenomai sur NIOS II 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 Portage de Xenomai sur NIOS II 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 Portage de Xenomai sur NIOS II /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 Portage de Xenomai sur NIOS II 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 Portage de Xenomai sur NIOS II 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 Portage de Xenomai sur NIOS II 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 Portage de Xenomai sur NIOS II
Documents pareils
guide d`utilisation de xenomai sur processeur - Enseirb
Le design de référence Quartus II pour Linux embarqué avec ou sans l’extension Temps Réel a été
construit à partir du design standard fourni avec la carte Stratix 1S10 par Altera.
Ce design standar...