Changes between Version 57 and Version 58 of boot_procedure

Timestamp:

Mar 2, 2019, 5:07:11 PM (6 years ago)

Author:

alain

Comment:

--

boot_procedure

@@ -116 +116 @@
    * '''argument''' : the kernel_init() function unique argument is a pointer on the ''boot_info_t'' structure, that is the first variable in the ''data'' segment.
    * '''stack pointer''' : In each cluster an array of idle thread descriptors, indexed by the local core index, is defined in the ''kdata''segment, on top of the ''boot_info_t'' structure. For any thread, the thread descriptor contains the kernel stack, and this is used to initialize the stack pointer. 
-   * '''base register''' : in each core, the cp0_ebase register, defines the kernel entry point in case of interrupt, exception, or syscall, and must be initialized.
+   * '''base register''' : in each core, the cp0_ebase register, defines the kernel entry point in case of interrupt, exception, or syscall, and must be initialized. '''[TO BE DONE in kernel_init()]'''
    * '''status register''' : in each core, the cp0_sr register defines the core state, and must be initialized  (UM bit reset / IE bit reset / BEV bit reset ).
 
-Moreover, all core[cxy][lid] with (lid != 0) must activate the instruction MMU to use both the local copy of the boot-loader code, and the local copy of the kernel.
-    * all core[cxy][lid] in cluster cxy synchronize on a local barrier.
-    * each core in cluster cxy initialize the following registers before jumping to kernel_init function:
-       * status register            : cp0_sr   <= reset BEV bit 
-       * kernel_init() argument : a0  <= boot_info
-       * stack pointer              : sp  <=
-       * program counter        : cp0_ebase  <= kernel_entry  
-
-All cores other than core[cxy][0] This 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()'''. 
-/
 At this point, the boot-loader completed its job: 
  * The kernel code ''kcode'' and ''kdata'' segments are loaded - in all clusters - in the first ''offset'' physical pages.
@@ -146 +130 @@
 == D) __Generic kernel initialization procedure__ ==
 
-The kernel_init( boot_info_t * info ) function is the kernel entry point when the boot_loader transfer control to the kernel.
-The ''info'' argument is a pointer on the fixed size boot_info_t structure, that is stored in the data kernel segment.
+The kernel_init( boot_info_t * info ) function is the kernel entry point when the boot_loader transfer control to the kernel. The argument is a pointer on the fixed size boot_info_t structure, that is stored in the data kernel segment.
 
 All cores execute this procedure in parallel, but some tasks are only executed by the CP0 core.