Changes between Version 9 and Version 10 of boot_procedure

Timestamp:

Jan 11, 2017, 10:24:21 AM (8 years ago)

Author:

alain

Comment:

--

boot_procedure

@@ -1 +1 @@
 Le boot-loader, en combinaison avec le preloader (qui est propre à chaque architecture matérielle), permettent de charger le système ALMOS-MK. Pour pouvoir minimiser la partie écrite en assembleur (qui dépend donc de l'architecture matérielle), l'initialisation d'ALMOS-MK (réalisée par la fonction '''kern_init()''') est totalement découplée de son chargement. Le rôle principal du boot-loader d'ALMOS-MK est de charger en mémoire l'image du noyau du système. 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 les structures de données '''boot_info_t''' qui sont rangées au début du segment de données '''kdata''' du noyau et seront utilisées par '''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 des informations de la partie opérative de l'architecture. 
 
-Pour choisir une stratégie de placement des différents fichiers binaires et des structures mémoire, il faut définir une borne maximale pour chacun de ces derniers. On réserve:
+Par convention, on définit des zones de longueur fixe pour les différents fichiers binaires et structures de données en mémoire: 
     * Au fichier binaire correspondant au noyau: une zone de mémoire physique de '''1Mo'''.
     * Au fichier binaire correspondant au boot-loader: une zone de mémoire physique de '''1Mo'''.
-    * Au fichier binaire '''arch_info.bin''': une zone de mémoire physique de '''2Mo''', puisque ce fichier peut nécessiter plus de mémoire si l'architecture matérielle comporte plus de clusters.
+    * Au fichier binaire '''arch_info.bin''': une zone de mémoire physique de '''2Mo'''.
     * À chaque core une pile de boot temporaire pour exécuter le code C du boot-loader de taille '''4Ko'''.
-Toutes ces quantités de mémoire sont des paramètres globaux de configuration modifiables du boot-loader.
+Toutes ces valeurs sont des paramètres de configuration du boot-loader définis dans le fichier '''boot_config.h'''.
  
-La procédure de chargement d'ALMOS-MK fonctionnant sur l'architecture TSAR se fait en 4 temps:
-1. Au démarrage, les valeurs dans les registres d'extension d'adresse de code et de données 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 de '''lid''' 0 du cluster de boot (appelé core '''bscpu''') charge, en mémoire locale du cluster de boot à 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 des IPI (Inter-Processor Interrupt).
+Le chargement d'ALMOS-MK sur l'architecture TSAR se fait en 4 étapes:
+== 1. préloader == 
+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 de '''lid''' 0 du cluster (0,0), appelé '''bscpu''', charge en mémoire locale du cluster de boot à 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 des IPI (Inter-Processor Interrupt).
 
    Voici le contenu de la mémoire du cluster de boot et des autres clusters (appelés ''banalus'') après ce premier temps.
    [[Image(Phys_Mem1.svg)]]
 
-2. Le '''bscpu''' exécute le code du boot-loader et réalise plusieurs tâches:
-    * Il initialise tout d'abord son pointeur de pile pour pouvoir exécuter du code C au lieu de l'assembleur. L'adresse de base de cette pile temporaire est aussi un paramètre configurable. Par défaut, les piles de boot des cores de '''lid''' 0 (appelés '''CP0''') de tous les clusters commencent à l'adresse '''0x600000'''. Notons que ce choix entraine une contrainte: l'espace adressable physique de chaque cluster doit avoir au moins '''6Mo''', ce qui ne pose pas de problème particulier aux machines actuelles.
+== 2. phase séquentielle ==
+Le '''bscpu''' exécute le code du boot-loader et réalise plusieurs tâches:
+    * Il initialise son pointeur de pile pour pouvoir exécuter du code C au lieu de l'assembleur. L'adresse de base de cette pile temporaire est aussi un paramètre configurable. Par défaut, les piles de boot des cores de '''lid''' 0 (appelés '''CP0''') de tous les clusters commencent à l'adresse '''0x600000'''. Notons que ce choix entraine une contrainte: l'espace adressable physique de chaque cluster doit avoir au moins '''6Mo''', ce qui ne pose pas de problème particulier aux machines actuelles.
     * Il initialise 2 périphériques: '''TTY0''' pour afficher les informations de débogage et '''IOC''' pour pouvoir charger les fichiers binaires depuis le 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.