Changes between Version 13 and Version 14 of boot_procedure

Timestamp:

Jan 11, 2017, 11:43:46 AM (7 years ago)

Author:

alain

Comment:

--

boot_procedure

@@ -1 @@
-Le boot-loader d'ALMOS-MK, en combinaison avec le preloader (qui est spécifique à l'architecture TSAR, mais indépendant du système d'exploitation à charger), a pour fonction de charger en mémoire le système ALMOS-MK. Au passage, il récupère les informations décrivant la plateforme matérielle contenues dans le fichier binaire '''arch_info.bin''' et les utilise pour construire - dans chaque cluster - la structure de données '''boot_info_t'''. Cette structure est utilisée - dans chaque cluster - par l'instance locale deu noyau ALMOS-MK, puisqu'elle décrit les composants matériels disponibles dans le cluster ainsi que les caractéristiques générales de la plateforme. Cette structure est qui rangée au début du segment de données '''kdata''' du noyau et est utilisée par la fonction '''kern_init()'''. Ces informations en entrée et en sortie du boot-loader peuvent sembler redondantes mais cette traduction est indispensable: elle permet au système de vérifier le bon fonctionnement de la plateforme matérielle et de détecter les pannes dues au vieillissement du matériel. En effet, les structures '''boot_info_t''' générées en sortie du boot-loader ne contiennent que les composants matériels effectivement utilisables par le noyau. 
+= Boot procedure =
+
+[[PageOutline]]
+
+Le boot-loader d'ALMOS-MK, en combinaison avec le preloader (qui est spécifique à l'architecture TSAR, mais indépendant du système d'exploitation à charger), a pour fonction de charger en mémoire le système ALMOS-MK. Au passage, il récupère les informations décrivant la plateforme matérielle contenues dans le fichier binaire '''arch_info.bin''' et les 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 par la fonction '''kern_init()'''. Ces informations en entrée et en sortie du boot-loader peuvent sembler redondantes mais cette traduction est indispensable: elle 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. En effet, les structures '''boot_info_t''' générées construites par le boot-loader ne contiennent que les composants matériels effectivement utilisables par le noyau. 
 
 Par convention, on définit - dans chaque cluster - des zones de mémoire physique de longueur fixe pour les différents fichiers binaires et structures de données: 
@@ -7 +11 @@
     * Pour le code du noyau: une zone de '''1Mo''', à partir de l'adresse 0x400000.
     * Pour les piles d'exécutions des cores: une zone mémoire de '''1Mo''', à partir de l'adresse 0x500000.
+
 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'''.
@@ -14 +19 @@
 
 == 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 cores de la plateforme travaillent par défaut dans le même espace adressable physique: celui du cluster de '''cxy''' (0, 0) appelé cluster de boot. Tous les cores commencent par exécuter le code du preloader (qui se situe à l'adresse '''0x0''' de l'espace adressable physique du cluster de boot), mais ils réalisent des tâches différentes: le core CP0 du cluster (0,0), appelé '''bscpu''', 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 correspondant 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 cores de la plateforme travaillent par défaut dans le même espace adressable physique: celui du cluster de '''cxy''' (0, 0) appelé cluster de boot. Tous les cores commencent par exécuter le code du preloader, mais ils réalisent des tâches différentes: le core CP0 du cluster (0,0), appelé '''bscpu''', 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 (appelés ''banalus'') après cette première étape.