Changes between Version 14 and Version 15 of stageM2


Ignore:
Timestamp:
Dec 21, 2009, 1:21:16 PM (14 years ago)
Author:
becoulet
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • stageM2

    v14 v15  
    125125[[Include(StageContexte/MutekH)]]
    126126
    127 Une MMU(Memory Management Unit) est un composant passerelle entre le processeur et la mémoire centrale. L'espace d'adressage de cette dernière n'est pas forcément identique à celui utilisé par le processeur. L'accès au données nécessite alors une traduction d'adresse, effectué par la MMU. Celle-ci convertit l'adresse demandée par le processeur (adresse dite virtuelle) en une adresse réellement disponible en mémoire (adresse physique).
     127Une MMU(Memory Management Unit) est un composant matérielle qui traduit les adresses mémoires employées par le code qui s'exécute en adresses physiques à destination des composants mémoire. En effet, la MMU permet la mise en oeuvre de la mémoire virtuelle où l'espace d'adressage virtuel et physique sont découpés en pages qui sont permutées. La mémoire virtuelle est la base de tous les systèmes d'exploitations modernes multi-utilisateur et sécurisée. Elle rend possible la protection de la mémoire, la séparation des processus en mémoire, la mémoire partagée, le swapping, la création efficace de processus par copy-on-write, et bien d'autre mécanismes essentiels de l'OS... Depuis longtemps employé dans les stations de travails et dans les serveurs, elle l'est aujourd'hui de plus en plus également dans l'embarqué.
    128128
    129 Suivant les processeurs et les architectures, les MMU diffèrent, les fonctionnalités proposées ne sont pas les mêmes. Par exemple, alors que sur x86 les pages mémoire ont une taille de 4 Kio ou 4 Mio, elles ont une taille de 1 Kio, 4 Kio, 64 Kio ou 1 Mio sur ARM.
     129Suivant les processeurs et les architectures les MMU diffèrent. Les caratéristiques, les fonctionnalités proposées et la manière d'y accéder ne sont pas les mêmes. Par exemple les tailles de pages peuvent être différentes d'une architecture à l'autre et les mécanisme d'accès à la table de page peuvent être logiciels ou matériels.
    130130
    131131La gestion de la mémoire virtuelle est décomposable en deux parties dans Hexo/MutekH:
    132  * un driver, spécifique à chaque MMU, qui effectue des opération bas niveau pour lire/modifier les tables de pages dans Hexo. L'ensemble des drivers de MMU partage une API générique.
    133  * des gestionnaires de page physiques et virtuelles dans MutekH, qui font directement appel au driver.
     132 * un driver, spécifique à chaque MMU, effectue des opération bas niveau pour lire/modifier les tables de pages dans Hexo. L'ensemble des drivers de MMU partage une API générique.
     133 * des gestionnaires de page physiques et virtuelles dans MutekH font directement appel au driver via l'API générique.
    134134
    135135L'objectif de ce stage est d'ajouter à l'exo-noyau Hexo le support de la mémoire virtuelle sur un processeur ARM doté d'une MMU de référence.
    136 Pour cela, l'étudiant devra implémenter le driver pour la MMU du processeur ARM. Ce driver devra évidement respecter l'API citée précédemment.
    137 Hexo s'exécute déjà nativement sur une architecture munie d'un processeur ARM et d'une MMU générique du projet SoCLib. Il sera possible de s'inspirer de ce driver pour effectuer le travail demandé.
     136Pour cela, l'étudiant devra étudier la documentation de l'architecture ARM et implémenter le driver pour la MMU. Ce driver devra respecter l'API citée précédemment.
     137Hexo s'exécute déjà nativement sur des architectures employant une MMU. Le processeur ARM et la MMU générique du projet SoCLib étant supporté, il sera possible de s'inspirer de ce driver pour effectuer le travail demandé.
    138138
    139139La validation se fera soit sur une carte de développement [http://www.olimex.com/dev/sam9-L9260.html SAM9-L9260 d'Olimex], soit sur la console de jeux portable [http://darkfader.net/gp32/ GamePark32].