Changes between Version 52 and Version 53 of boot_procedure


Ignore:
Timestamp:
Feb 28, 2019, 1:34:48 PM (6 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • boot_procedure

    v52 v53  
    4646
    4747The values given in this array are indicative. The actual values are defined by configuration parameters in the ''boot_config.h'' file.
    48 The main constraint is the following: 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.
    49 
     48The two main constraint are the following:
     49   * 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.
     50   * the BOOT_CODE region (containing the boot loader instructions and data) must be entirely contained in the
     51next big physical page, because it will be mapped in the boot-loader virtual space yo allow the cores to access locally the boot code as soon as it has been copied in the local cluster.
    5052
    5153A core is identified by  two indexes: '''cxy''' is the cluster identifier, an '''lid''' is the core local index in cluster.
     54The CP0 register containing the core gid (global hardware identifier) has a fixed format:   '''gid''' = ('''cxy''' << 2) + '''lid'''
    5255
    5356All cores contribute to the boot procedure, but all cores are not simultaneously active:
    … …  
    6063=== B1. Preloader phase ===
    6164
    62 At 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.
    63 Therefore, all cores can only access the physical address space of cluster 0.
    6465 * In the TSAR_LETI architecture, the preloader is loaded in the first 16 kbytes of the physical address space in cluster 0.
    6566 * In the TSAR_IOB architecture, the preloader is stored in an external ROM, that is accessed throug the IO_bridge located in cluster 0.
    6667
     68At reset, the MMU is de-activated (for both data and instructions), and the extension address registers supporting direct access to remote memory banks (for data only)  contain the 0 value.
     69Therefore, all cores can only access the physical address space of cluster 0.
     70
    6771All cores execute the same preloader code (stored in cluster 0, but the work done depends on the core identifier:
    68    * The core[0][0] load in the BOOT_CODE zone of cluster 0, the boot-loader code.
     72   * The core[0][0] load in the BOOT_CODE zone of cluster 0, the boot-loader code stored on disk.
    6973   * 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). 
    70 
    71 This shows the memory content after this pre-loader phase.
    72    [[Image(Phys_Mem1.svg)]]
    7374
    7475=== B2. Boot-loader Sequencial phase ===
    7576
    76 The 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,
    77 but 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.
     77In this phase, only core [0][0] is running, while all other cores are blocked in the preloaded, waiting to be activated by an IPI.
    7878
    79 This assembly code makes the assuption that the CP0 register containing the core gid (global hardware identifier) has a fixed format:   '''gid''' == ('''cxy''' << 2) + '''lid'''
     79The 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, but not at the same time.
    8080
    8181Each 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,                                                                    *
     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,                                                                   
    8383   * It changes the value of the DATA address extension CP2 register, using the '''cxy''' value extracted from the '''gid'''                                                                           
    8484   * It jumps to the boot_loader() C function defined in the ''boot.c'' file, passing the two (cxy , lid) arguments.
    … …  
    9393   * The core[0][0] send IPIs to activate all cores [i][0] in all other clusters.
    9494   
    95 This shows the memory content after this phase.
    96    [[Image(Phys_Mem2.svg)]]
    97 
    9895=== B3. Boot-loader partially parallel phase ===
    9996
    100 This phase is executed by all core[cxy][0], but the core[0][0].
     97In this phase all core[cxy][0], other than the core[0][0] are running.
    10198
    102 At 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.
     99At 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.
    103100
    104101Therefore, the core[cxy][0] exécutes the boot-loader code (stored in physical memory of cluster 0), to do he following tasks:
    105     * The core[cxy][0] copies the boot-loader code from cluster 0 to BOOT_CORE zone in cluster cxy.
    106     * The core[cxy][0] copies the ''arch_info.bin'' structure from cluster 0 to ARCH_INFO zone in cluster cxy.
    107     * The core[cxy][0] copies the ''kcode'' and ''kdata'' segments from cluster 0 to KERNEL_CODE zone in cluster cxy.
     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.
     104    * The core[cxy][0] copies the ''arch_info.bin'' structure from ARCH_INFO zone in cluster 0 to ARCH_INFO zone in cluster cxy.
     105    * The core[cxy][0] copies the ''kcode'' and ''kdata'' segments from KERNEL_CODE zone in cluster 0 to KERNEL_CODE zone in cluster cxy.
    108106    * 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.
    109     * Il arrive à la barrière de synchronisation, et le dernier '''CP0''' débloque tous les '''CP0''' (y compris '''bscpu'''),
    110107    *  All core[cxy][0], including core[0][0], synchronize using a global barrier.
    111     * in each cluster cxy, the core[cxy][0] activates the other cores that are still blocked in the preloaded.
    112 
    113 This shows the memory content after this phase. 
    114    [[Image(Phys_Mem3.svg)]]
     108    * in each cluster cxy, the core[cxy][0] activates the other cores that are  blocked in the pre-loader.
    115109
    116110=== B4. Boot-loader fully parallel phase ===
    … …  
    195189
    196190Finally, each core enables its private timer IRQ to activate its private scheduler, and jump to the idle thread code.= Boot procedure =
    197