Changes between Version 22 and Version 23 of boot_procedure

Timestamp:

May 3, 2017, 4:57:45 PM (7 years ago)

Author:

alain

Comment:

--

boot_procedure

@@ -36 +36 @@
 The TSAR boot_loader allocates - in each cluster containing a physical memory bank - five fixed size memory zones, to store various
 binary files or data structures :
- ||                                                     ||  size    ||  local physical address   ||
- || préloader code itself                    || 16 Kb  ||  0x0          ||
- || boot-loader code local copy        || 1 Mb   ||  0x100000 ||
- || arch_info.bin file local copy         ||  2 Mb   || 0x200000 ||
- || kernel.elf binary file                     ||  1 Mb   || 0x400000 ||
- || execution stacks (one per core)   || 1 Mb    || 0x500000 ||
+ ||                                                     ||  size                                              ||  local physical address     ||
+ || préloader code itself                    ||  PRELOADER_MAX_SIZE (16 Kb)  ||  RELOADER_SIZE (0x0)    ||
+ || boot-loader code local copy        ||  BOOT_MAX_SIZE (1 Mb)              ||  BOOT_BASE (0x100000)  ||
+ || arch_info.bin file local copy         ||  ARCHINFO_MAX_SIZE (2 Mb)       ||  ARCHINFO_BASE (0x200000)  ||
+ || kernel.elf binary file                     ||  KERN_MAX_SIZE (1 Mb)               ||  KERN_BASE (0x400000)  ||
+ || execution stacks (one per core)   ||  BOOT_STACK_SIZE (1 Mb)           ||  BOOT_STACK_BASE (0x500000)  ||
 
-In each cluster hosting one kernel instance, the physical memory must contain at least 6 Mbytes.
-All the values are configuration parameters, that can be redefined in the '''boot_config.h''' file.
+The values given in this array are configuration parameters, that can be redefined in the '''boot_config.h''' file.
 This memory is only used for temporary storage : when the boot_loader completes, and transfer control to the kernel_init procedure,
 the kernel code (i.e. the code and data segments) has been copied at physical address 0x4000 in all clusters. 
@@ -52 +51 @@
 
 Le chargement d'ALMOS-MK sur l'architecture TSAR se fait donc en 4 phases:
+A core is identified by  two indexes[cxy][lid] : ''cxy'' is the cluster identifier, an ''lid'' is the core local index in cluster cxy.
+ In all clusters, the core with local index 0 is called ''CP0''. 
 
-== 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).
+=== B1. Preloader phase ===
 
-   Voici le contenu de la mémoire du cluster de boot et des autres clusters après cette première étape.
+At reset, the extension address registers (for both data and instructions) in all cores[cxy][lid] contain the 0 value.
+Therefore, all cores can only access the physical address space of cluster 0.
+If the  preloaded is stored in an external ROM, the I/O cluster must be cluster 0, to access the external ROM.
+
+All cores execute the same preloader code, but the work done depends on the core identifier. The core[0][0] (i.e. CP0 in cluster 0) load
+in local memory of cluster 0, at address the boot loader code. All other cores do only one task before going to sleep (low-power) state:
+each core activates its private WTI channel in the local ICU (Interrupt Controller Unit) to be wake-up by core [0][0], using an
+IPI (Inter Processor Interrupt).  
+
+This shows the memory content after this first phase.
    [[Image(Phys_Mem1.svg)]]
 
-== 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:
+=== B2. Sequencial phase ===
+
+In this second phase the work is entirely done by core[0][0].
+
     * 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.
@@ -71 +82 @@
    [[Image(Phys_Mem2.svg)]]
 
-== 3. Phase partiellement parallèle ==
+=== B3. 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.
@@ -86 +98 @@
    [[Image(Phys_Mem3.svg)]]
 
-== 4. Phase totalement parallèle ==
+=== A4. Fully parallel phase ===
+
 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 .
@@ -105 +118 @@
 
 == D) Generic kernel initialization procedure
-