Changes between Version 15 and Version 16 of boot_procedure


Ignore:
Timestamp:
Feb 23, 2017, 11:20:10 AM (5 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • boot_procedure

    v15 v16  
    33[[PageOutline]]
    44
    5 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.
     5Le boot-loader d'ALMOS-MK, est chargé par le preloader, qui est spécifique à l'architecture cible, mais indépendant du système d'exploitation à charger. Le boot-loader a pour fonction de charger en mémoire le système ALMOS-MK, et il est dépend de l'architecture cible.
    66
    7 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:
    8     * Pour le code du pré-loader : une zone de '''1 Mo''', à partir de l'adresse 0x0.
     7== Boot-loader pour l'architecture TSAR ==
     8
     9Le 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.
     10
     11Par 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:
     12    * Pour le code du pré-loader : une zone de '''1 Mo''' dans le cluster (0,0), à partir de l'adresse 0x0.
    913    * Pour le code du boot-loader: une zone de mémoire physique de '''1Mo''', à partir de l'adresse 0x100000.
    1014    * Pour le fichier binaire '''arch_info.bin''': une zone de mémoire physique de '''2Mo''', à partir de l'adresse 0x200000.
     
    1418Notons que l'espace adressable physique de chaque cluster doit avoir une capacité au moins égale à '''6Mo'''.
    1519Toutes ces valeurs sont des paramètres de configuration du boot-loader, qui peuvent être redéfinis dans le fichier '''boot_config.h'''.
    16 La zone réservée au préloader n'est utilisée que si le préloaer n'est stocké dans une ROM externe.
     20La zone réservée au pré-loader n'est utilisée que si le pré-loader n'est stocké dans une ROM externe.
    1721
    18 Le chargement d'ALMOS-MK sur l'architecture TSAR se fait en 4 phases:
     22Le chargement d'ALMOS-MK sur l'architecture TSAR se fait donc en 4 phases:
    1923
    2024== 1. Phase de préchargement ==
    21 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).
     25Au 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).
    2226
    23    Voici le contenu de la mémoire du cluster de boot et des autres clusters (appelés ''banalus'') après cette première étape.
     27   Voici le contenu de la mémoire du cluster de boot et des autres clusters après cette première étape.
    2428   [[Image(Phys_Mem1.svg)]]
    2529
    2630== 2. Phase séquentielle ==
    27 Dans cette seconde phase, le '''bscpu''' exécute seul le code du boot-loader et réalise les tâches suivantes:
     31Dans cette seconde phase, le CP0 du cluster(0,0) exécute seul le code du boot-loader et réalise les tâches suivantes:
    2832    * 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'''.
    29     * Il initialise 2 périphériques: '''TTY0''' pour afficher les informations de débogage et '''IOC''' pour accéder aux fichiers sur disque.
     33    * 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.
    3034    * 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.
    3135    * Il utilise la structure '''arch_info.bin''' pour initialiser les différents champs de la structure '''boot_info_t''' du cluster de boot.
    32     * Il réveille les '''CP0''' de tous les clusters ''banalus''.
     36    * Il réveille les coeurs '''CP0''' de tous les autres clusters.
    3337    * 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.
    3438
    35    Voici le contenu de la mémoire du cluster de boot et des autres clusters (appelés ''banalus'') après ce deuxième temps.
     39   Voici le contenu de la mémoire du cluster de boot et des autres clusters après cette deuxième étape.
    3640   [[Image(Phys_Mem2.svg)]]
    3741
    3842== 3. Phase partiellement parallèle ==
    39 Dans chaque cluster, le core '''CP0''', réveillé par le core '''bscpu''', sort du preloader et exécute le code du boot-loader qui se trouve toujours stocké dans la mémoire physique du cluster( 0,0), en effectuant les tâches suivantes:
    40     * Il analyse le contenu de la structure '''arch_info.bin''' (toujours stocké dans la mémoire physique du cluster de boot) en parcourant le tableau de descripteurs de core pour retrouver son identificateur de cluster '''cxy'''. Notons que cette étape est exécutée parallèlement par tous les '''CP0''', ce qui entraine une contention au banc mémoire contenant ce tableau de descripteurs de core.
     43Dans chaque cluster, le coeur '''CP0''', réveillé par le CP0 du cluster de boot, sort du preloader et exécute le code du boot-loader qui se trouve toujours stocké dans la mémoire physique du cluster(0,0), pour effectuer les tâches suivantes:
     44    * Il analyse le contenu de la structure '''arch_info.bin''' (toujours stocké dans la mémoire physique du cluster de boot) en parcourant le tableau de descripteurs de core pour retrouver son identificateur de cluster '''cxy'''. Notons que cette étape est exécutée parallèlement par tous les '''CP0''', ce qui entraine une contention au banc mémoire contenant ce tableau des descripteurs des coeurs.
    4145    * Il peut maintenant, à partir de son '''cxy''', mettre à jour ses registres d'extension d'adresse pour accéder à la mémoire physique du cluster dans lequel il se trouve. Néanmoins, il continue à accéder au code de boot stocké dans le cluster (0,0) tant que le code du boot-loader n'a pas été copiée dans son banc de mémoire local.
    4246    * Il alloue sa pile de boot en initialisant son pointeur de pile à l'adresse '''0x600000''' dans l'espace adressable physique son cluster.
     
    4852    * Les '''CP0''' se mettent en attente jusqu'à ce que tous les autres cores arrivent à ce point de rendez-vous en utilisant le mécanisme de barrière de synchronisation.
    4953
    50    Voici le contenu de la mémoire du cluster de boot et des autres clusters (appelés ''banalus'') après ce troisième temps.
     54   Voici le contenu de la mémoire du cluster de boot et des autres clusters (appelés ''banalus'') après cette troisième étape.
    5155   [[Image(Phys_Mem3.svg)]]
    5256
    5357== 4. Phase totalement parallèle ==
    54 Chaque core CPi ('''lid''' non nul), réveillé par le CP0 local de son cluster, sort du code du preloader et exécute le boot-loader dans le cluster de boot puisque ses registres d'extension d'adresse ne sont pas encore mis à jour. Une fois sortis du preloader, ces cores décrémentent le compteur de la barrière de synchronisation et débloquent les '''CP0'''. Tous ces '''CP0''' sauf un, se mettent tout de suite en attente jusqu'à ce que les '''CPi''' finissent leur exécution du boot-loader. Le seul '''CP0''' qui n'arrive pas encore à cette barrière de synchronisation, le '''bscpu''', peut maintenant écraser le code du preloader en déplaçant l'image du noyau à l'adresse '''0x0''' de l'espace adressable physique du cluster de boot, puisque tous les cores sont déjà sortis du preloader. Il rejoint ensuite les autres '''CP0''' au dernier point de rendez-vous dans le boot-loader. Les '''CPi''', quant à eux, exécutent, pour le moment, le code du boot-loader se trouvant dans le cluster de boot car leurs registres d'extension d'adresse ont toujours la valeur 0 par défaut. Chacun de ces '''CPi''' effectue les étapes suivantes:
     58Chaque core CPi ('''lid''' non nul), réveillé par le CP0 local de son cluster, sort du code du preloader et exécute le boot-loader dans le cluster de boot puisque ses registres d'extension d'adresse ne sont pas encore mis à jour. Une fois sortis du preloader, ces cores décrémentent le compteur de la barrière de synchronisation et débloquent les '''CP0'''. Tous ces '''CP0''' sauf un, se mettent tout de suite en attente jusqu'à ce que les '''CPi''' finissent leur exécution du boot-loader. Le seul '''CP0''' qui n'arrive pas encore à cette barrière de synchronisation, celui du cluster(0,0), peut maintenant écraser le code du preloader en déplaçant l'image du noyau à l'adresse '''0x0''' de l'espace adressable physique du cluster(0,0), puisque tous les cores sont déjà sortis du preloader. Il rejoint ensuite les autres '''CP0''' au dernier point de rendez-vous dans le boot-loader. Les '''CPi''', quant à eux, exécutent, pour le moment, le code du boot-loader se trouvant dans le cluster de boot car leurs registres d'extension d'adresse ont toujours la valeur 0 par défaut. Chacun de ces '''CPi''' effectue les étapes suivantes:
    5559    * Il analyse le contenu de '''arch_info.bin''' (dans l'espace adressable physique du cluster de boot) en parcourant le tableau de descripteurs de core pour retrouver son identificateur de cluster '''cxy''' ainsi que son identificateur de core local dans son cluster '''lid'''. Notons que cette étape est exécutée parallèlement par tous les '''CPi''', ce qui entraine une contention, encore plus forte que celle créée par les accès parallèles des '''CP0''', au banc mémoire contenant ce tableau de descripteurs de core .
    5660    * Il peut maintenant, à partir de son '''cxy''', mettre à jour les valeurs dans ses registres d'extension d'adresse de code et de données. Comme le '''CP0''' du même cluster a déjà copié les informations nécessaires dans le banc mémoire local aux mêmes adresses que du cluster de boot, il peut toujours exécuter le code du boot-loader en local.
     
    6367   [[Image(Phys_Mem4.svg)]]
    6468
    65 Arrivé à ce point, le boot-loader a fini son travail, les informations de description de la l'architecture matérielle contenues dans '''arch_info.bin''' ont été transformées dans la variable globale de type '''boot_info_t''' du noyau, stockée dans le segment data du noyau. Dans chaque cluster, ALMOS-MK peut utiliser tout l'espace adressable physique occupé antérieurement par l'image du boot-loader, '''arch_info.bin''' et les piles de boot. La seule zone de mémoire persistante est l'image du noyau elle-même (les segments ''kcode'' et ''kdata''), stockée à l'adresse '''0x0''' dans tous les clusters.
     69Arrivé à ce point, le boot-loader a fini son travail, la description de la l'architecture matérielle contenue dans '''arch_info.bin''' a été analysée et stockée dans la variable globale de type '''boot_info_t''' du noyau, stockée dans le segment data du noyau. Dans chaque cluster, ALMOS-MK peut utiliser tout l'espace adressable physique occupé antérieurement par l'image du boot-loader, '''arch_info.bin''' et les piles de boot. La seule zone de mémoire persistante est l'image du noyau elle-même (les segments ''kcode'' et ''kdata''), stockée à l'adresse '''0x0''' dans tous les clusters.