Changes between Version 16 and Version 17 of SoclibCourseTp3

Timestamp:

Sep 16, 2009, 8:28:43 PM (15 years ago)

Author:

alain

Comment:

--

SoclibCourseTp3

@@ -61 +61 @@
 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''.
-
-La phase de chargement du code applicatif et du système d'exploitation est exécutée à chaque mise sous tension. Elle peut être 
-très longue (plusieurs millions de cycles). Un fois que le ''bootloader'' a été validé cette phase de chargement n'apporte plus beaucoup
-d'information, quand on souhaite mettre au point une application logicielle sur une architecture matérielle modélisée avec SoCLib.
+ * 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,
+ou chaque fois qu'on active le signal NRESET. Elle peut être très longue (plusieurs millions de cycles). Un fois que le ''bootloader'' a été validé,
+cette phase d'initialisation n'apporte plus beaucoup
+d'information, quand on souhaite mettre au point ou mesurer les performances d'une application logicielle sur une architecture matérielle modélisée avec SoCLib.
 
 La plate-forme SoCLib fournit donc un service permettant d'initialiser directement les mémoires embarquées à partir du code contenu
@@ -74 +74 @@
 contenu du fichier ELF contenant le code binaire. Le constructeur possédant un autre argument lui permettant d'accéder 
 à la MappingTable, il peut déterminer quels segments de la RAM (ou de la ROM) doivent être initialisés.
+Danx ces conditions, le code de boot peut être beaucoup plus court.
  
 = 4 Travail à réaliser =
@@ -84 +85 @@
 
 Cette archive contient un très grand nombre de fichiers, car les composants instanc!és sont des objets complexes,
-qui font appel à beaucoup de code ''caché'' (analyse du format de fichier binaire ELF et chargement de ce code binaire dans les mémoires embarquées ROM ou RAM, ou ouverture d'une fenêtre XTERM pour le composant TTY). 
+qui font appel à beaucoup de code ''caché'' : le chargement initial  des mémoires embarquées ROM et RAM nécessite l'analyse du format de fichier binaire ELF.
+De même, l'utilisation d'un contrôleur de terminal suppose l'ouverture d'une ou plusieurs fenêtres XTERM sur la station de travail qui exécute la simulation.
+
 Nous ne les décrivons pas en détail, mais vous pouvez consulter le fichier ''Makefile'' pour avoir la liste de tous les
-fichiers objets qui doivent être compilés pour générer le simulateur.
-
-L'archive contient en particulier les fichiers suivants correspondant aux modèles des composants instanciés :
+fichiers objets qui doivent être compilés pour générer le simulateur de cette architecture très simple.
+
+L'archive fournie contient en particulier les fichiers suivants correspondant aux modèles des composants instanciés :
  * `vci_xcache_wrapper.h` : définition du composant `VciXcacheWrapper`
  * `vci_xcache_wrapper.cpp` : méthodes associées