| 120 | |
| 121 | The kernel_init( boot_info_t * info ) function is the kernel entry point when the boot_loader transfer control to kernel. |
| 122 | The ''info'' argument is a pointer on the fixed size boot_info_t structure, that is stored in the data kernel segment. |
| 123 | |
| 124 | All cores execute this procedure in parallel, but some tasks are only executed by the CP0 core. |
| 125 | This procedure uses two synchronisation barriers, defined as global variables in the data segment: |
| 126 | * the global_barrier variable is used to synchronize all CP0 cores in all clusters containing a kernel instance. |
| 127 | * the local_barrier variable is used to synchronize all cores in a given cluster. |
| 128 | |
| 129 | The kernel initialization procedure execute sequentially the following steps: |
| 130 | |
| 131 | === D1) Core and cluster identification === |
| 132 | |
| 133 | Each core has an unique hardware identifier, called '''gid''', that is hard-wired in a read-only register. |
| 134 | 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. |
| 135 | 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. |
| 136 | Then the CP0 initialize the global variable '''local_cxy''' defining the local cluster identifier. |
| 137 | |
| 138 | === D2) TXT0 device initialization === |
| 139 | |
| 140 | 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 : |
| 141 | the calling thread call directly the relevant TXT driver, without using a server thread. |
| 142 | |
| 143 | A first synchonization barrier is used to avoid other cores to use the TXT0 terminal before initialization completion. |
| 144 | |
| 145 | === D3) Cluster manager Initialization === |
| 146 | |
| 147 | In Each cluster the CP0 makes the cluster manager initialization, namely the cores descriptors array, and the physical memory allocators. |
| 148 | Then it initializes the local process_zero, containing al kernel threads in a given cluster. |
| 149 | |
| 150 | A second synchonization barrier is used to avoid other cores to access cluster manager before initialization completion. |
| 151 | |
| 152 | === D4) Internal & external devices Initialization === |
| 153 | |
| 154 | In each cluster, the CP0 makes the devices initialization. For multi-channels devices, there is one channel device (called chdev_t) per channel. |
| 155 | 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 |
| 156 | index by a modulo. |
| 157 | |
| 158 | The internal devices descriptors are created first( ICU, then MMC, then DMA ), because the ICU device is used by all other devices. |
| 159 | Then the WTI mailboxes used for IPIs (Inter Processor Interrupt) are allocated in local ICU : one WTI mailbox per core. |
| 160 | Then each external chdev descriptor is created by the CP0 in the cluster where it must be created. |
| 161 | |
| 162 | A third synchonization barrier is used to avoid other cores to access devices before initialization completion. |
| 163 | |
| 164 | === D5) Idle thread Initialization === |
| 165 | |
| 166 | In this step, each core creates and initializes, its private idle thread. |
| 167 | |
| 168 | === D6) File system initialization === |
| 169 | |
| 170 | The CP0 in I/O cluster) initializes the file system. |
| 171 | |
| 172 | A fourth synchonization barrier is used to avoid other cores to access file system before initialization completion. |
| 173 | |
| 174 | === D7) Scheduler activation === |
| 175 | |
| 176 | Finally, each core enables its private timer IRQ to activate its private scheduler, and jump to the idle thread code. |
| 177 | |