Changes between Version 16 and Version 17 of boot_procedure

Timestamp:

Apr 2, 2017, 4:18:07 PM (8 years ago)

Author:

alain

Comment:

--

boot_procedure

@@ -9 +9 @@
 Le boot-loader récupère les informations décrivant les caractéristiques de la plateforme matérielle (nombre de clusters, nombre de coeurs par cluster, périphériques disponibles, ciblage des interruptions, etc.)  dans le fichier binaire '''arch_info.bin'''. Il utilise pour construire - dans chaque cluster - la structure de données '''boot_info_t''', utilisée par l'instance locale du noyau ALMOS-MK, et décrivant les composants matériels disponibles dans le cluster, ainsi que les caractéristiques générales de la plateforme. Cette structure est rangée au début du segment de données '''kdata''' du noyau et est utilisée - dans caque cluster - par la fonction '''kernel_init()'''. Ces informations en entrée et en sortie du boot-loader peuvent sembler redondantes mais cette traduction (arch-info -> boot_info) permet - en principe - au boot-loader de vérifier le bon fonctionnement de la plateforme matérielle et de détecter les pannes dues au vieillissement du matériel. Dans cette approche, les structures '''boot_info_t''' générées par le boot-loader ne contiennent que les composants matériels effectivement utilisables par le noyau. Cette vérification/reconfiguration n'est pas implémentée.
 
-Par convention, on définit - dans chaque cluster - des zones de mémoire physique de longueur fixe pour les différents fichiers binaires et/ou structures de données: 
-    * Pour le code du pré-loader : une zone de '''1 Mo''' dans le cluster (0,0), à partir de l'adresse 0x0.
+Par convention, on définit - dans chaque cluster - des zones de mémoire physique de longueur fixe pour les différents fichiers binaires et/ou structures de données utilisés pendant le démarrage du système.
+    * Pour le code du pré-loader : une zone de '''16 Ko''', à partir de l'adresse 0x0.
     * Pour le code du boot-loader: une zone de mémoire physique de '''1Mo''', à partir de l'adresse 0x100000.
     * Pour le fichier binaire '''arch_info.bin''': une zone de mémoire physique de '''2Mo''', à partir de l'adresse 0x200000.
@@ -18 +18 @@
 Notons que l'espace adressable physique de chaque cluster doit avoir une capacité au moins égale à '''6Mo'''.
 Toutes ces valeurs sont des paramètres de configuration du boot-loader, qui peuvent être redéfinis dans le fichier '''boot_config.h'''.
-La zone réservée au pré-loader n'est utilisée que si le pré-loader n'est stocké dans une ROM externe. 
+Les quatre premières pages (16 Koctets) réservées au pré-loader ne sont utilisée que dans le cluster 0, et uniquement si le pré-loader n'est pas stocké dans une ROM externe. 
 
 Le chargement d'ALMOS-MK sur l'architecture TSAR se fait donc en 4 phases:
 
 == 1. Phase de préchargement == 
-Au démarrage, les valeurs dans les registres d'extension d'adresse de code et de données des coeurs MIPS32 sont à 0. Cela veut dire que tous les coeurs de la plateforme ne peuvent accéder qu'à l'espace adressable physique du cluster(0,0), appelé cluster de boot. Tous les coeurs commencent par exécuter le code du preloader, mais ils réalisent des tâches différentes: le CP0 du cluster (0,0) charge dans la mémoire locale du cluster(0,0) à l'adresse '''0x100000''', l'image du boot-loader; tandis que les autres cores ne font qu'une seule chose avant de s'endormir: initialiser le canal d'interruption WTI du contrôleur XICU pour pouvoir être réveillés ultérieurement par une IPI (Inter-Processor Interrupt).
+Au démarrage, les valeurs dans les registres d'extension d'adresse de code et de données des coeurs MIPS32 sont à 0. Cela veut dire que tous les coeurs de la plateforme ne peuvent accéder qu'à l'espace adressable physique du cluster(0,0), qui est donc appelé cluster de boot. Tous les coeurs commencent par exécuter le code du preloader, mais ils réalisent des tâches différentes: le CP0 du cluster (0,0) charge dans la mémoire locale du cluster(0,0) à l'adresse '''0x100000''', l'image du boot-loader; tandis que les autres cores ne font qu'une seule chose avant de s'endormir: initialiser le canal d'interruption WTI du contrôleur XICU pour pouvoir être réveillés ultérieurement par une IPI (Inter-Processor Interrupt).
 
    Voici le contenu de la mémoire du cluster de boot et des autres clusters après cette première étape.
@@ -30 +30 @@
 == 2. Phase séquentielle ==
 Dans cette seconde phase, le CP0 du cluster(0,0) exécute seul le code du boot-loader et réalise les tâches suivantes:
-    * Il initialise son pointeur de pile pour pouvoir exécuter du code C au lieu de l'assembleur. La taille de cette pile temporaire est aussi un paramètre de configuration. Par défaut, le pointeur de pile pile des cores CP0 de chaque cluster ('''lid''' = 0) sont initialisés à l'adresse '''0x600000'''. 
-    * Il initialise 2 périphériques: '''TTY''' (canal 0)  pour afficher les informations de débogage et '''IOC''' pour accéder aux fichiers sur disque.
+    * Il initialise son pointeur de pile pour pouvoir exécuter du code C. La taille de cette pile temporaire est aussi un paramètre de configuration. Par défaut, le pointeur de pile du core CP0 de chaque cluster ('''lid''' = 0) est initialisé à l'adresse '''0x600000'''. 
+    * Le CP0 cu cluster (0,0) initialise 2 périphériques: '''TTY''' (canal 0)  pour afficher les informations de débogage et '''IOC''' pour accéder aux fichiers sur disque.
     * Il charge ensuite, toujours en mémoire locale du cluster de boot, le fichier binaire '''arch_info.bin''' ainsi que l'image binaire du noyau d'ALMOS-MK, respectivement à l'adresse '''0x200000''' et '''0x400000''', juste au dessus du segment mémoire correspondant à l'image du boot-loader. 
-    * Il utilise la structure '''arch_info.bin''' pour initialiser les différents champs de la structure '''boot_info_t''' du cluster de boot.
+    * Il utilise les informations contenues dans la structure '''arch_info.bin''' pour initialiser les différents champs de la structure '''boot_info_t''' du cluster de boot.
     * Il réveille les coeurs '''CP0''' de tous les autres clusters.
     * Il se met en attente jusqu'à ce que tous les autres '''CP0''' arrivent à ce point de rendez-vous en utilisant une barrière de synchronisation.
@@ -46 +46 @@
     * Il alloue sa pile de boot en initialisant son pointeur de pile à l'adresse '''0x600000''' dans l'espace adressable physique son cluster.
     * Il copie l'image du boot-loader et le fichier '''arch_info.bin''' aux mêmes adresses, respectivement '''0x100000''' et '''0x200000''', dans la mémoire physique locale. À partir d'ici, chaque '''CP0''' peut exécuter le code du boot-loader en local.
-    * Il copie ensuite l'image du noyau à l'adresse '''0x0''' de la mémoire physique locale de son cluster. 
+    * Il copie ensuite l'image du noyau à l'adresse '''0x4000''' de la mémoire physique locale de son cluster (c'est à dire, juste après les quatre pages réservées au prélasser). 
     * Il utilise la structure '''arch_info.bin''' locale pour initialiser les différents champs de la structure '''boot_info_t''' de son cluster. Cette tâche n'utilise que des accès mémoire locaux puisque toutes les informations nécessaires sont disponibles localement.
     * Il arrive à la barrière de synchronisation, et le dernier '''CP0''' débloque tous les '''CP0''' (y compris '''bscpu'''),