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

Ajout du support du MicroBlaze dans DNA-OS
      Stage d’excellence Juin-Juillet 2012

                 Guiroux Hugo
             Laboratoire SLS - TIMA

                 24 juillet 2012

Table des matières

1 Introduction                                                                                                             3

2 Présentation                                                                                                             4
  2.1 Précédents travaux . . . . . . . . . . . . . .                      .   .   .   .   .   .   .   .   .   .   .   .    4
  2.2 Apes : Application Elements for SoCs . . .                          .   .   .   .   .   .   .   .   .   .   .   .    4
  2.3 DNA-OS : Système d’exploitation soft-core                           .   .   .   .   .   .   .   .   .   .   .   .    5
  2.4 Processeur Xilinx MicroBlaze . . . . . . . .                        .   .   .   .   .   .   .   .   .   .   .   .    6
  2.5 Plateforme FPGA Virtex-5 . . . . . . . . .                          .   .   .   .   .   .   .   .   .   .   .   .    6

3 Travaux                                                                                                                  7
  3.1 Description du HAL . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    7
  3.2 Validation de l’implantation    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    8
  3.3 État des lieux et objectifs .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    8
  3.4 Mono-processeur . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    9
      3.4.1 Simulation QEmu .         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    9
      3.4.2 FPGA : premier acte       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    9
  3.5 Multiprocesseurs . . . . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   10
      3.5.1 FPGA : le retour . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   10
  3.6 Validation et problèmes . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   10

4 Conclusion                                                                                                              11

Bibliographie                                                                                                             11

A Patch GDB                                                                                                               12

B Chaine compilation Apes                                                                                                 13

C Composant Apes                                                                                                          14

D Modules                                                                                                                 15

                                          1

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 possi-
bilité 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 mo-
ments de convivialité.

                                       2

Chapitre 1

Introduction

    L’informatique embarquée est de plus en plus présente dans notre vie quoti-
dienne. 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’avi-
ation, 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

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 im-
plantation 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 tra-
vail 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

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 sim-
plifié, 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 co-
    hérence dans les zones attribuées aux différents threads ; ainsi que l’allo-
    cation et la libération de l’espace.
Le Système de Fichiers Virtuels : se basant sur la FHS (Filesystem Hier-
    archy 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 plate-
    forme 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

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
8.20. 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 ar-
ray). C’est un circuit logique dont le principal intérêt est de pouvoir être re-
programmé après sa fabrication. Il est composé de blocs logiques contenants
principalement une table de correspondances (LUT). Il s’agit d’une table ser-
vant à 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 en-
tièrement programmable grace à la suite d’outils proposée par Xilinx nommée
EDK (Embedded Development Kit).

                                        6

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’im-
plantation 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 (reg-
    istres) 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 com-
     portements 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

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 com-
mentaires. De plus, deux tests globaux ont été ajoutés : un test pour l’ordon-
nanceur, appelant toutes les parties du HAL, et le célèbre test du dîner des
philosophes[?], proposé par Dijkstra en 1971.

3.3     É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

3.4     Mono-processeur
3.4.1    Simulation QEmu
    Avant de commencer à travailler sur une carte FPGA directement, la ma-
chine 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 bi-
naire 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.

3.4.2    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

3.5     Multiprocesseurs
3.5.1    FPGA : le retour
    Après quelques recherches, il apparait qu’il n’existe pas de solution logi-
cielle pour simuler une plateforme multi-MicroBlaze. L’utilisation de la carte
a donc été immédiate. Concernant la partie matérielle, les principaux change-
ments sont l’emploi d’un composant appelé MailBox. Il permet la communi-
cation 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 multipro-
cesseurs à 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 prob-
lè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 mo-
     ment 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’ap-
    prendre que le MicroBlaze ou aucun composant mémoire ne propose de
    protocole de cohérence de cache matériel. Cela est vraiment probléma-
    tique. Lorsqu’un processeur met à jour une donnée en mémoire, il n’a au-
    cun moyen de prévenir les autres processeurs que cette donnée a été mod-
    ifié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.

   1. http://www.fpgadeveloper.com/2011/06/how-to-convert-an-ml505-edk-project-for-the-xupv5.
html

                                       10

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 dif-
fé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 enseigne-
ments. 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

Annexe A

Patch GDB

diff --git a/gdb/microblaze-tdep.c b/gdb/microblaze-tdep.c
index ca6d129..a2af4c9 100644
--- a/gdb/microblaze-tdep.c
+++ b/gdb/microblaze-tdep.c
@@ -74,7 +74,8 @@ 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..4afd026 100644
--- a/gdb/microblaze-tdep.h
+++ b/gdb/microblaze-tdep.h
@@ -42,7 +42,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 *saved_regs;
@@ -107,7 +107,9 @@ 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

};

/* All registers are 32 bits.   */

                                13

Annexe B

Chaine compilation Apes

             14

Annexe C

Composant Apes

            15

Annexe D

Modules

           16