Changes between Version 10 and Version 11 of mapping_info


Ignore:
Timestamp:
Oct 27, 2014, 3:35:47 PM (10 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • mapping_info

    v10 v11  
    88All software objects (user applications code and data, but also kernel code and critical kernel structures such as the page tables or the processors schedulers) are statically build and loaded from disk into physical memory by the GIET_VM bootloader in the boot phase.
    99
    10 The main advantage of this static approach is to provide the system designed a full control on the placement of tasks on processors but also of the data (software objects) on the distributed physical memory banks. It supports optional replication of critical objects such as kernel code, or page tables.
     10The main advantage of this static approach is to provide the system designed a full control on the placement of tasks on processors but also of the data (software objects) on the distributed physical memory banks. It supports replication of critical objects such as kernel code, or page tables.
    1111
    1212To control the mapping, the system designer must provide a '''map.bin''' file containing a dedicated C binary data structure, that is loaded in memory by the bootloader.
     
    3939The ''map.bin'' file must be stored on disk and will be loaded  in memory by the GIET_VM bootloader in the ''seg_boot_mapping'' segment.
    4040
    41 == __Python mapping introduction__ ==
     41== __Python mapping description__ ==
    4242
    4343A specific mapping requires at least two python files:
     
    4747The various Python Classes used by these these files are defined in the [source:soft/giet_vm/giet_python/mapping.py mapping.py] file.
    4848
    49 == __Python architecture description__ ==
     49== __Python hardware architecture description__ ==
    5050
    51 To define an architecture, you must use the following constructors:
     51The target hardware architecture must be defined in the ''arch.py'' file , you must use the following constructors:
    5252
    5353=== 1. mapping ===
     
    115115The supported ISR types are defined in the [source:soft/giet_vm/giet_python/mapping.py mapping.py] file.
    116116
    117 === 5. Kernel vseg ===
     117== __Python global vsegs description__ ==
    118118
    119 The '''mapping.addGlobal()''' construct define a kernel virtual segment (a ''kernel vseg'' is defined in all ''vspaces'', and is called ''global''). It has the following arguments:
     119The mapping of the GIET_VM vsegs must be defined in the ''arch.py'' file.
     120
     121Each kernel virtual segment has the ''global'' attribute, and must be mapped in all vspaces. It can be mapped to a set of consecutive small pages (4 Kbytes), or to a set of consecutives big pages (2 Mbytes).
     122
     123The '''mapping.addGlobal()''' construct define the mapping for one kernel vseg. It has the following arguments:
    120124|| name       || virtual segment name  ||
    121125|| vbase       || virtual base address ||
     
    133137
    134138The supported values for the ''mode'' argument, and for the ''vtype'' arguments are defined in the [source:soft/giet_vm/giet_python/mapping.py mapping.py] file.
    135 The ''x'', ''y'', and ''pseg'' define actually the mapping.
     139The ''x'', ''y'', and ''pseg'' arguments define actually the mapping.
     140
     141=== Boot vsegs ===
     142
     143There is 4 'vsegs for the GIET_VM bootloader:
     144 * The '''seg_boot_mapping''' vseg contains the C binary structure defining the mapping. It is loaded from disk by the boot-loader.
     145 * The '''seg_boot_code''' vseg contains the boot-loader code. It is loaded from disk by the preloader.
     146 * The '''seg_boot_data''' vseg contains the boot-loader global data.
     147 * The '''seg_boot_stacks''' vseg contains the stacks for all processors.
     148These 4 vsegs must be identity mapping (because the page table are not available), and are mapped in the first big physical page (2 Mbytes) in cluster [0][0].
     149
     150=== Kernel vsegs ===
     151
     152There is six types of vsegs for the GIET_VM kernel, but some vsegs are replicated in all clusters, to improve locality and minimize contention, as explained below:
     153 * The '''seg_kernel_ptab_x_y''' vseg has type PTAB. It contains the page tables for all vspaces (one page table per vspace). There is one such vseg in each cluster
     154(one set of page tables per cluster). Each vseg is mapped in one big physical page.
     155 * The '''seg_kernel_code''' & '''seg_kernel_init''' have type ELF. They contain the kernel code. These two vsegs must be mapped in one big physical page. They are  replicated in each cluster, to improve locality and minimize contention. The ''local'' attribute must be set, because the same virtual address will be mapped on different physical address depending on the cluster.   
     156 * The  '''seg_kernel_data''' & '''seg_kernel_uncdata''' have type ELF. They contain the kernel global data (cacheable, or non cacheable). They are not replicated, and must be mapped in cluster[0][0].
     157 * The '''seg_kernel_sched_x_y''' vseg has type SCHED. It contains the processor schedulers (one scheduler per processor). There is one such vseg in each cluster, and it must be mapped on small pages (two small pages per scheduler).
     158
     159=== Peripheral vsegs ===
     160
    136161As a global vseg can be mapped (replicated) in more than one cluster, the local argumentpage tables can be r, the ''local'' argument
    137 Any ''vseg'' can be mapped or in a set of consecutive small pages (4 Kbytes), either on a set of consecutives big pages (2 Mbytes).
     162
    138163
    139164== __Python application description__ ==