Changes between Version 20 and Version 21 of boot_procedure

Timestamp:

May 3, 2017, 4:07:08 PM (7 years ago)

Author:

alain

Comment:

--

boot_procedure

@@ -17 +17 @@
  * available physical memory in cluster.
 
-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: Hardware Platform Definition].
-
 This boot_info_t structure is defined in the '''boot_info.h''' file.
 
-This section describes successively the ALMOS-MKH boot loader for the TSAR architecture, the ALMOS-MKH boot loader for the
-I86 architecture, and the generic ALMOS-MKH kernel initialization procedure.
+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 method allows -in principle - the boot_loader to check and reconfigure the hardware components, to guaranty that the generated boot_info_t structures contain only functionally tested hardware components.
+
+We describe below the boot_loader for the TSAR architecture, the boot_loader for the I86 architecture, and the generic kernel initialization procedure.
 
 == Boot-loader for the TSAR architecture ==
@@ -30 +32 @@
 '''boot-loader''' code from an external block-device to the memory. This preloaded is specific for the TSAR architecture, but independent on the Operating System. It is used by ALMOS-MKH, but also by LINUX, NetBSD, or the GIET-VM.  
 
+The TSAR boot_loader allocates - in each cluster containing a physical memory bank - five fixed size memory zones, to store various
+binary files or data structures :
+ ||                                                     ||  size    ||  local physical address   ||
+ || préloader code itself                    || 16 Kb  ||  0x0          ||
+ || boot-loader code local copy        || 1 Mb   ||  0x100000 ||
+ || arch_info.bin file local copy         ||  2 Mb   || 0x200000 ||
+ || kernel.elf binary file                     ||  1 Mb   || 0x400000 ||
+ || execution stacks (one per core)   || 1 Mb    || 0x500000 ||
 
-the shared resources (such as the récupère les informations décrivant les caractéristiques de la plateforme matérielle (nombre de clusters, nombre de coeurs par cluster, périphériques disponibles, ciblage des interruptions, etc.)  dans le fichier binaire '''arch_info.bin'''. Il utilise pour construire - dans chaque cluster - la structure de données '''boot_info_t''', utilisée par l'instance locale du noyau ALMOS-MK, et décrivant les composants matériels disponibles dans le cluster, ainsi que les caractéristiques générales de la plateforme. Cette structure est rangée au début du segment de données '''kdata''' du noyau et est utilisée - dans caque cluster - par la fonction '''kernel_init()'''. Ces informations en entrée et en sortie du boot-loader peuvent sembler redondantes mais cette traduction (arch-info -> boot_info) permet - en principe - au boot-loader de vérifier le bon fonctionnement de la plateforme matérielle et de détecter les pannes dues au vieillissement du matériel. Dans cette approche, les structures '''boot_info_t''' générées par le boot-loader ne contiennent que les composants matériels effectivement utilisables par le noyau. Cette vérification/reconfiguration n'est pas implémentée.
+In each cluster hosting one kernel instance, the physical memory must contain at least 6 Mbytes.
+All the values are configuration parameters, that can be redefined in the '''boot_config.h''' file.
+This memory is only used for temporary storage : when the boot_loader completes, and transfer control to the kernel_init procedure,
+the kernel code (i.e. the code and data segments) has been copied at physical address 0x4000 in all clusters. 
+The four pages (16 Kbytes) reserved for the prelloader are only used in cluster 0 and can be saved if the preloader is stored in an external ROM.
 
-Par convention, on définit - dans chaque cluster - des zones de mémoire physique de longueur fixe pour les différents fichiers binaires et/ou structures de données utilisés pendant le démarrage du système.
-    * Pour le code du pré-loader : une zone de '''16 Ko''', à partir de l'adresse 0x0.
-    * Pour le code du boot-loader: une zone de mémoire physique de '''1Mo''', à partir de l'adresse 0x100000.
-    * Pour le fichier binaire '''arch_info.bin''': une zone de mémoire physique de '''2Mo''', à partir de l'adresse 0x200000.
-    * Pour le code du noyau: une zone de '''1Mo''', à partir de l'adresse 0x400000.
-    * Pour les piles d'exécutions des cores: une zone mémoire de '''1Mo''', à partir de l'adresse 0x500000.
 
-Notons que l'espace adressable physique de chaque cluster doit avoir une capacité au moins égale à '''6Mo'''.
-Toutes ces valeurs sont des paramètres de configuration du boot-loader, qui peuvent être redéfinis dans le fichier '''boot_config.h'''.
-Les quatre premières pages (16 Koctets) réservées au pré-loader ne sont utilisée que dans le cluster 0, et uniquement si le pré-loader n'est pas stocké dans une ROM externe. 
 
 Le chargement d'ALMOS-MK sur l'architecture TSAR se fait donc en 4 phases: