Ajout du support du MicroBlaze dans DNA-OS Stage d excellence Juin-Juillet Guiroux Hugo Laboratoire SLS - TIMA

Transcription

1 Ajout du support du MicroBlaze dans DNA-OS Stage d excellence Juin-Juillet 2012 Guiroux Hugo Laboratoire SLS - TIMA 24 juillet 2012

2 Table des matières 1 Introduction 3 2 Présentation Précédents travaux Apes : Application Elements for SoCs DNA-OS : Système d exploitation soft-core Processeur Xilinx MicroBlaze Plateforme FPGA Virtex Travaux Description du HAL Validation de l implantation État des lieux et objectifs Mono-processeur Simulation QEmu FPGA : premier acte Multiprocesseurs FPGA : le retour Validation et problèmes Conclusion 11 Bibliographie 11 A Patch GDB 12 B Chaine compilation Apes 13 C Composant Apes 14 D Modules 15 1

3 Remerciements Je souhaite tout d abord remercier Nicolas Fournel, mon tuteur, pour m avoir accepté en tant que stagiaire et m avoir entrouvert les portes du domaine de la recherche. Son sujet m a permis d apprendre énormément tout au long de ces deux mois et d acquérir des connaissances et des compétences qui me serviront tout le long de mes études. Je remercie Frédéric Pétrot pour m avoir accueilli dans son laboratoire ainsi que Olivier Muller pour ses multiples explications et aides précieuses. Un remerciement au DLST de l UJF qui m a donné la possibilité de faire ce stage d excellence. Enfin je remercie toute l équipe SLS, pour m avoir accueilli et permis de passer un agréable stage ainsi que de bons moments de convivialité. 2

4 Chapitre 1 Introduction L informatique embarquée est de plus en plus présente dans notre vie quotidienne. Que ce soit dans nos smart-phones, nos tablettes ou encore nos voitures. Elle est aussi utilisée dans le monde industriel, dans des domaines tels que l aviation, les satellites, les centrales nucléaires, etc. Selon la loi de Moore, le nombre de transistors sur un circuit double tous les deux ans. Ce qui permet de multiplier la puissance ainsi que le nombre de processeurs disponibles à un coût constant. La multiplication de ces processeurs impose la création de nouveaux outils autant matériels que logiciels afin de s adapter aux ressources disponibles. Le laboratoire SLS s applique à la création de ces outils logiciels dans le but de créer et de simuler ces systèmes multiprocesseurs sur circuit (ou MpSoc). Durant ces deux mois de stage j ai eu l occasion de travailler sur DNA-OS, un système d exploitation léger conçu pour les MpSoc, notamment sur l ajout d un modèle de processeur en particulier : le MicroBlaze de Xilinx. L idée était d ajouter le support de ce type de processeur à cet OS tout en proposant une méthode de validation du travail de manière rétroactive, permettant d être certain de la justesse du travail. Dans une première partie je présenterai certains travaux antérieurs, l OS en particulier et le Microblaze. Je parlerai aussi de la plateforme matérielle ayant servi aux différents tests. Je parlerai ensuite de mon avancées et du travail effectué via le logiciel de simulation QEmu puis sur la plateforme matérielle. 3

5 Chapitre 2 Présentation 2.1 Précédents travaux Je ne suis pas le premier à travailler sur l implantation du MicroBlaze dans DNA-OS. En effet, Xavier Guerrin, l auteur initial de DNA, a proposé une implantation du HAL pour la version 8.1 du processeur [?]. Cette version a semble t-il été utilisée comme base par deux autres stagiaires (Mingault et Nesta[?]). Ce travail sur le portage du HAL est à ce jour le plus avancé. C est sur ce dernier que je me suis basé. Le contenu de ce travail sera décrit plus tard. Il est à noter que l idée derrière ce travail est de proposer un système de validation de l implantation via une application lançant des tests (unitaires ou non) pour ce HAL. Enfin concernant le support de la plateforme, Eynard Charles a mis à disposition le code pour les différents composants et drivers. Bien que ce travail soit assez avancé, j ai pu rencontrer quelques soucis dans ce que proposait mes prédécesseurs et qu il m a fallu corriger. Il restait encore plusieurs aspects à traiter (évoqués plus bas) ainsi que différents composants à intégrer. 2.2 Apes : Application Elements for SoCs APES (Application Elements for SoCs) est un framework logiciel pensé pour faciliter le développement d applications visant les MpSoCs (multi-processors system on chip). Il est utilisé ici comme base pour développer les différents composants : l OS, la gestion de la mémoire, les drivers de la plateforme, le HAL (hardware abstraction layer) du MicroBlaze ainsi que différents autres composants (C) (liste des composants disponibles [?]). Différents HAL sont déjà proposés : celui de l ARM ou du MIPS par exemple. Le framework est flexible et met à disposition différents outils pour accélérer le développement (B). Il gère seul les dépendances, permettant ainsi de se concentrer sur l essentiel. 4

