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. 

Par convention, on définit des zones de longueur fixe pour les différents fichiers binaires et structures de données en mémoire physique: 
    * Pour le code du pré-loader : une zone de '''1 Mo''', à partir de l'adresse 0x0.
    * Pour le code du boot-loader: une zone de mémoire physique de '''1Mo''', à partir de l'adresse 0x100000.
    * Pour le code du noyau: une zone de '''1Mo''', à partir de l'adresse 0x200000.
    * Pour le fichier binaire '''arch_info.bin''': une zone de mémoire physique de '''2Mo''', à partir de l'adresse 0x300000.
    * Pour les piles d'exécutions des cores: une zone mémoire de '''1Mà''', à partir de l'adresse 0x500000.
Notons que l'espace adressable physique de chaque cluster doit avoir une capacité au moins égale à '''6Mo'''.
Toutes ces valeurs sont des paramètres de configuration du boot-loader, qui peuvent être redéfinis dans le fichier '''boot_config.h'''.
La zone réservée au préloader n'est utilisée que si le préloaer n'est stocké dans une ROM externe. 

Le chargement d'ALMOS-MK sur l'architecture TSAR se fait en 4 étapes:

== 1. Phase de préchargement == 
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 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).

   Voici le contenu de la mémoire du cluster de boot et des autres clusters (appelés ''banalus'') après cette première étape.
   [[Image(Phys_Mem1.svg)]]

== 2. Phase séquentielle ==
Dans cette seconde phase, le '''bscpu''' exécute seul le code du boot-loader et réalise les tâches suivantes:
    * 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'''. 
    * Il initialise 2 périphériques: '''TTY0''' pour afficher les informations de débogage et '''IOC''' pour accéder aux fichiers sur 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.
   [[Image(Phys_Mem2.svg)]]

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''' (dans l'espace adressable 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.
    * 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 '''0x600000''' 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.
   [[Image(Phys_Mem3.svg)]]

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é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:
    * 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 .
    * 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 '''0x600000 - 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 les '''CP0''', 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.
   [[Image(Phys_Mem4.svg)]]

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 de type '''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.