Changes between Version 63 and Version 64 of boot_procedure
- Timestamp:
- Nov 7, 2019, 8:24:49 PM (4 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
boot_procedure
v63 v64 60 60 We describe below the four phases of the TSAR boot-loader: 61 61 62 === B1. Pre-loader phase===62 === B1. Pre-loader === 63 63 64 64 * In the TSAR_LETI architecture, the pre-loader code is stored in the first 16 kbytes of the physical address space in cluster 0. 65 65 * In the TSAR_IOB architecture, the preloader is stored in an external ROM, that is accessed throug the IO_bridge located in cluster 0. 66 66 67 At reset, the MMU is de-activated (for both data and instructions), and the extension address register ssupporting direct access to remote memory banks (for data only) contain the 0 value.67 At reset, the MMU is de-activated (for both data and instructions), and the extension address register supporting direct access to remote memory banks (for data only) contain the 0 value. 68 68 Therefore, all cores can only access the physical address space of cluster 0. 69 69 … … 72 72 * 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). 73 73 74 === B2. Boot-loader sequencial phase === 74 === B2. Boot-loader entry === 75 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, but not at the same time. 77 78 Each core running this assembly code makes the 3 following actions: 79 * 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, 80 * It changes the value of the DATA address extension CP2 register, using the '''cxy''' value extracted from the '''gid''', to force each core to access its stack in local physical memory. 81 * It jumps to the boot_loader() C function defined in the ''boot.c'' file, passing the two (cxy , lid) arguments. 82 83 === B3. Boot-loader sequencial phase === 75 84 76 85 In this phase, only core [0][0] is running, while all other cores are blocked in the preloader, waiting to be activated by an IPI. … … 92 101 * The core[0][0] send IPIs to activate all cores [cxy][0] in all other clusters. 93 102 94 === B 3. Boot-loader partially parallel phase ===103 === B4. Boot-loader partially parallel phase === 95 104 96 105 In this phase all core[cxy][0], other than the core[0][0] are running. … … 107 116 * In each cluster cxy, the core[cxy][0] activates the other cores that are blocked in the pre-loader. 108 117 109 === B 4. Boot-loader fully parallel phase ===118 === B5. Boot-loader fully parallel phase === 110 119 111 120 In this phase all core[cxy][lid] are running.