6 2.3 DNA-OS : Système d exploitation soft-core DNA-OS est un système d exploitation léger, rapide, créé pour des systèmes MpSoC. Il est un composant à part entière d APES et est basé sur un HAL simplifié, permettant le portage vers différentes plateformes et processeurs faciles. Il ne contient que le strict minimum, avec notamment un ordonnanceur et un support natif des threads POSIX. Les processus sont lancés en mode noyau, et il n y a pas de support de mémoire virtuelle. L OS est en fait séparé en plusieurs composants distincts : Le Core : contenant l ordonnanceur, les threads, de mutex/semaphores, de la communication inter-processeur. La Gestion Mémoire : de type WorstFit. Son rôle étant de garder une cohérence dans les zones attribuées aux différents threads ; ainsi que l allocation et la libération de l espace. Le Système de Fichiers Virtuels : se basant sur la FHS (Filesystem Hierarchy Standard). Permet un accès propre à certains périphériques (tty par exemple) ainsi que potentiellement à un espace disque. Les Outils : proposent quelques fonctions utilisées par le Core telles que la gestion de queue, des chaînes, de logging, etc. La Plateforme : ici un FPGA de Xilinx, mais peut très bien être une plateforme SocLib, Atmel,... Le HAL : différents sont déjà disponibles (ARM, Mips, Nios entre autres). Ici le travail est d adapter le MicroBlaze de Xilinx. D autres composants : de part la flexibilité d APES, d autres composants peuvent être ajoutés : drivers Ethernet, FrameBuffer, etc. 5

7 2.4 Processeur Xilinx MicroBlaze Le MicroBlaze[?] est un processeur soft-core (processeur implémenté sur un FPGA) 32 bits, à jeu d instructions RISC basé sur une architecture Harvard conçu par la société Xilinx. Il est hautement configurable avec pas moins de 70 options permettant de spécifier entre autre le niveau de pipeline, l utilisation d une FPU, d un barrel shifter, d un cache ou encore d une logique de débug. Sa principale utilisation se trouve dans les FPGA (field programmable gate array), permettant la conception de système correspondant aux besoins de l utilisateur, notamment lors de la phase de conception. Le processeur utilisé ici est la version Cette version pouvant atteindre une fréquence de 210 MhZ. Plusieurs OS supportent ce type de processeur, comme le noyau Linux, Xilinx MicroKernel, uclinux (linux pour micro-contrôleurs), FreeRTOS (système en temps réel). 2.5 Plateforme FPGA Virtex-5 Le MicroBlaze n est pas dissociable du FPGA (field programmable gate array). C est un circuit logique dont le principal intérêt est de pouvoir être reprogrammé après sa fabrication. Il est composé de blocs logiques contenants principalement une table de correspondances (LUT). Il s agit d une table servant à implanter des fonctions logiques booléennes à plusieurs entrées et donnant un résultat en sortie. Cela permet une grande souplesse et permet d adapter le matériel à un algorithme particulier lui permettant de s exécuter dans un temps plus court. Les FPGA sont généralement contenus sur des cartes regroupant plusieurs composants divers. Une carte Xupv5-LX110t de Xilinx était à ma disposition avec un port Ethernet, un port serial, un port dvi/vga, des LED, switchs et boutons push, un mémoire SRAM, DDR2,... [?] Le FPGA est entièrement programmable grace à la suite d outils proposée par Xilinx nommée EDK (Embedded Development Kit). 6

