Changes between Version 64 and Version 65 of boot_procedure

Timestamp:

Dec 7, 2019, 1:04:40 PM (5 years ago)

Author:

alain

Comment:

--

boot_procedure

@@ -6 +6 @@
 
 The ALMOS-MKH boot procedure can be decomposed in two phases:
- * The architecture dependent phase, implemented by an architecture specific '''boot_loader''' procedure.
+ * The architecture dependent phase, implemented by an architecture specific '''bootloader''' procedure.
  * The architecture independent phase, implemented by a generic (architecture independent) '''kernel-init''' procedure.
 
-As the generic (i.e. architecture independent) kernel initialization procedure is executed in parallel by all kernel instances in all clusters containing at least one core and one memory bank, the main task of the boot-loader is to load - in each cluster - a local copy of
-the ALMOS-MKH kernel code, and a description of the hardware architecture, contained in a local ''boot_info_t'' data-structure.
-
-This fixed size ''boot_info_t'' structure is build by the boot-loader, and stored at the beginning of the local copy of the kdata segment. As it contains both general and cluster specific information, the content depends on the cluster:
+As the generic (i.e. architecture independent) kernel initialization procedure is executed in parallel by all kernel instances in all clusters containing at least one core and one memory bank, the main task of the bootloader is to load - in each cluster - a local copy of
+the ALMOS-MKH kernel code, and a description of the hardware architecture, contained in a local ''boot_info'' data-structure, .
+
+This fixed size ''boot_info'' structure is build by the boot-loader, and stored at the beginning of the local copy of the kdata segment. As it contains both general and cluster specific information, the content depends on the cluster:
  * general hardware architecture features : number of clusters, topology, etc.
  * available external (shared) peripherals : types and features. 
@@ -19 +19 @@
  * available physical memory in cluster.
 
-This boot_info_t structure is defined in the '''boot_info.h''' file.
-
-To build the various boot_info_t structures (one per cluster), the boot-loader uses the '''arch_info_t''' binary structure, that is described in
-section [wiki:arch_info Hardware Platform Definition]. This binary structure is contained in the '''arch_info.bin''' file, and must be stored
-in the file system root directory. 
+This boot_info structure is defined in the  [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/tools/arch_info/boot_info.h  almos-mkh/tools/arch_info/boot_info.h] and [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/tools/arch_info/boot_info.c  almos-mkh/tools/arch_info_info/boot_info.c] files.
+
+To build the various boot_info structures (one per cluster), the boot-loader uses the '''arch_info''' binary structure, that is described in
+section [wiki:arch_info Hardware Platform Definition]. This '''arch_info''' structure is defined in the [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/tools/arch_info/arch_info.h  almos-mkh/tools/arch_info/arch_info.h] and [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/tools/arch_info/arch_info.c  almos-mkh/tools/arch_info/arch_info.c] files.
+To be accessed by the boot loader, the binary file '''arch_info.bin''' file must be stored on disk, in the file system root directory. 
 
 This method allows an intelligent boot_loader to check and - if required - reconfigure the hardware components, to guaranty that the generated boot_info_t structures contain only functionally tested hardware components.