Changes between Version 58 and Version 59 of boot_procedure

Timestamp:

Mar 5, 2019, 2:22:24 PM (5 years ago)

Author:

alain

Comment:

--

boot_procedure

@@ -116 +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.
    * '''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. 
-   * '''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. '''[TO BE DONE in kernel_init()]'''
+   * '''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. '''[TO BE MOVED to kernel_init()]'''
    * '''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 ).
 
@@ -130 +130 @@
 == D) __Generic kernel initialization procedure__ ==
 
-The kernel_init( boot_info_t * info ) function is the kernel entry point when the boot_loader transfer control to the kernel. The argument is a pointer on the fixed size boot_info_t structure, that is stored in the data kernel segment.
-
-All cores execute this procedure in parallel, but some tasks are only executed by the CP0 core.
-This procedure uses two synchronisation barriers, defined as global variables in the data segment:
- * the global_barrier variable is used to synchronize all CP0 cores in all clusters containing a kernel instance. 
+The kernel_init( boot_info_t * info ) function is the kernel entry point when the boot_loader transfers control to the kernel. The argument is a pointer on the fixed size boot_info_t structure, stored in the local  ''kdata'' segment.
+
+When a core enters this function, the MMU status depends on the target architecture:
+ * 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. 
+ * For the '''I86''' architectures, both the instruction and the data MMUs have been activated, an use the Page Table defined by the boot-loader.
+
+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.
+
+In each cluster, all local cores execute this procedure in parallel, but most tasks are only executed by core[0].
+This procedure uses two synchronisation barriers, defined as global variables in the ''kdata'' segment:
+ * the global_barrier variable is used to synchronize all core[0] in all clusters containing a kernel instance. 
  * the local_barrier variable is used to synchronize all cores in a given cluster.
 
-The kernel initialization procedure execute sequentially the following steps:
+The kernel initialization procedure execute sequentially the following steps:.
 
 === D1) Core and cluster identification ===
 
 Each core has an unique hardware identifier, called '''gid''', that is hard-wired in a read-only register.
-From 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.
-Then the CP0 initialize the global variable '''local_cxy''' defining the local cluster identifier.
-
-=== D2) TXT0 device initialization ===
-
-The core[io_cxy][0] (i.e. CP0 in I/O cluster) initializes the chdev descriptor associated to the kernel text terminal 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.
-
-A first synchonization barrier is used to avoid other cores to use the TXT0 terminal before initialization completion.
-
-=== D3) Cluster manager initialization ===
-
-In each cluster, the CP0 makes the cluster manager initialization, namely the cores descriptors array, and the physical memory allocators.
-Then it initializes the local process_zero, containing al kernel threads in a given cluster.
-
-A second synchonization barrier is used to avoid other cores to access cluster manager before initialization completion.
-
-=== D4) Internal & external devices initialization ===
-
-In each cluster, the CP0 makes the devices initialization. For multi-channels devices, there is one channel device (called chdev_t) per channel.
-For internal (replicated) devices, the khedive descriptors are allocated in the local cluster. For external (shared) devices, the chdev descriptors are regularly distributed on all clusters. These external chdev are indexed by a global index, and the host cluster is computed from this
-index by a modulo. 
+From 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.
+
+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.
+All cores makes a first initialization of their private kernel ''idle_thread''.
+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.
+
+A synchronization barrier is used to avoid other cores to use the TXT0 terminal before initialization.
+
+=== D2) Cluster manager initialization ===
+
+In each cluster, the core[0] makes the cluster manager initialization, namely the cores descriptors array, the DQDT, and the local physical memory allocators.
+
+A synchonization barrier is used to avoid  access to cluster manager before initialization.
+
+=== D3) Process_zero initialization ===
+
+In each cluster the core[0] initializes the local process_zero descriptor, containing al kernel threads in a given cluster.
+This include the creation of the local kernel GPT and VSL.
+
+A synchronization barrier is used to avoid  access to VSL/GPT before initialization.
+
+=== D4) MMU activation ===
+
+In each cluster, all cores activate their private MMU, as required by the architecture.
+For TSAR, only the instruction MMU is activated, but the data MMU is de-activated.
+
+Moreover, the core[0] in cluster[0]  initializes the external IOPIC device
+
+A synchronization barrier is used to avoid  access to IOPIC before initialization.
+
+=== D5) Internal & external devices initialization ===
+
+In each cluster, the core[0] makes the devices initialization. For multi-channels devices, there is one channel device (called chdev_t) per channel.
+For internal (replicated) devices, the chdev descriptors are allocated in the local cluster. For external (shared) devices, the chdev descriptors are regularly distributed on all clusters. These external chdev are indexed by a global index, and the host cluster is computed from this index by a modulo. 
 
 The internal devices descriptors are created first( ICU, then MMC, then DMA ), because the ICU device is used by all other devices.
 Then the WTI mailboxes used for IPIs (Inter Processor Interrupt) are allocated in local ICU : one WTI mailbox per core.
-Then each external chdev descriptor is created by the CP0 in the cluster where it must be created.
-
-A third synchonization barrier is used to avoid other cores to access devices before initialization completion.  
-
-=== D5) Idle thread initialization ===
-
-In this step, each core creates and initializes its private idle thread descriptor.
-
-=== D6) File system initialization ===
-
-The CP0 in I/O cluster) initializes the file system.
-
-A fourth synchonization barrier is used to avoid other cores to access file system before initialization completion.  
-
-=== D7) Scheduler activation ===
-
-Finally, each core enables its private timer IRQ to activate its private scheduler, and jump to the idle thread code.= Boot procedure =
+Then each external chdev descriptor is created in the cluster where it must be created.
+
+A synchronization barrier is used to avoid  access to devices before initialization.  
+
+=== D6) IPI, Idle thread, and VFS root initialization ===
+
+Each core enable its private input IPI, and completes initialization of its private idle thread descriptor.
+
+Then core[0] in cluster[0] creates the root VFS in cluster[0]. This requires to access the file system on disk. 
+
+A synchronization barrier is used to avoid  access to VFS root before initialization.  
+
+=== D7) VFS root initialisation in all clusters ===
+
+In each cluster other than cluster[0], the core[0] initializes the VFS and FS contexts in the local cluster,
+from values registered in cluster[0].
+
+A synchronization barrier is used to avoid  access to VFS before initialization.  
+
+=== D8) DEVFS global initialization ===
+
+The 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].
+
+A synchronization barrier is used to avoid access to DEVFS root before initialization.  
+
+=== D9) DEVFS local initialization ===
+
+In each cluster[cxy], the core[0] completes in parallel the DEVFS initialization. Each core[0] get the extended pointers on the ''dev'' and ''external'' directories from values stored in cluster[0]. Then each core[0] creates the DEVFS ''internal'' directory, and creates the pseudo-files for all chdevs in cluster[cxy].
+
+A synchronization barrier is used to avoid access to DEVFS before initialization.  
+
+=== D10) Process init creation ===
+
+The core[0] in cluster[0] creates (i.e. allocates memory, and initializes) the process descriptor for the first user process. This includes the VMM initialization (both the user GPT and VSL inherits relevant informations from the kernel GPT and VSL).
+
+The core[0] in cluster[0] displays the ALMOS-MK banner.
+
+A last synchronization barrier is used before jumping to idle_thread function
+
+=== D11) Enter idle_thread ===
+
+Finally, each core enables its private timer IRQ to activate its private scheduler, and jump to the idle_thread code,
+that contains an infinite loop waiting for an useful thread to be scheduled.