8 Chapitre 3 Travaux 3.1 Description du HAL Mon travail est la continuité du travail précédent[?]. L idée, en plus de l implantation du HAL pour le MicroBlaze, était de proposer une suite de tests unitaires et d intégrations pour valider le code. Le travail est divisé en huit parties : Alimentation : En réalité, le MicroBlaze n a pas d instruction pour la gestion d alimentation. Timer : Un composant du FPGA permet de configurer des horloges nécessaires à l ordonnanceur. Contextes : Il est nécessaire de faire une gestion du contexte d exécution (registres) lors d un changement de thread ou de son initialisation. Interruptions : Différents composants (timers, uart, mailbox) avertissent le processeur de leur activité en envoyant des interruptions à ce dernier, exécutant un code approprié pour les traiter. Dans certaines parties critiques du noyau, aucune interruption ne doit être traitée pour éviter des comportements non désirés. Synchronisation : Dans un environnement multiprocesseurs, certaines ressources peuvent être accédées en même temps (typiquement de la mémoire). Il faut alors mettre en place des mécanismes de protections et de synchronisations (appelés Sémaphores) permettant d assurer l intégrité de ces ressources. Multiprocesseur : Toujours dans un environnement multiprocesseurs, ces derniers ont besoin de communiquer entre-eux. Le cas typique est lorsque le thread contenant l ordonnanceur décide de demander à un autre processeur d exécuter une tâche. Cache : Le MicroBlaze intègre un système de cache d instructions ainsi qu un cache de données. Ce dernier permet d améliorer les performances en réduisant le nombre d accès à la mémoire, moins rapide. Intégration : Cette partie contient principalement des tests faisant tourner des mini-applications utilisant toutes les parties du HAL. 7

9 3.2 Validation de l implantation Comme dit précédemment, en plus de l implantation du HAL, le but était aussi de le valider. Pour cela chaque partie énoncée au-dessus a bénéficié d un certain nombre de tests unitaires, chacun étant décrit dans les sources en commentaires. De plus, deux tests globaux ont été ajoutés : un test pour l ordonnanceur, appelant toutes les parties du HAL, et le célèbre test du dîner des philosophes[?], proposé par Dijkstra en État des lieux et objectifs Bien que le travail ait été bien avancé, il manquait tout ce qui concernait la synchronisation, le multiprocesseurs et le cache. Ce sur quoi je me suis interessé. L ajout d autres tests pour les timers, les contextes et les interruptions ont permis de mettre à jour des soucis que mes prédécesseurs n avaient pas observé. Enfin la réécriture d un léger framework pour les tests a été faite. Concernant les différentes plateformes ayant servi, il a fallu adapter le ldscript (fichier décrivant le mappage mémoire dans l application) à chaque cas. Enfin différents fichiers d automatisation et de configuration ont été créés, notamment avec l EDK de Xilinx. 8

10 3.4 Mono-processeur Simulation QEmu Avant de commencer à travailler sur une carte FPGA directement, la machine virtuelle QEmu a été utilisée. QEmu est un logiciel qui permet d exécuter des systèmes d exploitations sur un autre système déjà installé sur la machine hôte. Elle permet d émuler un certain type de matériel et de faire croire au système virtualisé qu il tourne sur une configuration spéciale. Les systèmes d - exploitations tournant sous QEmu n ont donc pas conscience d être virtualisés. Cela permet d éviter d adapter un système à QEmu. Le matériel simulé ici correspond à une carte Spartan 3a dsp. Les parties timer, contexte, cache et interruptions ont été développées, testées et validées sous QEmu. Le principal avantage étant la vitesse de lancement, le plus long étant la compilation du binaire final. Aucun problème particulier n a été remarqué dans l implantation de cette plateforme dans QEmu. La seule astuce utilisée était au niveau du timer : QEmu ne stop pas le timer une fois désactivé, il faut lui mettre un timeout de zéro FPGA : premier acte Une fois les tests sous QEmu validés, l utilisation de la carte XupV5 de Xilinx s est imposée. La configuration de cette carte s est faite via le XPS. Les composants ajoutés sont : Un Processeur MicroBlaze Une BRAM Un contrôleur d interruptions Un timer Un UART pour le port serial Une SRAM de 1MO Un composant pour le débogueur La lecture des informations se fait via le port serial. Un module (mdm) permet de déboguer la plateforme via le logiciel XDM qui permet de lancer un serveur gdb sur chaque processeur. Différents scripts ont été développés pour permettre facilement d initialiser la plateforme avec le binaire. Des modifications à GDB ont aussi étaient apportées pour l utilisation avec ce type de plateforme (A). 9

