| 6 | | * Pour le code du noyau: une zone de '''1Mo''', à partir de l'adresse 0x200000. |
| 7 | | * Pour le fichier binaire '''arch_info.bin''': une zone de mémoire physique de '''2Mo''', à partir de l'adresse 0x300000. |
| 8 | | * Pour les piles d'exécutions des cores: une zone mémoire de '''1Mà''', à partir de l'adresse 0x500000. |
| | 6 | * Pour le fichier binaire '''arch_info.bin''': une zone de mémoire physique de '''2Mo''', à partir de l'adresse 0x200000. |
| | 7 | * Pour le code du noyau: une zone de '''1Mo''', à partir de l'adresse 0x400000. |
| | 8 | * Pour les piles d'exécutions des cores: une zone mémoire de '''1Mo''', à partir de l'adresse 0x500000. |
| 33 | | 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: |
| 34 | | * 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. |
| 35 | | * 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. |
| 36 | | * 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). |
| 37 | | * 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. |
| 38 | | * 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 | | * 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. |
| 40 | | * 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. |
| 41 | | * 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. |
| | 33 | == 3. Phase partiellement parallèle == |
| | 34 | Dans chaque cluster, le core '''CP0''', réveillé par le core '''bscpu''', 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), en effectuant les tâches suivantes: |
| | 35 | * 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 de descripteurs de core. |
| | 36 | * 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. |
| | 37 | * Il alloue sa pile de boot en initialisant son pointeur de pile à l'adresse '''0x600000''' dans l'espace adressable physique son cluster. |
| | 38 | * 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. |
| | 39 | * Il copie ensuite l'image du noyau à l'adresse '''0x0''' de la mémoire physique locale de son cluster. |
| | 40 | * 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. |
| | 41 | * Il arrive à la barrière de synchronisation, et le dernier '''CP0''' débloque tous les '''CP0''' (y compris '''bscpu'''), |
| | 42 | * Chaque CP0 envoie des IPIs pour réveiller les autres cores dans son cluster local. |
| 47 | | 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: |
| | 48 | == 4. Phase totalement parallèle == |
| | 49 | 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, 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: |
