Changes between Version 2 and Version 3 of DsxvmMappingInfoStructure


Ignore:
Timestamp:
Aug 30, 2012, 12:42:09 PM (12 years ago)
Author:
karaoui
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • DsxvmMappingInfoStructure

    v2 v3  
    1111= Document XML Structure =
    1212
    13 In order to simplify the document type definition, all element attributes are mandatory.
    14 
     13In order to simplify the parsing of the document the order between elements has to be respected.
     14This document contain two main descriptions:
     15 * a minimal description of the hardware : all elements described must exist on the targeted architecture. Non described element will not be used by the soft.
     16 * a description of the soft mapping on the hardware
    1517
    1618== The mapping_info element ==
    1719
    18 The mapping file is constituted of a single `mapping_info` element, containing the following attributes:
     20The two descriptions are regrouped in the `mapping_info` element, which contain the following attributes:
    1921 * `name`: the name of the mapping described
    20  * `signature`: ''what is it?'' (Mohamed?)
    21  * `clusters`: the number of clusters used in the mapping. It must correspond to the number of clusters in the targeted architecture
    22  * `vpsaces`: the number of vspaces defined. This number is typically equal to the number of applications (requirement?)
     22 * `signature`: a way to check that we are handling a mapping info structure, must be equal to "0xdeadbeef"
     23 * `clusters`: the number of clusters of the targeted architecture
     24 * `vpsaces`: the number of vspaces defined. This number is typically equal to the number of applications
    2325
    2426The `mapping_info` element contains the following elements:
    2527 * a `clusterset` element, describing the targeted hardware
    26  * a `globalset` element, describing the global segments, i.e. segments replicated in all virtual spaces
     28 * a `globalset` element, describing the global segments, i.e. segments replicated in all virtual spaces (typically the kernel code)
    2729 * a `vspaceset` element, describing the mapping for all virtual spaces
    2830
    … …  
    3739
    3840This element contains the following attribute:
    39  * `index`: the cluster index, or ''id''. It is unique for each cluster and must range from 0 to ''n - 1''. The cluster index make the correspondance with the cluster id in the architecture.
     41 * `index`: the cluster index, or ''id''. It is unique for each cluster and must range from 0 to ''n - 1'' (n being the number of cluster). The cluster index make the correspondance with the cluster id in the architecture.
    4042
    4143The cluster element contains the following elements:
    4244 * 0 to ''n'' `pseg` element(s)
    43  * 0 to ''n'' `proc` element(s). The number of `proc` elements must be equal to the number of processors in this cluster in the targeted architecture (doit être le même dans chaque cluster ?).
     45 * 0 to ''n'' `proc` element(s).
    4446 * 0 to ''n'' `periph` element(s)
    4547
    … …  
    4951This element contains the following attributes:
    5052 * `name`: name of the segment. The name of the segment is not related to any segment name in the architecture. It is used to associate virtual segments on physical segments inside the mapping info file.
    51  * `base`: base of the physical segment
    52  * `type`: type of the segment. It can be one of `RAM`, `ROM`, `PERI` (influence ??)
    53  * `length`: size of the segment (utilisé pour des vérifications ?)
     53 * `base`: base of the physical segment.
     54 * `type`: type of the segment. It can be one of `RAM`, `ROM`, `PERI`
     55 * `length`: size of the segment
    5456
    5557
    … …  
    5759
    5860This element contains the following attribute:
    59  * `index`: the processor index, or ''id''. It is unique for each processeur and must range from 0 to ''n - 1'' inside the cluster (vrai ? ou id global ?). The index corresponds to the processor id in the architecture
     61 * `index`: the processor index, or ''id''. It is unique for each processor and must range from 0 to ''n - 1'' inside the cluster (vrai ! c'est pas un id global.). The index corresponds to the processor id in the architecture.
    6062
    6163The proc element contains the following element:
    62  * 1 `irq` element
     64 * 0 to ''n'' `irq` element(s).
    6365
    6466
    6567== The irq (interrupt request) element
    6668
    67 This element contains the following attributes:
    68  * `type`: The type of interrupt request. Currently can only be `HARD` (?)
    69  * `icuid`: the identifier of ..?
    70  * `isr`: the interrupt sub-routine...what?
    71  * `channel`: the channel of the... (toujours égal à icuid ?)
     69This element describe the routing of the interruptions signals on the hardware. It contains the following attributes:
     70 * `type`: The type of interrupt request. Currently can only be `HARD`.
     71 * `icuid`: the index of the interrupt entry in the hardware icu or xicu.
     72 * `channel`: the peripheral channel from which the interruption is connected (for peripherals with only one channel, it must be set to zero).
     73 * `isr`: the interrupt sub-routine types:
     74    * `ISR_SWITCH`: Used to schedule the tasks of a processor, channel attribute must be equal to the processor id.
     75    * `ISR_TTY`: handle the irq emaning from the tty
     76    * `ISR_DMA`: handle the dma irq
     77    * `ISR_IOC`: handle the block device interruption
     78    * `ISR_TIMER`: handle user timer interruption
    7279
    7380
    … …  
    7582
    7683This element contains the following attributes:
    77  * `type`: type of the peripheral. It can be one of `TTY`, `TIM` (timer), ?
    78  * `psegname`: name of the physical segment in which the peripheral is mapped. This name must be one of the pseg elements' name. (pourquoi nom du pseg et pas nom du vseg ?)
     84 * `type`: type of the peripheral. It can be one of :
     85   * `PERIPH_TYPE_IOC` : block device peripheral
     86   * `PPERIPH_TYPE_TTY`: tty device peripheral
     87   * `PPERIPH_TYPE_TIM`: timer device peripheral
     88   * `PPERIPH_TYPE_DMA`: dma device peripheral
     89   * `PPERIPH_TYPE_FBF`: frame buffer peripheral
     90   * `PPERIPH_TYPE_NIC`: nic buffer peripheral
     91   * `PPERIPH_TYPE_IOB`: io bridge peripheral
     92 * `psegname`: name of the physical segment of the peripheral. This name must be one of the pseg elements name. (pourquoi nom du pseg et pas nom du vseg ?)
    7993 * `channels`: the number of channels in the peripheral (one channel usually corresponds to one processor; an exception is for ttys where one channel is used for the operating system)
    8094
    … …  
    90104
    91105This element contains the following attributes:
    92  * `name`: name of the virtual segment (utilisé quelque part ?)
    93  * `vbase`: base address of the virtual segment in the final binary. Depending on the virtual segment, it can be chosen arbitrarily or not (détailler)
    94  * `clusterid`: ''pourquoi est-ce que c'est nécessaire ?''
    95  * `psegname`: name of the physical segment in which this virtual segment must be mapped. This name must be one of the pseg elements' name.
     106 * `name`: name of the virtual segment (utilisé quelque part ? Non)
     107 * `vbase`: base address of the virtual segment in the final binary. Must be page size (4096) aligned.
     108 * `psegname`: name of the physical segment in which this virtual segment will be mapped. This name must be one of the pseg elements name.
     109 * `clusterid`: cluster id in which the the psegname have been defined.
    96110 * `mode`: specific properties of the segment. The value is of the form `[C_][X_][W_][U_]` e.g. `C_W_`. Each character indicates if the property is selected (letter) or not (underscore). The properties are the following:
    97111   * `C`: the segment is cached
    … …  
    99113   * `W`: the segment is writable
    100114   * `U`: the segment is accessible is user mode
    101  * `ident`: is 1 if the segment is an identity segment, 0 otherwise. An identity virtual segment is a virtual segment whose base address is the same as the one of the physical segment it is mapped on. ''Pourquoi a-t-on besoin de ça ? de toutes façons toutes les infos sont répliquées...''
     115 * `ident`: (optional) is 1 if the segment is an identity segment, 0 otherwise. An identity virtual segment is a virtual segment whose base address is the same as the one of the physical segment it is mapped on. Generally used for the mapping of vseg on peripherals.
    102116
    103117The vseg element contains the following elements:
    … …  
    108122
    109123This element contains the following attributes:
    110  * `name`: the name of the virtual object. ''utilisé ?''
    111  * `type`: type of the virtual object. It can be one of `ELF`, `PERI`, `BUFFER`, `MWMR`, `PTAB` (influence ?)
    112  * `length`: size of the virtual object in bytes. ''utilisé pour quoi ?''
    113  * `align`: logarithm in base 2 of the alignemnt required for this segment. For example, a value of 13 means that the segment must be aligned on 0x2000
    114  * `binpath`: path to the file to load in this segment, if any. This path can be relative or absolute.
     124 * `name`: the name of the virtual object. ''utilisé ?'' pour obtenir les ressources (mwmr, barrier,..) en mode utilisateur grace a l'appel system vobj_get_vbase(stdio.c).
     125 * `type`: type of the virtual object. It can be one of the following:
     126   * `ELF`: describe an elf section.
     127   * `PTAB`: reserve memory space for the page table, each vspace must have one vobj of this type.
     128   * `PERI`: for peripheral mapping.
     129   * `MWMR`: describe an mwmr channel, this vobj will be apropriatly initialised by the operating system
     130   * `LOCK`: describe a lock, this vobj will be apropriatly initialised by the operating system
     131   * `BARIERR`: describe a barrier, this vobj will be apropriatly initialised by the operating system
     132   * `BUFFER`: describe a buffer. The content of this vobj is not initialised
     133
     134 * `length`: size of the virtual object in bytes. The sum of the length of all vobj define the length of the vseg.
     135 * `align`: (optional) logarithm in base 2 of the physical alignemnt required for this segment. For example, a value of 13 means that the segment must be aligned on 0x2000. Be careful when using this attribute, since the size of the vobj will be incremented until the
     136 * `binpath`: path to the file to load in this segment, if any (ELF vobj). This path can be relative or absolute.
    115137
    116138
    … …  
    124146
    125147This element contains the following attributes:
    126  * `name`: name of the virtual space set (utilisé ?)
    127  * `startname`: ??
     148 * `name`: name of the virtual space.
     149 * `startname`: name of the data section of the application (a vspace correspond to an application). This section will contain at his top the table of task function entry.
    128150
    129151The vspace element contains the following elements:
    … …  
    135157
    136158This element contains the following attributes:
    137  * `name`: name of the task. It must be the name of the main function of the task.
     159 * `name`: name of the task.
    138160 * `clusterid`: cluster id in the targeted architecture of the processor on which to execute the task.
    139161 * `proclocid`: processor local id on which to execute the task.
    140  * `stackname`: name of the vobj on which to place the task's stack. It must the name of one of the vseg element.
    141  * `usetty`: is 1 if the task has to write its output on a tty, 0 otherwise.
    142  * `startid`: (j'ai oublié ce que c'est)
     162 * `stackname`: name of the vobj on which to place the task's stack.
     163 * `usetty`: if 1 the task a tty will be reserved to the task, 0 otherwise.
     164 * `startid`: indicate the index in the `startname` vobj for this task function entry.
    143165
    144166
    145 
    146