11 3.5 Multiprocesseurs FPGA : le retour Après quelques recherches, il apparait qu il n existe pas de solution logicielle pour simuler une plateforme multi-microblaze. L utilisation de la carte a donc été immédiate. Concernant la partie matérielle, les principaux changements sont l emploi d un composant appelé MailBox. Il permet la communication inter-processeur, primordiale pour un système comme DNA. Le second changement a été l utilisation du composant DRAM-DDR2. En effet, il était beaucoup plus simple d utiliser ce composant conçu pour un accès multiprocesseurs à la mémoire alors que le composant SRAM ne l était pas et aurait imposé de nombreuses configurations hasardeuses. Il a fallu modifier certaines options dans la configuration de base qui ne correspondait pas exactement à la XupV5. 1 Les parties synchronisation et multiprocesseur ont été ajoutées. Les tests ont été aussi ajoutés. On peut considérer que l implantation du HAL est complète, même si plusieurs problèmes restent à régler. Ils sont énoncés plus bas. Une astuce à noter est l utilisation des registres spéciaux PVR* dont un permet de rentrer une valeur lors de la configuration de la plateforme. Il est utilisé pour connaître l ID du processeur (il doit être différent pour chaque MicroBlaze et commence à 0). 3.6 Validation et problèmes Après avoir lancé de nombreux tests unitaires il est apparu plusieurs problèmes qui restent à corriger : Fin thread sur multiprocesseurs : Il semble que le code généré par GCC ne soit pas correct concernant l argument d une certaine fonction. Au moment où un thread a fini d être exécuté sur un processeur autre que le principal, lorsqu il est censé être réordonnancé pour lancer le thread idle, la fonction scheduler_dispatch appelée dans thread_exit ne prend pas bien l argument thread. Ce qui fait que le processeur part dans les limbes de la mémoire. Cohérence de cache : Après quelques recherches, il a été surprenant d apprendre que le MicroBlaze ou aucun composant mémoire ne propose de protocole de cohérence de cache matériel. Cela est vraiment problématique. Lorsqu un processeur met à jour une donnée en mémoire, il n a aucun moyen de prévenir les autres processeurs que cette donnée a été modifiée. Ces derniers utilisant une vieille version de cette valeur. Il faudrait alors développer un protocole logiciel de cohérence de cache, de préférence dans le HAL. Voilà les deux principaux problèmes rencontrés. Tout le reste est considéré comme valide. Ces problèmes ne ce sont pas manifestés sur une plateforme mono-processeur, ce qui parait logique html 10

12 Chapitre 4 Conclusion Tout au long de ce stage j ai pu acquérir de nombreuses connaissances et compétences telles que le fonctionnement d un système d exploitation, de différents composants ou encore d une carte FPGA (chose que je connaissais pas avant). J ai ainsi pu mettre en pratique et approfondir certains de mes enseignements. Ce stage m a aussi permis de découvrir le monde de la recherche ainsi que le travail en laboratoire. Une poursuite possible de mon travail serait l extension du processus de validation à d autres processeurs tel que l ARM ou le MIPS. L implantation d un protocole logiciel de cohérence de cache est aussi nécessaire pour utiliser pleinement le cache. Une autre possibilité serait d adapter Parallel MJPEG, une application embarquée, au MicroBlaze. 11

13 Annexe A Patch GDB diff --git a/gdb/microblaze-tdep.c b/gdb/microblaze-tdep.c index ca6d129..a2af4c a/gdb/microblaze-tdep.c ,7 static const char *microblaze_register_names[] = "rpc", "rmsr", "rear", "resr", "rfsr", "rbtr", "rpvr0", "rpvr1", "rpvr2", "rpvr3", "rpvr4", "rpvr5", "rpvr6", "rpvr7", "rpvr8", "rpvr9", "rpvr10", "rpvr11", - "redr", "rpid", "rzpr", "rtlbx", "rtlbsx", "rtlblo", "rtlbhi" + "redr", "rpid", "rzpr", "rtlbx", "rtlbsx", "rtlblo", "rtlbhi", + "rjunk", "rjunk2" }; #define MICROBLAZE_NUM_REGS ARRAY_SIZE (microblaze_register_names) diff --git a/gdb/microblaze-tdep.h b/gdb/microblaze-tdep.h index b0362b1..4afd a/gdb/microblaze-tdep.h ,7 struct microblaze_frame_cache int fp_regnum; /* Offsets to saved registers. */ - int register_offsets[57]; /* Must match MICROBLAZE_NUM_REGS. */ + int register_offsets[59]; /* Must match MICROBLAZE_NUM_REGS. */ /* Table of saved registers. */ struct trad_frame_saved_reg -107,7 enum microblaze_regnum MICROBLAZE_RTLBX_REGNUM, MICROBLAZE_RTLBSX_REGNUM, MICROBLAZE_RTLBLO_REGNUM, - MICROBLAZE_RTLBHI_REGNUM + MICROBLAZE_RTLBHI_REGNUM, + MICROBLAZE_RJUNK1_REGNUM, + MICROBLAZE_RJUNK2_REGNUM 12

14 }; /* All registers are 32 bits. */ 13

15 Annexe B Chaine compilation Apes 14

16 Annexe C Composant Apes 15

17 Annexe D Modules 16