Changes between Version 3 and Version 4 of DsxvmMappingInfoStructure


Ignore:
Timestamp:
Aug 30, 2012, 2:29:05 PM (12 years ago)
Author:
meunier
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • DsxvmMappingInfoStructure

    v3 v4  
    1111= Document XML Structure =
    1212
    13 In order to simplify the parsing of the document the order between elements has to be respected.
     13In order to simplify the parsing of the document, the order between elements has to be respected.
    1414This document contain two main descriptions:
    1515 * 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
     16 * a description of the software mapping on the hardware
    1717
    1818== The mapping_info element ==
    1919
    20 The two descriptions are regrouped in the `mapping_info` element, which contain the following attributes:
     20The two descriptions are regrouped in the `mapping_info` element, which contains the following attributes:
    2121 * `name`: the name of the mapping described
    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
     22 * `signature`: a way to check that we are handling a mapping info structure. It must be equal to "0xdeadbeef"
     23 * `clusters`: the number of clusters in the targeted architecture
    2424 * `vpsaces`: the number of vspaces defined. This number is typically equal to the number of applications
    2525
    2626The `mapping_info` element contains the following elements:
    2727 * a `clusterset` element, describing the targeted hardware
    28  * a `globalset` element, describing the global segments, i.e. segments replicated in all virtual spaces (typically the kernel code)
     28 * a `globalset` element, describing the global segments, i.e. the segments replicated in all virtual spaces (typically the kernel code)
    2929 * a `vspaceset` element, describing the mapping for all virtual spaces
    3030
    … …  
    3939
    4040This element contains the following attribute:
    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.
     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 makes the correspondance with the cluster id in the architecture.
    4242
    4343The cluster element contains the following elements:
    … …  
    5050
    5151This element contains the following attributes:
    52  * `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.
     52 * `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. The name is local to the cluster, i.e. two different cluster can have two pseg with the same name.
    5353 * `base`: base of the physical segment.
    5454 * `type`: type of the segment. It can be one of `RAM`, `ROM`, `PERI`
    … …  
    5959
    6060This element contains the following attribute:
    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.
     61 * `index`: the processor index, or ''id''. It is unique for each processor and must range from 0 to ''n - 1'' inside the cluster. The index corresponds to the processor id in the architecture.
    6262
    6363The proc element contains the following element:
    … …  
    6767== The irq (interrupt request) element
    6868
    69 This 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`.
     69This element describes the routing of interruption signals on the hardware. It contains the following attributes:
     70 * `type`: The type of interrupt request. It can currently only be `HARD`.
    7171 * `icuid`: the index of the interrupt entry in the hardware icu or xicu.
    7272 * `channel`: the peripheral channel from which the interruption is connected (for peripherals with only one channel, it must be set to zero).
    7373 * `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
     74    * `ISR_SWITCH`: Used to schedule the tasks of a processor (triggers a context-switch); the channel attribute must be equal to the processor id.
     75    * `ISR_TTY`: handles the interruptions emaning from the tty
     76    * `ISR_DMA`: handles the dma interruptions
     77    * `ISR_IOC`: handles the block device interruptions
     78    * `ISR_TIMER`: handle user timer interruptions
    7979
    8080
    … …  
    9090   * `PPERIPH_TYPE_NIC`: nic buffer peripheral
    9191   * `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 ?)
    93  * `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)
     92 * `psegname`: name of the physical segment of the peripheral. This name must be one of the pseg elements name, and whose type is `PERI`. This is used to make the association between the physical segment declared in the architecture and the peripheral (pourquoi nom du pseg et pas nom du vseg ?)
     93 * `channels`: the number of channels in the peripheral (one channel usually corresponds to one processor)
    9494
    9595
    … …  
    104104
    105105This element contains the following attributes:
    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.
     106 * `name`: name of the virtual segment. This name is used only for clarityand has no functional use.
     107 * `vbase`: base address of the virtual segment in the final binary. It must be page size (0x1000 or 4Ko) aligned.
    108108 * `psegname`: name of the physical segment in which this virtual segment will be mapped. This name must be one of the pseg elements name.
    109109 * `clusterid`: cluster id in which the the psegname have been defined.
    … …  
    113113   * `W`: the segment is writable
    114114   * `U`: the segment is accessible is user mode
    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.
     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. This field is not necessarily required (TODO : à vérifier si c'est nécessaire et dans ce cas pourquoi)
    116116
    117117The vseg element contains the following elements:
    … …  
    124124 * `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).
    125125 * `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
     126   * `ELF`: describes an elf section. The system has to load the elf described by the binpath in this segment.
     127   * `PTAB`: memory space reservation for the page table. Each vspace must have one vobj of this type. The system will have to initialize the page tables with the information contained in this file.
     128   * `PERI`: type of vseg used for peripheral mapping. No particular action is performed by the operating system on this type of segment.
     129   * `MWMR`: describes an mwmr channel. This vobj will be appropriately initialized by the operating system.
     130   * `LOCK`: describes a lock. This vobj will be appropriately initialized by the operating system.
     131   * `BARRIER`: describes a barrier. This vobj will be appropriately initialized by the operating system.
     132   * `BUFFER`: describes a buffer. No particular action is performed by the operating system on this type of segment.
    133133
    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.
     134 * `length`: size of the virtual object in bytes. The sum of the length of all vobj defines 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. It is used only for ELF segments, and must empty for other segment types. This path can be relative or absolute.
    137137
    138138
    … …  
    147147This element contains the following attributes:
    148148 * `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.
     149 * `startname`: name of the data section of the application (a vspace corresponds to an application). This section will contain at its top the table of task function entry.
    150150
    151151The vspace element contains the following elements:
    … …  
    161161 * `proclocid`: processor local id on which to execute the task.
    162162 * `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.
     163 * `usetty`: if 1 the task a tty will be reserved for the task, 0 otherwise.
     164 * `startid`: indicates the index in the `startname` vobj for this task function entry.
    165165
    166166