Changes between Version 45 and Version 46 of boot_procedure


Ignore:
Timestamp:
Feb 27, 2019, 10:35:31 PM (5 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • boot_procedure

    v45 v46  
    9191    * Then it copies in the KERNEL_CORE zone the ''kcode'' and ''data'' segments, using the addresses contained in the .elf file (identity mapping).
    9292    * The core[0][0] load in the ARCH_INFO zone the ''arch_info.bin'' file from the disk file system.
    93     * Then it builds from this ''arch_info.bin'' file the specific ''boot_info_t'' structure for cluster 0, and stores it in the ''kdata'' segment.
     93    * Then it builds from this ''arch_info.t'' structure the specific ''boot_info_t'' structure for cluster 0, and stores it in the ''kdata'' segment.
    9494    * The core[0][0] send IPIs to activate all cores [i][0] in all other clusters.
    9595   
    … …  
    101101This phase is executed by all core[cxy][0], but the core[0][0].
    102102
    103 At this point, all INSTRUCTION address extension registers point on cluster(0,0), but the DATA extension registers point already on the local cluster to use the local stack. To access the bootloader global variables the core[cxy][0] must first copy the boot code (data and instructions) in the BOOT_CORE zone of cluster cxy.
     103At this point, all INSTRUCTION address extension registers point on cluster(0,0), but all DATA extension registers point already on the local cluster to use the local stack. To access the bootloader global variables the core[cxy][0] must first copy the boot code (data and instructions) in the BOOT_CORE zone of cluster cxy.
     104
     105Therefore, the core[cxy][0] exécutes the boot-loader code (stored in physical memory of cluster 0), to do he following tasks:
     106    * The core[cxy][0] copies the boot-loader code from cluster 0 to BOOT_CORE zone in cluster cxy.
     107    * The core[cxy][0] copies the ''arch_info.bin'' structure from cluster 0 to ARCH_INFO zone in cluster cxy.
     108    * The core[cxy][0] copies the ''kcode'' and ''kdata'' segments from cluster 0 to KERNEL_CODE zone in cluster cxy.
     109    * The core[cxy][0] builds from the ''arch_info.t'' the specific ''boot_info_t'' structure for cluster cxy, and stores it in the local ''kdata'' segment.
     110    * Il arrive à la barrière de synchronisation, et le dernier '''CP0''' débloque tous les '''CP0''' (y compris '''bscpu'''),
     111    *  All core[cxy][0], including core[0][0], synchronize using a global barrier.
     112    * in each cluster cxy, the core[cxy][0] activates the other cores that are still blocked in the preloaded.
     113
     114This shows the memory content after this phase. 
     115   [[Image(Phys_Mem3.svg)]]
     116
     117=== B4. Boot-loader fully parallel phase ===
     118
     119Chaque 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:
     120    * 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 .
     121    * 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.
     122    * 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).
     123    * 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.
     124    * 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.
     125    * Dès que le dernier core arrive à ce point et débloque les autres, tous les cores se branchent à la fonction '''kern_init()'''.
     126
     127There is the physical memory content at boot completion.
     128
     129   [[Image(Phys_Mem4.svg)]]
     130
     131At this point, the boot-loader completed its job:
     132 * The kernel code ''kcode'' and ''kdata'' segments are loaded - in all clusters - in the first ''offset'' physical pages.
     133 * The hardware architecture described by the '''arch_info.bin'''file has been analyzed, and copied - in each cluster - in the '''boot_info_t''' structure, stored in the kdata segment.
     134 * Each  local kernel instance can use all the physical memory that is not used to store the kernel ''kcode'' and ''kdata'' segments themselves.
     135
     136== C) __Boot-loader for the I86 architecture__ ==
     137
     138TODO
     139
     140== D) __Generic kernel initialization procedure__ ==
     141
     142The kernel_init( boot_info_t * info ) function is the kernel entry point when the boot_loader transfer control to the kernel.
     143The ''info'' argument is a pointer on the fixed size boot_info_t structure, that is stored in the data kernel segment.
     144
     145All cores execute this procedure in parallel, but some tasks are only executed by the CP0 core.
     146This procedure uses two synchronisation barriers, defined as global variables in the data segment:
     147 * the global_barrier variable is used to synchronize all CP0 cores in all clusters containing a kernel instance.
     148 * the local_barrier variable is used to synchronize all cores in a given cluster.
     149
     150The kernel initialization procedure execute sequentially the following steps:
     151
     152=== D1) Core and cluster identification ===
     153
     154Each core has an unique hardware identifier, called '''gid''', that is hard-wired in a read-only register.
     155From the kernel point of view a core is identified by a composite index (cxy,lid), where '''cxy''' is the cluster identifier, and ''lid'' is a local (continuous) index in the cluster. The association between the gid hardware index and the (cxy,lid) composite index is defined in the boot_info_t structure.
     156In this first step, each core makes an associative search in the boot_info_t structure to obtain the ('''cxy,lid''') indexes from the '''gid''' index.
     157Then the CP0 initialize the global variable '''local_cxy''' defining the local cluster identifier.
     158
     159=== D2) TXT0 device initialization ===
     160
     161The core[io_cxy][0] (i.e. CP0 in I/O cluster) initializes the chdev descriptor associated to the kernel text terminal TXT0. This terminal is used by any kernel instance running on any core to display log or debug messages.  This terminal is configured in ''non-descheduling'' mode :
     162the calling thread call directly the relevant TXT driver, without using a server thread.
     163
     164A first synchonization barrier is used to avoid other cores to use the TXT0 terminal before initialization completion.
     165
     166=== D3) Cluster manager initialization ===
     167
     168In each cluster, the CP0 makes the cluster manager initialization, namely the cores descriptors array, and the physical memory allocators.
     169Then it initializes the local process_zero, containing al kernel threads in a given cluster.
     170
     171A second synchonization barrier is used to avoid other cores to access cluster manager before initialization completion.
     172
     173=== D4) Internal & external devices initialization ===
     174
     175In each cluster, the CP0 makes the devices initialization. For multi-channels devices, there is one channel device (called chdev_t) per channel.
     176For internal (replicated) devices, the khedive descriptors are allocated in the local cluster. For external (shared) devices, the chdev descriptors are regularly distributed on all clusters. These external chdev are indexed by a global index, and the host cluster is computed from this
     177index by a modulo.
     178
     179The internal devices descriptors are created first( ICU, then MMC, then DMA ), because the ICU device is used by all other devices.
     180Then the WTI mailboxes used for IPIs (Inter Processor Interrupt) are allocated in local ICU : one WTI mailbox per core.
     181Then each external chdev descriptor is created by the CP0 in the cluster where it must be created.
     182
     183A third synchonization barrier is used to avoid other cores to access devices before initialization completion. 
     184
     185=== D5) Idle thread initialization ===
     186
     187In this step, each core creates and initializes its private idle thread descriptor.
     188
     189=== D6) File system initialization ===
     190
     191The CP0 in I/O cluster) initializes the file system.
     192
     193A fourth synchonization barrier is used to avoid other cores to access file system before initialization completion. 
     194
     195=== D7) Scheduler activation ===
     196
     197Finally, each core enables its private timer IRQ to activate its private scheduler, and jump to the idle thread code.= Boot procedure =
     198
     199[[PageOutline]]
     200
     201== A) __General Principles__
     202
     203The ALMOS-MKH boot procedure can be decomposed in two phases:
     204 * The architecture dependent phase, implemented by an architecture specific '''boot_loader''' procedure.
     205 * The architecture independent phase, implemented by a generic (architecture independent) '''kernel-init''' procedure.
     206
     207As 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
     208the ALMOS-MKH kernel code. This code includes a description of the hardware architecture, contained in the ''boot_info_t'' data-structure.
     209
     210This fixed size ''boot_info_t'' structure is build by the boot-loader, and stored at the beginning of the local copy of the kdata segment. As it contains both general and cluster specific information, the content depends on the cluster:
     211 * general hardware architecture features : number of clusters, topology, etc.
     212 * available external (shared) peripherals : types and features.
     213 * number of cores in cluster,
     214 * available internal (private) peripherals in cluster : types and features.
     215 * available physical memory in cluster.
     216
     217This boot_info_t structure is defined in the '''boot_info.h''' file.
     218
     219To build the various boot_info_t structures (one per cluster), the boot-loader uses the '''arch_info_t''' binary structure, that is described in
     220section [wiki:arch_info Hardware Platform Definition]. This binary structure is contained in the '''arch_info.bin''' file, and must be stored
     221in the file system root directory.
     222
     223This method allows  the boot_loader to check and reconfigure the hardware components, to guaranty that the generated boot_info_t structures contain only functionally tested hardware components.
     224
     225We describe below the boot_loader for the TSAR architecture, the boot_loader for the I86 architecture, and the generic kernel initialization procedure.
     226
     227== B) __Boot-loader for the TSAR architecture__ ==
     228
     229The TSAR boot-loader uses an OS-independent '''pre-loader''', stored in an external ROM, that load the TSAR
     230'''boot-loader''' code from an external block-device to the memory. This preloader is specific for the TSAR architecture, but independent on the Operating System. It is used by ALMOS-MKH, but also by LINUX, NetBSD, ALMOS_MKH, or the GIET-VM. 
     231
     232The TSAR boot_loader allocates - in each cluster containing a physical memory bank - five fixed size memory zones, to store various
     233binary files or data structures :
     234 ||                                                     ||  size                                              ||  local physical address     ||
     235 || préloader code itself                    ||  PRELOADER_MAX_SIZE (16 Kb)  ||  PRELOADER_BASE(0x0)    ||
     236 || boot-loader code local copy        ||  BOOT_MAX_SIZE (1 Mb)              ||  BOOT_BASE (0x100000)  ||
     237 || arch_info.bin file local copy         ||  ARCHINFO_MAX_SIZE (2 Mb)       ||  ARCHINFO_BASE (0x200000)  ||
     238 || kernel.elf binary file                     ||  KERN_MAX_SIZE (1 Mb)               ||  KERN_BASE (0x400000)  ||
     239 || execution stacks (one per core)   ||  BOOT_STACK_SIZE (1 Mb)           ||  BOOT_STACK_BASE (0x500000)  ||
     240
     241The values given in this array are indicative. The actual values are defined by configuration parameters in the '''boot_config.h''' file.
     242These memory zones are only used for temporary storage : when the TSAR boot_loader completes, and transfer control to the kernel_init procedure,
     243the kernel code (i.e. the code and data segments) has been copied - in each cluster - in the lowest part of the cluster physical memory.
     244The four pages (16 Kbytes) reserved for the prelloader are only used in cluster 0.
     245
     246A core is identified by  two indexes[cxy][lid] : ''cxy'' is the cluster identifier, an ''lid'' is the core local index in cluster cxy.
     247 
     248
     249We describe below the four phases for the TSAR boot-loader:
     250
     251=== B1. Preloader phase ===
     252
     253At reset, the MMU is de-activated, and the extension address registers (for both data and instructions) in all cores[cxy][lid] contain the 0 value.
     254Therefore, all cores can only access the physical address space of cluster 0.
     255 * In the TSAR_LETI architecture, the preloader is loaded in the first 16 kbytes of the RAM located in cluster 0.
     256 * In the TSAR_IOB architecture, the preloader is stored in an external ROM, that is accessed throug the IO_bridge located in cluster 0.
     257
     258All cores execute the same preloader code, but the work done depends on the core identifier. The core[0][0] (i.e. Core0 in cluster 0) load
     259in local memory of cluster 0, the boot-loader code. All other cores do only one task before going to sleep (low-power) state:
     260each core activates its private WTI channel in the local ICU (Interrupt Controller Unit) to be wake-up by core [0][0], using an
     261IPI (Inter Processor Interrupt). 
     262
     263This shows the memory content after this first phase.
     264   [[Image(Phys_Mem1.svg)]]
     265
     266=== B2. Sequencial phase ===
     267
     268In this second phase the work is entirely done by core[0][0].
     269
     270    * The core[0][0] initializes the stack pointer. The boot stack size is a configuration parameter.
     271    * The core[0][0] initializes 2 peripherals: The '''TTY''' terminal (channel 0)  to display log info, and the '''IOC''' to access the disk.
     272    * The core[0][0] loads in cluster 0 the '''arch_info.bin''' file and the  '''kernel.elf''' file at addresses ARCHINFO_BASE and KERN_BASE respectively.
     273    * The core[0][0] uses the '''arch_info.bin'''structure to initialize  the local '''boot_info_t''' structure in cluster 0.
     274    * The core[0][0] send IPIs to activate all cores [i][0] in all other clusters.
     275   
     276All Core0 in all clusters synchronize through a synchronisation barrier before entering the next phase.
     277This shows the memory content after this phase.
     278   [[Image(Phys_Mem2.svg)]]
     279
     280=== B3. partially parallel phase ===
    104281
    105282In each cluster(i), the core[I][0] exécutes the boot-loader code (stored in physical memory of cluster 0), to do he following tasks:
    … …  
    197374=== D7) Scheduler activation ===
    198375
    199 Finally, each core enables its private timer IRQ to activate its private scheduler, and jump to the idle thread code.= Boot procedure =
    200 
    201 [[PageOutline]]
    202 
    203 == A) __General Principles__
    204 
    205 The ALMOS-MKH boot procedure can be decomposed in two phases:
    206  * The architecture dependent phase, implemented by an architecture specific '''boot_loader''' procedure.
    207  * The architecture independent phase, implemented by a generic (architecture independent) '''kernel-init''' procedure.
    208 
    209 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
    210 the ALMOS-MKH kernel code. This code includes a description of the hardware architecture, contained in the ''boot_info_t'' data-structure.
    211 
    212 This fixed size ''boot_info_t'' structure is build by the boot-loader, and stored at the beginning of the local copy of the kdata segment. As it contains both general and cluster specific information, the content depends on the cluster:
    213  * general hardware architecture features : number of clusters, topology, etc.
    214  * available external (shared) peripherals : types and features.
    215  * number of cores in cluster,
    216  * available internal (private) peripherals in cluster : types and features.
    217  * available physical memory in cluster.
    218 
    219 This boot_info_t structure is defined in the '''boot_info.h''' file.
    220 
    221 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
    222 section [wiki:arch_info Hardware Platform Definition]. This binary structure is contained in the '''arch_info.bin''' file, and must be stored
    223 in the file system root directory.
    224 
    225 This method allows  the boot_loader to check and reconfigure the hardware components, to guaranty that the generated boot_info_t structures contain only functionally tested hardware components.
    226 
    227 We describe below the boot_loader for the TSAR architecture, the boot_loader for the I86 architecture, and the generic kernel initialization procedure.
    228 
    229 == B) __Boot-loader for the TSAR architecture__ ==
    230 
    231 The TSAR boot-loader uses an OS-independent '''pre-loader''', stored in an external ROM, that load the TSAR
    232 '''boot-loader''' code from an external block-device to the memory. This preloader is specific for the TSAR architecture, but independent on the Operating System. It is used by ALMOS-MKH, but also by LINUX, NetBSD, ALMOS_MKH, or the GIET-VM. 
    233 
    234 The TSAR boot_loader allocates - in each cluster containing a physical memory bank - five fixed size memory zones, to store various
    235 binary files or data structures :
    236  ||                                                     ||  size                                              ||  local physical address     ||
    237  || préloader code itself                    ||  PRELOADER_MAX_SIZE (16 Kb)  ||  PRELOADER_BASE(0x0)    ||
    238  || boot-loader code local copy        ||  BOOT_MAX_SIZE (1 Mb)              ||  BOOT_BASE (0x100000)  ||
    239  || arch_info.bin file local copy         ||  ARCHINFO_MAX_SIZE (2 Mb)       ||  ARCHINFO_BASE (0x200000)  ||
    240  || kernel.elf binary file                     ||  KERN_MAX_SIZE (1 Mb)               ||  KERN_BASE (0x400000)  ||
    241  || execution stacks (one per core)   ||  BOOT_STACK_SIZE (1 Mb)           ||  BOOT_STACK_BASE (0x500000)  ||
    242 
    243 The values given in this array are indicative. The actual values are defined by configuration parameters in the '''boot_config.h''' file.
    244 These memory zones are only used for temporary storage : when the TSAR boot_loader completes, and transfer control to the kernel_init procedure,
    245 the kernel code (i.e. the code and data segments) has been copied - in each cluster - in the lowest part of the cluster physical memory.
    246 The four pages (16 Kbytes) reserved for the prelloader are only used in cluster 0.
    247 
    248 A core is identified by  two indexes[cxy][lid] : ''cxy'' is the cluster identifier, an ''lid'' is the core local index in cluster cxy.
    249  
    250 
    251 We describe below the four phases for the TSAR boot-loader:
    252 
    253 === B1. Preloader phase ===
    254 
    255 At reset, the MMU is de-activated, and the extension address registers (for both data and instructions) in all cores[cxy][lid] contain the 0 value.
    256 Therefore, all cores can only access the physical address space of cluster 0.
    257  * In the TSAR_LETI architecture, the preloader is loaded in the first 16 kbytes of the RAM located in cluster 0.
    258  * In the TSAR_IOB architecture, the preloader is stored in an external ROM, that is accessed throug the IO_bridge located in cluster 0.
    259 
    260 All cores execute the same preloader code, but the work done depends on the core identifier. The core[0][0] (i.e. Core0 in cluster 0) load
    261 in local memory of cluster 0, the boot-loader code. All other cores do only one task before going to sleep (low-power) state:
    262 each core activates its private WTI channel in the local ICU (Interrupt Controller Unit) to be wake-up by core [0][0], using an
    263 IPI (Inter Processor Interrupt). 
    264 
    265 This shows the memory content after this first phase.
    266    [[Image(Phys_Mem1.svg)]]
    267 
    268 === B2. Sequencial phase ===
    269 
    270 In this second phase the work is entirely done by core[0][0].
    271 
    272     * The core[0][0] initializes the stack pointer. The boot stack size is a configuration parameter.
    273     * The core[0][0] initializes 2 peripherals: The '''TTY''' terminal (channel 0)  to display log info, and the '''IOC''' to access the disk.
    274     * The core[0][0] loads in cluster 0 the '''arch_info.bin''' file and the  '''kernel.elf''' file at addresses ARCHINFO_BASE and KERN_BASE respectively.
    275     * The core[0][0] uses the '''arch_info.bin'''structure to initialize  the local '''boot_info_t''' structure in cluster 0.
    276     * The core[0][0] send IPIs to activate all cores [i][0] in all other clusters.
    277    
    278 All Core0 in all clusters synchronize through a synchronisation barrier before entering the next phase.
    279 This shows the memory content after this phase.
    280    [[Image(Phys_Mem2.svg)]]
    281 
    282 === B3. partially parallel phase ===
    283 
    284 In each cluster(i), the core[I][0] exécutes the boot-loader code (stored in physical memory of cluster 0), to do he following tasks:
    285     * each core[i][0] analyses the '''arch_info.bin''' structure (stored in physical memory of cluster 0), to search his own cluster identifier '''cxy'''. This is done in parallel by all cores[i][0], and can create contention.
    286     * each core[i][0] updates its own extended address register to access the data stored in its local physical memory. Nevertheless, it still access to the boot code stored in cluster(0), as long as the code has not been copied in local cluster.
    287     * each core[i][0] allocates a private stack at address BOOT_STACK_BASE in its local memory.
    288     * each core[i][0] copy 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.
    289     * 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).
    290     * 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.
    291     * Il arrive à la barrière de synchronisation, et le dernier '''CP0''' débloque tous les '''CP0''' (y compris '''bscpu'''),
    292     *  Chaque CP0 envoie des IPIs pour réveiller les autres cores dans son cluster local.
    293     * 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.
    294 
    295 This shows the memory content after this phase. 
    296    [[Image(Phys_Mem3.svg)]]
    297 
    298 === B4. Fully parallel phase ===
    299 
    300 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:
    301     * 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 .
    302     * 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.
    303     * 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).
    304     * 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.
    305     * 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.
    306     * Dès que le dernier core arrive à ce point et débloque les autres, tous les cores se branchent à la fonction '''kern_init()'''.
    307 
    308 There is the physical memory content at boot completion.
    309 
    310    [[Image(Phys_Mem4.svg)]]
    311 
    312 At this point, the boot-loader completed its job:
    313  * The kernel code ''kcode'' and ''kdata'' segments are loaded - in all clusters - in the first ''offset'' physical pages.
    314  * The hardware architecture described by the '''arch_info.bin'''file has been analyzed, and copied - in each cluster - in the '''boot_info_t''' structure, stored in the kdata segment.
    315  * Each  local kernel instance can use all the physical memory that is not used to store the kernel ''kcode'' and ''kdata'' segments themselves.
    316 
    317 == C) __Boot-loader for the I86 architecture__ ==
    318 
    319 TODO
    320 
    321 == D) __Generic kernel initialization procedure__ ==
    322 
    323 The kernel_init( boot_info_t * info ) function is the kernel entry point when the boot_loader transfer control to the kernel.
    324 The ''info'' argument is a pointer on the fixed size boot_info_t structure, that is stored in the data kernel segment.
    325 
    326 All cores execute this procedure in parallel, but some tasks are only executed by the CP0 core.
    327 This procedure uses two synchronisation barriers, defined as global variables in the data segment:
    328  * the global_barrier variable is used to synchronize all CP0 cores in all clusters containing a kernel instance.
    329  * the local_barrier variable is used to synchronize all cores in a given cluster.
    330 
    331 The kernel initialization procedure execute sequentially the following steps:
    332 
    333 === D1) Core and cluster identification ===
    334 
    335 Each core has an unique hardware identifier, called '''gid''', that is hard-wired in a read-only register.
    336 From the kernel point of view a core is identified by a composite index (cxy,lid), where '''cxy''' is the cluster identifier, and ''lid'' is a local (continuous) index in the cluster. The association between the gid hardware index and the (cxy,lid) composite index is defined in the boot_info_t structure.
    337 In this first step, each core makes an associative search in the boot_info_t structure to obtain the ('''cxy,lid''') indexes from the '''gid''' index.
    338 Then the CP0 initialize the global variable '''local_cxy''' defining the local cluster identifier.
    339 
    340 === D2) TXT0 device initialization ===
    341 
    342 The core[io_cxy][0] (i.e. CP0 in I/O cluster) initializes the chdev descriptor associated to the kernel text terminal TXT0. This terminal is used by any kernel instance running on any core to display log or debug messages.  This terminal is configured in ''non-descheduling'' mode :
    343 the calling thread call directly the relevant TXT driver, without using a server thread.
    344 
    345 A first synchonization barrier is used to avoid other cores to use the TXT0 terminal before initialization completion.
    346 
    347 === D3) Cluster manager initialization ===
    348 
    349 In each cluster, the CP0 makes the cluster manager initialization, namely the cores descriptors array, and the physical memory allocators.
    350 Then it initializes the local process_zero, containing al kernel threads in a given cluster.
    351 
    352 A second synchonization barrier is used to avoid other cores to access cluster manager before initialization completion.
    353 
    354 === D4) Internal & external devices initialization ===
    355 
    356 In each cluster, the CP0 makes the devices initialization. For multi-channels devices, there is one channel device (called chdev_t) per channel.
    357 For internal (replicated) devices, the khedive descriptors are allocated in the local cluster. For external (shared) devices, the chdev descriptors are regularly distributed on all clusters. These external chdev are indexed by a global index, and the host cluster is computed from this
    358 index by a modulo.
    359 
    360 The internal devices descriptors are created first( ICU, then MMC, then DMA ), because the ICU device is used by all other devices.
    361 Then the WTI mailboxes used for IPIs (Inter Processor Interrupt) are allocated in local ICU : one WTI mailbox per core.
    362 Then each external chdev descriptor is created by the CP0 in the cluster where it must be created.
    363 
    364 A third synchonization barrier is used to avoid other cores to access devices before initialization completion. 
    365 
    366 === D5) Idle thread initialization ===
    367 
    368 In this step, each core creates and initializes its private idle thread descriptor.
    369 
    370 === D6) File system initialization ===
    371 
    372 The CP0 in I/O cluster) initializes the file system.
    373 
    374 A fourth synchonization barrier is used to avoid other cores to access file system before initialization completion. 
    375 
    376 === D7) Scheduler activation ===
    377 
    378376Finally, each core enables its private timer IRQ to activate its private scheduler, and jump to the idle thread code.