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:

• 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.
• À 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. 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). Voici le contenu de la mémoire du cluster de boot et des autres clusters (appelés banalus) après ce premier temps.

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 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.
   • 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.
   • Il extrait des informations depuis arch_info.bin pour initialiser les différents champs de la structure boot_info_t du cluster de boot.
   • Il réveille les CP0 de tous les clusters banalus.
   • Il se met en attente jusqu'à ce que tous les autres CP0 arrivent à ce point de rendez-vous en utilisant le mécanisme de barrière de synchronisation.
   Voici le contenu de la mémoire du cluster de boot et des autres clusters (appelés banalus) après ce deuxième temps.

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:
   • Il analyse le contenu de arch_info.bin 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.
   • Il peut maintenant, à partir de son cxy, mettre à jour les valeurs dans ses registres d'extension d'adresse de code et de données. Cela l'oblige à exécuter la suite du code du boot-loader en distant, jusqu'à ce que l'image du boot-loader soit copiée dans son banc de mémoire local.
   • Il alloue sa pile de boot en initialisant son pointeur de pile à l'adresse 0x500000 dans l'espace adressable physique locale de son cluster (grâce à la nouvelle valeur dans le registre d'extension d'adresse de code).
   • Il copie l'image du boot-loader et le fichier arch_info.bin aux mêmes adresses, respectivement 0x100000 et 0x200000, mais dans l'espace adressable physique locale de son cluster. À partir d'ici, chaque CP0 peut exécuter le code du boot-loader en local.
   • Il copie ensuite l'image du noyau à l'adresse 0x0 de l'espace adressable physique locale de son cluster. L'image du boot-loader locale commençant à l'adresse 0x100000, suffisamment de place (1Mo) a été réservée pour l'image du noyau.
   • Il extrait des informations depuis arch_info.bin pour initialiser les différents champs de la structure boot_info_t de son cluster. Cette étape n'est faite qu'avec des accès mémoire locaux puisque les informations nécessaires sont déjà recopiées dans la mémoire du cluster en question dans l'étape précédente.
   • Il arrive au point de rendez-vous avec bscpu, décrémente le compteur de la barrière de synchronisation et se met en attente.
   • Dès que le dernier CP0 arrive à ce point et débloque tous les CP0 (y compris bscpu), chacun d'eux envoie des IPIs pour réveiller tous les autres cores dans son cluster local.
   • 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.
   Voici le contenu de la mémoire du cluster de boot et des autres clusters (appelés banalus) après ce troisième temps.

4. Chaque core de lid non nul (appelé CPi), après avoir été 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 code 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écute, 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:
   • Il analyse le contenu de arch_info.bin 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 .
   • 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.
   • Il alloue sa pile de boot en initialisant son pointeur de pile à l'adresse 0x500000 - 4K*lid dans l'espace adressable physique locale de son cluster (grâce à la nouvelle valeur dans le registre d'extension d'adresse de code).
   • La structure boot_info_t du cluster étant déjà initialisée, chacun des CPi ne fait que vérifier les informations qui le concernent.
   • Il arrive finalement au point de rendez-vous avec tous lesCP0, décrémente le compteur de la barrière de synchronisation et se met en attente.
   • Dès que le dernier core arrive à ce point et débloque les autres, tous les cores se branchent à la fonction kern_init().
   Voici le contenu de la mémoire dans tous les clusters à la fin de la phase de boot, juste avant d'entrer dans le noyau d'ALMOS-MK.

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 les variables globales boot_info_t du noyau, ALMOS-MK peut récupérer 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, commencé à l'adresse 0x0 dans tous les clusters.