Changes between Version 44 and Version 45 of boot_procedure


Ignore:
Timestamp:
Feb 27, 2019, 9:05:01 PM (6 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • boot_procedure

    v44 v45  
    4343 || ARCH_INFO             || arch_info.bin file copy           || ARCH_INFO_BASE (3 MB)       || ARCH_INFO_MAX_SIZE (1 MB)                   ||
    4444 || KERNEL_ELF           || kernel.elf file copy                 || KERNEL_ELF_BASE (4 MB)     || KERN_ELF_MAX_SIZE (2 MB)                     ||
    45  || BOOT_CODE           || boot stacks (one per core)     || BOOT_STACK_BASE (6 MB)    || BOOT_STACK_MAX_SIZE (1MB)                ||
     45 || BOOT_STACK          || boot stacks (one per core)     || BOOT_STACK_BASE (6 MB)    || BOOT_STACK_MAX_SIZE (1MB)                ||
    4646
    4747The values given in this array are indicative. The actual values are defined by configuration parameters in the '''boot_config.h''' file.
    4848The main constraint is : the ''kcode'" segment (in the KERNEL_CODE zone must be entirely contained in one single big physical page (2 MBytes) because it will be mapped as one single big page in all process virtual spaces.
    4949
    50 A core is identified by  two indexes[cxy][lid] : ''cxy'' is the cluster identifier, an ''lid'' is the core local index in cluster cxy.
     50All cores contribute to the boot procedure, but all cores are not simultaneously activated.
     51A core is identified by  two indexes[cxy][lid] : ''cxy'' is the cluster identifier, an ''lid'' is the core local index in cluster:
     52 * in a first phase, only core[0][0] is running (core 0 in cluster 0).
     53 * In a second phase, only core[cxy][0] are running (one core per cluster).
     54 * in last phase, all core[cxy][lid] are running.
     55
     56We describe below the four phases of the TSAR boot-loader:
     57
     58=== B1. Preloader phase ===
     59
     60At reset, the MMU is de-activated (for both data and instructions), and the extension address registers supporting direct access to remote memory banks (for both data and instructions) in all cores[cxy][lid] contain the 0 value.
     61Therefore, all cores can only access the physical address space of cluster 0.
     62 * In the TSAR_LETI architecture, the preloader is loaded in the first 16 kbytes of the physical address space in cluster 0.
     63 * In the TSAR_IOB architecture, the preloader is stored in an external ROM, that is accessed throug the IO_bridge located in cluster 0.
     64
     65All cores execute the same preloader code (stored in cluster 0, but the work done depends on the core identifier:
     66   * The core[0][0] load in the BOOT_CODE zone of cluster 0, the boot-loader code.
     67   * 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). 
     68
     69This shows the memory content after this pre-loader phase.
     70   [[Image(Phys_Mem1.svg)]]
     71
     72=== B2. Boot-loader Sequencial phase ===
     73
     74The first instructions of the boot-loader are defined in the ''boot_entry.S'' file. This assembly code is executed by all cores entering the boot loader,
     75but not at the same time, because in this phase, only core [0][0] is running, while all other cores are blocked in the preloaded, waiting to be activated by an IPI.
     76
     77This assembly code makes the assuption that the CP0 register containing the core gid (global hardware identifier) has a fixed format:                              *
    5178 
    52 
    53 We describe below the four phases for the TSAR boot-loader:
    54 
    55 === B1. Preloader phase ===
    56 
    57 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.
    58 Therefore, all cores can only access the physical address space of cluster 0.
    59  * In the TSAR_LETI architecture, the preloader is loaded in the first 16 kbytes of the RAM located in cluster 0.
    60  * In the TSAR_IOB architecture, the preloader is stored in an external ROM, that is accessed throug the IO_bridge located in cluster 0.
    61 
    62 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
    63 in local memory of cluster 0, the boot-loader code. All other cores do only one task before going to sleep (low-power) state:
    64 each core activates its private WTI channel in the local ICU (Interrupt Controller Unit) to be wake-up by core [0][0], using an
    65 IPI (Inter Processor Interrupt). 
    66 
    67 This shows the memory content after this first phase.
    68    [[Image(Phys_Mem1.svg)]]
    69 
    70 === B2. Sequencial phase ===
    71 
    72 In this second phase the work is entirely done by core[0][0].
    73 
    74     * The core[0][0] initializes the stack pointer. The boot stack size is a configuration parameter.
    75     * The core[0][0] initializes 2 peripherals: The '''TTY''' terminal (channel 0)  to display log info, and the '''IOC''' to access the disk.
    76     * 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.
    77     * The core[0][0] uses the '''arch_info.bin'''structure to initialize  the local '''boot_info_t''' structure in cluster 0.
     79'''gid == (((x << Y_WIDTH) + y) << P_WIDTH) + lid'''                                          *
     80                                                                                           *
     81Each core running this code makes the 3 following actions:                                                                          *
     82   * It initializes the core stack pointer depending on the '''lid''' value extracted from the '''gid''', using the BOOT_STACK_BASE and BOOT_STACK_SIZE parameters defined in the  ''boot_config.h'' file,                                                                    *
     83   * It changes the value of the DATA address extension CP2 register, using the '''cxy''' value extracted from the '''gid'''                                                                           
     84   * It jumps to the boot_loader() C function defined in the ''boot.c'' file, passing the two (cxy , lid) arguments.
     85
     86In this sequencial phase, the core[0][0]  executes the following actions:
     87
     88   * The core[0][0] initializes 2 peripherals: The '''TTY''' terminal (channel 0)  to display log messages, and the '''IOC''' peripheral to access the disk.
     89   * The core[0][0] initializes the boot-loader private FAT32 structure, allowing the boot loader to access files stored in the FAT32 file system on disk.
     90    * The core[0][0] load in the KERNEL_ELF zone the ''kernel.elf'' file from the disk file system..
     91    * Then it copies in the KERNEL_CORE zone the ''kcode'' and ''data'' segments, using the addresses contained in the .elf file (identity mapping).
     92    * 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.
    7894    * The core[0][0] send IPIs to activate all cores [i][0] in all other clusters.
    7995   
    80 All Core0 in all clusters synchronize through a synchronisation barrier before entering the next phase.
    8196This shows the memory content after this phase.
    8297   [[Image(Phys_Mem2.svg)]]
    8398
    84 === B3. partially parallel phase ===
     99=== B3. Boot-loader partially parallel phase ===
     100
     101This phase is executed by all core[cxy][0], but the core[0][0].
     102
     103At 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.
    85104
    86105In 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: