Changes between Version 17 and Version 18 of boot_procedure


Ignore:
Timestamp:
May 3, 2017, 2:53:25 PM (7 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • boot_procedure

    v17 v18  
    33[[PageOutline]]
    44
    5 Le boot-loader d'ALMOS-MK, est chargé par le preloader, qui est spécifique à l'architecture cible, mais indépendant du système d'exploitation à charger. Le boot-loader a pour fonction de charger en mémoire le système ALMOS-MK, et il est dépend de l'architecture cible.
     5The ALMOS-MKH boot procédure can be decomposed in two phases:
     6 * The architecture dependent phase, implemented by the '''boot_loader''' procedure.
     7 * The architecture indépendant phase, inplemented by the '''kernel-init''' procedure.
    68
    7 == Boot-loader pour l'architecture TSAR ==
     9As 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, the main task of the architecture dependent boot-loader is to load - in each cluster - a local copy of
     10the ALMOS-MKH kernel code, including a description of the hardware architecture, contained in the '''boot_info_t''' data-structure.
     11This structure is build by the boot-loader and stored at the beginning of the local copy of the kdata segment. It contains both general and cluster specific informations:
     12 * general hardware architecture features : number of clusters, the topology, etc.
     13 * available external (shared) peripherals : types and features.
     14 * number of cores in cluster,
     15 * available internal (private) peripherals in cluster : types and features.
     16 * available physical memory in cluster.
     17 
     18This boot_info_t structure is defined in the
    819
    9 Le boot-loader 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.
     20This section describes successively the ALMOS-MKH boot loader for the TSAR architecture, the ALMOS-MKH boot loader for the
     21I86 architecture, and the generic ALMOS-MKH kernel initialization procedure.
     22
     23== Boot-loader for the TSAR architecture ==
     24
     25The TSAR boot-loader uses an OS-independant '''pre-loader''', stored in an external ROM, and in charge of loading the TSAR
     26'''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. 
     27
     28The main task done by the TSAR boot-loader is to build - for each cluster - a so-called '''boot_info_t''' data structure, describing
     29
     30This boot_info_t structure can be find in the in the cluster
     31the 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.
    1032
    1133Par 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.
    … …  
    6890
    6991Arrivé à ce point, le boot-loader a fini son travail, la description de la l'architecture matérielle contenue dans '''arch_info.bin''' a été analysée et stockée dans la variable globale de type '''boot_info_t''' du noyau, stockée dans le segment data du noyau. Dans chaque cluster, ALMOS-MK peut utiliser tout l'espace adressable physique occupé antérieurement par l'image du boot-loader, '''arch_info.bin''' et les piles de boot. La seule zone de mémoire persistante est l'image du noyau elle-même (les segments ''kcode'' et ''kdata''), stockée à l'adresse '''0x0''' dans tous les clusters.
     92
     93== Boot-loader for the I86 architecture ==
     94
     95TODO
     96
     97== Generic ALMOS-MKH initialisation procedure