Changes between Version 20 and Version 21 of boot_procedure


Ignore:
Timestamp:
May 3, 2017, 4:07:08 PM (5 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • boot_procedure

    v20 v21  
    1717 * available physical memory in cluster.
    1818
    19 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
    20 section [wiki: Hardware Platform Definition].
    21 
    2219This boot_info_t structure is defined in the '''boot_info.h''' file.
    2320
    24 This section describes successively the ALMOS-MKH boot loader for the TSAR architecture, the ALMOS-MKH boot loader for the
    25 I86 architecture, and the generic ALMOS-MKH kernel initialization procedure.
     21To build the various boot_info_t structures (one per cluster), the boot-loader uses the '''arch_info_t''' binary structure, that is described in
     22section [wiki:arch_info Hardware Platform Definition]. This binary structure is contained in the '''arch_info.bin''' file, and must be stored
     23in the file system root directory.
     24
     25This 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.
     26
     27We describe below the boot_loader for the TSAR architecture, the boot_loader for the I86 architecture, and the generic kernel initialization procedure.
    2628
    2729== Boot-loader for the TSAR architecture ==
     
    3032'''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. 
    3133
     34The TSAR boot_loader allocates - in each cluster containing a physical memory bank - five fixed size memory zones, to store various
     35binary files or data structures :
     36 ||                                                     ||  size    ||  local physical address   ||
     37 || préloader code itself                    || 16 Kb  ||  0x0          ||
     38 || boot-loader code local copy        || 1 Mb   ||  0x100000 ||
     39 || arch_info.bin file local copy         ||  2 Mb   || 0x200000 ||
     40 || kernel.elf binary file                     ||  1 Mb   || 0x400000 ||
     41 || execution stacks (one per core)   || 1 Mb    || 0x500000 ||
    3242
    33 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.
     43In each cluster hosting one kernel instance, the physical memory must contain at least 6 Mbytes.
     44All the values are configuration parameters, that can be redefined in the '''boot_config.h''' file.
     45This memory is only used for temporary storage : when the boot_loader completes, and transfer control to the kernel_init procedure,
     46the kernel code (i.e. the code and data segments) has been copied at physical address 0x4000 in all clusters.
     47The 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.
    3448
    35 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.
    36     * Pour le code du pré-loader : une zone de '''16 Ko''', à partir de l'adresse 0x0.
    37     * Pour le code du boot-loader: une zone de mémoire physique de '''1Mo''', à partir de l'adresse 0x100000.
    38     * Pour le fichier binaire '''arch_info.bin''': une zone de mémoire physique de '''2Mo''', à partir de l'adresse 0x200000.
    39     * Pour le code du noyau: une zone de '''1Mo''', à partir de l'adresse 0x400000.
    40     * Pour les piles d'exécutions des cores: une zone mémoire de '''1Mo''', à partir de l'adresse 0x500000.
    4149
    42 Notons que l'espace adressable physique de chaque cluster doit avoir une capacité au moins égale à '''6Mo'''.
    43 Toutes ces valeurs sont des paramètres de configuration du boot-loader, qui peuvent être redéfinis dans le fichier '''boot_config.h'''.
    44 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.
    4550
    4651Le chargement d'ALMOS-MK sur l'architecture TSAR se fait donc en 4 phases: