Boot procedure

The ALMOS-MKH boot procédure can be decomposed in two phases:

• The architecture dependent phase, implemented by the boot_loader procedure.
• The architecture indépendant phase, inplemented by the kernel-init procedure.

As the generic (i.e. architecture independent) kernel initialization procedure is executed in parallel by all kernel instances in all clusters containing at least one core and one memory bank, the main task of the boot-loader is to load - in each cluster - a local copy of the ALMOS-MKH kernel code, including a description of the hardware architecture, contained in the boot_info_t data-structure.

This structure is build by the boot-loader and stored at the beginning of the local copy of the kdata segment. It contains both general and cluster specific informations:

• general hardware architecture features : number of clusters, the topology, etc.
• available external (shared) peripherals : types and features.
• number of cores in cluster,
• available internal (private) peripherals in cluster : types and features.
• available physical memory in cluster.

To build the various boot_info_t structures (one per cluster), the boot-loader uses the arch_info_t binary structure, that is described in the This boot_info_t structure is defined in the boot_info.h file.

This section describes successively the ALMOS-MKH boot loader for the TSAR architecture, the ALMOS-MKH boot loader for the I86 architecture, and the generic ALMOS-MKH kernel initialization procedure.

Boot-loader for the TSAR architecture

The TSAR boot-loader uses an OS-independant pre-loader, stored in an external ROM, and in charge of loading the TSAR boot-loader code from an external block-device to the memory. This preloaded is specific for the TSAR architecture, but independent on the Operating System. It is used by ALMOS-MKH, but also by LINUX, NetBSD, or the GIET-VM.

the shared resources (such as the 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.

Par 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 utilisés pendant le démarrage du système.

• Pour le code du pré-loader : une zone de 16 Ko, à 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 fichier binaire arch_info.bin: une zone de mémoire physique de 2Mo, à partir de l'adresse 0x200000.
• Pour le code du noyau: une zone de 1Mo, à partir de l'adresse 0x400000.
• Pour les piles d'exécutions des cores: une zone mémoire de 1Mo, à 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. Les quatre premières pages (16 Koctets) réservées au pré-loader ne sont utilisée que dans le cluster 0, et uniquement si le pré-loader n'est pas stocké dans une ROM externe.

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

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 coeurs de la plateforme ne peuvent accéder qu'à l'espace adressable physique du cluster(0,0), qui est donc 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).

Voici le contenu de la mémoire du cluster de boot et des autres clusters après cette première étape.

2. Phase séquentielle

Dans cette seconde phase, le CP0 du cluster(0,0) 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. La taille de cette pile temporaire est aussi un paramètre de configuration. Par défaut, le pointeur de pile du core CP0 de chaque cluster (lid = 0) est initialisé à l'adresse 0x600000.
• Le CP0 cu cluster (0,0) initialise 2 périphériques: TTY (canal 0) 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 utilise les informations contenues dans la structure arch_info.bin pour initialiser les différents champs de la structure boot_info_t du cluster de boot.
• Il réveille les coeurs CP0 de tous les autres clusters.
• 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.

Voici le contenu de la mémoire du cluster de boot et des autres clusters après cette deuxième étape.

3. Phase partiellement parallèle

Dans 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:

• 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.
• 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.
• Il alloue sa pile de boot en initialisant son pointeur de pile à l'adresse 0x600000 dans l'espace adressable physique son cluster.
• Il copie l'image du boot-loader et le fichier arch_info.bin aux mêmes adresses, respectivement 0x100000 et 0x200000, dans la mémoire physique locale. À partir d'ici, chaque CP0 peut exécuter le code du boot-loader en local.
• Il copie ensuite l'image du noyau à l'adresse 0x4000 de la mémoire physique locale de son cluster (c'est à dire, juste après les quatre pages réservées au prélasser).
• Il utilise la structure arch_info.bin locale pour initialiser les différents champs de la structure boot_info_t de son cluster. Cette tâche n'utilise que des accès mémoire locaux puisque toutes les informations nécessaires sont disponibles localement.
• Il arrive à la barrière de synchronisation, et le dernier CP0 débloque tous les CP0 (y compris bscpu),
• Chaque CP0 envoie des IPIs pour réveiller 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 cette troisième étape.

4. Phase totalement parallèle

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, 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:

• 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.

Arrivé à 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.

Boot-loader for the I86 architecture

TODO

Generic ALMOS-MKH initialisation procedure