Changes between Version 10 and Version 11 of boot_procedure


Ignore:
Timestamp:
Jan 11, 2017, 10:51:08 AM (8 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • boot_procedure

    v10 v11  
    11Le 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.
    22
    3 Par convention, on définit des zones de longueur fixe pour les différents fichiers binaires et structures de données en mémoire:
    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'''.
    7     * À chaque core une pile de boot temporaire pour exécuter le code C du boot-loader de taille '''4Ko'''.
    8 Toutes ces valeurs sont des paramètres de configuration du boot-loader définis dans le fichier '''boot_config.h'''.
    9  
     3Par convention, on définit des zones de longueur fixe pour les différents fichiers binaires et structures de données en mémoire physique:
     4    * Pour le code du pré-loader : une zone de '''1 Mo''', à partir de l'adresse 0x0.
     5    * Pour le code du boot-loader: une zone de mémoire physique de '''1Mo''', à partir de l'adresse 0x100000.
     6    * Pour le code du noyau: une zone de '''1Mo''', à partir de l'adresse 0x200000.
     7    * Pour le fichier binaire '''arch_info.bin''': une zone de mémoire physique de '''2Mo''', à partir de l'adresse 0x300000.
     8    * Pour les piles d'exécutions des cores: une zone mémoire de '''1Mà''', à partir de l'adresse 0x500000.
     9Notons que l'espace adressable physique de chaque cluster doit avoir une capacité au moins égale à '''6Mo'''.
     10Toutes ces valeurs sont des paramètres de configuration du boot-loader, qui peuvent être redéfinis dans le fichier '''boot_config.h'''.
     11La zone réservée au préloader n'est utilisée que si le préloaer n'est stocké dans une ROM externe.
     12
    1013Le chargement d'ALMOS-MK sur l'architecture TSAR se fait en 4 étapes:
    11 == 1. préloader ==
    12 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).
    1314
    14    Voici le contenu de la mémoire du cluster de boot et des autres clusters (appelés ''banalus'') après ce premier temps.
     15== 1. Phase de préchargement ==
     16Au 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).
     17
     18   Voici le contenu de la mémoire du cluster de boot et des autres clusters (appelés ''banalus'') après cette première étape.
    1519   [[Image(Phys_Mem1.svg)]]
    1620
    17 == 2. phase séquentielle ==
    18 Le '''bscpu''' exécute le code du boot-loader et réalise plusieurs tâches:
    19     * 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.
    20     * 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.
     21== 2. Phase séquentielle ==
     22Dans cette seconde phase, le '''bscpu''' exécute seul le code du boot-loader et réalise les tâches suivantes:
     23    * 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'''.
     24    * Il initialise 2 périphériques: '''TTY0''' pour afficher les informations de débogage et '''IOC''' pour accéder aux fichiers sur disque.
    2125    * 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.
    2226    * Il extrait des informations depuis '''arch_info.bin''' pour initialiser les différents champs de la structure '''boot_info_t''' du cluster de boot.