| 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. |
| | 2 | |
| | 3 | 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: |
| | 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'''. |
| | 8 | Toutes ces quantités de mémoire sont des paramètres globaux de configuration modifiables du boot-loader. |
| | 9 | |
| | 10 | La procédure de chargement d'ALMOS-MK fonctionnant sur l'architecture TSAR se fait en 4 temps: |
| | 11 | 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). Voici le contenu de la mémoire du cluster de boot et des autres clusters (appelés ''banalus'') après ce premier temps. |
| | 12 | |
| | 13 | 2. 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 | |
| | 21 | 3. 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 | |
