Changes between Version 20 and Version 21 of boot_loader

Timestamp:

Feb 5, 2015, 10:51:24 AM (9 years ago)

Author:

alain

Comment:

--

boot_loader

@@ -4 +4 @@
 
 The boot procedure is done in three phases: 
- * 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. 
- * The GIET_VM boot-loader is executed in parallel by all processors P(x,y,0): one processor per cluster. It loads 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. 
- * Finally, the GIET_VM ''kernel_init()'' function is executed by all processors, and completes the kernel initialization.
+ * The generic ''reset'' code (hard-coded in the external ROM) is executed by processor P(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. 
+ * The GIET_VM boot-loader is executed in parallel by all processors P(x,y,0): one processor per cluster. The bootloader loads 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. 
+ * Finally, the GIET_VM ''kernel_init()'' function is executed by all processors P(x,y,p), and completes the kernel initialization.
 
 == Phase 1 : Reset Initialization ==
 
 After 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: 
- * Processor P(0,0,0) load the GIET_VM boot-loader code from the external disk (or another bootable mass storage peripheral), to the physical memory bank in cluster(0,0): segments seg_boot_code and seg_boot_data.
+ * Processor P(0,0,0) load the GIET_VM boot-loader code from the external disk (or another bootable peripheral), to the physical memory bank in cluster(0,0): segments seg_boot_code and seg_boot_data.
  * 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.
 This ''reset'' code is generic, and can be used to boot any operating system.  
@@ -28 +28 @@
 
 === step 1 ===
-Processor P(0,0,0) initializes the FAT,  initializes the TTY0 lock, initializes the synchronization barrier, and load the ''map.bin''file to the physical memory bank in cluster(0,0). Then processor P(0,0,0) use inter-processor-interrupts (WTI) to start the parallel execution, and activate processors P(x,y,0) in all clusters containing processors.
+Processor P(0,0,0) initializes the FAT,  initializes the TTY0 lock, initializes the synchronization barrier, and load the ''map.bin'' file to the physical memory bank in cluster(0,0): segment seg_boot_mapping. Then processor P(0,0,0) uses inter-processor-interrupts (WTI) to start the parallel execution, and activates one processor per cluster (processor P(x,y,0) ) in all clusters containing processors.
 
 === step2 ===
-In 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).
+In each cluster(x,y), processor P(x,y,0) makes the physical memory allocator 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).
 There is one SPP and one BPP allocator per cluster containing a physical memory bank.
 All the physical memory allocation must be done by the boot-loader in the boot phase, and these memory allocators