Changes between Version 74 and Version 75 of SoclibCourseTp3


Ignore:
Timestamp:
Dec 5, 2013, 7:57:52 PM (11 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • SoclibCourseTp3

    v74 v75  
    1414Puisque l'utilisation d'un processeur programmable suppose le déploiement du code sur l'architecture modélisée, on a besoin d'un système d'exploitation
    1515minimal pour permettre l'accès aux périphériques partagés, gérer les interruptions en provenance des périphériques, et traiter les exceptions liées aux inévitables
    16 erreurs de programmation. On introduit donc dans ce TP le GIET (Gestionnaire d'Interruptions, Exceptions et Trappes), qui sera utilisé comme OS dans ce tP et les suivants.
     16erreurs de programmation. On introduit donc dans ce TP le '''GIET''' (Gestionnaire d'Interruptions, Exceptions et Trappes), qui sera utilisé comme OS dans ce TP et dans les suivants.
    1717
    1818On introduit également dans ce TP l'outil de compilation '''soclib-cc''' qui facilite la génération du prototype virtuel de l'architecture matérielle.
     
    5252= 3 Logiciel embarqué =
    5353
    54 Si l'application logicielle est écrite en langage C, il faut utiliser un cross-compilateur C spécifique
    55 au processeur embarqué pour compiler ce code applicatif, ainsi que le code du système d'exploitation embarqué.
    56 Le résultat est un fichier binaire au format ELF, qui doit ensuite être chargé dans les mémoires embarquées du MPSoC.
     54Les composants de la bibliothèque SoCLib permettent d'exécuter des systèmes d'exploitation généralistes (tels que LINUX ou NetBSD), ou des systèmes d'exploitation spécialisés pour MPSoC (tels que MutekH ou ALMOS). Dans ce TP et les suivants, on se contentera d'un
     55système d'exploitation minimal, constitué par un Gestionnaire d'Interruptions, Exceptions et Trappes (GIET).
     56
     57L'application qui nous intéresse dans ce TP est une application logicielle qui s'exécute en mode utilisateur.
     58Comme elle utilise deux périphériques (terminal TTY et coprocesseur GCD), elle doit faire faire des appels
     59système vers le GIET pour accéder à ces périphériques.
    5760
    5861== 3.1 Gestionnaire d'Interruptions, exceptions et Trappes ==
    5962
    60 Les composants de la bibliothèque SoCLib permettent d'exécuter des systèmes d'exploitation généralistes (tels que LINUX ou NetBSD), ou des systèmes d'exploitation spécialisés pour MPSoC (tels que [https://www.mutek.fr/ MutekH]). Dans ce TP et les suivants, on se contentera d'un
    61 système d'exploitation minimal, constitué par un Gestionnaire d'Interruptions, Exceptions et Trappes (GIET). Le GIET fournit quelques appels systèmes permettant aux programmes utilisateurs d'accéder aux périphériques, il traite les requêtes d'interruption vectorisées émises par les périphériques, et facilite le debug du logiciel embarqué en signalant les exceptions.
    62 
    63 Vous pouvez consulter le code source du système d'exploitation dans le répertoire
    64 {{{
    65 /users/enseig/alain/giet
    66 }}}
    67 
    68  * le fichier '''giet.s''' est écrit en assembleur et contient le code du Gestionnaire d'Interruption, Exceptions et Trappes. Le GIET est l'unique point d'entrée dans le système d'exploitation. Ce code s'exécute en mode ''kernel'', et se termine toujours par une instruction ''eret''.
    69  * les fichier '''stdio.c''' et '''stdio.h''' sont écrits en C, et contiennent le code des appels systèmes permettant à un programme s'exécutant en mode ''user'' d'accéder aux périphériques.
    70  * les fichiers '''drivers.c''' et '''drivers.h''' sont  écrits en C et contiennent le code des fonctions systèmes qui s'exécutent en mode kernel, qui accèdent effectivement aux périphériques ou aux registres protégés du processeur.
    71  * le fichier '''isr.s''' contient le code des routines de traitement des interruptions (Interrupt Service Routine).
     63Le GIET fournit principalement trois services:
     64
     65 * un ''gestionnaires d'appels systèmes'' fournissant en particulier des fonctions d'accès aux périphériques.
     66 * un ''gestionnaire d'interruptions'' supportant un mécanismes d'interruptions vectorisées.
     67 * un ''gestionnaire d'exceptions'' permettant de traiter les erreurs des programmes utilisateurs.
     68Les deux principales limitations du GIET, qui le différencient d'un ''vrai'' système d'exploitation, sont l'absence de support pour la mémoire virtuelle, et l'absence de support pour la création dynamique de tâches.
     69
     70Le code du GIET est séparé en deux parties: Les fichiers contenant le code qui s'exécute en mode ''superviseur'' est contenu dans le répertoire '''sys''', tandis que les fichiers contenant le code qui s'exécute en mode ''utilisateur'' est contenu dans le répertoire '''app'''.
     71
     72 * Le fichier '''sys_handler.c''' est écrit en C. Il est dans le répertoire '''sys''', et contient le code du gestionnaire d'appels systèmes, chargé d'appeler la fonction système correspondant au service demandé.
     73 * Le fichier '''exc_handler.c''' est écrit en C. Il est dans le répertoire '''sys''', et contient le code du gestionnaire d'exceptions, chargé de la signalisation et du traitement des erreurs détectées dans les programmes utilisateurs.
     74 * Le fichier '''irq_handler.c''' est écrit en C. Il est dans le répertoire '''sys''', et contient le code du gestionnaire d'interruptions, ainsi que les routines de traitement des interruptions (ISR).
     75 * Le fichier '''ctx_handler.c''' est écrit en C. Il est dans le répertoire '''sys''', et contient le code du gestionnaire de changements de contexte, utilisé lorsque un processeur exécute plusieurs tâches en multiplexage temporel.
     76 * Le fichier '''drivers.c''' contient les fonctions d'accès aux périphériques. Il rassemble donc les ''pilotes'' de tous les périphériques de la machine.
     77 * Le fichier '''common.c''' est écrit en C. Il est dans le répertoire '''sys''', et contient les fonctions générales du système d'exploitation, telles que les primitives de synchronisation entre tâches.
     78 * Le fichier '''giet.s''' est écrit en assembleur MIPS32. Il est dans le répertoire '''sys''', et contient la fonction qui analyse la cause de l'appel au GIET, et la fonction de sauvegarde/restauration de contexte.
     79 * Le fichier '''stdio.c''' est écrit en C. Il est dans le répertoire '''app''' car il contient l'ensemble des appels systèmes qui peuvent être utilisés par un programme utilisateur écrit en C. Le nom de ce fichier provient du fait que la plupart des appels systèmes sont utilisés pour accéder aux périphériques.
     80
     81Le code source du GIET est accessible et stocké dans le répertoire suivant:
     82
     83{{{
     84/users/enseig/alain/giet_2011/
     85}}}
    7286
    7387== 3.2 Génération du code ==
    7488
    75 Le code binaire doit être généré par un cross-compilateur spécifique pour le processeur Mips32. On utilise la chaîne de compilation GCC, pour compiler l'ensemble du logiciel embarqué (code applicatif et code système) et pour réaliser l'édition de liens entre le code applicatif, et le code système. Le résultat de cette compilation est un fichier au format ELF, contenant le code binaire exécutable par le processeur MIP32. Le code du GIET étant tès compact, on recompilera l'ensemble du code source (y compris le code système) à chaque modification du code de l'application.
     89Puisque le GIET et  l'application logicielle sont tous deux écrits écrits en langage C, il faut utiliser un cross-compilateur C spécifique au processeur MIPS32 pour générer d'une part le code applicatif, et d'autre part le code du système d'exploitation embarqué.
     90
     91Le résultat de la compilation consiste en deux fichiers binaire au format ELF, '''sys.bin''' et '''app.bin''', qui devront être chargés dans les mémoires embarquées du MPSoC.
    7692
    7793== 3.2 Chargement du code ==
     
    90106à la `MappingTable`. Il peut donc déterminer quels segments ont été affectés à la RAM (ou à la la ROM) et lesquels doivent être initialisés.
    91107
    92 On économise ainsi plusieurs millions de cycles de simulation, et le code de boot peut être beaucoup plus court (le code de boot
    93 utilisé dans ce TP contient moins de 20 lignes d'assembleur).
     108On économise ainsi plusieurs millions de cycles de simulation, et le code de boot peut être beaucoup plus court (le code de boot utilisé dans ce TP contient moins de 20 lignes d'assembleur).
    94109 
    95110= 4 Travail à réaliser =
     
    103118Outre les fichiers qui permettent de générer le simulateur de l'architecture matérielle, cette archive contient  également un sous-répertoire ''soft'' qui est utilisé pour la génération du logiciel embarqué.
    104119
    105 Pour cette architecture, il faut définir 9 segments dans l'espace adressable, dont 7 correspondent à de la mémoire, et 2 correspondent à 2 périphériques adressables :
     120== 4.1 segmentation de l'espace adressable ==
     121
     122Pour cette architecture, il faut définir 9 segments dans l'espace adressable, dont 3 correspondent à l'application et 6 appartiennent au système d'exploitation (adrresses plus grandes que 0x80000000).
     123
     124=== segments applicatifs ===
     125
     126 * '''seg_code''' est le segment contenant le code de l'application logicielle embarquée, qui s'exécute en mode ''user''. Il est assigné à la RAM. On choisira pour adresse de base la valeur 0x00400000, et une capacité de stockage de 64 Koctets. 
     127
     128 * '''seg_data''' est le segment contenant les données globales de l'application logicielle embarquée. Il est assigné à la RAM. On choisira pour adresse de base la valeur 0x01000000, et une capacité de stockage de 64 Koctets.
     129
     130 * '''seg_stack''' est le segment contenant la pile d'exécution de l'application logicielle embarquée. Il est assigné à la RAM. On choisira pour adresse de base la valeur 0x02000000, et une capacité de stockage de 64 Koctets.
     131
     132=== segments système ===
    106133
    107134 * '''seg_reset''' est le segment contenant le code de ''boot'' exécuté à la mise sous tension. Il est évidemment assigné à la ROM. L'adresse de base 0xBFC00000 est imposée par la spécification du processeur Mips32. On choisira une capacité de stockage de 4 Koctets.
     135
    108136 * '''seg_kcode''' est le segment contenant le code du système qui s'exécute en mode ''kernel''. Il s'agit principalement du code du Gestionnaire d'Interruptions, Exceptions, et Trappes (GIET), du code des fonctions système, ainsi que du code des routines d'interruption (ISR, pour interrupt Service Routine). Ce segment  est assigné à la RAM. L'adresse de base 0x80000000. On choisira une capacité de stockage de 64 Koctets.
     137
    109138 * '''seg_kdata''' est le segment contenant les données cachables du système d'exploitation. Il est assigné à la RAM. L'adresse de base est égale à 0x81000000. Sa capacité esr de 64Koctets. 
     139
    110140 * '''seg_kunc''' est le segment contenant les données non cachables du système d'exploitation. Il est assigné à la RAM. L'adresse de base est égale à 0x82000000. Sa capacité esr de 64Koctets. 
    111  * '''seg_code''' est le segment contenant le code de l'application logicielle embarquée, qui s'exécute en mode ''user''. Il est assigné à la RAM. On choisira pour adresse de base la valeur 0x00400000, et une capacité de stockage de 64 Koctets. 
    112  * '''seg_data''' est le segment contenant les données globales de l'application logicielle embarquée. Il est assigné à la RAM. On choisira pour adresse de base la valeur 0x10000000, et une capacité de stockage de 64 Koctets.
    113  * '''seg_stack''' est le segment contenant la pile d'exécution de l'application logicielle embarquée. Il est assigné à la RAM. On choisira pour adresse de base la valeur 0x20000000, et une capacité de stockage de 64 Koctets.
     141
    114142 * '''seg_tty''' est le segment associé au contrôleur de terminaux TTY. On prendra pour adresse de base la valeur 0x90000000, et pour longueur 64 octets, ce qui permet d'adresser jusqu'à 4 terminaux indépendants.
     143
    115144 * '''seg_gcd''' est le segment associé au coprocesseur GCD. On prendra pour adresse de base la valeur 0x95000000. La longueur de 16 octets correspond aux quatre registres adressables de ce composant.
    116145
    117 Remarquez que les 2 segments correspondant aux périphériques (seg_tty et seg_gcd), le segment contenant le code de boot, ainsi que les  3 segments utilisés par le système d'exploitation sont dans la zone protégée de l'espace adressable, qui n'est accessible que lorsque le processeur est en mode ''kernel'' (adresses supérieures à 0x80000000).
    118 
    119 Les adresses de base sont utilisées à la fois par le matériel et par le logiciel embarqué. Elles doivent donc être définies à deux endroits :
     146Les adresses de base des segments sont utilisées à la fois par le matériel et par le logiciel embarqué. Elles doivent donc être définies à deux endroits :
     147
    120148 1. Pour le matériel, les addresses de base et les longueurs des segments doivent être définies dans le fichier ''tp3_top.cpp'' pour ëtre stockées dans la !MappingTable. Elles sont utilisées dans la phase de configuration du matériel par les constructeurs des composants.
    121  1. Pour le logiciel, les adresses de base des segments doivent être définies dans le fichier ''soft/ldscript'' qui contient les directives pour l'éditeur de liens lors de la compilation du logiciel embarqué.
    122 
    123 Par ailleurs le GIET peut supporter des architectures comportant plusieurs processeur, mais les structures de données utilisées par le système doivent être dimensionnées en fonction du nombre de composants matériels disponibles: nombre de processeurs, nombre de terminaux TTY. Ces paramètres doivent donc être définies dans le fichier ''tp"_top.cpp'' et dans le fichier ''soft/ldscript''.
     149
     150 1. Pour le logiciel, les adresses de base des segments doivent être définies dans le fichier ''soft/seg.ld'' qui contient les directives pour l'éditeur de liens lors de la compilation du logiciel embarqué.
     151
     152Par ailleurs le GIET peut supporter des architectures comportant plusieurs processeur, mais les structures de données utilisées par le système doivent être dimensionnées en fonction du nombre de processeurs et du nombre de tâches parallèles. Ces paramètres doivent donc être définies dans le fichier ''tp"_top.cpp'' et dans le fichier ''soft/config.h''.
    124153
    125154== 4.1 Compilation du logiciel embarqué ==
     
    128157
    129158 * le fichier '''reset.s''' est écrit en assembleur et contient le code de boot qui est exécuté à la mise sous tension, ou lors de l'activation du signal NRESET. Ce code s'exécute en mode ''kernel'', mais il est spécifique à chaque plate-forme matérielle, car il est chargé d'initialiser les périphériques présents dans l'architecture.
    130  * le fichier '''main.c''' est écrit en C et contient le code de l'application logicielle. IL peut évidemment utiliser les appels système définis dans le fichier ''stdio.c''.
     159
     160 * le fichier '''main.c''' est écrit en C et contient le code de l'application logicielle. Il utilise les appels système définis dans le fichier ''stdio.c''.
     161
    131162 * le fichier '''ldscript''' contient les directives pour l'éditeur de liens, et en particulier les adresses de base des différents segments, ainsi que certains paramètres de la plate-forme matérielle tels que le nombre de processeurs ou de terminaux TTY.
     163
    132164 * le fichier '''Makefile''' permet de lancer la génération du logiciel embarqué.
    133165