Changes between Version 53 and Version 54 of boot_procedure


Ignore:
Timestamp:
Mar 1, 2019, 12:04:10 PM (5 months ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • boot_procedure

    v53 v54  
    6161We describe below the four phases of the TSAR boot-loader:
    6262
    63 === B1. Preloader phase ===
     63=== B1. Pre-loader phase ===
    6464
    6565 * In the TSAR_LETI architecture, the preloader is loaded in the first 16 kbytes of the physical address space in cluster 0.
     
    7373   * All other cores do only one task before going to sleep (i.e. low-power state): each core activates its private WTI channel in the local ICU (Interrupt Controller Unit) to be later activated by an IPI (Inter Processor Interrupt). 
    7474
    75 === B2. Boot-loader Sequencial phase ===
     75=== B2. Boot-loader sequencial phase ===
    7676
    7777In this phase, only core [0][0] is running, while all other cores are blocked in the preloaded, waiting to be activated by an IPI.
     
    9797In this phase all core[cxy][0], other than the core[0][0] are running.
    9898
    99 At this point, 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.
    100 
    101 Therefore, the core[cxy][0] exécutes the boot-loader code (stored in physical memory of cluster 0), to do he following tasks:
    102     * The core[cxy][0] copies the boot-loader code from BOOT_CODE zone in cluster 0 to BOOT_CORE zone in cluster cxy.
    103     * [TO BE DONE] The core[cxy][0] map the boot-loader code (one big page) and activates the instruction MMU to use the local copy of the boot-loader code.
     99At this point, all DATA extension registers point already on the local cluster( to use the local stack).
     100
     101Therefore, the core[cxy][0] exécutes the following tasks:
     102    * To access the global data stored in cluster cxy, the core[cxy][0] copies the boot-loader code from BOOT_CODE zone in cluster 0 to BOOT_CORE zone in cluster cxy.
     103    * To access the instructions stored in cluster cxy, the core[cxy][0] creates a minimal page table containing one single big page mapping the local BOOT_CORE zone, and activates the instruction MMU. '''[TO BE DONE]'''
    104104    * The core[cxy][0] copies the ''arch_info.bin'' structure from ARCH_INFO zone in cluster 0 to ARCH_INFO zone in cluster cxy.
    105105    * The core[cxy][0] copies the ''kcode'' and ''kdata'' segments from KERNEL_CODE zone in cluster 0 to KERNEL_CODE zone in cluster cxy.
     
    110110=== B4. Boot-loader fully parallel phase ===
    111111
    112 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:
     112In this phase all core[cxy][lid] are running.
     113
     114Each core must initialise few registers, as described below, and jump to the kernel_entry address. This address is defined in the ''kernel.elf'' file, and registered in the ''kernel_entry'' global variable. 
     115
     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.
     117   * '''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.
     118   * '''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.
     119   * '''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 ).
     120
     121Moreover, 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.
     122    * all core[cxy][lid] in cluster cxy synchronize on a local barrier.
     123    * each core in cluster cxy initialize the following registers before jumping to kernel_init function:
     124       * status register            : cp0_sr   <= reset BEV bit
     125       * kernel_init() argument : a0  <= boot_info
     126       * stack pointer              : sp  <=
     127       * program counter        : cp0_ebase  <= kernel_entry 
     128
     129All 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:
    113130    * 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 .
    114131    * 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.
     
    117134    * 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.
    118135    * Dès que le dernier core arrive à ce point et débloque les autres, tous les cores se branchent à la fonction '''kern_init()'''.
    119 
    120 There is the physical memory content at boot completion.
    121 
    122    [[Image(Phys_Mem4.svg)]]
    123 
     136/
    124137At this point, the boot-loader completed its job:
    125138 * The kernel code ''kcode'' and ''kdata'' segments are loaded - in all clusters - in the first ''offset'' physical pages.