Changes between Version 1 and Version 2 of boot_procedure


Ignore:
Timestamp:
Jul 21, 2016, 6:59:15 PM (8 years ago)
Author:
vusontuan
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • boot_procedure

    v1 v2  
    1 ==
     1Le 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.
     2
     3Pour 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:
     4    * Au fichier binaire correspondant au noyau: une zone de mémoire physique de '''1Mo'''.
     5    * Au fichier binaire correspondant au boot-loader: une zone de mémoire physique de '''1Mo'''.
     6    * 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.
     7    * À chaque core une pile de boot temporaire pour exécuter le code C du boot-loader de taille '''4Ko'''.
     8Toutes ces quantités de mémoire sont des paramètres globaux de configuration modifiables du boot-loader.
     9 
     10La procédure de chargement d'ALMOS-MK fonctionnant sur l'architecture TSAR se fait en 4 temps:
     111. 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). Voici le contenu de la mémoire du cluster de boot et des autres clusters (appelés ''banalus'') après ce premier temps.
     12
     132. Le '''bscpu''' exécute le code du boot-loader et réalise plusieurs tâches:
     14    * 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 '''0x500000'''. Notons que ce choix entraine une contrainte: l'espace adressable physique de chaque cluster doit avoir au moins '''5Mo''', ce qui ne pose pas de problème particulier aux machines actuelles.
     15    * Ensuite, il charge, toujours en mémoire locale du cluster de boot, l'image binaire du noyau d'ALMOS-MK ainsi que le fichier binaire '''arch_info.bin''', respectivement à l'adresse '''0x200000''' et '''0x300000''', juste au dessus du segment mémoire correspondant à l'image du boot-loader.
     16    * Il extrait des informations depuis '''arch_info.bin''' pour initialiser les différents champs de la structure '''boot_info_t''' du cluster de boot.
     17    * Il réveille les '''CP0''' de tous les clusters ''banalus''.
     18    * Il se met en attente jusqu'à ce que tous les autres CP0 arrivent à ce point de rendez-vous.
     19   Voici le contenu de la mémoire du cluster de boot et des autres clusters (appelés ''banalus'') après ce deuxième temps.
     20
     213. Chaque '''CP0''', après avoir été réveillé par '''bscpu''', sort du code du preloader et exécute le boot-loader qui se trouve toujours dans le cluster de boot en effectuant les différentes étapes ci-dessous:
     22    * Il
     23    * Il alloue sa pile de boot en initialisant son pointeur de pile à l'adresse
     24
     25