Changes between Version 17 and Version 18 of boot_loader


Ignore:
Timestamp:
Feb 1, 2015, 12:35:24 AM (10 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • boot_loader

    v17 v18  
    33[[PageOutline]]
    44
    5 The boot procedure is done in three steps:
    6  * The generic ''reset'' code (hard-coded in the external ROM) is executed by processor (0,0,0), and load the GIRT_VM ''boot-loader'' code from the hard disk to the physical memory.
    7  * The GIET_VM ''boot-loader'' is executed by processor (0,0,0). It load the ''map.bin'' file, build the page tables, initializes the schedulers as specified in the mapping, initializes the peripherals, and load the kernel code, as well as the user application(s) code into memory.
    8  * Finally, the GIET_VM ''kernel_init()'' function is executed by all processors, and completes the kernel initialisation.The system boot is done in three phases.
     5The boot procedure is done in three phases:
     6 * The generic ''reset'' code (hard-coded in the external ROM) is executed by processor (0,0,0), and load the GIET_VM boot-loader code, stored in the ''boot.elf'' file, from the external disk to the physical memory.
     7 * The GIET_VM boot-loader is executed in parallel by all processors (x,y,0). It load the ''map.bin'' file, build the page tables, initializes the schedulers as specified in the mapping, initializes the peripherals, and load the kernel code, as well as the user application(s) code into memory.
     8 * Finally, the GIET_VM ''kernel_init()'' function is executed by all processors, and completes the kernel initialization.
    99
    10 == Phase 1 : Reset Initialisation ==
     10== Phase 1 : Reset Initialization ==
    1111
    12 In case of hard reset, all processors execute the same ''reset'' code (also called ''preloader'' code) stored in the external ROM, but the work done depends on the processor global index. This ''reset'' code is generic. It is entirely defined by the target hardware architecture, and can be used to boot any operating system. 
    13  * Processor (0,0,0) load the GIET_VM boot-loader code from the external disk (or any other mass storage peripheral), to the physical memory of cluster(0,0).
     12In case of hard reset, all processors execute the same ''reset'' code (also called ''preloader'' code) stored in the external ROM, but the work done depends on the processor global index. This ''reset'' code is generic, and can be used to boot any operating system: 
     13 * Processor P(0,0,0) load the GIET_VM boot-loader code from the external disk (or any other mass storage peripheral), to the physical memory bank of cluster(0,0).
    1414 * All other processors initialize their private interrupt controller, to be able to receive an inter-processor interrupt (WTI), and enter ''wait_state'' in low-power mode.
    1515
    1616== Phase 2 : Boot Initialisation ==
    1717
    18 The GIET_VM boot-loader is executed by processor (0,0,0), while other processors are in wait state.
    19 The GIET-VM boot-loader is defined in the [source:soft/giet_vm/giet_boot/boot.c boot.c] file.
     18The GIET_VM boot-loader is defined in the [source:soft/giet_vm/giet_boot/boot.c boot.c] file.
    2019The main steps are the following:
    2120
    22 === void '''boot_pmem_init()''' ===
    23 This function makes the physical memory allocators initialisation. The GIET VM uses two types of pages:
    24  * BPP : Big Physical Page (2 Mbytes).
    25  * SPP : Small Physical Page (4 Kbytes).
     21=== step 1 ===
     22Processor P(0,0,0) initializes the FAT,  initializes the TTY0 lock, initialises the synchronisation barrier, and load the ''map.bin''file. Then processor P(0,0,0) use inter-processor-interrupts (WTI) to start the parallel execution, and activate processor P(x,y,0) in all clusters containing processors.
     23
     24=== step2 ===
     25In each cluster(x,y), processor P(x,y,0) makes the physical memory allocators initialisation (function  '''boot_pmem_init()''' ). The GIET VM uses two types of pages:  BPP (Big Physical Page, 2 Mbytes), and  SPP  (Small Physical Page, 4 Kbytes).
    2626There is one SPP and one BPP allocator per cluster containing a physical memory bank.
    27 All the physical memory allocation is done by the boot-loader in the boot phase, and these memory allocators
     27All the physical memory allocation must be done by the boot-loader in the boot phase, and these memory allocators
    2828should not be used by the kernel in the execution phase.
    2929
    30 === void '''boot_ptabs_init()''' ===
    31 This function makes the page table initialisation. There is one page table per user application (vspace) defined in the mapping.
    32 All these pages tables are packed in one segment (seg_ptab) occupying one single big page (2 Mbytes), but this PTAB segment is replicated in all clusters.
    33 As the kernel read-only segments (seg_kcode and seg_kinit) are replicated in all clusters to avoid contention, the content of the page tables depends
    34 on the cluster-coordinates: for the kernel code, a given virtual address is mapped to different physical addresses, depending on the cluster coordinates.
     30=== step 3 ===
     31In each cluster(x,y), processor P(x,y,0) makes the local page table initialisation (function '''boot_ptabs_init()''') as specified in the mapping.  There is one page table per user application (vspace) defined in the mapping, and it is replicated in all clusters containing processors. In each cluster, all pages tables are packed in one segment (seg_ptab) occupying one single big page (2 Mbytes). Global vsegs are mapped in all vspaces. Any vseg (but the peripherals)can be mapped on any physical segment. As the kernel read-only segments (seg_kcode and seg_kinit) are replicated in all clusters to avoid contention, the content of the page tables depends on the cluster-coordinates: for the kernel code, a given virtual address is mapped to different physical addresses, depending on the cluster coordinates.
    3532
    36 === '''boot_schedulers init()''' ===
    37 This function makes the schedulers initialisation, as specified in the mapping, respecting the following principles.
     33=== step 4 ===
     34In each cluster(x,y), processor P(x,y,0) makes the schedulers initialization for all processors in the cluster (function '''boot_schedulers init()''') as specified in the mapping:
    3835 * There is one scheduler per processor.
    3936 * Any task defined in any application can be allocated to any processor.
    … …  
    4239  * One scheduler occupies 8 Kbytes, and contains the contexts of all tasks allocated to the processor (256 bytes per task).
    4340 
    44 === '''boot_peripherals_init()''' ===
    45 This function makes the external peripherals and coprocessors initialisation.
     41=== step 5 ===
     42Finally, processor P(0,0,0) makes peripherals initialisation (function '''boot_peripherals_init()'''),  coprocessors initialisation, and load into memory the kernel code (''kernel.elf'' file), and the user code for all applications specified in the mapping (function '''boot_elf_load()''').
    4643
    47 === '''boot_elf_load()''' ===
    48 This function load into memory the kernel code (''kernel.elf'' file), and the user code for all applications specified in the mapping.
    49 
    50 Finally, processor(0,0,0) starts all other processors, using an inter-processor interrupt (WTI).
    51 Each processor initializes its own CP0_SCHED register, its own CP2_MODE register to activates its MMU, its own CP0_SR register to use the GIET_VM exception handler, and jumps
     44=== step 6 ===
     45Finally, in each cluster(x,y) processor(x,y,0) starts all other processors in the cluster, using an inter-processor interrupt (WTI). Each processor initializes its own CP0_SCHED register, its own CP2_MODE register to activates its MMU, its own CP0_SR register to use the GIET_VM exception handler, and jumps
    5246to the ''kernel_init()''  function.
    5347