Changes between Version 5 and Version 6 of boot_procedure

Timestamp:

Jul 22, 2016, 2:58:43 PM (8 years ago)

Author:

vusontuan

Comment:

--

boot_procedure

@@ -14 +14 @@
 
 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 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 '''0x600000'''. Notons que ce choix entraine une contrainte: l'espace adressable physique de chaque cluster doit avoir au moins '''6Mo''', 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. 
@@ -26 +26 @@
     * 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 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.
@@ -39 +39 @@
     * 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).
+    * 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.