Changes between Version 68 and Version 69 of boot_procedure


Ignore:
Timestamp:
Dec 7, 2019, 3:52:14 PM (4 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • boot_procedure

    v68 v69  
    140140The source code for this function is defined in the [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/kernel/kern/kernel_init.c  almos-mkh/kernel/kern/kernel_init.c] file.
    141141
    142 When a core enters this function, the MMU status depends on the target architecture:
     142All the kernel_init() code is independent on the architecture, but the MMU status depends on the target architecture:
    143143 * For the '''TSAR''' architectures, the instruction MMU has been activated and uses the Page Table defined by the boot-loader. The data MMU is de-activated, and the DATA address extension register points on the local physical memory.
    144144 * For the '''I86''' architectures, both the instruction and the data MMUs have been activated, an use the Page Table defined by the boot-loader.
    145145
    146 In both cases, a new GPT (Generic Page Table), and a new VSL (Virtual Segments List) must be created in each cluster. These structures will be used by all kernel threads (all threads directly attached to the local kernel process) and are stored in the process_zero VMM. The ''kcode'' and (possibly) ''kdata'' segments are copied in all user process descriptors.
     146In both cases, the kernel_init() function must create in each cluster a new kernel '''GPT''' (Generic Page Table), and a new kernel '''VSL''' (Virtual Segments List), to be used by the local core MMUs to access the local ''kcode'' and ''kdata'' segments. In each cluster, an unique kernel '''process_zero''' contains all kernel threads running in this cluster. These kernel '''VSL''' and '''GPT''' structures are registered in the '''process_zero''' descriptor, to be used by the kernel threads. The informations registered in these '''VSL''' and '''GPT''' kernel structures  will be copied later in the user '''VSL''' and '''GPT''' structures contained in all  user process descriptors created in the cluster, to be used by the user threads associated to this process.
    147147
    148148In each cluster, all local cores execute this procedure in parallel, but most tasks are only executed by core[0].
    … …  
    155155=== D1) Core and cluster identification ===
    156156
    157 Each core has an unique hardware identifier, called '''gid''', that is hard-wired in a read-only register.
     157Each core is supposed to have an unique hardware identifier, called '''gid''', hard-wired in a read-only register.
    158158From the kernel point of view a core is identified by a composite index (cxy,lid), where '''cxy''' is the cluster identifier, and ''lid'' is a local (continuous) index in the cluster. The association between the gid hardware index and the (cxy,lid) composite index is defined in the boot_info_t structure. In this first step, each core makes an associative search in the boot_info_t structure to obtain the ('''cxy,lid''') indexes from the '''gid''' index.
    159159
    160 The core[0] initialize the global variable '''local_cxy''' defining the local cluster identifier, and initialises the local cluster descriptor from informations found in the boot_info_t structure.
    161 All cores makes a first initialization of their private kernel ''idle_thread''.
    162 Finally, the core[0] in cluster[0] initialise the kernel TXT0. This terminal is used by any kernel instance running on any core to display log or debug messages.  This terminal is configured in ''non-descheduling'' mode : the calling thread call directly the relevant TXT driver, without using a server thread.
    163 
    164 A synchronization barrier is used to avoid other cores to use the TXT0 terminal before initialization.
     160The core[cxy][0] initialize the global variable '''local_cxy''' defining the local cluster identifier, and initialises the local cluster descriptor from informations found in the boot_info structure.
     161All cores make a first initialization of their private kernel IDLE thread.
     162Finally, the core[0][0] initialise the kernel TXT0. This terminal is used by the kernel code, running on any core, to display log or debug messages.  This terminal is configured in ''non-descheduling'' mode : the calling thread executes directly the relevant TXT driver, without using the dedicated DEV kernel thread.
     163
     164A first synchronization barrier is used to avoid that other cores use the TXT0 terminal before initialization.
    165165
    166166=== D2) Cluster manager initialization ===
    167167
    168 In each cluster, the core[0] makes the cluster manager initialization, namely the cores descriptors array, the DQDT, and the local physical memory allocators.
    169 
    170 A synchonization barrier is used to avoid  access to cluster manager before initialization.
     168In each cluster, the core[0] makes the cluster manager initialization. The cluster manager contains the structures describing the main kernel ressources in the cluster :
     169 * the hardware architecture parameters (both local and global).
     170 * an array of cores descriptors, and the associated schedulers.
     171 * the physical memory allocator(s) in this cluster.
     172 * the DQDT, that is a global, distributed structure registering the current level of ressource (cores and memory) availability.
     173
     174The cluster manager is defined in the [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/kernel/kern/cluster.h  almos-mkh/kernel/kern/cluster.h] and [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/kernel/kern/cluster.c  almos-mkh/kernel/kern/cluster.c] files.
     175
     176As all cluster managers are global variables, accessible by any kernel instance, running in any cluster, a synchonization barrier is required to avoid  access to a cluster manager before initialization.
    171177
    172178=== D3) Kernel entry point and process_zero initialization ===
    … …  
    174180All cores initialise the registers, defining the kernel entry point(s) in case of interrupt, exception or system call.
    175181This must be done here because the VFS initialization uses RPCs requiring Inter Processor Interrupts.
    176 All core initialise their (currently running) IDLE thread descriptor.
    177 In each cluster the core[0] initializes the local process_zero descriptor, containing al kernel threads in a given cluster.
     182All cores initialise their (currently running) IDLE thread descriptor.
     183In each cluster the core[cxy][0] initializes the local kernel process_zero descriptor.
    178184This include the creation of the local kernel GPT and VSL.
    179185
    180 A synchronization barrier is used to avoid  access to VSL/GPT before initialization.
     186Here again, a synchronization barrier is required to avoid  access to VSL/GPT before initialization.
    181187
    182188=== D4) MMU activation ===
    … …  
    186192Moreover, the core[0] in cluster[0]  initializes the external IOPIC device
    187193
    188 A synchronization barrier is used to avoid  access to IOPIC before initialization.
     194A synchronization barrier is required to avoid  access to IOPIC before initialization.
    189195
    190196=== D5) Internal & external devices initialization ===
    … …  
    197203Then each external chdev descriptor is created in the cluster where it must be created.
    198204
    199 A synchronization barrier is used to avoid  access to devices before initialization. 
     205A synchronization barrier is required to avoid  access to devices before initialization. 
    200206
    201207=== D6) IPI, Idle thread, and VFS root initialization ===
    … …  
    204210Then core[0] in cluster[0] creates the root VFS in cluster[0]. This requires to access the file system on disk.
    205211
    206 A synchronization barrier is used to avoid  access to VFS root before initialization. 
     212A synchronization barrier is required to avoid  access to VFS root before initialization. 
    207213
    208214=== D7) VFS root initialisation in all clusters ===
    … …  
    211217from values registered in cluster[0].
    212218
    213 A synchronization barrier is used to avoid  access to VFS before initialization. 
     219A synchronization barrier is required to avoid  access to VFS before initialization. 
    214220
    215221=== D8) DEVFS global initialization ===
    … …  
    217223The core[0] in cluster[0] makes the DEVFS global initialization: It initializes the DEVFS context, and creates the DEVFSb''dev'' and ''external'' directory inodes in cluster[0].
    218224
    219 A synchronization barrier is used to avoid access to DEVFS root before initialization. 
     225A synchronization barrier is required to avoid access to DEVFS root before initialization. 
    220226
    221227=== D9) DEVFS local initialization ===