Changes between Version 65 and Version 66 of boot_procedure


Ignore:
Timestamp:
Dec 7, 2019, 1:44:40 PM (5 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • boot_procedure

    v65 v66  
    99 * The architecture independent phase, implemented by a generic (architecture independent) '''kernel-init''' procedure.
    1010
    11 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
    12 the ALMOS-MKH kernel code, and a description of the hardware architecture, contained in a local ''boot_info'' data-structure, .
    13 
    14 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:
     11As 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, .
     12
     13This 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:
    1514 * general hardware architecture features : number of clusters, topology, etc.
    1615 * available external (shared) peripherals : types and features.
    … …  
    1918 * available physical memory in cluster.
    2019
    21 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.
     20This '''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.
    2221
    2322To build the various boot_info structures (one per cluster), the boot-loader uses the '''arch_info''' binary structure, that is described in
    24 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.
     23section [wiki:arch_info Hardware Platform Definition].
     24
     25This '''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.
     26
    2527To be accessed by the boot loader, the binary file '''arch_info.bin''' file must be stored on disk, in the file system root directory.
    2628
    27 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.
     29This method allows an intelligent boot_loader to check the hardware components, to guaranty that the generated '''boot_info''' structures contain only functionally tested hardware components.
    2830
    2931We describe below the boot_loader for the TSAR architecture, the boot_loader for the I86 architecture, and the generic kernel initialization procedure.
    … …  
    3133== B) __Boot-loader for the TSAR architecture__ ==
    3234
    33 The TSAR boot-loader uses an OS-independent '''pre-loader''', stored in an addressable but non-volatile device, that load the TSAR
    34 '''boot-loader''' code from an external block-device to the cluster 0 physical memory. This preloader is specific for the TSAR architecture, but independent on the Operating System. It is used by ALMOS-MKH, but also by LINUX, NetBSD, ALMOS_MKH, or the GIET-VM. 
     35The  bootloader uses an OS-independent '''preloader''', stored in an addressable but non-volatile device, that load the
     36'''bootloader''' code from an external block-device to the cluster 0 physical memory. This preloader is specific for the TSAR architecture, but is independent on the Operating System. It is used by ALMOS-MKH, but also by LINUX, NetBSD, ALMOS_MKH, or the GIET-VM. 
    3537
    3638The TSAR boot_loader allocates - in each cluster containing a physical memory bank - six fixed size memory zones, to store various
    37 binary files or data structures. The two first zones are permanently allocated: The '''PRE_LOADER''' zone is only defined in cluster 0, and contains the pre-loader code. The '''KERNEL_CODE''' zone containing the ''kcode'' and ''kdata'' sgments is directly used by the kernel when the boot_loader transfers control - in each cluster - to the kernel_init procedure. The '''BOOT_CODE''', '''ARCH_INFO''', '''KERNEL_ELF''', and '''BOOT_STACK''' zones are temporary: they are only used - in each cluster - by the boot-loader code, and the corresponding physical memory can be freely re-allocated by the local kernel instance when it starts execution.
     39binary files or data structures. The two first zones are permanently allocated: The '''PRE_LOADER''' zone can contain (for example in the TSAR-LETI architecture) the preloader code. The '''KERNEL_CODE''' zone containing the ''kcode'' and ''kdata'' sgments is directly used by the kernel when the bootloader transfers control - in each cluster - to the kernel_init procedure. The '''BOOT_CODE''', '''ARCH_INFO''', '''KERNEL_ELF''', and '''BOOT_STACK''' zones are temporary: they are only used - in each cluster - by the boot-loader code, but the corresponding physical memory can be freely re-allocated by the local kernel instance when it starts execution.
    3840
    3941 || name                        || description                            ||  base address (physical)          || size                                                             ||
    … …  
    5052   * the BOOT_CODE zone (containing the boot loader instructions and data) must be entirely contained in the next big physical page, because it will be mapped in the boot-loader page table to allow the cores to access locally the boot code as soon as it has been copied in the local cluster.
    5153
    52 A core[cxy][lid] is identified by  two indexes: '''cxy''' is the cluster identifier, an '''lid''' is the core local index in cluster.
    53 The CP0 register containing the core gid (global hardware identifier) has a fixed format:   '''gid''' = ('''cxy''' << 2) + '''lid'''
     54For almos-mkh, a  core is identified by  two - architecture independent - indexes: '''cxy''' is the cluster identifier, an '''lid''' is the core local index in cluster.
     55
     56For the TSAR architecture, the MIPS32 CP0 register containing the core gid (global hardware identifier) that has a fixed format:   '''gid''' = ('''cxy''' << 2) + '''lid'''
    5457
    5558All cores contribute to the boot procedure, but all cores are not simultaneously active:
    … …  
    5861 * in the last phase - fully parallel - all core[cxy][lid] are running.
    5962
    60 We describe below the four phases of the TSAR boot-loader:
    61 
    62 === B1. Pre-loader ===
    63 
    64  * In the TSAR_LETI architecture, the pre-loader code is stored in the first 16 kbytes of the physical address space in cluster 0.
     63We describe below the five phases of the TSAR bootloader:
     64
     65=== B1. Preloader ===
     66
     67 * In the TSAR_LETI architecture, the preloader code is stored in the first 16 kbytes of the physical address space in cluster 0.
    6568 * In the TSAR_IOB architecture, the preloader is stored in an external ROM, that is accessed throug the IO_bridge located in cluster 0.
    6669
    67 At reset, the MMU is de-activated (for both data and instructions), and the extension address register supporting direct access to remote memory banks (for data only)  contain the 0 value.
    68 Therefore, all cores can only access the physical address space of cluster 0.
    69 
    70 All cores execute the same pre-loader code, but the work done depends on the core identifier:
     70At reset, the MMU is de-activated (for both data and instructions), and the extension address register supporting direct access to remote memory banks (for data only)  contain the 0 value. Therefore, in this first phase, all cores can only access the physical address space of cluster 0.
     71
     72All cores execute the same preloader code, but the work done depends on the core identifier:
    7173   * The core[0][0] load in the BOOT_CODE zone of cluster 0, the boot-loader code stored on disk.
    7274   * All other cores do only one task before going to sleep (i.e. low-power state): each core activates its private WTI channel in the local ICU (Interrupt Controller Unit) to be later activated by an IPI (Inter Processor Interrupt). 
    7375
    74 === B2. Boot-loader entry ===
    75 
    76 The first instructions of the boot-loader are defined in the ''boot_entry.S'' file. This assembly code is executed by all cores entering the boot-loader, but not at the same time.
     76=== B2. Bootloader entry ===
     77
     78The first instructions of the bootloader are defined in the [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/boot/tsar_mips32/boot_entry.S  almos-mkh/boot/tsar_mips32/boot_entry.S] file. This assembly code is executed by all cores entering the boot-loader, but not at the same time.
    7779
    7880Each core running this assembly code makes the 3 following actions:
    … …  
    8587In this phase, only core [0][0] is running, while all other cores are blocked in the preloader, waiting to be activated by an IPI.
    8688
    87 The first instructions of the boot-loader are defined in the ''boot_entry.S'' file. This assembly code is executed by all cores entering the boot-loader, but not at the same time.
    88 
    89 Each core running this assembly code makes the 3 following actions:
    90    * It initializes the core stack pointer depending on the '''lid''' value extracted from the '''gid''', using the BOOT_STACK_BASE and BOOT_STACK_SIZE parameters defined in the  ''boot_config.h'' file,                                                                   
    91    * It changes the value of the DATA address extension CP2 register, using the '''cxy''' value extracted from the '''gid''', to force all cores to use the local stack segments.                                                                           
    92    * It jumps to the boot_loader() C function defined in the ''boot.c'' file, passing the two (cxy , lid) arguments.
    93 
    94 In this sequencial phase, the core[0][0]  executing this C function makes the following actions:
     89In this sequencial phase, the core[0][0]  executes the boot_loader() C function, defined in the  [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/boot/tsar_mips32/boot.c  almos-mkh/boot/tsar_mips32/boot.c] function.
     90
     91It makes the following actions:
    9592   * The core[0][0] initializes 2 peripherals: The '''TTY''' terminal (channel 0)  to display log messages, and the '''IOC''' peripheral to access the disk file system.
    9693   * The core[0][0] initializes the boot-loader FAT32, allowing the boot loader to access files stored in the FAT32 file system on disk.
    … …  
    103100=== B4. Boot-loader partially parallel phase ===
    104101
    105 In this phase all core[cxy][0], other than the core[0][0] are running.
     102In this phase all core[cxy][0], other than the core[0][0] are running (one core per cluster).
    106103
    107104At this point, all DATA extension registers point already on the local cluster( to use the local stack).