Changes between Version 18 and Version 19 of SoclibCourseTp3

Timestamp:

Sep 16, 2009, 8:33:21 PM (15 years ago)

Author:

alain

Comment:

--

SoclibCourseTp3

@@ -60 +60 @@
 
 Il existe deux méthode méthodes permettant de charger le code binaire dans les mémoires embarquées sur la puce:
- * Le code peut être stocké dans des mémoires mortes (ROM). Le contenu de ces mémoires est défini lors de la fabrication de la puce, et n'est plus modifiable. Cette approche est évidemment très peu flexible, et elle n'est généralement utilisée que pour le code de boot. 
- * Le code est stocké dans des mémoires inscriptibles (SRAM), qui sont chargées lors de la mise sous tension du système à partir d'un périphérique de stockage externe (cela peut être une ROM externe, une mémoire flash, ou un autre dispositif de stockage. On peut même imaginer qu'on utilise une liaison sans fil pour télécharger du code applicatif disponible sur un serveur distant.  Cette approche est utilisée pour le code applicatif, mais également pour le système d'exploitation embarqué. Le code qui exécute ce chargement de code s'appelle un ''bootloader''.
+ 1. Le code peut être stocké dans des mémoires mortes (ROM). Le contenu de ces mémoires est défini lors de la fabrication de la puce, et n'est plus modifiable. Cette approche est évidemment très peu flexible, et elle n'est généralement utilisée que pour le code de boot. 
+ 1. Le code est stocké dans des mémoires inscriptibles (SRAM), qui sont chargées lors de la mise sous tension du système à partir d'un périphérique de stockage externe (cela peut être une ROM externe, une mémoire flash, ou un autre dispositif de stockage. On peut même imaginer qu'on utilise une liaison sans fil pour télécharger du code applicatif disponible sur un serveur distant.  Cette approche est utilisée pour le code applicatif, mais également pour le système d'exploitation embarqué. Le code qui exécute ce chargement de code s'appelle un ''bootloader''.
 
 La phase de chargement du système d'exploitation et du code applicatif  est en pratique exécutée à chaque mise sous tension,
@@ -129 +129 @@
 Certains de ces fichiers sont écrits en assembleur MIPS32, certains sont écrits en C :
  * 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'' et initialise quelques registres, avant d'exécuter l'instruction ''eret''.
- * le fichier '''giet.s''' est écrit en assembleur et contient le code du Gestionnaire d'Interruption, Exceptions et Trappes.
-Ce code s'exécute en mode ''kernel'', et se termine toujours par une instruction ''eret''.
+ * le fichier '''giet.s''' est écrit en assembleur et contient le code du Gestionnaire d'Interruption, Exceptions et Trappes. Ce code s'exécute en mode ''kernel'', et se termine toujours par une instruction ''eret''.
  * le fichier '''syscall.s''' est écrit en assembleur et contient le code des quelques appels système disponibles sur cette plate-forme minimale. Ils s'exécutent en mode ''kernel'', et permettent l'accès aux périphériques.
  * le fichier '''stdlib.c''' est la version C des appels système définis dans le fichier ''syscalls.s''. Ces fonction C se contentent d'encapsuler l'instruction assembleur ''syscall'' après avoir placé les valeurs des arguments dans les registres appropriés. Elles peuvent donc être appelées depuis un programme s'exécutant en mode ''user''.
  * le fichier '''main.c''' est écrit en C et contient n'importequelle application logicielle qui se contente des quelques appels système définis dans ''stdlib.c''.
- * le fichier ''Makefile'' permet de lancer la compilation du logiciel embarqué. 
+ * le fichier '''Makefile''' permet de lancer la compilation du logiciel embarqué. 
 
 On peut considérer que les trois fichiers ''reset.s'', ''giet.s'', et ''syscalls.s'' jouent le rôle d'un système d'exploitation