Changes between Version 22 and Version 23 of boot_procedure


Ignore:
Timestamp:
May 3, 2017, 4:57:45 PM (5 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • boot_procedure

    v22 v23  
    3636The TSAR boot_loader allocates - in each cluster containing a physical memory bank - five fixed size memory zones, to store various
    3737binary files or data structures :
    38  ||                                                     ||  size    ||  local physical address   ||
    39  || préloader code itself                    || 16 Kb  ||  0x0          ||
    40  || boot-loader code local copy        || 1 Mb   ||  0x100000 ||
    41  || arch_info.bin file local copy         ||  2 Mb   || 0x200000 ||
    42  || kernel.elf binary file                     ||  1 Mb   || 0x400000 ||
    43  || execution stacks (one per core)   || 1 Mb    || 0x500000 ||
     38 ||                                                     ||  size                                              ||  local physical address     ||
     39 || préloader code itself                    ||  PRELOADER_MAX_SIZE (16 Kb)  ||  RELOADER_SIZE (0x0)    ||
     40 || boot-loader code local copy        ||  BOOT_MAX_SIZE (1 Mb)              ||  BOOT_BASE (0x100000) ||
     41 || arch_info.bin file local copy         ||  ARCHINFO_MAX_SIZE (2 Mb)       ||  ARCHINFO_BASE (0x200000) ||
     42 || kernel.elf binary file                     ||  KERN_MAX_SIZE (1 Mb)               ||  KERN_BASE (0x400000) ||
     43 || execution stacks (one per core)   ||  BOOT_STACK_SIZE (1 Mb)           ||  BOOT_STACK_BASE (0x500000) ||
    4444
    45 In each cluster hosting one kernel instance, the physical memory must contain at least 6 Mbytes.
    46 All the values are configuration parameters, that can be redefined in the '''boot_config.h''' file.
     45The values given in this array are configuration parameters, that can be redefined in the '''boot_config.h''' file.
    4746This memory is only used for temporary storage : when the boot_loader completes, and transfer control to the kernel_init procedure,
    4847the kernel code (i.e. the code and data segments) has been copied at physical address 0x4000 in all clusters.
     
    5251
    5352Le chargement d'ALMOS-MK sur l'architecture TSAR se fait donc en 4 phases:
     53A core is identified by  two indexes[cxy][lid] : ''cxy'' is the cluster identifier, an ''lid'' is the core local index in cluster cxy.
     54 In all clusters, the core with local index 0 is called ''CP0''.
    5455
    55 == 1. Phase de préchargement ==
    56 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).
     56=== B1. Preloader phase ===
    5757
    58    Voici le contenu de la mémoire du cluster de boot et des autres clusters après cette première étape.
     58At reset, the extension address registers (for both data and instructions) in all cores[cxy][lid] contain the 0 value.
     59Therefore, all cores can only access the physical address space of cluster 0.
     60If the  preloaded is stored in an external ROM, the I/O cluster must be cluster 0, to access the external ROM.
     61
     62All 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
     63in 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:
     64each core activates its private WTI channel in the local ICU (Interrupt Controller Unit) to be wake-up by core [0][0], using an
     65IPI (Inter Processor Interrupt). 
     66
     67This shows the memory content after this first phase.
    5968   [[Image(Phys_Mem1.svg)]]
    6069
    61 == 2. Phase séquentielle ==
    62 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:
     70=== B2. Sequencial phase ===
     71
     72In this second phase the work is entirely done by core[0][0].
     73
    6374    * 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'''.
    6475    * 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.
     
    7182   [[Image(Phys_Mem2.svg)]]
    7283
    73 == 3. Phase partiellement parallèle ==
     84=== B3. Phase partiellement parallèle ===
     85
    7486Dans 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:
    7587    * 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.
     
    8698   [[Image(Phys_Mem3.svg)]]
    8799
    88 == 4. Phase totalement parallèle ==
     100=== A4. Fully parallel phase ===
     101
    89102Chaque 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:
    90103    * 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 .
     
    105118
    106119== D) Generic kernel initialization procedure
    107