FR2970577A1 - Plateforme d'execution modulaire amelioree. - Google Patents
Plateforme d'execution modulaire amelioree. Download PDFInfo
- Publication number
- FR2970577A1 FR2970577A1 FR1150325A FR1150325A FR2970577A1 FR 2970577 A1 FR2970577 A1 FR 2970577A1 FR 1150325 A FR1150325 A FR 1150325A FR 1150325 A FR1150325 A FR 1150325A FR 2970577 A1 FR2970577 A1 FR 2970577A1
- Authority
- FR
- France
- Prior art keywords
- partition
- code
- error
- service
- driver
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000005192 partition Methods 0.000 title claims abstract description 351
- 238000004891 communication Methods 0.000 title claims abstract description 61
- 238000000034 method Methods 0.000 claims abstract description 58
- 230000002093 peripheral effect Effects 0.000 claims abstract description 49
- 230000015654 memory Effects 0.000 claims description 83
- 230000006870 function Effects 0.000 claims description 36
- 238000011161 development Methods 0.000 claims description 10
- 238000000638 solvent extraction Methods 0.000 claims description 7
- LVXVIPZBNJSUKL-NJAPINKUSA-N [(6ar,9r,10as)-10a-methoxy-4,7-dimethyl-6a,8,9,10-tetrahydro-6h-indolo[4,3-fg]quinoline-9-yl]methanol Chemical compound C1=CC([C@]2(OC)[C@H](N(C)C[C@H](CO)C2)C2)=C3C2=CN(C)C3=C1 LVXVIPZBNJSUKL-NJAPINKUSA-N 0.000 description 99
- 239000000872 buffer Substances 0.000 description 24
- 230000008569 process Effects 0.000 description 21
- 238000012360 testing method Methods 0.000 description 20
- 230000001360 synchronised effect Effects 0.000 description 19
- 238000012546 transfer Methods 0.000 description 19
- 230000009471 action Effects 0.000 description 18
- 238000007726 management method Methods 0.000 description 17
- 238000013507 mapping Methods 0.000 description 17
- 230000006399 behavior Effects 0.000 description 16
- 238000005070 sampling Methods 0.000 description 13
- 230000005540 biological transmission Effects 0.000 description 12
- 230000000903 blocking effect Effects 0.000 description 12
- 239000011800 void material Substances 0.000 description 12
- 230000008859 change Effects 0.000 description 10
- 230000018109 developmental process Effects 0.000 description 10
- 238000010200 validation analysis Methods 0.000 description 10
- 241001674048 Phthiraptera Species 0.000 description 9
- 230000008520 organization Effects 0.000 description 9
- 230000000875 corresponding effect Effects 0.000 description 8
- 238000013461 design Methods 0.000 description 8
- 230000007246 mechanism Effects 0.000 description 7
- 239000008186 active pharmaceutical agent Substances 0.000 description 5
- 238000004519 manufacturing process Methods 0.000 description 5
- 230000002123 temporal effect Effects 0.000 description 5
- 241000518994 Conta Species 0.000 description 4
- 238000004458 analytical method Methods 0.000 description 4
- 230000010354 integration Effects 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 101000741965 Homo sapiens Inactive tyrosine-protein kinase PRAG1 Proteins 0.000 description 3
- 102100038659 Inactive tyrosine-protein kinase PRAG1 Human genes 0.000 description 3
- 238000004422 calculation algorithm Methods 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 230000004044 response Effects 0.000 description 3
- 238000013515 script Methods 0.000 description 3
- LMDZBCPBFSXMTL-UHFFFAOYSA-N 1-ethyl-3-(3-dimethylaminopropyl)carbodiimide Chemical compound CCN=C=NCCCN(C)C LMDZBCPBFSXMTL-UHFFFAOYSA-N 0.000 description 2
- 101100023365 Caenorhabditis elegans mif-2 gene Proteins 0.000 description 2
- 101100023369 Caenorhabditis elegans mif-3 gene Proteins 0.000 description 2
- 102100030148 Integrator complex subunit 8 Human genes 0.000 description 2
- 101710092891 Integrator complex subunit 8 Proteins 0.000 description 2
- 101100465000 Mus musculus Prag1 gene Proteins 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 230000001427 coherent effect Effects 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 230000003247 decreasing effect Effects 0.000 description 2
- 230000007717 exclusion Effects 0.000 description 2
- 150000002500 ions Chemical class 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- DFUSDJMZWQVQSF-XLGIIRLISA-N (2r)-2-methyl-2-[(4r,8r)-4,8,12-trimethyltridecyl]-3,4-dihydrochromen-6-ol Chemical compound OC1=CC=C2O[C@@](CCC[C@H](C)CCC[C@H](C)CCCC(C)C)(C)CCC2=C1 DFUSDJMZWQVQSF-XLGIIRLISA-N 0.000 description 1
- 241000238876 Acari Species 0.000 description 1
- 240000002234 Allium sativum Species 0.000 description 1
- 102100022704 Amyloid-beta precursor protein Human genes 0.000 description 1
- 101100508411 Caenorhabditis elegans ifb-1 gene Proteins 0.000 description 1
- 101000823051 Homo sapiens Amyloid-beta precursor protein Proteins 0.000 description 1
- KVTFEOAKFFQCCX-UHFFFAOYSA-N N-hexadecanoylglycine Chemical compound CCCCCCCCCCCCCCCC(=O)NCC(O)=O KVTFEOAKFFQCCX-UHFFFAOYSA-N 0.000 description 1
- 240000001155 Opuntia dillenii Species 0.000 description 1
- 235000006544 Opuntia dillenii Nutrition 0.000 description 1
- 101000767160 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) Intracellular protein transport protein USO1 Proteins 0.000 description 1
- 230000003213 activating effect Effects 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 230000002730 additional effect Effects 0.000 description 1
- DZHSAHHDTRWUTF-SIQRNXPUSA-N amyloid-beta polypeptide 42 Chemical compound C([C@@H](C(=O)N[C@@H](C)C(=O)N[C@@H](CCC(O)=O)C(=O)N[C@@H](CC(O)=O)C(=O)N[C@H](C(=O)NCC(=O)N[C@@H](CO)C(=O)N[C@@H](CC(N)=O)C(=O)N[C@@H](CCCCN)C(=O)NCC(=O)N[C@@H](C)C(=O)N[C@H](C(=O)N[C@@H]([C@@H](C)CC)C(=O)NCC(=O)N[C@@H](CC(C)C)C(=O)N[C@@H](CCSC)C(=O)N[C@@H](C(C)C)C(=O)NCC(=O)NCC(=O)N[C@@H](C(C)C)C(=O)N[C@@H](C(C)C)C(=O)N[C@@H]([C@@H](C)CC)C(=O)N[C@@H](C)C(O)=O)[C@@H](C)CC)C(C)C)NC(=O)[C@H](CC=1C=CC=CC=1)NC(=O)[C@@H](NC(=O)[C@H](CC(C)C)NC(=O)[C@H](CCCCN)NC(=O)[C@H](CCC(N)=O)NC(=O)[C@H](CC=1N=CNC=1)NC(=O)[C@H](CC=1N=CNC=1)NC(=O)[C@@H](NC(=O)[C@H](CCC(O)=O)NC(=O)[C@H](CC=1C=CC(O)=CC=1)NC(=O)CNC(=O)[C@H](CO)NC(=O)[C@H](CC(O)=O)NC(=O)[C@H](CC=1N=CNC=1)NC(=O)[C@H](CCCNC(N)=N)NC(=O)[C@H](CC=1C=CC=CC=1)NC(=O)[C@H](CCC(O)=O)NC(=O)[C@H](C)NC(=O)[C@@H](N)CC(O)=O)C(C)C)C(C)C)C1=CC=CC=C1 DZHSAHHDTRWUTF-SIQRNXPUSA-N 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000003139 buffering effect Effects 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 230000009849 deactivation Effects 0.000 description 1
- 230000000593 degrading effect Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- JEIPFZHSYJVQDO-UHFFFAOYSA-N ferric oxide Chemical compound O=[Fe]O[Fe]=O JEIPFZHSYJVQDO-UHFFFAOYSA-N 0.000 description 1
- 239000000796 flavoring agent Substances 0.000 description 1
- 235000019634 flavors Nutrition 0.000 description 1
- 235000004611 garlic Nutrition 0.000 description 1
- 208000017482 infantile neuronal ceroid lipofuscinosis Diseases 0.000 description 1
- 230000009191 jumping Effects 0.000 description 1
- 230000004807 localization Effects 0.000 description 1
- 101150039067 maf-1 gene Proteins 0.000 description 1
- 230000007257 malfunction Effects 0.000 description 1
- 230000003211 malignant effect Effects 0.000 description 1
- 230000000873 masking effect Effects 0.000 description 1
- 238000012737 microarray-based gene expression Methods 0.000 description 1
- 101150016164 msw1 gene Proteins 0.000 description 1
- 238000012243 multiplex automated genomic engineering Methods 0.000 description 1
- 238000011017 operating method Methods 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 238000009877 rendering Methods 0.000 description 1
- 230000008439 repair process Effects 0.000 description 1
- 230000011218 segmentation Effects 0.000 description 1
- 238000004088 simulation Methods 0.000 description 1
- 230000009897 systematic effect Effects 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5061—Partitioning or combining of resources
- G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
Cette plateforme comprend : une couche matérielle comprenant une carte principale et une carte d'entrée/sortie périphérique ; et, une couche logicielle comprenant un hyperviseur de partitionnement de la couche matérielle et de fourniture de services de communication entre deux partitions, au moins un code applicatif exécuté sur une partition qui lui est dédiée, et un pilote associé à la carte d'entrée/sortie périphérique. Elle comporte un code de service (180), exécuté sur une autre partition (190), ladite autre partition étant dédiée audit code de service, ledit code de service comportant ledit pilote (188) et un composant logiciel serveur (181), ledit composant logiciel serveur (181) encapsulant ledit pilote et constituant un serveur de services génériques d'accès à la carte d'entrée/sortie périphérique, et en ce que ledit code applicatif comporte un composant logiciel client (187) propre, lorsque ledit code applicatif appelle un service afin d'accéder à la carte d'entrée/sortie périphérique, à requérir l'exécution de ce service auprès du composant logiciel serveur (181), en émettant une requête adaptée en utilisant le service de communication entre partitions du code hyperviseur.
Description
Plateforme d'exécution modulaire améliorée L'invention a pour domaine celui des plateformes d'exécution modulaires embarquées, en particulier du type « Avionique modulaire intégrée » (IMA pour «Integrated Modular Avionics » en anglais), comportant : - une couche matérielle comprenant au moins un processeur, une mémoire de processeur, une horloge, un contrôleur d'entrée/sortie et une carte d'entrée/sortie périphérique ; et, - une couche logicielle comprenant un code hyperviseur propre à partitionner spatialement et temporellement la couche matérielle, le code hyperviseur étant propre à fournir des services de communication pour l'échange de message de données entre deux partitions, au moins un code applicatif exécuté sur une partition qui lui est dédiée, et un pilote associé à la carte d'entrée/sortie périphérique. Une plateforme d'exécution embarquée, doit permettre de s'interfacer avec un grand nombre d'équipements périphériques externes de type différent : calculateurs, électroniques de proximité, capteurs, actionneurs, moyens de communication... De plus, avec l'augmentation de la puissance de calcul des processeurs et des capacités mémoire, il est demandé à ces plateformes d'exécution d'intégrer de plus en plus de fonctionnalités, qui étaient autrefois réparties entre plusieurs calculateurs disjoints.
Par ailleurs, une plateforme d'exécution embarquée doit répondre à des contraintes temporelles potentiellement fortes, par exemple du type temps réel, imposées par le système dans lequel elle est mise en oeuvre. Il en découle que les plateformes d'exécution sont d'une complexité croissante. Les couches matérielle et logicielle d'une plateforme d'exécution sont de ce fait développées au cas par cas, en fonction du cahier des charges imposé par les systèmes dans lesquels la plateforme d'exécution va être mise en oeuvre. Néanmoins, pour faciliter le développement, puis l'exécution de différents codes applicatifs au sein d'un même plateforme d'exécution, il est connu d'utiliser une architecture modulaire de la couche logicielle.
Par exemple, le document US 2008/0077919 Al divulgue une architecture de la couche logicielle fondée sur un code hyperviseur (aussi parfois dénommé « micronoyau ») propre à gérer le partitionnement spatial et temporel de la couche matérielle. Dans cette architecture, chaque code applicatif est exécuté sur une partition qui lui est dédiée, chaque partition étant exécutée séquentiellement. Cette architecture permet de garantir une indépendance entre les contextes d'exécution des différents codes applicatifs. L'exécution d'un code applicatif sur une partition confine les erreurs générées par ce code applicatif sans perturber l'exécution des autres codes applicatifs. C'est en cela que l'architecture est dite modulaire. De plus, cela autorise un développement « en parallèle » et indépendant des différents codes applicatifs les uns par rapport aux autres.
Comme connu en soi, un code applicatif résulte de l'édition de liens, puis de la compilation, d'un programme d'exploitation avec un programme applicatif. Le programme d'exploitation, qui comporte une interface matérielle, permet de virtualiser la couche matérielle. Le programme d'exploitation propose au programme applicatif une interface de programmation (API pour « Application programming interface » en anglais) permettant de développer le programme applicatif en utilisant une librairie de fonctions proposées par le programme d'exploitation. Au cours de l'exécution d'une tâche (ou « process » en anglais), lorsque le programme d'application cherche à accéder à une ressource matérielle particulière, il appelle ces fonctions. Pour la virtualisation des composants matériels permanents de la couche matérielle (processeur, mémoire de processeur, etc.), le programme d'exploitation comporte un système d'exploitation (OS en anglais pour « Operating System »). En revanche, pour virtualiser un contrôleur d'entrée/sortie et pour permettre l'accès à un équipement périphérique à travers la carte d'entrée/sortie périphérique connecté au contrôleur d'entrée/sortie, le programme d'exploitation comporte un pilote (« driver » en anglais). Ce pilote offre au programme applicatif une librairie de fonctions spécifiques permettant d'accéder à l'équipement périphérique connecté au port d'entrée/sortie. Or, une modification du contrôleur d'entrée/sortie impose généralement un changement du pilote, et éventuellement l'adaptation du programme applicatif pour permettre son fonctionnement avec, par exemple, les nouvelles fonctions proposées par le nouveau pilote. Dans tous les cas, cela nécessite une nouvelle édition de lien, puis une compilation du code applicatif. Dans le domaine des plateformes d'exécution embarquées, le nouveau code binaire obtenu doit systématiquement être complètement qualifié sur la cible matérielle par rapport à des spécifications applicables. Cette dernière opération est particulièrement complexe, longue et couteuse. L'invention a donc pour but de pallier aux inconvénients précités, notamment en proposant une plateforme d'exécution modulaire améliorée permettant de paralléliser le développement des différents services offerts par la plateforme, en limitant les impacts d'une modification au sein d'un de ces services et/ou au sein de la couche matérielle.
Pour cela l'invention a pour objet une plateforme d'exécution modulaire du type précité, comportant un code de service, exécuté sur une autre partition, ladite autre partition étant associée audit code de service, ledit code de service comportant ledit pilote et un composant logiciel serveur, ledit composant logiciel serveur encapsulant ledit pilote et constituant un serveur de services génériques d'accès à la carte d'entrée/sortie périphérique, et en ce que ledit code applicatif comporte un composant logiciel client propre, lorsque ledit code applicatif appelle un service afin d'accéder à la carte d'entrée/sortie périphérique, à requérir l'exécution de ce service auprès du composant logiciel serveur, en émettant une requête adaptée en utilisant les services de communication entre partitions du code hyperviseur. Suivant des modes particuliers de réalisation, le système comporte une ou plusieurs des caractéristiques suivantes, prise(s) isolément ou suivant toutes les combinaisons techniquement possibles : - l'échange de requêtes entre les composants logiciels client et serveur s'effectue selon un protocole standardisé, - l'interface de programmation dudit pilote et du composant logiciel serveur est standardisée, - le composant logiciel serveur est générique d'un type d'entrée/sortie, - le code hyperviseur respecte le standard ARINC 653, - il est du type « Avionique modulaire intégrée », - le code de service comporte un unique composant logiciel serveur et une pluralité de pilotes. L'invention a également pour objet un composant logiciel serveur, propre à être compilé avec un pilote de manière à obtenir un code de service apte à être exécuté sur I partition de la plateforme d'exécution modulaire présentée précédemment. L'invention a également pour objet un composant logiciel client propre à être compilé avec un programme applicatif et/ou un système d'exploitation de manière à obtenir un code applicatif apte à être exécuté sur une partition de la plateforme d'exécution modulaire présentée précédemment.
L'invention a également pour objet un procédé mis en oeuvre sur la plateforme d'exécution modulaire présenté précédemment, pour l'accès, par un code applicatif exécuté sur une partition, à une carte d'entrée/sortie périphérique, via un contrôleur d'entrée/sortie, caractérisé en ce qu'il comporte les étapes consistant en : - l'appel, par le code applicatif, d'un service générique du code de service ; - l'élaboration par le composant logiciel client du code applicatif, d'une requête selon un protocole prédéterminé, à partir du service appelé ; - la communication de la requête ainsi élaboré, au code de service exécuté sur une autre partition de la plateforme, en utilisant des services de communication inter-partitions fournis par le code hyperviseur ; - l'interprétation de la requête par le composant logiciel serveur du code de service ; et, - l'exécution par le composant logiciel serveur, du service requis, avec appel aux fonctions du pilote associé à la carte d'entrée/sortie périphérique. D'autres caractéristiques et avantages de l'invention ressortiront plus clairement de la description détaillée qui va suivre, donnée à titre indicatif et nullement limitatif, et faite en se référant aux dessins annexés sur lesquels : - la figure 1 est une représentation schématique d'une plateforme d'exécution modulaire embarquée selon l'art antérieur, à un premier instant de fonctionnement ; - la figure 2 représente schématique la plateforme d'exécution de la figure 1 à un second instant de fonctionnement ; - la figure 3 représente schématiquement une plateforme d'exécution modulaire embarquée selon l'invention, à un premier instant de fonctionnement ; - la figure 4 représente schématiquement la plateforme d'exécution de la figure 3 à un second instant de fonctionnement ; et, - la figure 5 représente schématiquement la plateforme d'exécution de la figure 3 à un troisième instant de fonctionnement. Les figures 1 et 2 sont relatives à une plateforme d'exécution modulaire embarquée selon l'art antérieur. Sur la Figure 1, la plateforme d'exécution modulaire 10 comporte une couche matérielle 12 et une couche logicielle 14.
La couche matérielle 12 comporte une carte électronique 16. La carte 16 comporte un processeur 18, constituant une unité centrale de traitement (CPU pour « Central Processing Unit » en anglais), une mémoire 20, du type mémoire vive (RAM pour «Random Access Memory » en anglais) associée au processeur 18, et une horloge 22, propre à cadencer le fonctionnement du processeur.
La carte 16 comporte également un ou plusieurs contrôleur(s) d'entrée/sortie. Sur les figures, un seul contrôleur d'entrée/sortie 24 est représenté pour la clarté de la présente description. Un contrôleur d'entrée/sortie est par exemple constitué d'un code de description matériel, par exemple le VHDL (« Vérilok Hardware Description Language » en anglais) intégré, dans un composant programmable, pare exemple du type FPGA (« Field-Programmable Gate Array » en anglais), dont les bornes d'entrée sont connectées à un bus de données de la carte 16 et dont les bornes de sortie sont reliées électriquement à un connecteur. La couche matérielle 12 comporte également une carte d'entrée-sortie périphérique 26. La carte d'entrée périphérique 26 est gérée par le contrôleur d'entrée/sortie 24. La couche logicielle 14 comporte une couche logicielle bas niveau 28 et une couche logicielle d'application 30. La couche logicielle bas niveau 28 est constituée par un code hyperviseur 32 (aussi dénommé « micronoyau »). Le code hyperviseur 32 est situé juste « au dessus » du processeur 18 et il fonctionne en tant que système d'exploitation principal, ou « maître », du système informatique 10. La couche logicielle d'application 30 comporte plusieurs codes applicatifs. Sur les figures 1 et 2, deux codes applicatifs sont représentés et référencés respectivement par les chiffres 40 et 50.
Le code applicatif 40 intègre un programme d'exploitation 42 et un programme d'application 44. Le programme d'exploitation 42 constitue une interface de virtualisation de la couche matérielle 12. Il comporte un système d'exploitation 46, pour la virtualisation des composants de la couche matérielle qui n'évoluent pas au cours du développement ou de l'utilisation de la plateforme d'exploitation modulaire 10, et un ou plusieurs pilotes (« drivers » en anglais), pour la virtualisation de chacune des cartes d'entrée/sortie périphériques accessibles via les contrôleurs d'entrée/sortie de la carte 16 (ces composants de la couche matérielle pouvant évoluer et être modifiés au cours de l'utilisation et du développement de le plateforme d'exécution). Sur les figures, puisqu'une unique carte d'entrée-sortie périphérique 26 est représenté, un unique pilote 48 associé à cette carte d'entrée-sortie périphérique est également représenté. Le programme d'exploitation 42 définit une interface de programmation (API) permettant à un programme d'application d'accéder indirectement à une ressource de la couche matérielle, en invoquant une fonction définie par ladite interface.
Ainsi, le programme d'application 44 est développé en utilisant les fonctions proposées par l'interface du programme d'exploitation 42, et en particulier, les fonctions définies par le pilote 48 qui permettent de gérer la carte d'entrée-sortie périphérique 26 via le contrôleur d'entrée/sortie 24. Le programme d'application 40 résulte de l'édition de lien entre les codes 46, 48 et 44, puis de la compilation de cet ensemble de manière à obtenir un code binaire exécutable.
Une description similaire pourrait être faite pour le code d'application 50. L'hyperviseur a pour fonction de configurer un partitionnement spatial et temporel du système et de gérer l'accès séquentiel des partitions à la couche matérielle. La notion de partition sera décrite ci-dessous.
Dans une plateforme d'exécution modulaire, chacun des codes d'application est propre à être exécuté sur une partition qui lui est affectée. Sur les figures, la partition associée au code d'application 40 porte la référence 60, tandis que la partition associée au code d'application 50 porte la référence 70. Une partition correspond au domaine sur lequel le code d'application peut être exécuté. Il s'agit à la fois d'un domaine spatial, en termes de zones de la mémoire 20 adressable par le code d'application, et d'un domaine temporel, en termes d'intervalles de temps pendant lequel le code d'application est exécuté et accède aux ressources de la couche matérielle. Les différentes partitions du système sont disjointes spatialement et temporellement. C'est la fonction de I'hyperviseur 32 que de configurer, lors de I'initialisation du système, les différentes partitions, puis, lors de l'exécution, d'autoriser séquentiellement chacun des codes d'application à accéder aux ressources de la couche matérielle. Lorsque le code d'application d'une partition, par exemple le code 40 de la partition 60, a accès à la couche matérielle, tout se passe comme si le programme d'exploitation 42 était exécuté seul et directement sur la couche matérielle. Lorsque le programme d'application 44 cherche à lire une donnée dans la mémoire 20 ou à effectuer un calcul au moyen du processeur 18, le système d'exploitation accède directement à la mémoire ou au processeur.
Lorsque le programme d'application 44 cherche à utiliser la carte d'entrée-sortie périphérique 26, le pilote 48 accède directement au contrôleur d'entrée/sortie 24. Le code hyperviseur 32 implémente des services de communication inter-partitions 34 qui permettent l'échange de messages entre partitions. Plus précisément, les services 34 permettent l'échange de messages de données entre des ports de partition. Sur les figures, la partition 60 comporte un port de partition 66, tandis que la partition 70 comporte un port de partition 76. La définition d'un port de partition est standardisée, tout comme la manière d'échanger des messages de données entre deux ports de partition. Par exemple, la norme ARINC 653 est un standard de partitionnement temporel et spatial pour les plateformes d'exécutions modulaires, qui décrit la façon d'implémenter des ports de partition et les services de communication inter-partitions.
L'échange d'un message de données entre les codes applicatifs 40 et 50 est schématisé sur les figures 1 et 2. Pendant la tranche de temps T1 d'exécution du code applicatif 40 (figure 1), le code applicatif 40 utilise l'un des services 34 pour « poster » sur le port de partition 66 un message à l'intention du code applicatif 50. A la fin de la tranche de temps T1, le code hyperviseur interrompt l'exécution du code applicatif 40, bascule le contexte d'exécution pour passer de celui de la partition 60 à celui de la partition 70, et lance l'exécution du code applicatif 50. Le code 50 requiert du code hyperviseur 32 qu'il scanne l'ensemble des ports de partition du système 10 afin que soient déposés sur le port de portion 76 les messages de données à l'intention du code applicatif 50. Le code hyperviseur 32 détecte ainsi le message déposé par le code applicatif 40 sur le port de partition 66 et le dépose sur le port de partition 76 de la partition 70 sur laquelle est exécuté le code applicatif 50.
Dans ce système selon l'art antérieur, lorsque la carte d'entrée-sortie périphérique 26 est modifiée ou remplacée par une autre carte d'entrée-sortie périphérique, que ce soit une version améliorée de cette carte ou une autre carte du même type, il est nécessaire de modifier en conséquence les pilotes 48 et 58. Il est également potentiellement nécessaire de réécrire les programmes d'application 44 et 54 pour qu'ils utilisent les nouvelles fonctions définies par le pilote. L'ensemble du code applicatif doit, dans tous les cas, subir une nouvelle édition de liens, être compilé et le binaire ainsi obtenu doit finalement être requalifié. Il est également à noter que, le code hyperviseur ne gérant pas les contrôleurs d'entrée/sortie, il est possible qu'il y ait un conflit quant à l'utilisation du contrôleur d'entrée/sortie 24 par deux codes applicatifs souhaitant communiquer avec la carte d'entrée-sortie périphérique qui y est connecté. Par exemple, le code applicatif 40 utilise le contrôleur d'entrées-sortie 24 pour envoyer une quantité de données importantes à la carte d'entrée-sortie périphérique 26. L'ensemble constitué par le contrôleur d'entrée-sortie 24 et la carte d'entrée-sortie périphérique 26 prend alors un temps conséquent pour échanger ces données, temps pendant lequel le code hyperviseur bascule le contexte et lance l'exécution du second code applicatif 50. Le second code applicatif 50 alors exécuté cherche à envoyer des données à la même carte d'entrée-sortie périphérique 26 en utilisant ce même contrôleur d'entrées-sorties 24. L'ensemble constitué par le contrôleur d'entrée-sortie 24 et la carte d'entrée-sortie périphérique 26 étant occupé à traiter la requête précédente, il ne peut pas prendre en compte la requête du code applicatif 50. Dans le cas le plus défavorable, le contrôleur d'entrée-sortie 24 n'est à nouveau disponible que lorsque le premier code applicatif 40 est à nouveau exécuté. Ainsi, la bande passante vers la carte d'entrée-sortie périphérique 26 est totalement utilisée par le premier code applicatif 40 au détriment du code 50. Ceci n'est généralement pas compatible avec les exigences de qualité de service attendues par chacun des codes applicatifs hébergés par la plateforme d'exécution modulaires. Jusqu'à présent, pour éviter ce genre de conflit, les concepteurs n'hésitaient pas à multiplier les contrôleurs d'entrée/sortie et les cartes d'entrée-sortie périphériques de manière à faire correspondre à chaque code applicatif, un contrôleur d'entrée-sortie et une carte d'entrée-sortie périphérique. Quand cette solution n'était pas possible, des contrôleurs d'entrée-sortie spécialisés étaient développés pour garantir une qualité de service quel que soit le profil d'utilisation de la carte d'entrée-sortie périphérique, par les différents codes applicatifs, Mais cette solution conduit à une forte complexité de la couche matérielle, associée à des difficultés de mise au point et à un accroissement important des coûts de développement. En se référant maintenant aux figures 3 à 5, la plateforme d'exécution modulaire selon l'invention va être présentée. Sur les figures 3 à 5, un élément identique à un élément des figures 1 et 2 porte le même chiffre de référence que cet élément ; un élément similaire à un élément des figures 3 à 4 porte le même chiffre de référence que cet élément, mais augmenté d'une centaine. En se référant à la figure 3, la plateforme d'exécution modulaire 110 comporte une couche matérielle 12 et une couche applicative 114. La couche matérielle 12 est en tout point similaire à celle décrite précédemment en relation avec l'art antérieur. Cette couche matérielle 12 comporte une carte 16 munie d'un processeur 18, d'une mémoire de processeur 20, d'une horloge 22 et d'un contrôleur d'entrée/sortie 24. Une carte d'entrée-sortie périphérique 26 est gérée par le contrôleur d'entrée/sortie 24. La couche applicative 114 comporte une couche d'hypervision 128 comportant un code hyperviseur 132 apte à configurer et à gérer le partitionnement spatial et temporel des ressources matérielles du système. Le code hyperviseur 132 offre des services de communication inter-partitions 134 répondant par exemple à la norme ARINC 653.
La couche applicative 114 comporte également un premier code applicatif 140, un second code applicatif 150 et un code de service 180. Le code applicatif 140 est associé à une première partition 160, le second code applicatif 150 est associé à une seconde partition 170, et le code de service 180 est associé à une partition supplémentaire 190. Ces partitions sont disjointes entre elles.
Le code de service 180 comporte un pilote 188 spécifique de la carte d'entrée-sortie périphérique 26 géré par le contrôleur d'entrée/sortie 24.
Le code de service 180 comporte également un composant logiciel serveur 181 fournissant des services génériques et utilisant les fonctions offertes par les pilotes, ces services étant accessibles, par des codes applicatifs considérés comme des clients, selon un mécanisme client / serveur qui utilise les services de communication inter-partitions du code hyperviseur. Le composant logiciel serveur 181 encapsule le pilote 188. Une interface de programmation (API) est définie entre le pilote et le composant logiciel serveur pour permettre l'appel par ce dernier des fonctions proposées par le pilote. Cette interface est représentée schématiquement sur les figures et porte la référence 183. Les fonctions proposées par le pilote 188 doivent répondre à des spécifications prédéterminées. De préférence, ces spécifications sont celles détaillées dans l'annexe A de la présente demande de brevet. Ainsi, toute personne développant un nouveau pilote et souhaitant que celui-ci viennent s'interfacer avec le composant logiciel serveur 181, proposera des fonctions standardisées aptes à être appelées par le composant logiciel serveur 181. Il est à noter que les spécifications de l'interface entre le pilote et le composant logiciel serveur sont à la fois statique (« nommage » des fonctions, format des paramètres des fonctions, etc.), mais également dynamiques (chronologie des échanges entre le composant logiciel et le pilote, etc.) Le composant logiciel serveur 181 est propre à proposer des services (méta- fonctions) aux codes applicatifs exécutés sur d'autres partitions. L'architecture utilisée est une architecture client / serveur s'appuyant sur les services de communication inter-partition 134. Les codes applicatifs sont alors considérés comme des clients du serveur de services que constitue le composant logiciel serveur 181. Ce serveur de services est représenté schématiquement sur les figures et porte la référence 185. Le serveur 185 est propre à interpréter les requêtes qu'il reçoit des codes applicatifs. Une requête comporte l'appel à un service ainsi que les paramètres et/ou les données que ce service doit traiter. Le serveur de service est également propre à émettre une réponse à une requête, à destination d'un code applicatif client ayant émis la requête initiale. La communication entre un client et le serveur s'effectue selon un protocole de communication prédéterminé utilisant les services de communication inter-partitions 134. Un protocole de communication possible est défini dans l'annexe B de la présente demande de brevet. Le composant logiciel serveur 181 est propre à exécuter le service requis en tenant compte des paramètres et/ou des données reçues. Il appelle pour ce faire une ou plusieurs fonctions du pilote 188.
Le composant 181 est également propre à gérer le partage des accès à la carte d'entrée-sortie périphérique 26, entre les codes applicatifs 140 et 150. Pour y parvenir, le composant 181 alloue statiquement des tranches de temps pendant lesquelles les ports de chaque partition sont autorisés à accéder à la carte d'entrée-sortie périphérique 26.
Cette allocation permet de garantir une qualité de service à chacun des applicatifs. Grâce à ce mécanisme, toute partition qui tenterait d'utiliser plus de bande passante que ce qui était initialement prévu viendrait à perdre des messages de données, sans toutefois dégrader la bande passante de l'autre partition, qui est ainsi garantie. Du côté d'un code applicatif client, par exemple le code 140, celui-ci comporte un programme d'exploitation 142 et un programme applicatif 144. Le programme d'exploitation 142 comporte un système d'exploitation 46 identique à celui de l'art antérieur, ainsi qu'un composant logiciel client 187. Le code applicatif 140 résulte de l'édition de liens puis de la compilation des codes 46, 187 et 144.
Le programme applicatif 144 est développé en tenant compte de la librairie du composant logiciel client 187. Cette librairie est en cohérence des services que propose le composant logiciel serveur 181. Le composant logiciel client 187 est propre à détecter l'appel, par le programme d'application, d'un service. Il est propre à élaborer à partir de cet appel et des paramètres et/ou des données associés, une requête conformément au protocole de communication prédéterminé. Il est finalement propre à poster, sur un port de la partition sur laquelle le code applicatif 140 est exécuté, et à destination du code de service 180, un message de données dont la charge (« payload » en anglais) correspond à la requête ainsi élaborée. De manière similaire, le code applicatif 150 intègre un système d'exploitation 56, similaire à celui de l'art antérieur, un composant logiciel client 187 (identique ou équivalent à celui intégré au code applicatif 140) et un programme d'application 154. Il est à noter que le code 154 a été écrit de manière à utiliser la librairie du composant logiciel client 187. L'échange de messages de données entre, par exemple, un code applicatif et le code de service 180 s'effectue via l'un des services de communication inter-partitions 134 fournis par le code hyperviseur 132. Pour ce faire, les différentes partitions du système sont munies de ports de partition standardisés, par exemple conformément à la norme ARINC 653. Ainsi, la partition 160 comporte des ports 66 et 168, la partition 170, des ports 76 et 178, et la partition 190, un port 198.
Le procédé de fonctionnement de la plateforme d'exécution modulaire selon l'invention venant d'être décrit va maintenant être présenté en relation avec les figures 3 à 5. A la figure 3, le code applicatif 140 est exécuté sur la partition associée 160 (celle- ci est représentée en trait continu sur la figure). Le système d'exploitation 46 peut alors accéder directement aux ressources matérielles de la carte 16 (processeur, mémoire, etc.) Pour échanger une donnée avec un autre code applicatif exécuté sur une autre partition, le code 140 poste sur le port de partition 66, un message de données, de la manière précédemment décrite en relation avec l'art antérieur. Lorsque le code applicatif 140 cherche à accéder à la carte d'entrée-sortie périphérique 26 via le contrôleur d'entrée/sortie 24, il a recours à un service du code de service 180. Le programme applicatif 144 appelle un service en passant des arguments qui sont des paramètres d'exécution du service et/ou des données sur lesquels doit porter le service ainsi paramétré. Lorsque le programme applicatif 144 appelle un service, le composant logiciel client 187 élabore une requête conformément au protocole de communication prédéterminé. Il encapsule ensuite la requête ainsi élaborée dans un message de données qu'il poste sur le port 168, à destination du code de service 180. Lors d'une séquence ultérieure, représentée à la figure 4, I'hyperviseur 132 autorise l'exécution du code de service 180, sur la partition 190. Sur demande du code de service 180, le code hyperviseur scrute alors l'ensemble des ports de partition pour déterminer les messages de données qui sont adressées au code de service 180. Ces messages de données sont alors transmis au code de service 180, via le port 198 de la partition 190. La requête du code applicatif 140 est alors extraite du message de données. Le composant logiciel serveur 181 interprète le contenu de la requête puis exécute le service paramétré conformément aux paramètres contenus dans la requête sur les données également contenues dans la requête. Pour cette exécution, le composant logiciel serveur 181 appelle à des fonctions du pilote 188. Dans le cas de l'appel d'une fonction en émission, le pilote 188 accède au contrôleur d'entrée/sortie 24 pour émettre les données vers la carte d'entrée-sortie périphérique 26.
Une description similaire pourrait être faite de la transmission d'une donnée depuis la carte d'entrée/sortie périphérique et le contrôleur d'entrée/sortie vers un code applicatif client (cas d'une fonction en réception). Enfin, comme cela est représenté à la figure 5, lors d'une séquence ultérieure à la séquence de la Figure 2, le code hyperviseur 134 autorise l'exécution du code applicatif 150 de la partition 170. Le code applicatif 150 accède alors directement aux ressources matérielles de la carte, requiert de l'hyperviseur que lui soit transmis l'ensemble des messages postés sur les ports des autres partitions. Un composant logiciel serveur est défini de façon générique, de manière à être compatible avec différents types d'entrée-sortie, différents types de protocoles (maître-esclave, multi-maîtres), et différents types d'échanges (synchrones, asynchrones). Un type d'entrée-sortie regroupe les différents solutions électroniques d'entré/sortie permettant l'accès à un bus de communication, un capteur, un actionneur, un registre mémoire, une adresse mémoire particulière correspondant à une entrée-sortie, ou tout autre composant. Le composant logiciel générique implémente ainsi un ensemble de services génériques compatibles des traitements que les différentes entrées-sorties d'un même type sont susceptibles de proposer. L'architecture logicielle de la plateforme d'exécution modulaire venant d'être décrite permet d'assurer l'indépendance d'un code applicatif client vis-à-vis d'un ensemble particulier composé du code de service, du pilote, du contrôleur d'entrée-sortie et de la carte d'entrée-sortie périphérique. En conséquence, le programme applicatif client peut être développé, puis lié et compilé, et enfin qualifié, de façon définitive, sans avoir l'ensemble de ces étapes à réitérer à chaque modification de l'un des éléments de cet ensemble.
Par ailleurs, cette architecture logicielle permet de limiter au maximum les dépendances entre le code de service et l'ensemble particulier comportant un pilote, un contrôleur d'entrée-sortie et une carte d'entrée-sortie périphérique. En conséquence, le code source du code de service n'est pas systématiquement impacté à chaque modification du contrôleur d'entrée-sortie et/ou de la carte d'entrée-sortie périphérique et/ou de son pilote. En variante, la carte électronique comporte N contrôleurs d'entrée/sortie. Chaque contrôleur d'entrée/sortie est connecté à un type de carte d'entrée-sortie périphérique particulière ou plus généralement à un type d'entrée-sortie. Un code de service générique, lui-même associé à une partition, est alors prévu pour chacun de ces contrôleurs d'entrée sortie.
De manière alternative, pour limiter le nombre de partitions du système informatique, plusieurs contrôleurs d'entrée/sortie peuvent être accédés au travers d'un unique code de service exécuté sur une seule partition associée. Ce code de service résulte de la compilation d'un composant logiciel serveur avec les pilotes de ces différents contrôleurs d'entrée-sortie. En variante, le code de service résulte de la compilation du composant logiciel serveur, d'au moins un pilote et d'un système d'exploitation, de manière à permettre au code de service ainsi obtenu d'accéder au processeur et à la mémoire de la carte dans le but, par exemple, d'effectuer des tâches algorithmiques plus avancées.
En variante, un code applicatif ne comporte pas de système d'exploitation. L'homme du métier constatera que l'utilisation des services de communication inter-partitions de l'hyperviseur pour l'échange de données entre code applicatif et code de service, associée à une implémentation du code de service garantissant des tranches de temps à chacun des ports permet de garantir la bande passante entre les différentes applications utilisatrices d'un même périphérique. En effet, mais sans entrer dans le détail du fonctionnement des ports de partition selon la norme ARINC 653, cet avantage réside : En ce qu'un code applicatif ne peut poster qu'un nombre prédéfini de messages de données sur un port de partition et doit attendre qu'une place se libère dans le port avant de pouvoir y écrire un nouveau message de données; En ce qu'un code hyperviseur garantit, par conception, à toutes les partitions la satisfaction du service de communication inter-partitions ; et, En ce que le moyen de gestion du partage du temps implémenté dans le code de service garantit par ailleurs, une bande passante à chacun des ports de chacune des partitions utilisant un même périphérique. En conséquence, si un code applicatif cherche à communiquer un flot de données trop important, les erreurs restent confinées à l'intérieur de la partition sur laquelle est exécutée ce code applicatif. Grâce à ce mécanisme, les dysfonctionnements de ce code applicatif ne viennent pas monopoliser le contrôleur d'entrée/sortie et bloquer ainsi momentanément les émissions vers la carte d'entrée-sortie périphérique, la rendant momentanément inutilisable par d'autres codes applicatifs exécutés sur la plateforme.
Annexe A Spécifications de l'interface pilote SOMMAIRE 1. OBJET 15 2. REFERENCES 15 3. PRESENTATION GENERALE 15 4. INTERFACES 10 17 4.1. PRESENTATION DE L'API 10 ET LOGIQUE D'APPEL 17 4.1.1. IDENTIFICATION DU PERIPHERIQUE 18 4.1.2. PARAMETRAGE DU PERIPHERIQUE 18 4.1.3. CODE DE RETOUR 19 4.1.4. UTILISATION SYNCHRONE/ASYNCHRONE 19 4.1.5. EXCLUSION MUTUELLE 20 4.2. DESCRIPTION DE L'API 10 GENERIQUE 21 4.2.1. IO INITIALIZE 21 4.2.2.10_OPEN 22 4.2.3.10_W RITE 23 4.2.4.10_READ 25 4.2.5.10_C L O S E 27 4.2.6.10_SHUTDOWN 28 4.2.7.10 CONTROL 29 5. COMPATIBILITE AVEC L'IO SERVER 30 5.1. NOMAGE DES API 30 5.2. PARAMETRES DE FONCTIONNEMENTS 30 5.3.TEMPS D'EXECUTION DES API 30 5.4. LES API 30 5.4.1.10_OPEN 31 5.4.2.10 CONTROL 31 5.5. DYNAMIQUE 32 5.5.1. ZONE DE DONNEES PARTAGES 32 5.5.2. MODE WAIT 33 5.5.3. MODE NO WAIT 35 6. ANNEXES 41 6.1.ANNEXE 1 - LES MODES DE TRANSMISSIONS 41 6.2.ANNEXE 2 - CODE D'ERREUR DRIVER 41 6.3.ANNEXE 3 - LISTE DES CODE D'INITIALISATION D'UN DRIVER 41 6.4.ANNEXE 4 - LISE DES IOCONTROL NECESSAIRE A L'10 SERVER 41 OBJET Ce document a pour objet de spécifier les interfaces entre le logiciel de vol et les drivers bas niveaux associés aux périphériques 10. ~a EEEREI CE .......................................................................... .......................................................................... .......................................................................... ................................ .......................................................................... .......................................................................... .......................................................................... ............................... .......................................................................... .......................................................................... .......................................................................... ............................... .......................................................................... .......................................................................... .......................................................................... .............................. RI SRB IO Server 1.3 Erreur ! Nom de propriété de document inconnu. R2 Table 1 - Documents de références a P E E TATI E ERALE On se place ici dans le contexte d'un modèle logiciel structuré en couches. Ce modèle comprend les couches suivantes :
1. Hardware
2. Board Support Package
3. Middleware/ OS
4. Couche applicative
La présente spécification traite de l'interface entre la couche 2-BSP et la couche 3-Middleware concernant les périphériques d'entrée/sortie. 15 Pa Ifni onl Partition Partition3 Domaine d'application de la SSI IO Manager eDriver\ (Driver\ "Driver\ (Driver\ "Driver\ "'Driver\ HW : 10, IT, Memories, Debug WP r Boat } k 4: Applioatifs 3: Middleware 2: I3P 1: Hardware Fig. Modèle logiciel et domaine d'application de la présente SSI Cette interface est décrite sous la forme d'une API applicable aux drivers des périphériques d'entrée/sortie. La définition de cette API découle des deux objectifs suivants :
Généricité : L'API doit permettre l'utilisation de la même couche « Middleware » sous différents ensembles matériel/BSP, y compris avec différents types de périphériques 10. Il doit également permettre l'utilisation du même ensemble matériel/BSP avec différents Middlewares/applicatifs. Ces contraintes imposent les caractéristiques suivantes à l'API :
o L'API doit assurer un ensemble de fonctionnalités commun pour tous les drivers 10. Ces fonctionnalités doivent permettre d'écrire/lire des trames de données sur le périphérique en faisant abstraction de la nature de celui-ci.
o L'API doit permettre d'identifier les liens 10 d'une façon symbolique dans les appels aux fonctions. La sélection du périphérique par linkage direct de la fonction du driver avec le Middleware ou l'Applicatif est à proscrire.
o La prise en compte des caractéristiques spécifiques des périphériques 10 de différente nature ne doit pas modifier la logique d'appel des fonctionnalités communes. P.ex. un middleware compilé en faisant abstraction de ces spécificités doit pouvoir être linké avec un driver qui les prend en compte (le nom de la fonction et le nombre/nature des paramètres doit rester inchangé).
o L'API ne doit pas faire référence à des types de données et/ou méthodes d'un OS particulier.
o L'API ne doit pas faire référence à des implémentations HW particulières.
o L'API doit supporter des implémentations de driver synchrones et asynchrones
Complétude : L'API doit offrir les moyens nécessaires au paramétrage/observabilité de toutes les fonctions offertes par le périphérique matériel, pour tous les types de périphérique couverts par l'API.
Évolutivité : L'API doit permettre d'intégrer des nouveaux services (génériques et/ou spécifiques) ou des nouveaux périphériques dans des versions successives des drivers tout en restant « top-down » compatible. Ceci se traduit par la prise des marges convenables dans la définition des structures d'appel des fonctions constituant l'API
La structure de l'API est conçue pour gérer les services offerts par les drivers à deux niveaux : Un premier niveau obligatoire des services génériques et un deuxième niveau facultatif de services spécifiques associés au périphérique.
Le niveau de services générique doit être assuré par toutes les implémentations des drivers quelle qu'elle soit la nature du périphérique. Ce niveau de services générique doit permettre au moins de :
- Initialiser le périphérique au niveau matériel Définir le comportement temps-réel du driver dans le cas d'une implémentation synchrone Envoyer une trame de données sur le lien 10 (à partir d'une adresse de buffer et un nombre d'octets) Recevoir une trame de données sur le lien 10 (à partir d'une adresse de buffer et un nombre d'octets) Désactiver proprement le périphérique au niveau matériel
Ces services partagent la même structure d'appel pour tous les drivers. La définition exacte des services génériques est reprise par la suite du document.
Le niveau de services spécifique doit permettre accéder à des particularités de certains périphériques 10 (p.ex. calcul intégré de CRC, sélection de la vitesse du lien, modes d'adressage particuliers, niveaux de Qualité de service, etc.)
La décision de rendre un service générique ou spécifique dépend de plusieurs critères, dont par exemple la communalité du service parmi les différents périphériques, son utilité, l'overhead associé pour les périphériques qui n'en disposent pas, etc. A noter qu'il est prévu au moins développer des drivers pour des périphériques suivants :
Ethernet ? (AC) UART 12C OSLink PacketW i re SpaceWire
L'API est décrite sous la forme d'une série de fonctions en langage C, suite à la prépondérance de ce langage dans les applications attendues. 40 INTERFACES IO L'API IO est défini sous une logique objet. Pour chaque driver, il définit une série d'attributs (paramètres) et une série de méthodes (fonctions) associés aux différentes fonctionnalités offertes par le driver.
Dans ce chapitre, on décrit une structure générique de drivers. Les spécificités des différents périphériques sont gérées via les provisions en paramétrage prévues à cet effet.
Dans le cas où certaines méthodes/fonctionnalités génériques n'aient pas d'objet sur un périphérique ou une implémentation spécifique du driver, on adoptera la politique suivante :
Pour les drivers dont certaines de ces méthodes génériques n'ont pas d'objet, elles seront implémentées au niveau API, même si elles ne représentent aucune action. L'utilisation de ces fonctions par les couches applicatives ne doit pas entraîner des perturbations sur le fonctionnement du périphérique et leur code de retour sera toujours « successful ».
Pour les drivers n'implémentant pas certaines fonctionnalités génériques, l'activation de ces fonctionnalités sur utilisation des paramètres génériques prévus à tel effet doit générer un retour en erreur de la méthode de type « param_error ».
Les méthodes définies par l'API sont :
io_initialize : Méthode se chargeant d'activer le périphérique au niveau matériel et de réaliser les initialisations nécessaires au niveau logiciel pour l'utilisation du driver.
io_open : Méthode se chargeant de démarrer une session de communication à travers du périphérique. Elle se charge de paramétrer celui-ci, de sorte à ce que les échanges réalisés avec les méthodes « io_write » et « io_read » ne voient qu'un lien du type « tuyau de données ».
io_write : Méthode se chargeant d'envoyer une trame de données (une série d'octets) à travers du périphérique spécifié.
io_read : Méthode se chargeant de recevoir une trame de données (une série d'octets) à travers du périphérique spécifié. io_close : Méthode se chargeant d'effectuer les opérations nécessaires à finir la session de communication démarrée par « io_open ». Le périphérique et le driver doivent rester dans un état permettant le démarrage d'une nouvelle session de communication
io shutdown : Méthode se chargeant de désactiver le périphérique au niveau matériel.
io_control : Méthode permettant de réaliser une série d'actions de paramétrage/gestion du driver. Le nombre et type de ces actions vont dépendre du type de périphérique et de l'implémentation du driver. Cette méthode doit permettre également d'accéder aux paramètres/registres de commandabilité/observabilité prévus à tel effet au niveau HW et SW.
La définition de cet API doit également réponde aux problématiques suivantes : Identification du périphérique
Paramétrage du périphérique
Code de retour
Utilisation Synchrone vs utilisation Asynchrone
Les paragraphes suivants présentent la réponse de l'API à chacune de ces problématiques, L'identification du périphérique est assurée à l'aide des deux paramètres :
- dev_major (unsigned32) : Correspond à l'identificateur numérique du type de périphérique (p.ex 12C, UART, OSlink, etc). La table de correspondance entre la valeur numérique et le type de driver est fournie en annexe de la présente SSIS. A noter que la valeur de cet identificateur permet aux méthodes de connaître le type des structures de paramétrage et les actions de « io_control » spécifiques à chaque type de driver.
- dev_minor (unsigned 32) : Correspond à l'identificateur numérique du périphérique dans le HW (numérotation à partir de « 0 »). La correspondance entre la valeur numérique et le périphérique matériel est fournie par le BSP. PARAtIEr RAGE DU PERPHERQUE Pour chaque méthode de l'API, on distingue deux ensembles de paramètres : un ensemble de paramètres générique et un ensemble de paramètres spécifique. L'ensemble de paramètres génériques permet de contrôler les fonctionnalités génériques de la méthode. Le nombre et type de ces paramètres est défini dans l'API pour chaque méthode. Quelques exemples : Adresse du buffer de réception /émission, taille des données échangées, mode temps-réel (synchrone/asynchrone), etc.
L'ensemble de paramètres spécifiques permet de contrôler les fonctionnalités associées à un type de périphérique donné. L'API générique ne définit pas la nature ou le nombre des paramètres spécifiques, cependant il exige que pour un type de périphérique ces paramètres soient définis et partagés par toutes les implémentations du driver concerné.
Ces paramètres pourront être modifies par via plusieurs mécanismes : Par passage direct de paramètres lors de l'appel aux méthodes de communication pour certains d'entre eux. (p.ex. adresse buffer, taille de données)
Via l'utilisation des méthodes de gestion du périphérique « io_control » ou « io_open » pour les paramètres qui ne sont pas passés en appel sur les méthodes
Afin de répondre aux spécificités des différents périphériques on garde un paramètre de type pointeur au vide (« void *spec_param ») sur chaque méthode. Il est prévu pour passer une structure de paramètres définie en fonction du type de périphérique. Il permet ainsi de prendre en compte les éventuels paramètres à passer aux méthodes pour un driver spécifique. Il pourra ne pas être utilisé, auquel cas il prendra la valeur « NULL ». 413, CODE DE RETOUR Toutes les fonctions de l'API ont un code de retour de type « unsigned 32 ». L'API doit permettre de remonter autan les codes d'erreur sur les fonctionnalités génériques que sur les fonctionnalités spécifiques. Pour cela, il impose la politique suivante :
La valeur retour « 0 » est réservée au code de retour « SUCCESSFUL » (pas d'erreur). Tout le reste des valeurs sont réservées à des cas d'erreur.
â ` °" :S C\PON SYNCHRONE. ASYNCHRONE. L'API doit permettre une utilisation de type synchrone ou asynchrone du périphérique. Ces deux paradigmes d'utilisation présentent beaucoup de différences : - Il n'y a pas d'abstraction du lien de communication fournie aux couches applicatives - Les appels aux primitives de communication correspondent à l'envoi/réception immédiat du message - Les appels de communication peuvent être bloquants - Le driver fournit aux couches applicatives une abstraction du lien du type « tuyau de données»
- Les appels aux primitives de communication correspondent à la bufferisation du message. L'envoi/réception s'effectue avec une certaine latence
- Les appels de communication ne peuvent pas être bloquants Cette SSIS n'impose pas le choix d'un de ces deux paradigmes à une implémentation particulière des drivers. Cependant, le driver devra être cohérent vis-à-vis des paramètres acceptés au niveau de ses méthodes, en particulier au niveau de la gestion de modes d'attente prévue dans les paramètres génériques. P.ex. l'appel à une méthode « io_read » en mode « WAIT » sous un paradigme asynchrone sortira en erreur, avec une erreur du type « PARAM_ERROR ».
Dans le même esprit, pour les drivers permettant uniquement une communication de type asynchrone, la gestion de l'occupation du lien de communication sera gérée entièrement par le driver afin de maintenir l'abstraction « tuyau de données ». P.ex sur les liens de nature « halfduplex » le driver devra gérer les conflits potentiels entre les opérations de lecture et les opérations d'écriture.
EXCLUMN MUTUELLE L'API ne prévoit des mécanismes de gestion de l'exclusion mutuelle sur l'utilisation concurrente de l'API par plusieurs tâches applicatives. Cette gestion de l'usage partagé du périphérique revient à la couche « middleware » située au-dessus de l'API.
Cette stratégie est nécessaire pour garder la généricité vis-à-vis de l'OS et des stratégies d'ordonnancement.
DESCRWMN DE L'AM GENERIQUE On reprend ici la description des méthodes de l'API IO et des paramètres génériques associées. jNFnAUSE Objet
Méthode se chargeant d'activer le périphérique au niveau matériel et de réaliser les initialisations nécessaires au niveau logiciel pour l'utilisation du driver.
Prototype :
uint32 io initialize(uint32 dev ma]or, uint32 dev minor, void *spec param)
Paramètres : Codes de retour : SUCCESSFUL Initialisation correctement effectuée PARAM ERROR Erreur dans le passage de paramètres HW INIT ERROR Problème matériel lors de l'initialisation du périphérique SW INIT ERROR Problème lors de l'initialisation du driver au niveau logiciel OTHER Autre type de problème Identification du type de périphérique (cf §4.1.1) Identification du périphérique (cf §4.1.1) Pointeur vers une structure de paramètres spécifiques associés à « io initialize » pour ce type de périphérique.
En cas d'inexistence de paramètres il prendra la valeur « NULL » dev major uint32 [0,21'32-1] dev minor uint32 [0,21'32-1] Spec param voici* NA 22 4'2,2. ~0._OPEN Ob'et
Méthode se chargeant d'effectuer les opérations nécessaires pour démarrer une session de communication. uint32 io_open(uint32 denmajor, uint32 denminor, void *spec_param) Paramètres : Codes de retour : Identification du type de périphérique (cf 8411) Identification du périphérique (cf §411) Pointeur vers une structure de paramètres spécifiques 8SS0CiéS à = i0_0p8n » pour ce type de périphérique.
En cas d'inexistence de paramètres il prendra la valeur =NULL" dev major uint32 0,21'32'1l dev in0r uint32 0,21'32'1l v0id° SUCCESSFUL Ouverture correctement effectuée Erreur dans le passage de paramètres Problème matériel lors de l'ouverture de la session de communication PROTOCOL OPEN ERROR Problème d'ouverture d8!8session d8communication 8univeau protocole (échanges sur le lien de communication) OTHER Autre type de problème '23, 0._VVRTE Objet
Méthode se chargeant d'envoyer une trame de données (une série d'octets) à travers du périphérique spécifié.
Prototype :
uint32 io write(uint32 dev major, uint32 dev minor, uint8 *message, uint32 size, T WRITE GENPARAM *gen param, void *spec param)
Paramètres : dev major uint32 [0,21'32-1] dev minor uint32 [0,21'32-1] message uint8* NA size uint32 [0,21'32-1] NbBytesSent uint32* [0,21'32-1] gen_param T WRITE GENPARAM* [0,21'32-1] (cf. ci-dessous) spec_param void* NA Identification du type de périphérique (cf §4.1.1) Identification du périphérique (cf §4.1.1) Pointeur vers l'adresse mémoire où se trouve la série d'octets constituant le message (buffer d'émission) Taille du message en octets Pointeur pointant vers une zone où il est possible de stocker la taille réellement écrite. Pointeur vers une structure contenant des paramètres génériques pour « io write » Pointeur vers une structure de paramètres spécifiques associés à « io write » pour ce type de périphérique.
En cas d'inexistence de paramètres il prendra la valeur « NULL » uint32 wait mode Définition du caractère bloquant ou non bloquant de l'appel à « io write » NO WAIT L'appel à « io write » n'effectue pas d'attentes bloquantes. 23 WAIT L'appel à « io_write » effectue une attente bloquante jusqu'à la fin de la transmission du message ou expiration d'un timeout. adresse; uint32 [0,2"32-1 ] adresse du destinataire du message. sEngineeringData BswSAckEData NA zone de stockate des engineering data au format pmu protocol. Codes de retour : Contraintes particulières : - Le message envoyé est fourni comme une série d'octets. L'octet avec l'adresse la plus faible est envoyé en premier. - Au cas où l'architecture matérielle ne permet pas l'adressage au niveau octet, l'octet envoyé en premier sera l'octet de poids le plus faible du mot mémoire constituant l'unité d'adressage d'adresse la plus faible. - Sur certaines implémentations des contraintes particulières supplémentaires pourront s'appliquer sur l'adresse du message (p.ex. qu'elle soit multiple de 4). Dans ce cas, elles seront clairement spécifiées dans le manuel utilisateur des drivers et elles généreront une erreur « PARAM_ERROR » si elles ne sont pas respectées. SUCCESSFUL Ecriture correctement effectuée PARAM_ERROR Erreur dans le passage de paramètres HW_ERROR Problème matériel lors de l'envoi du message sur le lien MEMORY_ERROR Erreur lors de la gestion du buffer contenant le message (yc problèmes du DMA) PROTOCOL_ERROR Problème lors de l'envoi du message sur le lien au niveau protocole TIMEOUT ONGOING Sortie en time-out de l'attente bloquante en cas d'utilisation du mode « WAIT » Écriture en mode NO WAIT en cours OTHER Autre type de problème R` A` Objet
Méthode se chargeant de recevoir une trame de données (une série d'octets) depuis le périphérique spécifié.
Prototvpe :
uint32 io_read(uint32 dev_major, uint32 dev_minor, uint8 *message, uint32 size, T_READ_GENPARAM *gen_param, void *spec_param)
Paramètres : dev major uint32 [0,2"32-1] dev_minor uint32 [0,2"32-1] message uint8* NA size uint32 [0,2"32-1] NbBytesReceived uint32* [0,2"32-1] gen_param T READ GENPARAM* [0,2"32-1] (cf. ci-dessous) spec_param void* NA Identification du type de périphérique (cf §4.1.1) Identification du périphérique (cf §4.1.1) Pointeur vers l'adresse mémoire où doit être placé le message (buffer de réception) Taille attendue du message en octets Pointeur pointant vers une zone où il est possible de stocker la taille réellement reçue. Pointeur vers une structure contenant des paramètres génériques pour « io_read » Pointeur vers une structure de paramètres spécifiques associés à « io_read » pour ce type de périphérique.
En cas d'inexistence de paramètres il prendra la valeur « NULL » uint32 wait mode Définition du caractère bloquant ou non bloquant de l'appel à « io_read » NO_WAIT L'appel à « io_read » n'effectue pas d'attentes bloquantes. 25 WAIT L'appel à « io_read » effectue une attente bloquante jusqu'à la fin de la réception du message ou expiration d'un timeout. adresse; uint32 [0,2"32-1] adresse de l'émetteur du message à lire (in) ou recu (out). sEngineeringData BswSAckEData NA zone de stockate des engineering data au format pmu protocol. Codes de retour : Contraintes particulières : - Le message à recevoir est constitué d'une série d'octets. Le premier octet reçu sera stocké à l'adresse la plus faible du buffer de réception. - Au cas où l'architecture matérielle ne permet pas l'adressage au niveau octet, l'octet reçu en premier sera stocké dans l'octet de poids le plus faible du mot mémoire constituant l'unité d'adressage d'adresse la plus faible. - Sur certaines implémentations des contraintes particulières supplémentaires pourront s'appliquer sur l'adresse du buffer de réception (p.ex. qu'elle soit multiple de 4). Dans ce cas, elles seront clairement spécifiées dans le manuel utilisateur des drivers et elles généreront une erreur « PARAM_ERROR » si elles ne sont pas respectées. SUCCESSFUL Lecture correctement effectuée PARAM_ERROR Erreur dans le passage de paramètres HW_ERROR Problème matériel lors de la réception du message sur le lien MEMORY_ERROR Erreur lors de la gestion du buffer contenant le message (yc problèmes du DMA) PROTOCOL_ERROR Problème lors de la réception du message sur le lien au niveau protocole TIMEOUT ONGOING Sortie en time-out de l'attente bloquante en cas d'utilisation du mode « WAIT » Écriture en mode NO WAIT en cours OTHER Autre type de problème OSE Objet
Méthode se chargeant d'effectuer les opérations nécessaires pour fermer une session de communication. Tout échange d'écriture ou de lecture en cours sera abandonné.
Prototvpe :
uint32 io_close(uint32 dev_major, uint32 dev_minor, void *spec_param) Paramètres : Codes de retour : dev major uint32 [0,2"32-1] dev_minor uint32 [0,2"32-1] spec_param void* NA Identification du type de périphérique (cf §4.1.1) Identification du périphérique (cf §4.1.1) Pointeur vers une structure de paramètres spécifiques associés à « io_close » pour ce type de périphérique.
En cas d'inexistence de paramètres il prendra la valeur « NULL » SUCCESSFUL Fermeture correctement effectuée PARAM_ERROR Erreur dans le passage de paramètres HW_CLOSE _ERROR Problème matériel lors de la fermeture de la session de communication PROTOCOL_CLOSE _ERROR Problème de fermeture de la session de communication au niveau protocole (échanges sur le lien de communication) OTHER Autre type de problème 27 '26, 0._SHUTDOW N Objet Méthode se chargeant de désactiver le périphérique au niveau matériel. Prototype : uint32 io shutdown(uint32 dev major, uint32 dev minor, void *spec param) Paramètres : Codes de retour : * **** * * ..... dev major uint32 [0,21'32-1] dev minor uint32 [0,21'32-1] spec_param voici* NA Identification du type de périphérique (cf §4.1.1) Identification du périphérique (cf §4.1.1) Pointeur vers une structure de paramètres spécifiques associés à « io shutdown » pour ce type de périphérique.
En cas d'inexistence de paramètres il prendra la valeur « NULL » SUCCESSFUL Désactivation correctement effectuée PARAM ERROR Erreur dans le passage de paramètres HW SHUTDOWN ERROR Problème matériel lors de la désactivation du périphérique OTHER Autre type de problème 28 C O N T L Objet
La méthode « io_control » sert au contrôle fin du périphérique et du driver associé. Elle n'est pas associée à un comportement particulier, mais à un ensemble d'actions unitaires qu'on identifie à l'aide d'un code action passé en paramètre.
Prototvpe :
uint32 io_control(uint32 dev_major, uint32 dev_minor, uint32 action, void *action_param)
Paramètres : Codes action :
Les codes d'action présentés ci-dessous sont génériques et doivent être implémentés sur tous les types de périphérique. Pour chaque type de périphérique, des codes d'action complémentaires permettent de gérer les spécificités Codes de retour : SUCCESSFUL Action correctement effectuée dev_minor uint32 [0,2"32-1] Identification du périphérique (cf §4.1.1) action uint32 [0,2"32-1] Identification de l'action à effectuer (liste de codes action identifiée ci-dessous) dev major uint32 Identification du type de périphérique (cf §4.1.1 action param void* NA Pointeur vers une structure de paramètres associés à l'action à effectuer. En cas d'inexistence de paramètres il prendra la valeur « NULL » INIT_DEV NA Réinitialise le périphérique au niveau du matériel avec le même paramétrage que celui utilisé par « io initialise » ABORT_DMA_TX NA Arrêt d'un transfert DMA TX encours (mode « NO_WAIT ») ABORT_DMA_RX NA Arrêt d'un transfert DMA TX encours (mode « WAIT ») 29 PARAM_ERROR Erreur dans le passage de paramètres UNSUCCESSFUL Action non effectué ou effectuée partiellement ACCESS ERROR Erreur d'accès du CPU au hardware. OTHER Autre type de problème a O P T1BILITE AVEC LM SERVER L'IO Server tel que définit dans R1 est composé d'un moteur appelé « 10 Engine » ainsi que de drivers compatibles SSIS.
Voici les particularités attendus par 1'10 SERVER en termes d'interface avec un driver compatible SSIS:
5.1. NOMAGE DES AP Le format du nom des API du SSIS est le suivant : lo[NomDriver][NomApi]. Par exemple, le driver 12C (12cDrv) aura comme API :
- IoDriverl2cDrvinitialize
- IoDriverl2cDrvRead 5.2. PARAMETRES DE F«)NCnONNEMENTS Le fournisseur du driver devra indiquer les paramètres de configuration afin de permettre l'intégration ainsi que la configuration du driver par un intégrateur au sein de 1'10 Server.
Notamment le fournisseur du driver devra indiquer les modes de communication supportés : Mode WAIT : mode synchrone.
Mode NO_WAIT :mode asynchrone permettant le transfert en tâche de fond. 5.3. TEMPS D"EXECUTION DES Le fournisseur du driver doit s'assurer des points suivants : - Chaque API soit se terminer dans un temps fini
- Les temps d'exécution des API Read, Write et 10 CTL doivent être mesurés et maximisés.
Remarque : L'IO Engine met à disposition des driver la primitive 10_EndOfSequence afin de détecter lorsqu'un driver doit rendre la main. Cela permet d'amélioré la sécurité des drivers surtout lorsque celui-ci utilise des boucles. static inline Bool 10_ EndOfSequence(); LES AM A l'exception de 10 Initialize, les API des drivers n'ont pas à utilisé le paramètre spec_param de l'interface. De même 10 Control doit supporter une liste minimale d'actions. 41, \ E L'API d'ouverture des drivers est compatible du SSIS. Le paramètre spec_param est un pointeur sur une table de IOS_EloCmd (mémoire associative de type Tag/Value).
Le type IOS_EloCmd est de la forme suivante : eTag IOS_E IoTags Cf §6.3 Descripteur de paramètre cf fichier d'interface IO Server) ulValue uint32 [0,21'32-1] Valeur du paramètre Remarque : Cette table se termine toujours par le Tag END_OF_SPEC. Par exemple :
IOS_EloCmd ConfDevSimu2[]= { {SPEED, 57600}, {RETRY, OFF}, {REDUNDANCY, ON}, {LOOP_BACK_STATE, OFF}, {ALIGN, 4}, {RX_FIFO_LENGTH, 512}, {TX_FIFO_LENGTH, 2048}, {END_ OF_SPEC,O} }; Les IO control devant exister dans un driver pour pouvoir s'interfacé avec l'IO Engine sont les suivants : G ET_FIN DMA TX Test la fin de transfert asynchrone GET_FIN_DMA_RX Test la fin de réception asynchrone G ET_N B_DMA_RX Lecture du nombre d'octet déjà reçu dans le cadre de la réception asynchrone en cours. ABORT_DMA_TX Annulation d'un transfert asynchrone en cours ABORT_DMA_RX Annulation d'une réception asynchrone en cours Ces codes sont définis dans le chapitre 6.4. Les interfaces de ces IO Control sont les suivantes : GET_FIN_DMA_RX SUCCESSFUL Transfert terminé avec Ack matériel G ET_FIN DMA TX ONGOING Transfert en tache de fond Action_param = HW_ERROR Erreur de transmission du à un problème pointeur vers un matériel uint32 pour stocker la taille lue. PARAM_ERROR Action_param est NULL PROTOCOL_ERROR Erreur de transfert UNCONFIRMED Transfert terminé avec matériel ne supportant (TX only) pas les Ack ACCESS_ERROR Accès au périphérique refusé GET NB DMA RX SUCCESSFUL Transfert terminé de x octets. Action_param = pointeur vers un uint32 pour stocker la taille lue. HW_ERROR Accès au périphérique refusé PARAM_ERROR Api non implémentée ACCESS_ERROR Accès au périphérique refusé ABORT DMA RX SUCCESSFUL Annulation du transfert réussie ABORT DMA TX action_param = non utilise HW ERROR Erreur matériel PARAM_ERROR Api non implémentée ACCESS_ERROR Accès au périphérique refusé Les codes d'erreurs sont définis au chapitre 6.2. 5,5, DYNAMIQUE Voici dynamiquement d'interface entre l'IO engine et les drivers pour les lectures / écritures en mode WAIT (synchrone) et NO_WAIT (asynchrone).
L'IO Engine adaptera son comportement (WATT ou NO_WAIT) en fonction du comportement du driver : Un driver retournant ON_GOING lors d'une API read ou write indique un fonctionnement NO_WAIT.
551, ZONE DE DONNEES PARTAGES Dans le cadre des API read et write l'IO Engine fournie deux buffers aux drivers : un buffer d'émission / réception.
un buffer d'Engineering data pour stocker des données privé propriété du driver pouvant être utile pour le débogage.
L'IO Engine garantie que ces buffers ne sont pas utilisés/modifiés entre le début et la fin des algorithmes suivants. Cela permet à un driver d'utiliser ces zones comme bon lui semble et d'éviter ainsi des recopies de donnés inutiles.
D'autre part les buffers d'émission / réception sont tous deux précédés et suivis de zones libres de 128 octets allouées aux drivers afin que ce dernier puisse implémenter une encapsulation des données (l'IO Engine garantie qu'ils ne seront pas modifiés). Le but des ces zones libres est de permettre l'implémentation de piles de communications dite « sans recopie » de buffer afin d'optimiser la vitesse de transmission. .52. MODE WAIT En mode WAIT l'engine s'attend à ce que les drivers retournent SUCCESSFUL lors d'un appel à 10 Read.
5,5.2.1 IO READ IO Encline Driver 1 Read(buffer,length) SUCCESSFUL(X bytes read from address A) Figure 1- Lecture synchrone - lecture de donnée sur un device. Remarques :
L'adresse de l'émetteur peut être fourni à l'API read lorsque celle ci est doit être connue préalablement à toute lecture (mode maitre/esclave).
L'adresse de destinataire peut être fournie part l'API read lorsqu'il est possible de la déduire du message reçu.
Figure 2- Lecture synchrone - erreur de lecture. 5,5.2.. 10 RITE En mode WAIT l'engine s'attend à ce que les drivers retournent SUCCESSFUL lors d'un appel à 10 Write. IO Encline Driver 1 10 Read(buffer,length) Error(engineering data ED) IO Encline 1 Driver 10 Write(buffer,length, address) SUCCESSFUL(X bytes sent) Figure 3- Ecriture synchrone - écriture sur un device.
IO Encline 1 Driver 10 Write(buffer,length, address) Error(engineering data ED) Figure 4- Ecriture synchrone - écriture sur un device en erreur. 5.5,3, MODE. NO_WMT
5,55.1. f~ READ En mode NO_WAIT l'engine s'attend à ce que les drivers retournent ONGOING lors d'un appel à 10 Read. 10 Enaine Driver 1 10 Read(buffer,length[, Address A]) ONGOING 10 Control(GET_FIN_DMA_RX) ONGOING 10 Control(GET_NB_DMA_RX) SUCCESFUL(X bytes read yet) V Optional part that can be repeated several times Figure 5- Lecture asynchrone - première partie de l'algorithme.
IO Enaine Driver IO Control(GET_NB_DMA RX) optional IO Control(GET_FIN_DMA RX) SUCCESSFUL SUCCESFUL(X bytes read on device A) Figure 6- Lecture asynchrone - fin de la réception à l'initiative du driver. Remarques :
L'adresse de l'émetteur peut être fourni à l'API read lorsque celle ci est doit être connue préalablement à toute lecture (mode maitre/esclave).
L'adresse de destinataire peut être fournie part l'API read lorsqu'il est possible de la déduire du message reçu.
IO Enaine Driver Timeout IO Control(GET_FIN_DMA RX) ONGOING IO Control(GET_NB_DMA RX) SUCCESFUL(X bytes read) IO Control(ABORT_DMA RX) SUCCESSFUL Figure 7- Lecture asynchrone - fin de la réception à l'initiative de l'engine. IO Enaine Driver IO Control(GET_FIN_DMA RX) Error(engineering data ED) IO Control(ABORT_DMA RX) SUCCESSFUL Figure 8- Lecture asynchrone - erreur de lecture dans le driver. ,5,3.2. IO 1TE En mode NO_WAIT l'engine s'attend à ce que les drivers retournent ONGOING lors d'un appel à 10 Write. Figure 9- Lecture asynchrone - première partie de l'algorithme.
Enaine Driver 10 Control(GET_FIN_DMA TX) SUCCESSFUL W Figure 10- Ecriture asynchrone - fin de la réception à l'initiative du driver. 10 Enaine Driver 1 10 Write(buffer,length, Address A) ONGOING V V O IO Encline Driver IO Control(GET_FIN_DMA TX) IO Control(ABORT_DMA TX) SUCCESSFUL ONGOING Figure 11- Ecriture asynchrone - fin de la réception à l'initiative de l'engine. IO Encline Driver IO Control(GET_FIN_DMA TX) Error(engineering data ED) IO Control(ABORT_DMA TX) SUCCESSFUL Figure 12- Ecriture asynchrone - erreur de lecture dans le driver. 6. ANNEXES Dans cette annexe on spécifie les valeurs des différentes constantes utilisées dans l'API générique. On donne également des directives pour l'assignation des constantes utilisées dans les paramètres/actions/codes de retour spécifiques des drivers.
ANNEXE LES MODES DE TRANSMSSONS Définition des valeurs d'entrée de « io write » et « io read » 6.2. ANNEXE 2 - CODE D'ERREUR DRVER Les code d'erreur driver sont définis dans le fichier d'interface IO Server : IoDrvDefs.h 63. ANNEXE 3 .». t.. S E DES CODE ti 'éN MA\-OSA TéON D'UN L R V La définition du type IOS_EloTags permetant d'initialiser les drivers se trouve dans le fichier d'interface de l'IO Server IoDrvDefs.h
6.& ANNEXE - ~..~w ~.. DES ~O '\ N TRO L NE \.Si e\\. RE \ .. . \ SE iVER La liste des codes de l'API io control est définie dans le fichier IoProtos.h de l'interface générale des driver IO Server. « NO WAIT » 0 « WAIT » 1 ANNEXE B Spécification du protocole sur les services de communication inter-partitions ARINC 653 TABLE OF CONTENTS 1. INTRODUCTION 46 1.1 Introduction 46 1.2 Limitations 46 1.3 Reference documents 46 1.4 Applicable documents 47 1.5 Lerms, definitions and abbreviated terms 48 2. ARCHITECTURE OVERVIEW 49 2.1 Main entities of the architecture 49 2.2 Actors using the platform 50 2.2.1 Partition developer 50 2.2.2 Integrator 50 2.3 Partition organisation and configuration 50 2.3.1 Sources organisation 51 2.3.2 Production description 53 3. SIMULATOR CONFIGURATION 54 4. BSW DELIVERY 55 4.1 Package delivery content 55 4.2 bin 55 4.3 conf 55 4.4 include 56 4.5 Makefile 57 4.6 Package utilisation 58 4.6.1 Table binaries generation 58 4.6.2 BSW start-up 58 5. USER MANUAL FOR PARTITION SUPPLIER 59 5.1 Interface priciples 59 5.1.1 SW/SW interface 59 5.1.2 Inter-partition communication PMU protocol 59 5.1.3 Acknowledge service 60 5.2 Process to make evolution on PMU protocol 61 5.3 BSW interface 62 5.3.1 MM&DL interface 63 5.3.2 IO Server interface 67 5.3.3 Common BSW interfaces 70 5.4 Delivery principles 71 5.4.1 Partition code binary 71 5.4.2 Mandatory services 71 6. USER MANUAL FOR INTEGRATOR 72 6.1 Configuration/Customization process 72 6.1.1 Overview & BSW issues 72 6.1.2 Process for mock-up phase 73 6.1.3 Proposal of process for industrial phase 74 6.2 Basic software Configuration 74 6.2.1 MM&DL partition 74 6.2.2 IO_Server partition 79 43 6.3 Global system image 93 6.4 Bootloader (RSW) 94 6.4.1 Behaviour of the resident software 94 6.4.2 Booting the BSW 94 7. LIMITATIONS 96 7.1 Limitations on design 96 7.2 Limitations on validation 96 7.2.1 Memory mapping 96 7.2.2 SimLEON target 97 7.2.3 Test Partitions 97 8. ANNEXE 98 8.1 Product limitations 98 8.2 Simleon flavor 98 8.3 MMDL Interna/ Error Code Values 101 8.4 IOS Interna/ Error Code Values 103 8.5 SSIS DEVICES Major numbers 107 8.6 IOS Interna/ LICE Code Values 107 8.6.1 Code IOS_TRACE_INIT (offset 0) 107 8.6.2 Driver codes (offset 1-3) 108 8.6.3 Code IOS_SEQ_NUM (offset 4) 108 8.6.4 Code IOS_SEQ_STATUS (offset 5) 108 8.6.5 Code IOS_DRV_STATUS (offset 6) 109 8.6.6 Code IOS_CODE_ENGINE (offset 7) 109 8.6.7 Code IOS_PERF_INFO (offset 8) 109 8.6.8 Code IOS_DATA_LENGTH (offset 9) 109 8.6.9 Code IOS_TRAP_PC (offset 10) 109 8.7 MMDL Interna/ LICE Code Values 109 8.7.1 Code MMDL_TRACE_INIT (offset 0) 109 8.7.2 Driver codes (Code 49-51) 109 8.7.3 Code IOS_PERF_INFO (offset 3) 109 8.7.4 Code IOS_SEQ_NUM (offset 4) 110 TABLE OF FIGURES Figure 1 : Architecture overview 49 Figure 2 : Source Code Configuration, Configuration Table & Customization Table 51 Figure 3 : Sources organisation 52 Figure 4 : Sources organisation - Module focus 52 Figure 5 : PMU protocol interface 60 Figure 6 : MM&DL ports description 63 Figure 7 : IO Server ports description 67 Figure 8 : Configuration process overview 72 Figure 9 : Future configuration process 74 44 TABLE OF TABLES Table 1 - Reference Documents 46 Table 2 - Applicable Documents 47 Table 3 - Module Ids definition 56 45 INTRODUCTION 1.1 LV ~fODUCTION This document provides directives to integrate and use the Basic Software. Following chapters will have a top/down approach: ^ Architecture overview : identification of mains modules in the architecture, place of BSW regarding other modules, interface protocol with BSW ^ Organisation of the file repository ^ Information focused of Partition supplier activities : interface, PMU protocol Information focused of Integrator activities : Configuration process and parameters ^ 1.2 LIMITATIONS 1.3 REFEREA,«X DOCUMENTS .......................................................................... .......................................................................... .......................................................................... ................................ .......................................................................... .......................................................................... .......................................................................... ................................ .......................................................................... .......................................................................... .......................................................................... .............................. R1 SRS IOS 1.0 R2 SRS MMDL 1.0 R3 SDD BSW 1.0 R4 XM2 User Manual 002n R5 XM2 Release Notes 009p R6 Ground Systems and Operations - Telemetry and ECSS-E-70-41 A Telecommand Packet Utilisation R7 Software PA and Engineering requirements for the 1.0 DCT/AQ /SO - 2008.0030194 development of the Basic SW of the Generic Payload Unit SW R8 Avionics Application Software Standard Interface ARINC specification 653 R9 SSS Basic Software 1.1 NA R10 SHIS NA R11 Drivers user manual 2/11/ Ed. 1 Rev. LVCUGEN-MU-DRV-9500- 2010 1 CS R12 IP SpaceWire CEA 24/01/ Ed. 1 Rev. SE-CNS-SPW-IPSPW-MU 2008 1 R13 OBC version filière v2.2 30/05/ Ed. 2 Rev. µST-MU-S-3-OC-4528-CNS 2006 1 R14 spécification des fonctions et interfaces des formware de 15/06/ Ed. 4 Rev. µST-SP-1111 l'OBC (version v2.2.bis filière Myriade) 2006 1 R15 I2C Protocol firmaware 15/06/ Ed. 1 Rev. µST-DC-S-3-OC-416-CNS 2000 0 Table 1 - Reference Documents 46 .4 APPLICLIBLEDOC T' NTS AD4 IRD CCSBSW 3.0 NA AD5 Règles communes pour l'utilisation des langages de 3 RNC-CNES-Q-HB-80-501 programmation AD6 Règles pour l'utilisation du langage C 8 RNC-CNES-Q-HB-80-506 AD8 SSIS 01/0 2.1 Draft DCT/SB/LV-XXXX 7/20 10 AD9 CPU ITAR FREE FPGA definition 23/0 Ed. 1 SE-IFREE-FPGA-T-DD 3/20 Rev. a 10 47 Table 2 - Applicable Documents 1.5 ï 48 ARINC ARINC653 BSP BSW CC CCSDS DPU EDAC GPMU I2C LVCUGEN PMU PTF PUS RSW RUP SOIS TSP UML UPV XM Aeronautical Radio Incorporated Avionics Application Software Standard Interface Board Support Package Basic Software Command Control Software Consultative Committee for Space Data Systems Data Processing Unit Error Detector And Corrector Generic Payload Management Unit Inter-IC bus Generic Payload Software (Logiciel de Vol Charge Utile Générique) Payload Management Unit Platform Packet Utilization Standard Resident Software Rational Unified Process Spacecraft On Board Interface Services Time and Space Partitioning Unified Modeling Language Universidad Politicnica de Valencia XtratuM ARCHITECTURE OVERVIEW This chapter highlights mains modules of the architecture. 2.1 MAIN ENI"! ..... OP' THE ARCHITECTURE Following scheme identifies Basic Software components inside global architecture. It aims to identify configuration capabilities for each entity. - Resident Software is an autonomous module without any configuration table. - Hypervisor needs configuration parameters describing configuration of the platform: list of partitions + specific information. - Each BSW partition has its own configuration table and part of them have also a customisation table. - Each Mission SW partition may have its own configuration table and part of them might have also a customisation table. PMU partitions can be adapted through: - Source code configuration (SCC) It allows defining the functional perimeter of the partition. This configuration is under partition developer responsibility. A new source code configuration leads to a new validation of the delivered partition. - Configuration Table (CT) It allows defining the utilisation context within the existing functional perimeter. Configuration Table is under PMU Integrator responsibility. A new Configuration Table does not lead to a new validation of the impacted partition. A validation of the Configuration Table itself is sufficient. However, in operation, a new Configuration Table leads to a partition upload. - Customization Table Resident SWI Campuent amiable a~ PQI pli Commuent amiable a. Umid. platfonn -------------------------------------------------------------------------- --------------Basic SW 1 Goerg 1 1 1
---------------- Figure 1 : Architecture overview HyperviSelr Mode met 1 Data lnadirg Goerg GU6bd ----------------------------------------------------------------------- f i Goerg GU5fa f i Goerg GU61a Mission SW 1 Contrai 1 Cournand 110 Servwer Goerg f Mass rnemory Goerg GU61a f HW 15W event rang Gonfg 1 nslnrnentation Goerg ~mplàg x ^ z. - Y - 5isinm f Mission SW P GU6bd I 49 Customization Table (CST) allows defining parameter values with a pre-defining context. It is User modifiable code. A change within the Customization Table does not impact validation. In operation, a new Customization Table can be uploaded independently of the partition binary itself. 2.2.1 Partition developer He is focused on a dedicated partition. - He develops and tests its own partition - He defines interfaces between its partition and others: using existing ones, creating new oves. - He provides characteristics and constraints about its partition to integrator: minimum timing for initialisation and shut down ...
2,2.2 leggrgIQr. He has a global view on the platform with all partitions. - He gets basic requirements from each partition developer: memory, scheduling constraints - He configures XM2 declaring each partition: characteristics, memory mapping... - He configures IO-Server declaring each port: characteristics, size... - He declares each connection between partitions : port used - He configures the IO-Server scheduling plan - He configures the XM2 scheduling plan - He tests and validates the global behaviour. 2,3 PARTITION ORGANISATION A ND CGlttirFIGUR.
Any software partitions can be adapted through: - Source code configuration - Configuration Table - Customization Table Suuu!iurle rrrapolrum --_------- Parbl:ko 51ppiar t Palilirdà. t crgIrmnarmirabip_wl t t U~r~~ieü~ Pie user Figure 2 : Source Code Configuration, Configuration Table & Customization Table 2.3,1 Sources organisation GPMU sources will be organized has shown on Figure 3. Partition supplier might have to use the complete directory tree: focused on its own partition. Integrators will be focused on binary files and configuration or customisation tables: inside each partition, he will find its information into BLD directory. LVCUGEN TOOLS Tools used for production such as cross-compiler. Tool used to generate PMU Protocol definition XM XtratuM source code as delivered by UPV. COMMON Common code that can be shared between partitions. INC PmuProtocol.XML file to modify. BLD PmuProtocol.h file generated and used for building. PARTITION_X Partition X source code.
TEST Test tools and tests scripts. TU PARTITION X PARTITION X Unit lest
TI Each partition source code is organized with the same arborescence. PARTITION _X PARTITION X Integration lest
TV PARTITION X PARTITION X Validation lest and associated lest Partitions
SCRIPTS Automation lest Framework Figure 3 : Sources organisation PARTITION _X SRC PARTITION X source code directory. SUB MODULE Y Hw SW Event Manager partition source code. SRC SUB MODULE Y source code. INC SUB MODULE Y interface. BLD SUB MODULE Y build directory INC PARTITION X interface BLD PARTITION X build directory. Binary files used for integration. for Figure 4 : Sources organisation - Module focus A build directory is created during compilation. It contains all generated object, libraries and binaries. It is not under source control.
Integrator is not interested in Source files. He will find used files for each partition in "BLD" directory and shared files in "COMMON" directory.
2.3,2 ProEluctior Eles cri ti~+flr Compilation relies on Make. Common definitions are centralized within COMMON/SRC/Makefile.in. Common compilation targets are centralized within COMMON/SRC/Makefile.out. Each Makefile includes COMMON/SRC/Makefile.in and COMMON/SRC/Makefile.out. Each makefile implements the following targets: - all: default compilation target. Produce the current module and its dependencies. - clean: clean the build directory of the current module and of its dependencies. Each module production can be performed with the following option: - "make ail": production of the module in release mode - "make all DEBUG=-DDEBUG": production of the module in debug mode SIMULATOR CONFIGURATION The simulator compatible with this software is called simLEON. It is developed by Astrium and configured for Itar-Free board. See §8.2 for the configuration. .1 PACKIGE DE'LIVERY CONTENT The BSW package is delivered through a tar.bz2 archive. To extract data, the following command fine has to be executed: $ tar -xjvf bsw.tar.bz2 A directory named "BSW" will be created locally. The package tree is described here below: - ~ es - bin - conf kable_sample xm - include - makefile It contains the binaries corresponding to Mmdl and IoServer partitions. Hence, it contains makefiles, loaders and includes which allow generating binaries of all tables (config, custom and compatibility tables for Mmdl and config table for IoServer). At the end, it contains useful files to work with the BSW. All archive directories are described hereafter in details. REMARK: MMDL related files are no more delivered in this package. 4.2 131-x% bin A IoServerParkikion,binary A MmdlParkikion,binary This directory contains the binaries of: - Mmdl partition - IoServer partition Binaries contain a BSW header which is described in §3.5. 4.3 CONF. conf kable_sample 1 IaServerConfigTable.c MmdlCompabbilikyTable.c MmdlConfigurakionTable,c MmdlCuskamisakionTable,c xm A core_config This directory contains 2 sub-directories. First contains table samples of all types. It allows integrator to easily instanciate its own tables in relation to its needs. The second contains the core_config file which allows generating the Xm core binary used to vafidate BSW partitions. 55 .4 INCL 17D.~ include - l Error,h - I IoDriverTypes,h - I IoDrvDefs,h - I IoMotorDefs,h - I IoMokorTypes,h - I IaServerSrcCodeConfig,h ^ I Ivcugen_macro,h - I MmdlError,h - I MmdlSrcCodeConfigurabon,h - I MmdlTypes,h - I PmuProkocol,h `» PmuProkocol,xml - I PmuProkocolParser,pl ^ I TypesDefinikion,h This directory contains: - includes needed to generate table binaries TypeDefinitions.h, PmuProtocol.h MmdlTypes.h, IoDriverTypes.h, IoDrvDefs.h, IoMo to rTyp es. h, lvcugen_macro.h - source code configuration for Mmdl and IoServer partitions IoSrverSrcCode Configuration.h, MmdlSrcCode Config.h - Error definitions Error.h: structures and macros. This file contains also Module Ids and sub-modules Ids necessary for BSW error codes generation. The tables below list the different modules Ids and sub-modules ids. Module ID Name Description 1 MOD_COMMON COMMON module id. (not used) 2 MOD_MMDL MMDL module id. 3 MOD_IOSERVER IO_SERVER module id. Table 3 - Module Ids definition Sub module Name Description ID 2 SMOD_IOSERVER_MOTOR IO MOTOR sub-module id. 3 SMOD_IOSERVER_DRIVERS IO DRIVERS sub-module id. 4 SMOD_MMDL_DL Data Loading sub-module id.
SMOD_MMDL_MM Mode management sub-module id. 6 SMOD_MMDL_CMN MMDL Common sub-module id. 7 SMOD_MMDL_INIT Init sub-module id. 8 SMOD_MMDL_MAIN Main sub-module id. Table 4 - Sub-module Ids definition IoMotorDefs.h: errons (Id and explanation) managed by IO Server MmdlError.h: errons (Id and explanation) managed by MMDL
- Error codes managed by MMDL are described below §8.2. - Error codes managed by IO Server are described below §8.3 56 - PmuProtocol.xml and associated parser PmuProtocol.xml, PmuProtocolParser.pl 4.5 t~~,~._a~l~FL makefile A iosconfigloader, Ids MakefileIosConfig A MakefileMmdlCompat A MakefileMmdlConfig A MakefileMmdlCustom A mmdlcompakloader.lds A mmdlconfigloader,lds mmdlcustomloader, lds This directory contains all makefiles and correspondent loaders to generate all table binaries. Warning, the binary generated doesn't contain a BSW header. It is up to the integrator to add it at the beginning. The new binary will 16 bytes bigger. It is described here below: Signature Reserved Maj Min CRC Length version version 4 bytes 2 bytes 1 byte 1 byte 4 bytes 4 bytes Table 7 - BSW header - Signature: set to $ M M D" - Reserved: set to 0 - Maj Version: contains the major version of current binary - Min Version: contains the minor version of current binary (revision) - CRC: contains the CRC of current binary itself (16 bits) based on R6 Annexe A using the last two significant bytes (the most two significant bytes are set to 0 for now) - Length: contains the length of current binary Here below, is a BSW header example dumped of example.binary containing the following data: - Siganture Ox244d4d44 - Major version - Minor version k - CRC : Oxa556 ................... ................... - Length: octets 57 $hexdump -C example.binary lhead $00000000 24 4d 4d 44 00 00 Üo ÜO All binaries (partition code, configuration table, customisation table) managed by MMDL have to have a BSW header including MMDL binaries itself and compatibility table. 4, 6 , 'A C,K G UTILISATION 40601 Table binarles generatinn To generate table binaries (config, custom, compatibility), makefiles and loaders delivered have to be used with defining the following variables first: - BSW_DIR: path to BSW directory delivery - BUILD_DIR: path to building directory for output - SRC_DIR: path to directory containing the .c of table to be generated - CC: sparc linux gcc executable name - LD: sparc linux ld executable name - OBJCOPY: sparc linux objcopy executable name
Notice: check the sparc linux executables location is defined in the PATH variable
Now table binaries can be generated. The following command fine allows generating the MmdlConfigurationTable.bin: $ make -f $BSW_DIR/makefile/MakefileMmdlConfig $BUILD_DIR/MmdlConfigurationTable.bin 4:6,2 BSW start-up Here after are described the different mandatory steps to allow the BSW to start-up. 1. Partitions (code + tables) managed by MMDL have to be placed into Flash including MMDL partition itself as specified into Mmdl configuration table. The binaries have to contain a BSW header 2. Xm (core and config) and Mmdl (partition code and all its tables without BSW header) has to be placed into RAM 3. Jump to Xm start address . USER N. NUAL FOR PARTITION SUPPLIER 5.1 LVTERFACE PRIC.Ifb1,E 50101 ;r nterface PMU interface is described by a list of sampling and queuing ports, and by the PMU protocol definition. Characteristics and behaviour of each kind of port are described in XM2 User Manual.
All partitions, whether they belong to the Basic Software or not, will use the PMU protocol for inter-partitions communications with the Basic Software. Others communications, for instance between two none BSW partitions, can be opaque and so differ from PMU protocol.
5,1.2 Inter-partition communication PMU protocol Inter-partition communication is based on a common PMU protocol. Each BSW sampling port and queuing port uses this protocol. Tag 1 Bytes Id of the communication service. See Chapter 5.3.1 for MMDL details See Chapter 5.3.2 for I0_Server details Service Status Flag 1 Bytes Service Status : See Chapter 5.3.1 for MMDL details See Chapter 5.3.2 for I0_Server details Sub-type 2 Bytes Sub-type of communication service See Chapter 5.3.1 for MMDL details See Chapter 5.3.2 for I0_Server details Length 4 Bytes Length of the Data payload parameter Index 4 Bytes Index of the PMU protocol packet Data payload Sub-type specific Specific sub-type date See Chapter 5.3.1 for MMDL details See Chapter 5.3.2 for I0_Server details Table 8 - PMU protocol
Each BSW partition declines the PMU protocol on its specific sub-type. A sampling port supports only one sub-type and is multicast. That means there is one writer and should the occasion one or multiple readers. A queuing port support one or several tag and sub-type and is unicast. That means there is only one writer and one reader. A protocol tag and sub-type can be supported by different channels. Hereafter is an example of the BSW interface hierarchy.
PMU protocol is described in XML description file. BSW provides PmuProtocolParser tool to translate XML description file in C header files. 5.1.3 Acknowledge service View from partition providers, each output port needs to be associated to an acknowledge port. A acknowledge port has the "queuing" type, with 24 bytes message length.
In case of request reception (as specified by the validity flag), the receiver will send an execution acknowledgement to the sender.
Acknowledge service has the following sub-type: - Protocol/Execution status For this sub-type, data payload is: Index Error type Internai Error Engineering Data 4 bytes 4 Bytes Pmu Error BswSAckEData 4 Bytes 28 bytes Table 9 - Acknowledge service data payload Index parameter is the index of the relevant received packet. Error type specifies the detected error. It indicates: - If 0, the received packet has been successfully executed. - A protocol header error - A protocol payload error - An execution error PMU protocol +Tag +Validity Flag +Sub-Type +Length +Index +D ta Mass Memory TYP channe) Mass memo +Tag = 18 +Validity Flag 1 +Sub-Type +Length +Index Greate Logbook +Tag = 18 +Validity Flag = Request +Sub-Type = 22 +Length = 32 +Index Td +Daita: Dndhnnk +Tag = 18 +Validity Flag = Request +Suh-Type = 23 +Length = 32 +Index +Data: rndhnnk Td + 4tri nrr Figure 5 : PMU protocol interface Internai Error is for development purpose and is not documented. It identifies the unique error origin within the source code. Engineering data are additional data provided along the message that may carry internai information to help for debugging. The meaning of this information depends on the sender of the acknowledgment message and does not meant to be understood by the receiver. This data are only for the developer of the partition sending the acknowledgment. Engineering data are composed of a BswSAckEData structure containing this: Type Engineering Data 4 bytes 20 Bytes Table 9 - Engineering data payload Type can be one of the following: - NONE - SPW RX - SPW TX - PIC RX - PIC TX - 12C RX - 12C TX - OSL RX - OSL TX - IO ENGINE - MMDL - CCSW - MSW - OPISS PMU protocol is defined with an XML file. Any partition provider may need to add new messages. Following description shows where to find the file "PmuProtocol.xml" in the global repository. LVCUGEN TOOLS Tools used for production such as cross-compiler. Tool used to generate PMU Protocol definition
COMMON Common code that can be shared between partitions. - INC .XML file to modify.
BLD .H file generated and used for building.
PARTITION X Partition X source code. Table 10 - PMU protocol localisation When XML file is done, user must run the tool "PmuProtocolParser.pl" to generate the .H file. He must use the following command line:
PmuProtocolParser.pl [-h help] [-i source_file.xml] [-o generated_file.h] 5.3 BS II' INTI,:RFAC Following interfaces are « public » and available for other partition such as described in ports configurations. Anytime, we will write about "partition ID" will mean ID of the partition in XM2 configuration.
How to set the partition ID? We must take care that each software (BSW, CCSW, MSW) might be implemented through several partitions. In order to keep stability within IDs, we propose to reserve range of value for each software: ^ BSW : From 0 to 9 o MMDL : 0 o IO-Server : 1 ^ CCSW : From 10 to 19 Durmg protocol definition, following types are used : typedef unsigned char UInt8; /* unsigned 8 bits */ /* signed 8 bits */ /* unsigned 16 bits */ /* signed 16 bits */ /* unsigned 32 bits */ /* signed 32 bits */ /* unsigned 64 bits */ /* signed 64 bits */ /* simple float */ /* double float */ /* booleen */ Then, each data must be defined in "PmuProtocol.xml" using following syntax : <BSW Interfaces Version="1.0">
<Type Type="ENUM" Name="PmuEMode" Prefixe="MODE_" Description="Enumerated the different mode of the PMU"> <EnumField Name="INIT" End=","/> <EnumField Name="OPERATIONAL" End=","/> <EnumField Name="DEBUG" End=","/> <EnumField Name="DOWNGRADED" End=","/> <EnumField Name="SHUTDOWN" End=""/> </Type> <!-- Define enum for the Bsw Tag --> <Define Prefixe="TAG_" Description="Enumerated the tag of the BSW services"> <DefineField Name="DATA LOADING"/> <DefineField Name="MODES MANAGER"/> <DefineField Name="IOSERVER"/> <DefineField Name="ACK"/> <DefineField Name="PARTITION STATE"/> </Define>
<Type Name="MmdlSLoadMemoryDP"> <StructField Type="UInt32" Name="1SequenceNumber" Description="unique id for this part, should be 1"/> <StructField Type="UIntl6" Name="sMemoryID" Description="Memory ID for destination"/> <StructField Type="UIntl6" Name="sDataLength" Description="Data length"/> <StructField Type="UInt32" Name="1StartAddress" Description="Start address"/> <ArrayField Type="UInt8" Name="cData" Description="Data"/> </Type> Table 11 - PMU protocol syntax definition typedef char typedef unsigned short typedef short typedef unsigned int typedef int typedef unsigned long long typedef long long typedef float typedef double typedef unsigned char Int8; UInt16; Intl6; UInt32; Int32; UInt64; Int64; SFloat; DFloat; Bool; - MSW1: From 20 to 29 - MSW2: From 30 to 39 - MSW3: From 40 to 49 5.3.1 MM&DL interface « Any partition' G et_G PM U Statu s -)D-0 ) get GPMU status request -C 0-d(- Re set request Reset BSVV & GPM -C 0-< Change_Mode Get_GPMU_Configuration -> 0) Lo ad, Du mp, Co py 0 Send ack cc 1,51&DL G et partition state request Get_Partition_State (TBC) (If n eede d) Legend: src 0 0 de st Queuing port src~ dest Sam pling port Get GPMU configuration requests 0 Memory operation requests 0 Memory operation responses
0 Acknowlegments 0 Change mode requests Reset request Figure 6 : MM&DL ports description This service allows to change the GPMU mode Transition between DEBUG to OPERATIONAL mode is performed through a BSW Reset Header TAG: TAG_MODES_MANAGER Header Sub-type: STYPE_MMDL_CHANGE_MODE_SERVICE Mode En u merated 2 6 ^ MODE OPERATIONAL ^ MODE DEBUG - MODE DOWNGRADED Mode 1 2 3 63 This service allows to start a binary upload. The configuration check is only based on the major version of the binary present into the BSW header Header TAG: TAG DATA LAODING 1 Header Sub-type: STYPE_MMDL _LOAD_MEMORY_SERVICE 1
Sequence Memory ID Data Start Data number Length Address Unsigned int Unsigned short Unsigned short Unsigned int Variable byte string Sequence number This field gives is a unique identification for this part. It shall be equal to 1 Memory ID This field gives the MMDL configuration table Memory ID concerning the loading Length This field gives the data length to be loaded Start Address This field gives the absolute start address for loading the data = destination address where data will be copied Data This field gives a data block to be loaded .......................................................................... .......................................................................... .......................................................................... ........................... . .......................................................................... .......................................................................... .......................................................................... ............................ . .......................................................................... .......................................................................... .......................................................................... ........................... . .......................................................................... .......................................................................... .......................................................................... ............................ . .......................................................................... .......................................................................... .......................................................................... ........................... . .......................................................................... .......................................................................... .......................................................................... .................... This service allows to upload a binary Header TAG: TAG DATA LAODING 1 Header Sub-type: STYPE_MMDL _LOAD_DATA _SERVICE 2
Sequence Start Data La st Data number Address Length Part Unsigned int Unsigned int Unsigned short Unsigned short Variable byte string Sequence number This field gives is a unique identification for this part. It shall be incremented by 1 in comparison with the previous part Start Address This field gives the absolute start address for loading the data = destination address where data will be copied Length This field gives the data length to be loaded (can not be equal to 0 if it is last part) Last Data This field indicates if it is the last part Remark: this field is implemented as an "unsigned char" instead of an "unsigned short" as described here above. However, it has to be considered that this field has a 2 bytes size. This fact has to be taken in account while setting "Data Length" field and data to be sent Data This field gives a data block to be loaded This service allows to dump a memory area Header TAG: TAG DATA LAODING Header Sub-type: STYPE_MMDL _DUMP_MEMORY_SERVICE Memory Reserved Start Length ID Address Unsigned short Unsigned short Unsigned int Unsigned int gives the MMDL configuration table Memory ID concerning the loading aims at insuring memory alignment gives the absolute start address (in SAUs, with the count starting from 0) within the memory block for dumping the data 1 3 Memory ID Reserved Start Address Length gives the length of SAU to be loaded Index Sequence Start Length Last Data Number Address part Unsigned int Unsigned int Unsigned int Unsigned short Unsigned short Variable byte string Index contains the index of the incoming request Sequence number gives is a unique identification for this part. Tt shall begin at 1 and be incremented by 1 in comparison with the previous part. Start Address gives the absolute start address for dumping the data. Length gives the data length to be dumped. Last Data indicates if it is the last part Data gives a data block to be dumped Index Checksum Unsigned int Unsigned int Index contains the index of the incoming request Checksum gives an up to 32-bit checksum of the data being dumped. . . . This service allows to get the CRC of a memory area Header TAG: TAG DATA LAODING 1 Header Sub-type: STYPE MMDL CHECK MEMORY SERVICE 4 Memory Reserved Start Length ID Address Unsigned short Unsigned short Unsigned int Unsigned int Memory ID gives the MMDL configuration table Memory ID concerning the loading Reserved aims at insuring memory alignment Start Address gives the absolute start address (in SAUs, with the count starting from 0) within the memory block for dumping the data gives the length of SAU to be loaded Index Checksum Unsigned int Unsigned int Index contains the index of the incoming request Checksum gives an up to 16-bit checksum of the data being dumped (even if 32-bit reserved for further versions of BSW). This service allows to get the GPMU status Header TAG: TAG MODES MANAGER 2 Header Sub-type: STYPE MMDL GPMU STATUS SERVICE 8 GPMU Current memory N Partition reserved Partition Mode Operation State Enumerated Enumerated Unsigned int bytes Enumerated - Repeated N times GPMU Mode indicates the current mode ^ MODE_INIT : GPMU initialisation 0 ^ MODE_OPERATIONAL : All partitions operational 1 ^ MODE_DEBUG : dedicated mode where all mission 2 partitions are stopped to validate BSW and CCSW 3 behaviour. 4 ^ MODE_DOWNGRADED : indicate that one or several partitions have been stopped due to problem ^ MODE_SHUTDOWN : GPMU stop Current Memory gives the current memory operation. SERVICE 0 Operation STYPE MMDL NONE SERVICE 1 SERVICE 3 4 ^ STYPE MMDL LOAD MEMORY ^ STYPE MMDL DUMP MEMORY ^ STYPE MMDL CHECK MEMORY N gives the monitored partition number Partition ID gives the monitored partition ID Partition state gives the monitored partition state. 0 1 2 ^ UNKNOWN XM STATE ^ HALTED XM STATE ^ STARTED XM STATE This service allows to get the version of all binaries Header TAG: TAG MODES MANAGER Header Sub-type: STYPE MMDL GPMU CONFIGURATION SERVICE XM XM Api XM Abi N Partition reserved Partition Configuration Customisation version version version ID Version Version Version U int U int U int U int 1 byte 1 byte 1 byte I 1 byte 1 byte I 1 byte 1 byte 1 byte This service allows to reset the BSW or the PMU Header TAG: TAG MODES MANAGER 2 7 Header Sub-type: STYPE MMDL RESET SERVICE Type Enumerated Type indicates the mode to be reached. - ~ Repeated N times N Number of partition indicates the partition ID (0 TBC for XM) indicates the partition code version (Major and minor = X.y) indicates the partition configuration version (Major and minor = X.y) indicates the customisation table version (Major and minor = X.y) Partition ID Partition version Configuration version Customisation version 2 9 67 2970577 ^ RESET_PMU 0 ^ RESET BSW 1 50302 I O Sera er interface Header TAG: - IO Server communication service - Acknowledgment service. - Partition state service. Payload description for each interface: Sub-service in charge of forwarding received data from input ports to IO devices Header TAG: TAG_IOSERVER Header Sub-type: STYPE DATA TX IO Server Any partition 1 ..M src ports 'LN lest port 0 1 ..M dent port 1 dent port O LN dent port 1 ..N sro ports HW&SW Event manager 1 dest port Display internai observation points 1 src port ->-C Update at each MAF 1 dent port DL& Send command Acknowledgment 1 ..N src ports 0 Set partition state 1 src port 1 1 des' port Legend: src } 0 de st Queuing port src ->-C des' Sampling port Figure 7 : IO Server ports description Write data received from 10 device Read data to send to device (from partition i) Instrumentation 1 lest port 1 dent port 3 1 NB: If the IO Server receives a Data transmission PMU packet whose functional validity flag is neither set at "Request" nor set at "Information", then a PMU syntax error will be detected and the packet will be rejected through the acknowledgment service. Sub-service in charge of transmitting received data from IO devices to the recipient ports Header TAG: TAG_IOSERVER 3 2 Header Sub-type: STYPE_DATA_RX .......................................................................... .......................................................................... .......................................................................... ............................ . .......................................................................... .......................................................................... .......................................................................... ........................... . .......................................................................... .......................................................................... .......................................................................... ............................ . .......................................................................... .......................................................................... .......................................................................... ........................... . .......................................................................... .......................................................................... .......................................................................... ............................ . .......................................................................... .......................................................................... .......................................................................... ........................... . Sub-service in charge of displaying on its source sampling port some internal information about the behaviour of the IO Server. These data will be gathered and processed by the two recipient partitions: HW&SW event manager and Instrumentation. Instrumentation partition will use these observation points to build its housekeeping and its monitoring telemetries and the HW&SW event manager partition will use these data to check if an internal failure occurred and inform other partitions of the dysfunction if necessary. Header TAG: TAG_IOSERVER 3 3 Header Sub-type: STYPE_OBS_DISPLAY Observables far HW8,SW Event manager and Instrumentation partitions Fixed 32bits aligned structure Length : 416 bytes Observation points structure is defined in "IoServerSObsDisplayDP" structure in the PmuProtocol xml file: sRxPortInfos [OUT_DATA_RX_QUEUING_PORTS_MAX_NUMBER] : This table contains for each output data Rx port 2 fields: - lreturnedStatus: XM returned status in case of error at message write attempt. - lerrorCounter: counts number of errors when writing a message in the port. This table is updated only in case of error, ie when returned status is different from XM_OK. sAckPortInfos [OUT_DATA_ACK_QUEUING_PORTS_MAX_NUMBER] : This table contains for each output data Ack port 2 fields: Raw data to transmit variable unsigned bytes string (size = Length) Raw data These are the data to physically transmit to the IO device. These data must be 4 bytes aligned Ravi data stream received from IO device unsigned bytes Stream - lreturnedStatus: XM returned status in case of error at message write attempt. - lerrorCounter: counts number of errors when writing a message in the port. This table is updated only in case of error, ie when returned status is different from XM 0K. sTxPortlnfos [IN_DATA_ TX_QUEUING_PORTS _MAX_NUMBER] : This table contains for each input data Tx port 2 fields: - lreturnedStatus: XM returned status in case of error at message read attempt. - lerrorCounter: counts number of errors when reading a message from the port. This table is updated only in case of error, ie when returned status is negative. 1DevicelnitStatus [IO_DEVICES_MAX_NUMBER] : This table lists for each device returned status at device initialization. This table is filled only in case of error, ie when returned status is not "successful". 1DeviceOpenStatus [IO_DEVICES_MAX_NUMBER] : This table lists for each device returned status when opening device. This table is filled only in case of error, ie when returned status is not "successful". 1DeviceCloseStatus [IO_DEVICES_MAX_NUMBER] : This table lists for each device returned status when closing device. This table is filled only in case of error, ie when returned status is not "successful". 1DeviceShutdownStatus [IO_DEVICES_MAX_NUMBER] : This table lists for each device returned status at device shutdown. This table is filled only in case of error, ie when returned status is not "successful". 1DeviceReadStatus [IO_DEVICES_MAX_NUMBER] : This table lists for each device returned status at read operation. This table is filled only in case of error, ie when returned status is neither "successful" nor "timeout". 1CompteurSaturation[IN_DATA _ TX_QUEUING_PORTS _MAX_NUMBER] : This table contains the number of times that saturation occurred on IOS internal buffer i where are stored DataTx port i incoming messages. 1NbBytesToSend and 1NbBytesRemainingToSend: These two fields are only for debug purpose, at the end of sequence, if the number of bytes to send (defined in the scheduling plan table) did not reach 0, then these two fields are updated with respectively the number of bytes to send (filled by the integrator in the scheduling plan table), and the number of bytes remaining to send (= Nb bytes to send - Number of bytes sent during sequence). 1NbBytesToReceive and 1NbBytesRemainingToReceive: These two fields are only for debug purpose, at the end of sequence, if the number of bytes to receive (defined in the scheduling plan table) did not reach 0, then these two fields are updated with respectively the number of bytes to receive (filled by the integrator in the scheduling plan table), and the number of bytes remaining (= Nb bytes to receive - Number of bytes received during sequence). Sub-service responsible for displaying IO Server state on its source sampling port Header TAG: TAG PARTITION STATE Header Sub-type: STYPE_SET_PARTITION _STATE 1 Mode Enumerated Mode STARTUP IN COURSE FUNC STATE: 1 Used to inform other partitions that IO Server is still in course of startup. ^ PARTITION READY FUNC STATE: 2 Notify other partitions that IO Server is ready for processing IO communications. ^ SHUTDOWN IN COURSE FUNC STATE: 3 Warn other partitions that IO Server has entered shutdown stage and that incoming packets will not be processed anymore. ^ SHUTDOWN FINISHED FUNC STATE: 4 Warn other partitions that shutdown has finished and that it is ready for reset. 5.3.3 CoE~~mon BSÇ$' interfaces .......................................................................... .......................................................................... .......................................................................... ............................ . .......................................................................... .......................................................................... .......................................................................... ........................... . .......................................................................... .......................................................................... .......................................................................... ............................ . .......................................................................... .......................................................................... .......................................................................... ........................... . .......................................................................... .......................................................................... .......................................................................... ............................ . ::::::::.:::::: This service will handle the acknowledgment of partitions write requests received on BSW input queuing ports. The acknowledgment in case of transmission success depends on the functional validity flag value ("Request/Information"), while in case of failure, the acknowledgment is systematic. Header TAG: TAG_ACK 4 Header Sub-type: STYPE_ACK_PROTOCOL_EXECUTION_STATUS 1
Packet index Error type Internal Error code Engineering data i -~ -~ -~ - 32 bits unsigned 32 bits unsigned 32 bits unsigned 24 bytes The packet index This field will be used by the recipient ports (or partitions) to discriminate which packets failed and which ones succeeded. The packet index is a copy of the "packet index" field received in the header of the "data transmission" PMU message Error type This field will give information about the error category. 0 ^ ERR_NO (No error), 1 ^ ERR_HEADER (Error wrt the header request), 2 ^ ERR_PAYLOAD (Error wrt the data payload request), 3 ^ ERR_EXEC (Error wrt the execution of the request) Error code Meaning of this Field will be under responsibility of each partition supplier. It gives the error code within the error category. This field will identify more precisely the cause of the error. This code will have a common structure. Bit field detailed here after : ^ MODULE : 8 bits ^ SUB_MODULE : 8 bits ^ GRAVENESS : 3 bits ^ ID : 13 bits MODULE, SUB-MODULE and GRAVENESS values are available in Error.h header file delivered with BSW package (see §3.4). Hence, structure which contains these fields is available too. Concerning ID field, values are available in MmdlError.h for MMDL partition and in IoDrvDefs.h and loMotorDefs.h for IO server partition. Errors are described in these files delivered in the BSW package. Engineering data This field is reserved for partition supplier debug information and might not be understandable by the receiver of this message. 5:4.1 Partition code binary Binary partition code delivered has to be a pure binary prefixed by a BSW header described in §3.5 5,4.2 Mandatory services All partition suppliers have to provide a "State display" service to allow BSW to check the partitions state when launching them. IO Server partition itself provides this service. It is described in §4.3.2. This service will be used by MMDL while GPMU start up and shutdown. Here after are summarise steps performing by MMDL around this service. - INIT - MMDL initialisation - MMDL get GPMU configuration - MMDL load binaries from Flash to RAM - MMDL launched all Partitions - MMDL wait for worst start up duration of all partition - MMDL use "State Display" service to check partitions are ready to work
That means launched partitions have to update their state once they are well initialised and partition provider has to indicate the maximum time to ensure a well initialisation. On another hand, to ensure a request will be dealt with, partitions have to wait for GPMU to be in operational mode (information is provided thanks to Get_GPMU _Status service) before starting sending any request except through Get_GPMU _Status service.
- SHUTDOWN - MMDL send an interruption to all partition through "XM shutdown partition" XM hypercall. - MMDL wait for worst shutdown duration of all partition - Other partitions have to shutdown properly to well start next time (data saving, communication closing, etc ...) - MMDL stop all partition even if they are not already stop
That means partition provider has to deal with XM_VT_EXT_SHUTDOWN XM interruption to ensure a safe shutdown and has to provide the maximum time to ensure it is well done.
USER MA'iiUAL FOR INTEGRATOR .......................................................................... .......................................................................... .......................................................................... ............................... .......................................................................... .......................................................................... .......................................................................... ............................... 6o1o1, Overview BSW issues Management of configuration/customisation tables is clearly a complex topic in this project. Many constraints must be supported but final process must stay as simple as possible. Following chapters gives an overview about needs, constraints and a future process to manage configuration/customisation tables.
Configuration tables used on platform are binary files. Their structure must allow modifying parameters without impact on partition software (no need of validation): it implies a very rigorous structure.
For future projects, partitions might be developed with different languages: to facilitate integration task, information should be stored into text files easily updatable.
Thus a tool will be used to process text files and generates binary files.
BSW has a specific issue due to information shared with XM2: Hyper visor configuration must be completed with BSW information. Processing needs to ensure consistency between Hyper visor configuration and BSW configuration.
Taking care about these constraints, a tool will be necessary for the industrialisation phase. Currently, many hypothesis need to be confirmed before tool definition. Otherwise, we could get something not adapted and very difficult to use.
First analysis shows that any partition provider might use this tool. We could have a common syntax and process for the parameter setting. and XI«É iermÉgfiRn >Inlln . ~~ pinlilim6 . rb ilfiunarm alzuR Fol31:mi-gmalin nedolErl . Idap1ed mxwtt xàà_srynmc . /gajalE]dQ id MW Ki:malin P mal f rra ez.1 . rra o~d 1 fil2 commuai.- . ChywraIE ds^yfies . Mie d ilrl¢le Crut nf ^ fie xrafiem, +rd -math ®YU .n 1m [Imi:à1imn 1 xlaaml%grml Iod -rod Ruidel hy wv Figure 8 : Configuration process overview Due to unstable syntax into XM2 configuration table, we propose a separate tool dedicated to this task and "easily" updatable to follow syntax evolutions.
6..2 rocess f~~r ar#tscl~ ~u r ~ Iaase Currently, our analysis raises many constraints and issues about an integrated tool able to generate the configuration/customisation tables. Thus, it seems necessary for the mock-up phase to manage parameters through their original form: ".h" or ".c" files. Official delivery will provide templates for each configuration table and this chapter gives guidelines about process to modify it. For each partition, integrator will find dedicated file for configuration parameters: - Mode Management & Dataloading : - IO-Server : ,,; These files have the same structure and number of parameters is limited. Taking care of parameters naming, it is easy to understand the modification process: /************************************************************************* ****** Header Comments ************************************************************************** ****/ /******************************************/ /*************** Includes *****************/ /******************************************/ /******************************************/ /************ Declaration Code ************/ /******************************************/ /******************************************/ /***** Pointers Initialisation Code *******/ /******************************************/ /******************************************/ /********** Initialisation Code ***********/ /******************************************/ : Value to set, if necessary : Value to set, if necessary ; keep consistence with data i : Value to set, if necessary ; keep consistence with data i const UInt32 11abl )rtSizes[e = { }; const UInt32 lIoDeyicesNumber = ; const UInt8 nnectionTable[e][ ] = /* dev0 deyl dev2 */ /* PortO - output */ {.,N', /* Portl - output */ {`,~ }; Table 12 - generic configuration table file came color came color Samples are delivered into BSW package such as described in §4.3. E .103 Proposai of process for industriat phase This process depends on several issues: - From integrator point of view, configuration tables must be independent from any coding language. - Management of parameters must be simple: after PoC phase, for the industrialisation phase, a tool should be proposed to manage parameters through a "friendly" MMI, helping integrator in its work... In order to provide an abstract view independent from any coding language, configuration parameters would be stored into XML files. To maximize consistency all along the project, we propose to use the same XML syntax for each parameter file: configuration or customization.
These files would be processed by a binary generator, using the XML file to generate the binary file. This generator will respect a modular architecture to allow future evolutions. 6.2 BASIC S«)FTWARE CONFIGURATION The BSW partitions binary delivered has to be integrated into XM partitions through XM configuration file to be executed.
Notice: binaries partition delivered (.binary) are pure binaries prefixed by a BSW header described in §3.5
6.2.1 MM&DL partition 6.2.1.1 Attrib unes MM&DL partition attributes should have the following values into the XM configuration file: - Partition ID = 0 - Image ID = 0 - Supervisor = yes - Boot = yes Cric XédL editar Biran tatar natrum cm' PYh m n:dify der îhegua^in ph:se ............... Iralim £_-- -: Cmle germent. alaplEd mfidLiguige . IE gereralm mat file ,m,sa ,eeded \~ n'aime ntckiefQ. iclugÀaFralin t . beJc d~ yr berge glmaecn Ica_ Ruser ideperc ert fonnul lx%ume . Analyse Sr mou. Buld nid data Imlel p LEq ro a -At math: ô 3- O ti. Figure 9 : Future configuration process 75 6.2.1.2 Configuration rules (2) For MMDL compatibility table and lash MAX number of section per partition 3(1) (1) Partition code, config table and custom table 6.2.1.3 Configuration table sMmU!MemOpznPort3!ze 48 b 256 b Yes sMmdlMemOpOutPortSize 48 b 10]2U Yes sMmdlLoadMemoryTimeout MAF) 1000 No MAF IMmdlStatusReportPeriod Conta!nsthe perioUof the GFMUstatus report ls No IMmdlBswStartTimeout 10 MAF No IMmdlBswShutdownTimeout 10 MAF No !oITimerounation Conta!nsthe umeaUocateU to Data NaU!ng acuvity. xm xm No vvm!e Data uaaU!ng !stke only one background acov!ty, value oftk!s parameter kas a low impact on MMoL Uekav!our. lt *Ul aUmw in the future others background acov!tyto UeexecuteU suck as soAC scruUU!ng for examp!e. This value kas to be equal to a MM&.oL umes!ot Uurauon (to be !nU!cateU !n us) In industrialisation pkasetk!s parameter*U! kaveto UefiUeU !n automaucaUy (Uy a parserforexamp!e) accon1!ngtoa preUefineU ru!epmv!UeU UyMM&.oL partition supplier. Notice: tk!s parameterUoesn't !mp!ya temporal sFlashMmdlErrorMemorylD Conta!nstke Memoryzo (defineU !n xm xm No tMmU!MemoryMapp!ngTaU!e)*kereMMoL *r!tesennr sRamMmdlCompatibilityMem xm xm No orylD tMmU!MemoryMapp!ngTaU!e Conta!ns numUer offuncoona! memory areas to be xm 70 No manageU by !ntegrator. sack index of this table Uefinesa Memoryzo. This table kasto kaveaU enmes po!nteU !nto pointed by sFlashMmdlErrorMemoryID parameter. This last area has to match the constraint indicated by (*). Entries contain the following information: StartAddress Start address of memory area NA NA NA Remark: for binary in Flash containing a BSW header, it has to indicate start of header Length Length of the memory area NA NA NA (*) >= 4bytes PartitionID ID of the partition this memory area belongs to NA NA NA defined in xm configuration file (optional) (*) = MMDL partition ID BinaryType Type of the binary. There are five types: NA NA NA - BINARY TYPE PARTITION CODE - BINARY TYPE CONFIG TABLE - BINARY TYPE CUSTOM TABLE - BINARY TYPE COMPAT TABLE - BINARY TYPE NONE (*) = BINARY_TYPE_NONE MemoryType Type of memory. There are three types: NA NA NA - MEMORY TYPE PROM - MEMORY TYPE FLASH - MEMORY TYPE RAM (*) = MEMORY_TYPE_FLASH tMmdlPartitionInformationTab Contains number of partition to be managed with the NA 8 Yes le following information ID ID of the partition defined in xm configuration file NA NA Yes Flash_PartitionCode_ Memory ID (defined in tMmdlMemoryMappingTable) of NA NA NA MemoryID partition code in Flash Flash_ConfigTable_M Memory ID (defined in tMmdlMemoryMappingTable) of NA NA NA emoryID configuration table in Flash (-1 if not available) Flash_CustomTable_ Memory ID (defined in tMmdlMemoryMappingTable) of NA NA NA MemoryID customisation table in Flash (-1 if not available) Ram_PartitionCode_ Memory ID (defined in tMmdlMemoryMappingTable) of NA NA NA MemoryID partition code in RAM Ram_ConfigTable_Me Memory ID (defined in tMmdlMemoryMappingTable) of NA NA NA moryID configuration table in RAM (-1 if not available) Ram_CustomTable_M Memory ID (defined in tMmdlMemoryMappingTable) of NA NA NA emoryID customisation table in RAM (-1 if not available) Active_In_Debug_Mo Indicates if partition is activated in DEBUG mode (0 if NA NA NA de not activated, 1 if activated). Not used for MMDL partition Monitored_Partitions Contains number of partition to be monitored. NA 7 No Indicated partitions will be monitored during GMPU startup and shutdown at a functional state level and at a XM state level otherwise. Entries contain the following information 1 ID ID of the partition defined in xm configuration file NA NA Yes tMmdlMemoryServiceConfig This table indicates authorized memory operation with NA NA NA regard to the different types of memory Load Contains authorized Load for PROM, FLASH and RAM NA NA NA (0 = unauthorized, 1 = authorized) Remark: Authorizations for Load are READ ONLY Dump Contains authorized Dump for PROM, FLASH and RAM NA NA NA (0 = unauthorized, 1 = authorized) Check Contains authorized Check for PROM, FLASH and RAM NA NA NA (0 = unauthorized, 1 = authorized) 6.2.1.4 Customisation parameters The only value provided in this table is not used. Presence of this table only aims at checking 6.2.1.5 Building option It is possible to compile the MMDL with several options: The mmdl_c£xml file in the MMDL directory allows modifying some behaviour. Ask the MMDL partition provider to set the right parameter for your MMDL delivery in the MMDL/mmdl_cf..xml. memory nb_char_checked_by_step="256" Atomic number of data to process during memory operation. (number of bytes to process between two mode management nb_char_copied_by_step="256" check. should be at least equal to a flash page size) Memop_slot_sync value="FALSE" Indicate if memory operation has to be synchronised with a MMDL slot. (i.e. put TRUE here if there is a timeout on the flash programmation) Other internal features configurable: stack length="8192" flash start="0x20000000" stop="0x20100000" driver="FLASH MAJOR" tm p_ra m addr="Ox602FE7EC' length="0x100000" Stack length to use in the MMDL. Flash memory configuration. Internai buffer description for memory operation. (Shall at least be equal to the length of the largest memory operation possible) 6.2.1.6 ~ umpatEbiiity para et rs .......................................................................... .......................................................................... .......................................................................... ..................... .......................................................................... .......................................................................... .......................................................................... ...................... . Xm version This parameter is the concatenation of Xm version, subversion and revision such as described here below: 1 0 1 xm version 1 xm subversion 1 xm revision 1 LSB 1 4 bytes 1 4 bytes 1 4 bytes 1 4 bytes 1 Example for Xm v2.2.2 1 0 1 2 1 2 1 2 1= 131586 The Xm version is available in the release document provided with Xm delivery Xm Abi Version This parameter is the concatenation of Xm Abi version, subversion and revision such as described here below: 1 0 1 abi version 1 abi subversion 1 abi revision 1 LSB 1 4 bytes 1 4 bytes 1 4 bytes 1 4 bytes 1 Example for Xm Abi v2.0.0 1 0 1 2 1 0 1 0 1= 131072 The Xm abi version is available in the xm-reference document (§1.1) provided with Xm delivery Xm Api Version This parameter is the concatenation of Xm Api version, subversion and revision such as described here below: 1 0 1 api version 1 api subversion 1 api revision 1 LSB 1 4 bytes 1 4 bytes 1 4 bytes 1 4 bytes 1 Example for Xm Api v2.0.0 1 0 1 2 1 0 1 0 1= 131072 The Xm api version is available in the xm-reference document (§1.1) provided with Xm delivery tMmdlBinariesPartitionInfotable Contains number of partition to be managed by BSW wrt version compatibility with the following information. AII partitions present into partition information of configuration table have to have an entry here Partition_ID ID of the partition defined in xm configuration file Reserved Reserved Partition code Major Major version of partition code version Partition code Minor Minor version of partition code version Configuration table Major Major version of configuration table version Configuration table Minor Minor version of configuration table version Customisation table Major Major version of customisation table version Customisation table Minor Minor version of customisation table version A partition can only have one configuration table and one customisation table. If not, the matching major and minor versions have to be set to O.
XM versions are provided through BSW package delivery. Partition code versions have to be provided by partition suppliers. Configuration tables versions and customisation tables versions have to be provided by integrator itself. During GPMU init, BSW check that all versions defined in current table match with those of present binaries. For XM, three versions are checked (Main, ABI and API). In the future, checks will be extended to the version of libxm used by a partition through additional data in the BSW header.
Remark: compatibility table binary has to have a BSW header even if major and minor versions are not used.
6:2,1.7 Ports configuration Here after are listed all port features. They have to be used while filling in the XM configuration file with regard to MM&DL partition and connection table. Sizes are linked to configuration table maximum values. It is up to integrator to populate the XM configuration file. GpmuStatus Port which provides the GPMU status report Sampling 88 NA GpmuConfiguratio Port which provides the GPMU configuration Sampling 96 NA n report CcReset Port which manages Reset Sampling 16 NA CcChangeMode Port which manages change mode Queuing 24 2 HsemChangeMode CcMemoryOpIn Port which manages Memory operation Queuing MMDI _Memory_In_Port 30 req u ests Size CcMemoryOpOut Port which provides Memory operation Queuing MMDI _Memory_Ou_Por 5 results t Size CcAck Port which provides acknowledgement Queuing 56 30 MonitoringPortl Ports which manages state of other Sampling 24 NA MonitoringPort7 partitions during GPMU init. Order is linked to monitored partition table 6:2,108 Memory mapping Here below is described the internai Mmdl memory mapping in RAM: 0x60200000 Partition Code 2042 KB 2MB MMDL Partition Configuration table 4 KB Ox603FE800 Customisation table 512 B Ox603FF800 Compatibility table 1536 B Ox603FFA00 It is possible for integrator to change the MMDL memory mapping on condition that it has the BSW generation tree. The following steps have to be performed to generate MMDL binaries fitted in with new memory mapping: 1) Choose new partition code RAM address with taking account of hardware constraint if any 2) Calculate addresses of tables without decreasing their memory spaces allocated. That means only partition code size can be decreased. 3) Calculate new RAM address and size of local temporary RAM for uploads with the three following constraints: - new area has to be placed just before configuration table - size has to be 16 bytes greater than the maximum upload authorized - start address has to take account of MMDL partition code binary size including .bss section to avoid memory overwritesi 4) Update MMDL binaries addresses in RAM in file ... /MMDL/SRC/CMN/INC/MmdlMemoryMapping.h 5) Update MMDL partition loader .../MMDL/MmdlLoader.lds with the new address for MMDL partition code 6) Update .../MMDL/SRC/CMN/INC/MmdlMemoryMapping.h with new addresses of MMDL tables 7) Update the MMDL temporary RAM address and size for uploads in ... /MMDL/mmdl_cf. xml 8) Update information linked to MMDL memory mapping in .../COMMON/SRC/bsw_cf.xml 9) Execute the script .../TOOLS/delivery/bsw_delivery.pl
This last step provides a bsw.tar.bz2 file which has to be extract at the appropriate location. It contains, among other things, MMDL partitions and tools to generate tables such as described in §3. Concerning Flash memory, sizes to be reserved for MMDL is 96 KB. Here after is detailed size for each MMDL binaries: - Partition code: 90 KB2 - Configuration table: 4 KB - Customisation table: 512 B - Compatibility table 1536 B
That means the MMDL partition code binary delivered within the BSW package has to be less than 90 KB including the BSW header (16 bytes). Respecting configuration rules defined in § 5.2.1.2 when building tables allows to ensure the size of binary generated will be lower than those indicated above.
6.2.1.9 Data e E nsistencv As shown in previous table, MM&DL partition shares few parameters with XM2. Integrator must take care about consistency of: - List of partitions including their characteristics and their ID - Characteristics of the input/output ports 6.2.2 10 Server a °tition 6.2.2.1_ A ttributes IO_SERVER partition attributes should have the following values into the XM configuration file: - Partition ID = 1 - Image ID = 1 - Supervisor = no - Boot = no
6.2.2.2 Dei>ice allocation The IOS server is a partition and as any other partitions its rights for accessing to hardware (devices) is described in the XM configuration file. (see R4) 1 You may want to use the gnu size command of the sparc-linux toolchain to know the whole partition size in RAM memory. 2 Remark : when compile in debug mode, MMDL partition need 110KB To enable IO devices use for IOS partition, the XM configuration file should be configured with IO ports range base address and the number of ports within this range as described below; Example with the simu device configuration: <HwResources> <IoPorts> <!-- UART Leon2 device driver --> <Range base="0x80000080" noPorts= "4"/>
<!-- Simu device driver --> <Range base="0x28080000" noPorts= "33024"/>
<!-- Simu device driver --> <Range base="Ox280AO400" noPorts= "33024"/>
<!-- Simu device driver --> <Range base="Ox28000800" noPorts= "33024"/>
<!-- Simu device driver --> <Range base="Ox280EOCOO" noPorts= "33024"/>
<!-- Simu device driver --> <Range base="0x28101000" noPorts= "33024"/>
<!-- Simu device driver --> <Range base="0x28121400" noPorts= "33024"/> </IoPorts> </HwResources> Example with the PIC/I2C and Spacewire device configuration: <HwResources> <IoPorts> <!-- UART Leon2 device driver --> "4"/> <Range base="0x80000080" noPorts= <!-- Simu device driver --> "33024"/> <Range base="0x28080000" noPorts= <!-- Simu device driver --> "33024"/> <Range base="Ox280AO400" noPorts= <!-- Simu device driver --> "33024"/> <Range base="Ox28000800" noPorts= <!-- Simu device driver --> "33024"/> <Range base="Ox280EOCOO" noPorts= <!-- Simu device driver --> "33024"/> <Range base="0x28101000" noPorts= <!-- Simu device driver --> "33024"/> <Range base="0x28121400" noPorts= <!-- SPW --> "10"/> <Range base="0x28000600" noPorts= <!-- Registre CPU ITAR FREE IOTOP --> <Range base="Ox2COOOOOO" noPorts= "1"/> <!-- IOTOP 12C --> .1./> <Range base="Ox2COOIOOO" noPorts= <Range base="Ox2CO02000" noPorts= .1./> 2970577 sl <Range base="Ox2C003000" noPorts= <Range base="Ox2COO4000" noPorts= <Range base="Ox2COO5000" noPorts= <Range base="Ox2COO6000" noPorts= <Range base="Ox2COO7000" noPorts= <Range base="Ox2COO8000" noPorts=
<!-- Registre LICE --> <Range base="Ox2COO9000" noPorts= "24"/>
<!-- 12C buffer addr register --> <Range base="Ox2COOE000" noPorts= "1"/>
<!-- Buffer DMA 12C --> <Range base="0x60000000" noPorts= "3072"/> </IoPorts> </HwResources> 6.2.2.3 IO S ~r Communication ports There are 3 kind of ARINC 653 queuing ports in the IO Server used to communicate with device: - RX port for reading data incoming from the device; - TX port for sending data to the device; - ACQ port for sending PMU acknowledgment message to client partitions. These ports must be first defined at the hypervisor level (for xm see xm_cf.xml file). For dealing with ports the configuration table must contains the following elements: Type Na me Description const UInt32 10utDataRxQueuingPortsNumber Number of RX port const Int8* cTableOutDataRxPortNames[] Table containing the names of the RX ports. The number of element must match 10utDataRxQueuingPortsNumber. const UInt32 1Tab1eOutDataRxPortSizes[] Table containing the length of the RX ports. The number of element must match 10utDataRxQueuingPortsNumber. const Ulnt8 cTableOutDataRxPortDepth Table containing the depth of the RX ports. The number of element must match 10utDataRxQueuingPortsNumber. const UInt32 11nDataTxQueuingPortsNumber Number of TX port const Int8* cTableInDataTxPortNames[] Table containing the names of the TX ports. The number of element must match IInD ataTxQueuingPortsNumber. const UInt32 1TablelnDataTxPortSizes Table containing the length of the TX ports. The number of element must match IInD ataTxQueuingPortsNumber. const Ulnt8 cTableInDataTxPortDepth Table containing the depth of the TX ports. The number of element must match 10utDataTxQueuingPortsNumber. const UInt32 10utDataAckQueuingPortsNumber Numer of ACQ port const Int8* cTableOutAckPortNames[] Table containing the names of the ACQ ports. The number of element must match 10utDataAckQueuingPortsNumber. const UInt8 cTableOutAckPortDepth Table containing the depth of the ACQ ports. The number of element must match 10utDataAckQueuingPortsNumber. In the configuration table, every reference to a port (in the MAF_IO_SchedulingPlanTable sequence table or in the routing tables) is based on an index in the tables. It is important to notice that for one index the 3 corresponding kind of ports shall be coherent. This mean that an acknowledgement service message on port at the index X correspond to the reading or the writing ports with the same index.
6.2.2.4 Devices description. One of the IO Server goals is to route data between arinc port and device. The previous paragraph explains how ports are identified. Here is how devices are identified. Devices are identified with two numbers: - a major number identifying the kind of hardware (cf §8.5); - a minor number identifying the instance number of this hardware. So the configuration table must have a table called DeviceDescriptionTable describing each device. Type Nome Description IoServerSDeviceDescription DeviceDescriptionTable Table containing a list of devices with its configuration Const UInt32 11oDevicesNumber Number of element in the DeviceDescriptionTable table. In the rest of the configuration table, devices will be identified (mainly in the MAF_IO_SchedulingPlanTable sequence table) according to the index in the DeviceDescriptionTable table Each device is descrbbed through a IoServerSDeviceDescription structure like this: Type Nome Description UInt32 1MajorNumber major number UInt32 1MinorNumber minor number IOS_EIoBehaviour eProtocol Indicate the type of behaviour of the device : MASTER_SLAVE when for reading it is first necessary to write a command to the device. STANDARD when reading and writing are not correlated. UInt32* pSpecParam Pointer to the device configuration. UInt32 u1RxTimeoutInUs RX Device timeout in NO WATT mode. The device configuration is a pointer to some data understood by a particular driver. You should refer to the driver's documentation for the content of this table (See R11 for TAGS meanings and their possible valuesErreur ! Source du renvoi introuvable.Erreur ! Source du renvoi introuvable.Erreur ! Source du renvoi introuvable.Erreur ! Source du renvoi introuvable.Erreur ! Source du renvoi introuvable.). The IO Server engine does not care of the format of these data by itself (drivers does care).
Examples of device configuration:
/* Stub device aka simu device */ UInt32 ConfDevSimuDevice [] [2] _ { {SPEED, 100000}, { RETRY, OFF}, { REDUNDANCY, OFF}, {LOOP_BACK_STATE, OFF}, {ALIGN, 4}, 1RX_FROM_LOOP_BACK, ON}, {END OF SPEC,O } };
/* Spacewire device */ UInt32 ConfSpw[][2] _ { { AUTOSTART,0 }, { LINKSTART,1 }, { MODE _EOP_TX,1 }, { MODE _EOP_RX,1 }, { TX_TIMECODE,O }, { RISEFALL,O }, {MODE TIME,O }, { EN_TX_TIME,0 }, {TICKS,0}, { CRC,CRC_ON }, { FORMAT,LITL_ENDIAN }, {END OF SPEC,O } };
/* I2C device */ UInt32 ConfI2c_1 [] [2] _ { { SPEED, 0 }, { ADRMOD, 0 }, {END OF SPEC,O } };
/* PIC device */ UInt32 ConfPic_1 [] [2] _ { { SPEED, 0 }, { ADRMOD, 0 }, {FILTRE IDE, 27 } , {END OF SPEC,O } }; :2,2. S 10 Server slot The IO server works in the context of an hypervisor using time and space partition. This means that the integrator schedules its execution. Each execution is called an IO server slot. The slot time and durations are defined at the hypervisor level (for xm see xm_cf.xml file). During a slot the IO Server is free to make several accesses to devices. 6,2.2°6 10 Server sequence Accesses to devices are called sequences whichever it is a READ or WRITE. Sequences are stored in order in the table called MAF_IO_schedulingPlanTable of the config table.
Here is the description of a sequence: The structure IoServerSMAFSequence is the following: Type Nam Description UInt32 1Port_Id Port index in the cTableOutDataRxPortNames (read access) or cTableInDataTxPortNames (write access) (cf. §6.2.2.3). Can be equal to ID _NA when not useful (see §6.2.2.8). UInt32 1Device Id Index of the device to use in the 11oDevicesNumber table (cf §6.2.2.4) IoEAccessType eAccessType READ or WRITE access (UNUSED_SEQ to make the sequence idle) UInt32 1SequenceDurationInUS Duration of this sequence (including sequence overhead and any optional additional timing. See performance documentation) UInt32 1MaxNumberOfBytesTo Number of bytes allowed to Transmit process in this sequence IoEWaitMode eWaitMode Sequence mode WAIT or NO WATT const I0S_SIoPortRoute spPortRoutingTable Optional routing table. NULL const * const when not used (cf §6.2.2.8) UInt16 sIsLastMIFSequence TRUE if this is the last sequence of an IO scheduling slot. UInt16 sIsAccessMultiCast Is multicast RX (cf §6.2.2.9) UInt32 u1XmAttachedSlot When the "check _xm_slot" option was enable at build time (cf §6.2.2.15) this force the IO to check that the current xm slot match this sequence field. So a sequence can be either a READ or a WRITE sequence. It occurs in WAIT or NO WATT mode. In WATT mode the transfer must be finish at the end of the sequence. 84 Seq x, READ on device y in WATT mode, 3ms and 1024 bvtes Return read data to client partition Seq x, WRTTE to device y in WATT mode, 3ms and 1024 bvtes Send acknowledgment data to client partition
In NO WATT mode the transfer is started during the sequence and finished in the next sequence. Seq x, READ on device Y in NO WATT mode,<Background READ Transfer Seq x +? , READ on device y in NO WATT mode, > > < lms and 1024 bvtes< lms and 1024 bvtes Return read data to client partition for Seq x, WRITE to device y in NO WATT mode, 86 < Background WRITE > Transfer Seq x +? ,WRITE to device y in NO WATT mode, > > < lms and 1024 bvtes< lms and 1024 bvtes Send acknowledgment data to client partition
In the NO WATT case: - Data are transferred between the two sequences in background so CPU is free during this time; - There should be enough time between two sequences dealing with the same physical device.
Beware that on some device it is possible to do parallelize (Spacewire for example) READ and WRITE whereas on others you have to sequence them (for I2C/PIC for example). This case need to be explicitly indicated in the IOS configuration table (cf. 6.2.2.13). Please refer to drivers manual for more information.
The data returned at the end of the sequence are sent according the first sequence configuration (not according the configuration of the current sequence).
So, the configuration table must have the following element for describing sequences: Type Naine Description IoServerSMAFSequence MAF_IO_SchedulingPlanTable Table containing sequences used for the internal scheduling of the IOS. const UInt32 1MafSequencesNumber Number of element in the DeviceDescriptionTable table. 6.2.2.7 IO SEver sE:heduler Sequences are all executed one after another. They are tiedly synchronized with the IO Server Slot : the MIF_end_flag of a sequence indicates if this must be the last sequence to execute in the current slot (ie it suspends the partition until its next slot).
6:2,2.£ Routing table A routing table shall be provided in the following case: - It is necessary to send (WRITE) a message to a specific address; - It is necessary to indicate to the driver what to READ on the distant device; - It is necessary to route received message (READ) to the relevant port according to an address embedded in the received message. - Otherwise, no routing table is needed. When no routing table is necessary, it shall be set to NULL and the lPort_Id field of the sequence properly configured: - In WRITE sequence: to the port with the client partition where the message to send was stored. - In READ sequence: to the port with a client partition that is able to receive message from the configured device
Routing Table structure A routing table is a table of IOS_SIoPortRoute structure: Type Name Description UInt32 ulPort Index of a port corresponding to the address UInt32 ulAddress Physical address corresponding to the port For example : const I0S_SIoPortRoute spw_route _table _rx[] = { /* I0S port index TO USE with the address provided BY THE driver */ { .ulPort 3, .ulAddress 14 1, { .ulPort 5, .ulAddress 15 1, { .ulPort 4, .ulAddress 16 1, { .ulPort LAST_ROUTE 1 1; Notice that the end of a routing table must end with a port filed set to LAST_ROUTE. Routing TX In case of WRITE operation where a destination address shall be provided, the 1Port _Id shall be set to the index of port where a message to send can be found (index in cTableInDataTxPortNames). Then according to the 1Port _Id index, the IO Server will look for a corresponding destination address in the routing table and send the message at this address. Pre-routing RX address mode On some device IO Server is the master of the read communication. This means that it knows what to read according to the READ sequence. In this case the 1Port _Id points in the configuration to a physical address where it is necessary to read. Post-routing RX address mode In this case the 1Port Id field is not used and shall be set to ID _NA. A routing table shall be provided and the received messages are routed to the right port according to the physical destination address found in the message. 6,2.2°9 Multicast RX When this flag is set for a sequence, the IO server expect to find a routing table in the sequence description and, instead of routing to a specific ports as describe in the previous paragraph, the messages are routed to all the port found in the routing table regardless to physical addresses. Remark: can be used also in conjunction with the pre-routing mode. 6.2.2.10 Timeout The READ or WRITE process of a sequence will not last longer that what was defined in the 1SequenceDurationInUS field of the sequence. In NO WATT mode, the maximum allowed time for the reception (READ) of an entire message (from the first byte received to the last message one) is limited by the value of the field u1RxTimeoutInUs in the description of the device In NO WATT mode, the maximum allowed time for sending a message in background (WRITE) is the time between two WRITE sequences. (Previous write transfer on a device must be finished when a new WRITE sequence start)
6.2.2.11 Aekrtt~wledgment Acknowledgments are forwarded to the corresponding ACQ port in case of successful WRITE of a TX port on a device.
There are no acknowledgment sent on reception (received data are forwarded on the relevant RX port). In case of error during a READ or a WRITE process, a bad acknowledgment is sent on the relevant port. In this case the internal error code value is set to one of the value defined in 8.3.
6.2,2.12 Configuration iules. Parameter Description Value OUT_DATA_RX_QUEUING_PORTS_MAX_N Maximum number of output queuing 10 UMBER ports dedicated to Data Rx sub-service. IN_DATA_TX_QUEUING_PORTS_MAX_NUM Maximum number of input queuing ports 10 BER dedicated to Data Tx sub-service. OUT_DATA_ACK_QUEUING_PORTS_MAX_ Maximum number of output queuing IN_DATA_TX_QUE NUMBER ports dedicated to acknowledgment sub- UING_PORTS_MAX service. _NUMBER OUT_DATA_RX_PORT_MAX_MSG_SIZE Maximum message size allowed for 1036 + 16 output Data Rx queuing ports. OUT_DATA_RX_PORT_MIN_MSG_SIZE Minimum message size allowed for 16 output Data Rx queuing ports. IN_DATA_TX_PORT_MAX_MSG_SIZE Maximum message size allowed for input 1036 + 16 Data Tx queuing ports. IN_DATA_TX_PORT_MIN_MSG_SIZE Minimum message size allowed for input 16 Data Tx queuing ports. OUT_DATA_ACK_QUEUING_PORTS_MSG_ The message size of output queuing ports PMU_HEADER_LEN SIZE dedicated to acknowledgment sub- GTH + service. BSW ACK DATA P This size is the same for all these ports. AYLOAD_LENGTH Table 1- Source code configuration description 6.2.2.13 Configuration gable This chapter indeicates the configuration table parameter limitation and some example of configuration parameters. 10utDataRxQueuingPortsNumber IInDataTxQueuingPortsNumber 10utDataAckQueuingPortsNumber cTable0utDataRxPortNames cTableInDataTxPortNames cTable0utAckPortNames ITableOutDataRxPortSizes ITableInDataTxPortSizes number of output queuing ports dedicated to Data Rx sub-service number of input queuing ports dedicated to Data Tx sub-service number of output queuing ports dedicated to acknowledgment sub-service
This parameter must be equal to IInDataTxQueuingPortsNumber. names of output queuing ports dedicated to Data Rx sub-service names of input queuing ports dedicated to Data Tx sub-service names of output queuing ports dedicated to acknowledgment sub-service sizes of Data Rx output queuing ports This size must be a multiple of 4. sizes of Data Tx input queuing ports.
These sizes must respect the constraints defined in the source code configuration table (min/max) and they must also be a multiple 0 10 Yes 0 10 Yes 0 10 Yes String Yes String Yes String Yes 16 1048 Yes 16 1048 Yes of 4 cTableOutDataRxPortDepth Table containing the depth of the RX ports. [1 2^32-1[ YES The number of element must match cTableInDataTxPortDepth Table containing the depth of the RX ports. [1 2^32-1[ YES The number of element must match cTableOutAckPortDepth Table containing the depth of the ACQ ports. [1 2^32-1[ YES The number of element must match IIoDevicesNumber number of IO devices to use through IO 1 2^32-1[ No Server DeviceDescriptionTable (Z) IO devices configuration table No Major Major ID of device 0x20/0x30 No Minor Minor ID of device 0 1 5 No eProtocol( 3) Type of behaviour of the device STANDARD / No MASTER_SLAVE DeviceConfiguationTable (4) Device configuration table 1 No Redundancy Redundancy capability (For simu device) ON/OFF No Speed Baudrate in bauds No Loopback state Loopback capability ON/OFF No Loopback dev ID Connection dev ID (only if Ioopback capability 0 5 No ON) Flow control Flow control capability (only for UART device) OFF No Align Device segmentation (bytes) (For simu No device) Retry Retry capability (For simu device) ON/OFF No Rx from Ioopback Rx from Ioopback capability (For simu device) ON/OFF No Rx FIFO Iength Rx FIFO Iength (bytes) (For simu device) No Tx FIFO Iength Tx FIFO Iength (bytes) (For simu device) No Depend on the driver (see driver user No manual) ulRxTimeoutInUs RX Device timeout in ps for NO_WAIT mode. 1 2^32-1[ No IMafSequencesNumber Number of MAF sequences in the scheduling 1 2^32-1[ No plan table MAF_I0_SchedulingPlanTable (5) IO Server scheduling plan table No Port ID See ConnectionTable (input or output port 0 9 No index) IO device ID See ConnectionTable (IO device index) 0 5 No Access type Access type (READ/WRITE/ UNUSED) READ/WRITE/ No UNUSED_SEQ Sequence duration Sequence duration (ms) No Number of bytes to transmit Set to device FIFO Iength in bytes (RX or Tx) No (Tx or Rx) eWaitMode Acces mode (WAIT / NO_WAIT) WAIT / NO_WAIT No const I0S_SIoPortRoute const spPortRoutingTable Pointer or Null No * const MIF end flag Flag of end of MIF (End = TRUE) TRUE/FALSE No Multicast access flag Flag of multicast (MULTICAST = TRUE) TRUE/FALSE No Xm Attached Slot Id of the XM slot number this sequence is 0 2^32-1 attached (2) The device description table is limited by the number of devices (NUMBER_OF_ IO_DEVICES).The conf device table depends on the device type.
Here is an example of a device description table: const IoServerSDeviceDescription DeviceDescriptionTable[] _ { {0x12, 0, SIMU, &ConfDeVSimu0[0][0], 10001, /* 38400 */ {0x12, 1, SIMU, &ConfDevSimul[0][0], 10001, /* 115200 */ {0x12, 2, SIMU, &ConfDevSimu2[0][0], 10001, /* 19200 */ {0x12, 3, SIMU, &ConfDevSimu3[0][0], 10001, /* 200000 */ {0x12, 4, SIMU, &ConfDevSimu4[0][0], 10001, /* 100000 */ {0x12, 5, SIMU, &ConfDevSimu5[0][0], 10001 /* 100000 */ 1; NB: In "DeviceDescriptionTable", the parameter "Type" is not used anymore and could have been set to O.
The device characteristics are defined in a device configuration table.
(3) The protocol field indicates if there is a direct link between a write and a read. A MASTER_SLAVE device necessitates finishing any read/write command prior to start a new read of write. Whereas, standard devices can parallelize read and write commands. (4) The device configuration table depends on the device type. Here is an example of information contained in this table for a simulator device: UInt32 COnfDeVSimu0[][2] = { {SPEED, 1152001, {RETRY, OFF}, {REDUNDANCY, OFF}, {LOOP_BACK_STATE, OFF}, {ALIGN, 4}, 5121, {RX_FIFO_LENGTH, {TX_FIFO_LENGTH, 1281, {END_ OF_SPEC,O} }; Here is an example of information contained in this table for the UART device: UInt32 ConfDevBoard[][2] = { {SPEED, 1152001, {LOOP_BACK_STATE, ON}, {FLOW_CONTROL, OFF}, {END_ OF_SPEC,O} }; See configuration samples file provided in package described in §4.3 for more information.
NB 1: For a simulator device, the parameter ALIGN represents device alignment constraints, for example, if a device driver requires sending and receiving 4-bytes data, then parameter ALIGN should be set to 4.
NB2: For a simulator device, the parameter RETRY allows enabling or disabling retry function for the specified device. When RETRY is set to ON, this function is only enabled at device register level, ie that no software retry mechanism is implemented. (Only device register is updated)
For other device configuration table see the relevant device driver manual. (5) The scheduling plan table is limited by the number of sequences (1MafSequencesNumber). Here is an example of scheduling plan: const IoServerSMAFSequence MAF_IO_SchedulingPlanTable[] _ { /* IOS Mif_0 */ {0, 0, WRITE, 6 ms, 2 kb, SYNC_MODE, spw_route_table_tx, FALSE, FALSE }, {IOS_NA, 0, READ, 4 ms, 976, SYNC_MODE, spw_route_table_rx, FALSE, FALSE {1, 1, WRITE, 2 ms, 2 kb, SYNC_MODE, spw_route_table_tx, FALSE, FALSE }, {IOS_NA, 1, READ, 2 ms, 512, SYNC_MODE, spw_route_table_rx, FALSE, FALSE {2, 2, WRITE, 4 ms, 2 kb, SYNC_MODE, spw_route_table_tx, TRUE, FALSE }, /* IOS Mif_1 */ {3, 3, WRITE, 5 ms, 2 kb, SYNC_MODE, spw_route_table_tx, FALSE, FALSE }, {4, 4, WRITE, 8 ms, 2 kb, SYNC_MODE, spw_route_table_tx, FALSE, FALSE }, {5, 5, WRITE, 9 ms, 2 kb, SYNC_MODE, spw_route_table_tx, FALSE, FALSE }, {1, 1, WRITE, 5 ms, 2 kb, SYNC_MODE, spw_route_table_tx, TRUE, FALSE }, /* IOS Mif_2 */ {IOS_NA, 0, READ, 5 ms, 976, SYNC_MODE, spw_route_table_rx, FALSE, FALSE {IOS_NA, 1, READ, 3 ms, 512, SYNC_MODE, spw_route_table_rx, FALSE, FALSE {2, 2, WRITE, 1 ms, 2 kb, SYNC_MODE, spw_route_table_tx, TRUE, FALSE }, /* IOS Mif_3 */ {IOS_NA, 2, READ, 5 ms, 512, SYNC_MODE, spw_route_table_rx, FALSE, FALSE {0, 0, WRITE, 4 ms, 2 kb, SYNC_MODE, spw_route_table_tx, FALSE, FALSE }, {2, 2, WRITE, 4 ms, 2 kb, SYNC_MODE, spw_route_table_tx, TRUE, FALSE }, /* IOS Mif_4 */ {3, 3, WRITE, 5 ms, 2 kb, SYNC_MODE, spw_route_table_tx, FALSE, FALSE }, {IOS_NA, 3, READ, 3 ms, 512, SYNC_MODE, spw_route_table_rx, FALSE, FALSE {4, 4, WRITE, 7 ms, 2 kb, SYNC_MODE, spw_route_table_tx, FALSE, FALSE }, {IOS_NA, 5, READ, 5 ms, 512, SYNC_MODE, spw_route_table_rx, FALSE, FALSE {5, 5, WRITE, 2 ms, 2 kb, SYNC_MODE, spw_route_table_tx, TRUE, FALSE } } ; In this example, 5 IOS MIF (End of IOS MIF flag set to TRUE) of different durations: - t(MIF_0) = 18ms - t(MIF_1) = 27ms - t(MIF_2) = 10ms - t(MIF_3) = 9ms - t(MIF_4) = 22ms IOS MIF duration corresponds to the sum of sequences duration of the IOS MIF: - For IOS MIF 0: 6+4+2+2+4=18ms NB3: The time of switch between 2 consecutive sequences is about 50us The number of bytes to send or receive represents FIFO size: - For Tx, requests sizes shall not exceed this number to prevent device FIFO being full. - For Rx, it is device FIFO size. NB4: This parameter should be set to device fifo length unless integrator wants to limit the number of data to send (or receive) during the sequence. For example, if we want to prevent IOS from sending more than 1Kbyte for a given sequence, then this parameter should be set to 1024. NB5: If a client partition sends a DataTx message request to IOS, then Tx message payload size should not exceed the value of the parameter "Number of Bytes to Transmit", otherwise payload data cannot be sent during the given sequence. /!\ : Sequence duration always elapses whatever read or write transaction results (success, failure etc). If the number of bytes to transmit is not compatible with Tx requests payload sizes, (for example fewer than payload size), then the message remains in IOS internal buffer until next sequence allocated to such transaction. (defined by: port _id/device _id/access_type). IO scheduler will not manage the following sequence as long as current sequence duration did not elapse. Scheduling plan sequences durations are always respected whatever transactions result. See configuration samples file provided in package described in §4.3 for more information. 6:2,2.1.4 Customis,atiE n parameters N/A. 6.2.2.15 Building option It is possible to compile the IOS with several options: The ios_cf.xml file in the IOS directory allows modifying some behaviour of the IO server. Ask the IOS partition provider to set the right parameter for your IO server delivery in the IO SERVER/ios cf..xml. }, }, Some lice traces can be activated also by the IOS partition provider: ios_trace_init ="TRUE" Enable/Disable the configuration table analysis and internai initialization 0 traces; ios_seq_num ="TRUE" Enable/Disable the sequence number traces; 4 ios_seq_status ="TRUE" Enable/Disable the sequence status; 5 ios code drv ="TRUE" Enable/Disable the traces of the driver results; 6 ios_code_engine ="TRUE" Enable/Disable the traces of interal I0S error code; 7 ios_perf ="TRUE" Enable/Disable the traces for measuring performances. 8 ios_data_ength ="TRUE" Enable/Disable the traces of the length received. 9 Some security features can be also deactivated: rx_pre_routing value="TRUE" dynamic_tx value="TRUE" pic_perf_measure_patch value="FALSE" lice marks value="TRUE" Enable/Disable pre-routing feature (needed for master/slave devices) Enable/Disable dynamic TX feature (searching for candidate port with data to send) Patch the PIC driver to allow perf measure TRUE to route lice traces to HW or FALSE on to route to the simulator. HwSwSupport value="FALSE" base="0x51" Activation/deactivation of HSEM support. Customization of the I0S events offset. display_binary_timestamp value="TRUE" Display I0S build date on UART A on startup. trap_on_sequence_overrun value="TRUE" trap_on_slot_overrun value="TRUE" check_xm_slot value="TRUE" trap="TRUE" pic_perf_measure_patch value="FALSE" lice marks value="TRUE" Enable/Disable trap in case of sequence overrun Enable/Disable trap in case of slot overrun Enable/Disable slot mismatch detection (sequence not executed in the right xm slot). Patch the PIC driver to allow perf measure TRUE to route lice traces to HW or FALSE on to route to the simulator. Other internal features configurable : ;;;:~. -; .:~-:}:':{.:].~':(~ :.::::::::::::::::::.i:-i:-i:-i:-i:-i:-i:-i:-i:-i:-i:-i:-i:-i:-i:-i:-i:-i: -i:-i:-i:-i:-i:-i:-i:-i:-i:^:^:^:^:^:^:^:^:~^:~i .......................................................................... .......................................................................... .......................................................................... .............................. .......................................................................... .............................................. .......................................................................... .......................................................................... .......................................................................... ............................. :... stack length="8192" Stack length to use in the I0S signature value="Ox24494f54" I0S configuration table signature patern config_table_interface="2" Version number of the configuration table format 6.2.2.16 Ports configuration Here after are listed all ports' features. They must be used while filling in the XM configuration file with regard to IO Server partition and connection table. Names and sizes are linked to configuration table values. It is up to integrator to populate the XM configuration file. Display0bs Port which provides observables Sampling 428 NA DisplayStatus Port which provides the functional state Sampling 16 NA of IO Server cTable0utDataRxPortNames Ports which manage Data Rx packets. Queuing ITableOutDataRx 10 PortSizes cTableInDataTxPortNames Ports which manage Data Tx requests. Queuing ITableInDataTxP 10 ortSizes cTable0utAckPortNames Ports which provide acknowledgement Queuing 56 10 6:2,201` Memory mapping Here below is described the internal IoServer memory mapping in RAM: Ox60000000 256 IO Server Partition Code 240 KB KB Partition Configuration table 16 KB Ox600FC000 It is possible for integrator to change the IO Server memory mapping on condition that it has the BSW generation tree. The following steps have to be performed to generate IO Server binaries fitted in with new memory mapping: 1) Choose new partition code RAM address with taking account of hardware constraint if any 2) Calculate addresses of table without decreasing its memory space allocated. That means only partition code size can be decreased. 3) Update information linked to IO Server memory mapping in ... /COMMON/SRC/b sw_c£xml 4) Execute the script .../TOOLS/delivery/bsw_extract.pl
This last step provides a bsw.tar.bz2 file which has to be extract at the appropriate location. It contains, among other things, IO Server partitions and tools to generate table such as described in §3.
Concerning Flash memory, sizes to be reserved for IO Server binaries is 40 KB plus 14 KB per device. Here after is detailed size for each IO Server binaries: - Partition code: 51 KB - Configuration table: 16 KB 6.2.2.18 Data consisteney Most of IO-server parameters are strongly linked to XM2 parameters. IO-Server provides interface capabilities through a list of ports. These ports are defined in IO-Server configuration but they must be consistent with XM2 configuration.
6.3 GLOBAL SI/STEM MAGE To ensure the well GMPU start up. Integrator has to follow the here after steps:
Pre-requisite: integrator has to take in account needs of partition suppliers and then has to allocate them RAM locations to be executed.
When performing the following steps, all partition binaries (including XM core) constituting the global system and tools to generate tables must have been got.
1) Get size needs in Flash for all partitions including tables if any in correspondent user manuals (BSW User Manual for MMDL and IO Server) 2) Create the notional global mapping in Flash with taking account of previous constraints 3) Check that notional needs in RAM for all partition are compliant. Information has to be present in correspondent user manuals. 4) Generate all needed tables (MMDL configuration table has to be filled in thanks to the previous mapping) including Xm configuration table with the correspondent tools and user manuals 5) Place XM core and XM configuration table without BSW header in Flash such as described in the previous mapping. XmPack delivered with XM package could be used for this step 6) Place all binaries (with a BSW header) managed by MMDL in Flash (partitions and their tables if any) as described in the previous mapping including MMDL binaries themselves. XmPack delivered with XM package could be used for this step 7) Place XM core and XM configuration table in RAM without a BSW header. XM core location in RAM is available in core_config file provided in BSW package. XM configuration table location in RAM is available in XM core binary itself such as described in xm user manual §5.3.1 RSW delivered with XM package could be used for this step (on condition that XmPack has been used for step 5) 8) Place MMDL binaries (without a BSW header) at the start of their correspondent location in RAM RSW delivered with XM package could be used for this step (on condition that XmPack has been used for previous step 6) 9) The GPMU is now ready to start. Jump to XM entry point. Address is available in XM core binary itself such as described in xm user manual §5.3.1
6.4 .BOOT.L Of1,D.ER (R S VV)
6.4.1 Behaviour of the resident software The resident software (bootloader) is provided with XM2. The aim of this test resident software is to put the memory in a correct state for starting XM2: - Load the hypervisor with its configuration table ; - Load any bootable partition data. So, the RSW copy each binaries of the container to its relevant address in RAM without copying MMDL headers. Then it jumps to the entry point address of XM2. This bootloader relies on the XM2 header at start of each partition to know where to load partitions and its additional binaries (See XM2 user manual for the definition of the xmImageHdr structure). In case of error inside the resident a trace starting with "[RSW]" is outputted on the UART A and describes the problem (area overwriting, bad partition signature, no hypervisor found, no hypervisor configuration found,... ). Otherwise, nothing is outputted and you should consider that the control was given to XM2. There is more information about its configuration in the XM2 user manual. 6.4.2 B~ afro° the BSW There is no obligation to use a dedicated boot loader and BSW and XM2 does not rely on a specific flash packaging tools. But to be able to boot XM2 and the BSW some rules exist: - XM2 expects to find its configuration table at the proper RAM address and when it starts (see below how to know the address). - XM2 expects to find the bootable partitions at relevant addresses in RAM according what is defined in its configuration table. - BSW expects to find non-bootable partitions in FLASH according to MMDL configuration file. There are also some binary format requirements: - Any binary must be pure binary (not "elf" file) - Any binary element in RAM must not be prefixed with a MMDL header. - Any partition and binaries belonging to those partitions must be prefixed by MMDL a BSW header (see§4.5) when stored in FLASH So, boot loader must not copy the S W header from FLASH memory to RAM. The address where to load XM2 in RAM is configured at XM2 compilation (usually 0x40000000 in make menuconfig). In case of doubt, the header of XM2 binary is using an xmImageHdr structure (see XM2 user manual). Among other information, this structure indicates the following necessary things for the configuration process of a bootloader: - Offset 0x00: contains "$XMH" : the XM2 signature; - Offset 0x14: XM2 address in RAM (base address); - Offset Ox1C: RAM address for jumping to XM2 (entry point); - Offset 0x24: RAM address where configuration table must be loaded. ,IMIT AT'IONS .......................................................................... .......................................................................... .......................................................................... .............................. . .......................................................................... .......................................................................... .......................................................................... .............................. . BSW V2.2 is a final version. Some limitations exist. These limitations are described hereafter and belong to several categories: design, validation, or usage. More that limitations the present chapter tries to give a snapshot of the BSW V2.2. 7,1 LIMITA l'IONS ON DESIGN The following table gathers limitations of the BSW V2 design: .......................................................................... .......................................................................... .......................................................................... ..................... . . . .;:.;:.; : .......................................................................... .......................................................................... .......................................................................... ...................... .......................................................................... .......................................................................... .......................................................................... ..................... .......................................................................... .......................................................................... .......................................................................... ...................... Upload max = 1 MB (') If Upload > 1 MB, upload refused (*) The other memory operations like check or dump have no limitation except the ones defined by MMDL configuration table settings o memory mapping field.
The XM2 limitations are listed in R5. 7,2 LIMITATIONS ON VALIDATION 7.2.1 Mention mapping The BSW V2 has been validated with the following SDRAM memory mapping: 256 XM2 512kB 0x40000000 512 0x40040000 768 Test Partition 256kB 0x60080000 1024 IOS 256kB Ox60000000 2304 MMDL Partition 2MB 0x60200000 2560 0x60240000 2816 0x60280000 3072 Ox602C0000 3328 0x60300000 3584 0x60340000 3840 0x60380000 4096 Ox603C0000 Configuration tables of XM2, MMDL and IOS are contained in their respective memory ranges. Sizes of MMDL and IOS tables are limited through their source code configuration file.
The memory mapping previously defined takes account of LEON2 limitation due to WPR (Write Protection Register) mechanism which implies that: - the memory allocated to the partition must be align to the size of the partition - the smallest partition size shall be 32 Kb - the size shall be a power of 2 See XM2 limitations in R5 for more details
Anyway XM2 core, MMDL, IOSERVER and Test Partition binaries can not be moved without having been recompiled. 7:202 SimLEON target SimLEON is used for validation in order to demonstrate the good behaviour of BSW V2 on the features not testable on Itar-Free board because of the Itar-Free board limitations.
SimLEON has the following limitations of representatively: o Writing in PROM is possible o There is no emulation of the FPGA chip.
7:203 Test Partitions The following limitations on validation are introduced by the test partitions behaviour: It is impossible to use instance of MMDL test partition and MMDL partition simultaneously with one or several external partitions client of MMDL partition It is impossible to use instance of MMDL test partition and MMDL partition simultaneously with one or several external partitions client of MMDL partition "BSW+CCSW" has been out-of-scope during Test Partition design. Test Partition is used to stimulate the BSW through standard BSW interface, the same interface than the one used by CCSW. "BSW+CCSW" has been out-of-scope during Test Partition design. Test Partition is used to stimulate the BSW through standard BSW interface, the same interface than the one used by CCSW. It is impossible to use instance of IOS test partition and IOS partition simultaneously with one or several external partitions client of IOS partition It is impossible to use instance of Multi-partitions test partition, IOS partition and MMDL partition simultaneously with one or several external partitions client of MMDL or IOS partitions It is impossible to use instance of IOS test partition and IOS partition simultaneously with one or several external partitions client of IOS partition
It is impossible to use instance of Multi-partitions test partition, IOS partition and MMDL partition simultaneously with one or several external partitions client of MMDL or IOS partitions "BSW+CCSW" has been out-of-scope during Test Partition design. Test Partition is used to stimulate the BSW through standard BSW interface, the same interface than the one used by CCSW.
ANNEXE ....................................................................... ........................................................................ 8.1 PRODUCT LIMIIA LIONS Product limitations are: - IOS does not support shutdown functionalities when using I2C, PIC or Spacewire driver. (driver interface not fully compatible with SSIS). - When using lice trace with IOS partition there is possibility to disable the traces coming form the drivers. - Whatever the parent partition lices traces relative to a SSIS driver always use the code 49,50 and 51. Following is the simulator configuration : - user event nb : 30 - conf reg : celui de l'AT697E par défaut - la fréquence : 12.5 (80MHz) - fonctionnalités (enable/disable) - memory failure/edac : enable - trace : disable - gdb : disable - breakpoint : enable - watchpoint : disable - trace écriture MEC : enable - Configuration des devices : ceux de l'AT697E - Configuration mémoire : Zone 1 . - managed (SDRAM) - adresse de départ : 0x60000000 - taille en octets : 16 Mo - Permissions de la zone - read : - 8 . true - 16 . true - 32 . true - 64 . true - write . - 8 . true - 16 . true - 32 . true - 64 . true - swap : - 8 . true - 32 . true - exec : true - cache : - instruction . - cachable : yes - prefetch : yes - data : - cachable : yes - timings - read : - 8 : 76 cycles - 16 : 76 cycles - 32 : 76 cycles 98 - 64 : 152 cycles - write : - 8 : 152 76 cycles - 16 : 152 76 cycles - 32 : 76 cycles - 64 : 152 cycles - exec : - begin burst : 75 cycles - continue burst : 75 cycles - end burst : 76 cycles - accès sans burst : 76 cycles Zone 2 : - managed (SRAM) - adresse de départ : 0x40000000 - taille en octets : 5 Mo - Permissions de la zone - read : - 8 : true - 16 : true - 32 : true - 64 : true - write : - 8 : true - 16 : true - 32 : true - 64 : true - swap : - 8 : true - 32 : true - exec : true - cache : - instruction : - cachable : yes - prefetch : yes - data : - cachable : yes - timings - read : - 8 : 6 cycles - 16 : 6 cycles - 32 : 6 cycles - 64 : 12 cycles - write : - 8 : 12 6 cycles - 16 : 12 6 cycles - 32 : 6 cycles - 64 : 12 cycles - exec : - begin burst : 5 cycles - continue burst : 5 cycles - end burst : 6 cycles - accès sans burst : 6 cycles Zone 3 : - I/O (registres FPGA) - adresse de départ : 0x28000000 - taille en octets : 64 Mo - Permissions de la zone - read : - 8 : true - 16 : true - 32 : true - 64 : true - write : 0 - 8 : true - 16 : true - 32 : true - 64 : true - swap : - 8 : true - 32 : true - exec : false Zone 4 : - managed (flash SPI - partie RSW + uploads MMDL) - adresse de départ : 0x20000000 - taille en octets : 4 Mo - Permissions de la zone - read : - 8 : true - 16 : true - 32 : true - 64 : true - write : - 8 : false - 16 : false - 32 : false - 64 : false - swap : - 8 : false - 32 : false - exec : true - cache : - instruction : - cachable : no - prefetch : no - data : - cachable : no - timings - read : - 8 : 17730 cycles - 16 : 17730 cycles - 32 : 17730 cycles - 64 : 35460 cycles - write : - 8 : N/A - 16 : N/A - 32 : N/A - 64 : N/A - exec : - begin burst : 17730 cycles - continue burst : 17730 cycles - end burst : 17730 cycles - accès sans burst : 17730 cycles Zone 5 : - managed (PROM) - adresse de départ : 0x00000000 - taille en octets : 128 octets - Permissions de la zone - read : - 8 : true - 16 : true - 32 : true - 64 : false - write : - 8 : false - 16 : false - 32 : false - 64 : false 1 swap : - 8 : false - 32 : false exec : true cache : instruction : - cachable : yes - prefetch : no data : - cachable : no timings read : 8 : 30 cycles 16 : 30 cycles 32 : 30 cycles 64 : N/A write : 8 : N/A 16 : N/A 32 : N/A 64 : N/A exec : begin burst : 30 cycles continue burst : 30 cycles end burst : 30 cycles accès sans burst : 30 cycles 8.3 IWMDL 'A !:RROR CODE VALUES 7 {'f ID Mme Description 0 MMDL_NO_ERROR No error 1 MMDL_EMPTY_PORT Port scanned is empty 2 MMDL_PARAM_ERROR One or more parameters contained in tables are not valid facing source code configuration 3 MMDL_SAMPLING_PORT _CREATION_ERROR Error during sampling port creation 4 MMDL_QUEUING_PORT _CREATION_ERROR Error during queuing port creation MMDL_ PORT _WRITING_ERROR Error while writing into a port MMDL_ PORT _READING_ERROR Error while reading into a port 7 MMDL_MEMORY_REQUEST_ERROR Error while analyzing memory request 8 MMDL_XM_PARTITION _GET_STATUS_ERROR Error while getting XM partition status of a partition 9 MMDL_ PARTITION _GET_STATUS_ERROR Error while getting functional partition status MMDL_ CHANGE_ MODE_ PORT _ACCESS_ERROR Change mode port access error 11 MMDL_RESET_PORT _ACCESS_ERROR Reset port access error 12 MMDL_ACK_PORT _ACCESS_ERROR Ack port access error 13 MMDL_ MODE _UNKNOWN_ERROR Unknown mode asked 14 MMDL_ CHANGE_ MODE _NOT_ALLOWED_ERROR Change mode asked not allowed MMDL_SAME_MODE _ERROR Same mode asked 16 MMDL_ PARTITION _HALT_ERROR Error while halting a partition 17 MMDL_ PARTITION _SHUTDOWN_ERROR Error while shutdowning a partition 18 MMDL_MASK_ERROR Error while while masking IT 19 MMDL_UNMASK_ERROR Error while while unmasking IT MMDL_RESET_ERROR Error while resetting 2 21 MMDL _INIT_ERROR Error during MMDL initialisation 22 MMDL_ RESET_UNKNOWN_ERROR Reset type asked unknown 23 MMDL _RESET_WHILE_COPYING_IN_FLASH _ERROR Reset asked while a copy in flash is processing 24 MMDL_ RESET_NOT_PERFORMED_ERROR Reset not performed 25 MMDL_ CHANGE_ MODE _UNKNOWN_ERROR Mode asked unknown 26 MMDL _WRITE_CONFIG_ERROR Error while writing current configuration 27 MMDL _IRQ_NOT_MANAGED_ERROR Irq received not managed 28 MMDL _PARAMETER_ERROR Function parameter not valid 29 MMDL _LOAD_PARTITION _ERROR Error while loading a binary from Flash to RAM 30 MMDL _LAUNCH_PARTITION _ERROR Error while launching a partition 31 MMDL _PARTITION _STATE_ PORT _ACCESS_ERROR State port access error 32 MMDL_ BAD_MEMORY_ID_ERROR Memory ID not valid into tMmdlPartitionInfoTable from MMDL config table. Too large or < -1 33 MMDL _BAD_BINARY_ TYPE _MEMORY_TYPE _ERROR Binary or memory type is incorrect into tMmdlMemoryMappingTable 34 MMDL_ BAD_ PARTITION_ ID_ERROR partition ID is different between areas in Flash and in RAM for a same binary 35 MMDL _BINARY_LENGTH_ERROR Binary length got into BSW header of a binary in Flash is too large facing its allocated areas in Flash and in Ram 36 MMDL _CORRUPTED_MEMORY_ID_ERROR Memory IDs pointed into tMmdlPartitionInfoTable is incorrect for a partition code binary 37 MMDL _INCOMPLETE_COMPATIBILY_TABLE _ERROR Compatibility table incomplete. Partition number for which versions are indicated into tMmdlBinariesPartitionInfoTable is less than partition number to be managed (indicated into tMmdlPartitionInfoTable) 38 MMDL _XM_VERSION _ERROR XM version (Main, Abi, api) present not compatible facing those indicated in compatibility table 39 MMDL_ PARTITION_ VERSION_ERROR Partition version got in Flash not compatible facing those indicated in compatibility table 40 MMDL _BINARY_CRC_ERROR Crc computed after loading a binary from Flash to RAM is different than crc indicated in the correspondent BSW header 41 MMDL_ FLASH _WRITE_ERROR Error while writing opcode in flash 42 MMDL _GET_TIME_ERROR Error while getting XM time 43 MMDL_ SET_TIMER_ERROR Error while setting XM timer 44 MMDL_ PARTITION _INIT_ERROR At least one partition init launched by MMDL fails 45 MMDL _MEMORY_REQUEST_NOT_WAITED The memory request type incoherent 3 facing the current memory operation 46 MMDL_CRC_CHECK_ERROR Crc computed once incomming binary is uploaded at all in tmp RAM is different than crc indicatedin its BSW header Table 5- MMDL errors The following internai error codes are defined in the IOS include file IoMotorDefs.h: enum { /* additional specific errors */ /* TRAP macro error id: Failure when creating * status sampling port **/ IOMOTOR_STATUS_SAMPLING_PORT _CREATION_ERROR = MAX( (LAST_DRV_ERROR + 1),0x100), /** TRAP macro error id: Failure when writing * in status sampling port **/ IOMOTOR_SAMPLING_PORT _WRITE_ERROR, /** TRAP macro error id: Number of queuing * ports exceeds limit. **/ IOMOTOR_QUEUING_PORTS _NUMBER_ERROR, /** TRAP macro error id: Failure when creating * Tx queuing ports **/ IOMOTOR_DATA _ TX_QUEUING_PORT _CREATION_ERROR, /** TRAP macro error id: Failure when creating * Rx queuing ports **/ IOMOTOR_DATA _RX_QUEUING_PORT _CREATION_ERROR, /** TRAP macro error id: Failure when creating * Acknowledgment queuing ports **/ IOMOTOR_ACK_QUEUING_PORT _CREATION_ERROR, /** TRAP macro error id: Failure when calling * XM_get_time hypercall **/ IOMOTOR_XM_GET_TIME_ERROR, /** TRAP macro error id: Failure when calling * XM_set_timer hypercall **/ IOMOTOR_XM_SET_TIMER_ERROR, /** TRAP macro error id: trap if shutdown * interrupt number is uncorrect **/ IOMOTOR_INTERRUPT_ERROR, /** TRAP macro error id: Failure when receiving * message on Tx queuing port **/ IOMOTOR_DATA _ TX_QUEUING_PORT _READ_ERROR, /** TRAP macro error id: trap if port * index is out of range. **/ IOMOTOR_DATA _TX_PORT _IDX_OUT_OF_RANGE, /** TRAP macro error id: Failure when creating * obs sampling port **/ IOMOTOR_OBS_SAMPLING_PORT _CREATION_ERROR, /** TRAP macro error id: Failure when writing 4
* in obs sampling port **/
IOMOTOR_OBS_SAMPLING_PORT _WRITE_ERROR, /** Error creating ports for HSEM services */ IOMOTOR_HSEM_PORTS _CREATION_ERROR, /** TRAP macro error id: Failure when checking * configuration table **/
IOMOTOR_CONFIG_TABLE _CHECK _ERROR = 0x200, /** Bad config table signature */ IOMOTOR_CONFIG_TABLE _BAD_SIGNATURE, /** Bad config table interface version number * (table not compatible with this I0S) */
IOMOTOR_CONFIG_TABLE _BAD_VERSION _NUMBER, /** Invalid number of ports in the configuration table * check plOutDataRxQueuingPortsNumber, plInDataTxQueuingPortsNumber * and plOutDataAckQueuingPortsNumber */
IOMOTOR_CONFIG_TABLE _BAD_NUMBER_OF_PORTS, /** Driver interface error */ IOMOTOR_SSIS_DRIVER _INTERFACE _ERROR, /** Sequence overrun detected */ IOMOTOR_SEQUENCE_OVERRUN_DETECTED, /** Slot overrun : sequence terminated on another slot */ IOMOTOR_SLOT_OVERRUN_DETECTED, /** Slot mismatch : the sequence is not executed during the * right xm slot. */
IOMOTOR_SLOT_OVERRUN_DETECTED, /** Invalid size of a RX port * check plTableOutDataRxPortSizes, all values * should belong to * ] OUT_ DATA _RX_PORTi_MIN_MSG_SIZE ; OUT_ DATA _RX_PORTi_MAX_MSG_SIZE [ */
IOMOTOR_CONFIG_TABLE _BAD_SIZE_OF_A_RX_PORT, /** Invalid size of a TX port in the configuration table */ IOMOTOR_CONFIG_TABLE _BAD_SIZE_OF_A_TX_PORT, /** Invalid number of device in the configuration table */ IOMOTOR_CONFIG_TABLE _INVALID_NUMBER_OF_DEVICE, /** Invalid read sequence sieze in the configuration table */ IOMOTOR_CONFIG_TABLE _INVALID_READ_SEQUENCE_SIZE, /** Wait mode is not WAIT or NO WAIT */ IOMOTOR_CONFIG_TABLE _INVALID_WAIT _MODE, /** Using multicast for a tx sequence is not supported */ IOMOTOR_CONFIG_TABLE _INVALID_TX_MUTICAST_SETTING, /** A sequence table is missing for a sequence */ IOMOTOR_CONFIG_TABLE _MISSING_ROUTING_TABLE, /** Sequence type is not READ, WRITE or UNUSED_SEQ */ IOMOTOR _CONFIG_TABLE _INVALID_SEQUENCE_TYPE,
/** unexpected service tag in PMU message header */ IOMOTOR _MESSAGE _BAD_TX_SERVICE _TAG = 0x300,
/** unexpected sub service tag in PMU message header */ IOMOTOR _MESSAGE _BAD_TX_SUB_SERVICE _TAG,
/** bad validity flag in PMU message header */ IOMOTOR _MESSAGE _BAD_ TX_FUNCTIONAL_VALIDITY_FLAG,
/** inconsistant payload in PMU message header */ IOMOTOR _MESSAGE _BAD_TX_PAYLOAD_LENGTH,
/** XM failed in retrieving port satus */ IOMOTOR _MESSAGE _FAILED_ IN_RETRIEVING_TX_PORT _STATUS,
/** XM failed to send ack message */ IOMOTOR _MESSAGE _ FAILED_TO_SEND_ACK_CONFIRMED,
/** XM failed to send nack message 1 */ IOMOTOR _MESSAGE _ FAILED_TO_SEND_ACK_REJECTED,
/** XM failed to send nack message 2 */ IOMOTOR _MESSAGE _ FAILED_TO_SEND_ACK_REJECTED2,
/** XM failed to read time 1 */ IOMOTOR _RX_READ_TIME_ERROR1 = 0x400,
/** XM failed to read time 2 */ IOMOTOR _RX_READ_TIME_ERROR2,
/** Unexpected IoServer internal status error * (neither ongoing nor succesful transfert) */ IOMOTOR _INTERNAL_UNEXPECTED_RX_STATE_VALUE,
/** Timout detected in mode wait */ IOMOTOR _RX_WAIT_MODE _TIMEOUT,
/** Timout detected in mode no wait */ IOMOTOR _RX_NO_WAIT_MODE _TIMEOUT,
/** General error during driver read API see ED */ IOMOTOR RX FAILED,
/** General error during driver ioctl API see ED */ IOMOTOR _RX_DMA_RESULT_IOCTL_FAILED,
/** Failed to send queuing message */ IOMOTOR _RX_UNABLE_TO_SEND_QUEUING_MESSAGE,
/** Driver API ABORT DMA RX return an error */ IOMOTOR _DRV_FAILED_IN_ABORTING_RX, IOMOTOR _RX_CANCELED_,
/** Failed to send NACK after one of these error * - RX forward failed * - Device timeout reached on reception (too long for receiving one message) * - IOMOTOR RX WAIT MODE TIMEOUT * - IOMOTOR SSIS DRIVER INTERFACE ERROR 6 * - IOMOTOR RX FAILED IOMOTOR_RX_FAILED_TO_SEND_NACK, /** Failed to send NACK when no route found in pre routing procedure * \see IOMOTOR RX NO PRE ROUTE FOUND */ I0MOTOR_RX_FAILED_TO_SEND_NACK_2, /** No post-reception route found * Maybe consider revising the routing tables (missing address inside) */ 10MOTOR RX NO ROUTE, /** No pre-route found * Maybe consider using 10S NA as sequence port (for Spacewire) or provide * a correct port index (for PIC) */ IOMOTOR_RX_NO_PRE_ROUTE _FOUND, /** No message in TX queuing port or message too big for the buffer * (check IO config table). */ IOMOTOR_TX_READ_ON_PORT _XM_ERROR = 0x500, /** Driver WRITE API report a timeout. */ IOMOTOR_TX_WAIT_MODE _TIMEOUT, /** Driver GET_FIN_DMA_TX API reports ONGOING in NO_WAIT mode : this * is a timeout case. Transfer will be canceld. */ IOMOTOR_TX_NO_WAIT_MODE _TIMEOUT, /** Error in the driver WRITE API other than timeout. */ IOMOTOR_TX_WRITE _FAILED, /** Driver API GET_FIN_DMA_TX reports an error. */ IOMOTOR_TX_GET_FIN_DMA_TX_FAILED, /** Rather an internal error, * there are still an ongoing transfer on the device that should have * been properly finished or canceld at that point. */ IOMOTOR_TX_ERROR_DEVICE_ISNT_AVAILABLE, /** Rather an internal error, * there are still an ongoing transfer on the device that should have * been properly finished or canceld at that point. * (RX timeout on master/slave device) */ IOMOTOR_RX_ERROR_DEVICE_ISNT_AVAILABLE, /** Generally this is a nominal error indicating that there * is no message to send for this sequence (associated queuing is empty). * may also indicate that no route in the routing table is found. * Consider revising the routing table (missing port id in the table) */ IOMOTOR_TX_NO_ROUTE _FOUND_OR_NO_MESSAGE, /** Driver ABORT_DMA_TX API reports an error */ IOMOTOR_TX_FAILED_TO_CANCEL, /** Received payload does not fit inside the current sequence length 7 * Is it a badly formated PMU message that would indicate a wrong * payload size ? */ IOMOTOR_TX_MESSAGE _T00_BIG_FOR_CURRENT_SEQUENCE,
/** Failed to send HSEM event on NACK. */ IOMOTOR_FAILED_TO_SEND_HSEM _EVENT_ON_NACK = 0x600,
/** Failed to send the first HSEM life status */ IOMOTOR_FAILED_TO_SEND_HSEM _LIFE_STATUS_AT_INITIALISATION,
/** Failed to send HSEM life status when looping on the sequence table */ IOMOTOR_FAILED_TO_SEND_HSEM _LIFE_STATUS_AT_SEQUENCE_LOOP, /** Failed to send the shutdown HSEM life status */ IOMOTOR_FAILED_TO_SEND_ HSEM _LIFE_STATUS_AT_SHUTDOWN,
/** Failed to send the HSEM life status on trap */ IOMOTOR_FAILED_TO_SEND_HSEM _LIFE_STATUS_ON_TRAP 1; 8.5 S SIS EVICES MAJOR NLTMB RS The following major numbers of drivers are defined in the include file IoDrvDefs.h of SSIS: PIC MAJOR = 0, SPW_MAJOR = 1, FLASH MAJOR = 2, 12C _MAJOR = 3, DUMMY_MAJOR = 4, FAKE_TIMEOUT_DRIVER 5, SIMU_FLASH _MAJOR = 6, SIMU_MAJOR = 7, UART_MAJOR = 8, OSL_MAJOR = 9, 1553 MAJOR = 10, 8.6 10S 1NT1J'RKIL LICE CODA- I~iII! JES IOS code start at 48 8.6. 1 Code IOS TR CE INI T ol~set 11 Lower bits of the value are a possible initialisation state: - INIT_CREATE_STATUS = 1- start status queue creation - INIT-WRITE_STATUS = 2 - start writing status (STARTUP_IN_COURSE_FUNC_STATE) - INIT_CHECK_CONFIG_TABLE = 3 - start checking the configuration table - INIT_CREATE_QUEUING_PORTS = 4 - start creating communication ports queues - INIT-WRITE-READY = 5 - start writing ready status (PARTITION_READY_FUNC_STATE) - INTT_FINISHED_OK = 6 - Initialisation complete waiting to be synchronized on next MAF start - INIT_OK = 7 - IOS synchronized, scheduling plan ongoing. In case of error during the initialization on of the following status is also reported (in upper bits)
- INIT_ERROR_BAD_SIGNATURE=0x8000,
- INIT_ERROR_BAD_VERSION=0x8001,
- INIT_ERROR_CREATE_STATUS_PORT=0x8002, los - INIT_ERROR_WRITE_STATUS_PORT=0x8003, - INIT_ERROR_WRITE_STATUS_PORT2=0x8004, - INIT_ERROR_CHECKING_CONFIGURATION _TABLE=0x8005, - INIT_ERROR_WRONG_PORTS _NUMBER=0x8006, - INIT_ERROR_CREATING_TX_PORTS=0x8007, - INIT_ERROR_CREATING_RX_PORTS=0x8008, - INIT_ERROR_CREATING_ACQ_PORTS=0x8009, - INIT_ERROR_WRONG_NUMBER_OF_PORTS=Ox800A, - INIT_ERROR_WRONG_RX_PORT _SIZE=Ox8OOB, - INIT_ERROR_WRONG_TX_PORT _SIZE=0x8000, - INIT_ERROR_WRONG_ACQ_PORT _SIZE=Ox8OOD, - INIT_ERROR_MISSING_ROUTING_TABLE=Ox8OOE, - INIT_ERROR_WRONG_WATT _MODE=Ox800F, - INIT_ERROR_TX_MULTICAST_NOT_SUPPORTED=0x8010, - INIT_FAILED_TO_INITIALIZE_DEVICE=0x8011, - INIT_ERROR_INVALID_SEQUENCE_TYPE =0x8012, - INIT_ERROR_CREATE_HSEM_PORTS =0x8013, 8:6,2 Driver godes (offset 1-3) See user manuals of drivers R11. 8.6.3 Code 10S SEO NUM (offset 4) The value is the sequence number (starting from 0) in the IOS scheduling plan. 8:6,4 Code 10S SF STATUS The value indicates the result of the sequence. This value is bit field composed like this: - IOS_NOTHING_HAPENED=O, - IOS_START_NEW_ONGOING_RX = 0x1, - IOS_STILL_ONGOING_RX = 0x2, - IOS_PREVIOUS_ONGOING_RX_FINISHED = 0x4, - IOS_RX_FINISHED = 0x8,
- IOS_START_NEW_ONGOING_TX = 0x00100, - I0S_PREVIOUS_ONGOING_TX_FINISHED=0x400, - IOS_TX_FINISHED = 0x800,
- I0S_ENGINE_SLOT_MISMATCH=0x100000, - I0S_ENGINE_SLOT_OVERFLOW=0x200000, - I0S_ENGINE_ERROR_CODE_EXIST=0x400000, 9 - I0S_ENGINE_SEQUENCE_OVERRUN=0x800000 8.6.5 :ode IOS__DRV _STATUS (offset 6) The value indicates the call to a driver API. There is one value before the call that indicates the API. - Upper bits contain IO_TRACE_STATUS_MASK = OxA00000 - Lower bits contain: o IO_TRACE_Initialize = 0, o IO_TRACE_Shutdown = 1, o IO_TRACE_Open = 2, o IO_TRACE_Close = 3, o IO_TRACE_Read = 4, o IO_TRACE_Write = 5, o IO_TRACE_Control = 6, There is one value after the call that indicates the API result. - Upper bits contain IO_TRACE_FUNC_MASK = OxF00000 - Lower bits contain one of the possible return value code defined in the SSIS interface documentation 8.6.6 Code IOS CODE ENGINE (offset 7' The value contains a BswError to report (see PMU protocol for the encoding of this error). 8.6.7 Code IOS PERI+ INFO {offset 8' The value contains information for measuring performances of the engine (see IO server test manual for more information). 8.6,8 :ode IOS DATA LENGTH (offset 9' The value indicates the number of bytes sent or received during the sequence. 8.6.9 Code IOS TRAP PC {offset 10 The value of the first instance of this code indicates the PC register of a error trap. The value of the second instance indicates the GPMU error code associated to the trap. 8.7 t~LIL~3%; .INI"ERNAL LICE CODE VALUE MMDL code start at 24 8.7.1 Corde MMDL TRACE 1 NIT offset 0) Possible value and meaning: - INIT_OK = 0 - MMDL synchronized and running. 8.7.2 Driver codes (Code 4945 See user manuals of drivers R11. 8.7.3 Code IOS PERF IN O (offset 3) The value contains information for measuring performances of the engine (see MMDL server test manual for more information). tto 8.7,4 Code 100 SEO NUM (offset 4) The value indicates an increasing sequence number (starting from 0).
Claims (1)
- REVENDICATIONS1.- Plateforme d'exécution modulaire comprenant : - une couche matérielle comprenant au moins un processeur, une mémoire de processeur, une horloge, un contrôleur d'entrée/sortie et une carte d'entrée/sortie périphérique ; et, - une couche logicielle comprenant un code hyperviseur propre à partitionner spatialement et temporellement la couche matérielle, le code hyperviseur étant propre à fournir des services de communication pour l'échange de message de données entre deux partitions, au moins un code applicatif exécuté sur une partition qui lui est dédiée, et un pilote associé à la carte d'entrée/sortie périphérique, caractérisé en ce qu'elle comporte un code de service (180), exécuté sur une autre partition (190), ladite autre partition étant associée audit code de service, ledit code de service comportant ledit pilote (188) et un composant logiciel serveur (181), ledit composant logiciel serveur (181) encapsulant ledit pilote et constituant un serveur de services génériques d'accès à la carte d'entrée/sortie périphérique, et en ce que ledit code applicatif comporte un composant logiciel client (187) propre, lorsque ledit code applicatif appelle un service afin d'accéder à la carte d'entrée/sortie périphérique, à requérir l'exécution de ce service auprès du composant logiciel serveur (181), en émettant une requête adaptée en utilisant les services de communication entre partitions du code hyperviseur.2.- Système selon la revendication 1, caractérisé en ce que l'échange de requêtes entre les composants logiciels client et serveur s'effectue selon un protocole prédéterminé.3.- Système selon l'une quelconque des revendications précédentes, caractérisé en ce que l'interface de programmation dudit pilote (188) et du composant logiciel serveur (181) est standardisée.4.- Système selon l'une quelconque des revendications précédentes, caractérisé en ce que le composant logiciel serveur (181) est générique d'un type d'entrée/sortie.5.- Système selon l'une quelconque des revendications précédentes, caractérisé en ce que le code hyperviseur respecte le standard ARINC 653.6.- Système selon l'une quelconque des revendications précédentes caractérisé en ce qu'il est du type « Avionique modulaire intégrée ». 1127.- Système selon l'une quelconque des revendications précédentes, caractérisé en ce que le code de service comporte un unique composant logiciel serveur et une pluralité de pilotes.8.- Composant logiciel serveur (181), caractérisé en ce qu'il est propre à être compilé avec un pilote (188) de manière à obtenir un code de service(180) apte à être exécuté sur une partition d'une plateforme d'exécution modulaire conforme à l'une quelconque des revendications 1 à 7.9.- Composant logiciel client (187), caractérisé en ce qu'il est propre à être compilé avec un programme applicatif (144) et/ou un système d'exploitation (46) de manière à obtenir un code applicatif (140) apte à être exécuté sur une partition d'une plateforme d'exécution modulaire conforme à l'une quelconque des revendications 1 à 7.10.- Procédé mis en oeuvre sur une plateforme d'exécution modulaire conforme à l'une quelconque des revendications 1 à 7, pour l'accès, par un code applicatif exécuté sur une partition, à une carte d'entrée/sortie périphérique, via un contrôleur d'entrée/sortie, caractérisé en ce qu'il comporte les étapes consistant en : - l'appel, par le code applicatif d'un service générique du code de service ; - l'élaboration par le composant logiciel client du code applicatif d'une requête selon un protocole prédéterminé, à partir du service appelé ; - la communication de la requête ainsi élaboré au code de service exécuté sur une autre partition de la plateforme, en utilisant des services de communication inter-partitions fournis par le code hyperviseur ; - l'interprétation de la requête par le composant logiciel serveur du code de service ; et, - l'exécution par le composant logiciel serveur, du service requis, avec appel aux fonctions du pilote associé à la carte d'entrée/sortie périphérique.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1150325A FR2970577B1 (fr) | 2011-01-14 | 2011-01-14 | Plateforme d'execution modulaire amelioree. |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1150325A FR2970577B1 (fr) | 2011-01-14 | 2011-01-14 | Plateforme d'execution modulaire amelioree. |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2970577A1 true FR2970577A1 (fr) | 2012-07-20 |
| FR2970577B1 FR2970577B1 (fr) | 2014-02-07 |
Family
ID=44543303
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1150325A Active FR2970577B1 (fr) | 2011-01-14 | 2011-01-14 | Plateforme d'execution modulaire amelioree. |
Country Status (1)
| Country | Link |
|---|---|
| FR (1) | FR2970577B1 (fr) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2998073A1 (fr) * | 2012-11-14 | 2014-05-16 | Thales Sa | Systeme electronique, plateforme d'execution modulaire embarquee et procede assurant le cloisonnement de regles decisionnelles parametrables |
| EP3792759A1 (fr) * | 2019-09-12 | 2021-03-17 | Thales | Procédé d'accès aux ressources partagées d'une plateforme informatique, programme d'ordinateur et plate-forme informatique associés |
-
2011
- 2011-01-14 FR FR1150325A patent/FR2970577B1/fr active Active
Non-Patent Citations (3)
| Title |
|---|
| CRESPO A ET AL: "XTRATUM: AN OPEN SOURCE HYPERVISOR FOR TSP EMBEDDED SYSTEMS IN AEROSPACE", INTERNET CITATION, 26 May 2009 (2009-05-26), pages 1 - 9, XP002663261, Retrieved from the Internet <URL:http://www.fentiss.com/documents/dasia09.pdf> [retrieved on 20111028] * |
| ENRIQUILLO VALDEZ ET AL: "Retrofitting the IBM POWER Hypervisor to Support Mandatory Access Control", TWENTY-THIRD ANNUAL COMPUTER SECURITY APPLICATIONS CONFERENCE (ACSAC 2007), 1 December 2007 (2007-12-01), pages 221 - 231, XP055011752, ISBN: 978-0-76-953060-4, DOI: 10.1109/ACSAC.2007.43 * |
| J. ZAMORANO AND J. DE LA PUENTE: "Open Source Implementation of Hierarchical Scheduling for. Integrated Modular Avionics", 25 October 2010 (2010-10-25), XP002663262, Retrieved from the Internet <URL:https://www.osadl.org/fileadmin/dam/rtlws/12/Zamorano.pdf> [retrieved on 20111107] * |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2998073A1 (fr) * | 2012-11-14 | 2014-05-16 | Thales Sa | Systeme electronique, plateforme d'execution modulaire embarquee et procede assurant le cloisonnement de regles decisionnelles parametrables |
| US9582299B2 (en) | 2012-11-14 | 2017-02-28 | Thales | Electronic system, onboard modular execution platform and method ensuring partitioning of configurable decision-making rules |
| EP3792759A1 (fr) * | 2019-09-12 | 2021-03-17 | Thales | Procédé d'accès aux ressources partagées d'une plateforme informatique, programme d'ordinateur et plate-forme informatique associés |
| FR3100909A1 (fr) * | 2019-09-12 | 2021-03-19 | Thales | Procédé d'accès aux ressources partagées d'une plateforme informatique, programme d'ordinateur et plate-forme informatique associés |
| US11467880B2 (en) | 2019-09-12 | 2022-10-11 | Thales | Method for accessing shared resources of a computer platform, associated computer program and computer platform |
Also Published As
| Publication number | Publication date |
|---|---|
| FR2970577B1 (fr) | 2014-02-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN113312306B (zh) | 可配置逻辑平台 | |
| Corbet et al. | Linux device drivers | |
| Yaghmour | Embedded Android: Porting, Extending, and Customizing | |
| CN101840346B (zh) | 云主机部署的方法及系统 | |
| CA3095629A1 (fr) | Procede de gestion d'etat de configuration d'application a l'aide de techniques de gestion d'application en nuage | |
| CN104137062B (zh) | 将代码动态注入到运行中的进程 | |
| WO2022016848A1 (fr) | Procédé et appareil pour réaliser un déploiement d'application en fonction du rôle de service | |
| EP1387304A1 (fr) | Procédé de vérification fonctionnelle d'un modèle de circuit intégré pour constituer une plate-forme de vérification, équipement émulateur et plate-forme de vérification | |
| FR2797963A1 (fr) | Protocole de gestion, procede de verification et de transformation d'un fragment de programme telecharge et systemes correspondants | |
| EP1290554B1 (fr) | Systeme informatique modulaire et procede associe | |
| FR2972545A1 (fr) | Controle de flux d'instruction commande par des instructions de programme | |
| US9110758B2 (en) | Cross-platform software framework for embedded systems on data storage device | |
| CN114675935A (zh) | 联盟链中部署链码的方法和系统 | |
| CN114675934A (zh) | 联盟链中部署链码的方法和系统 | |
| CN110083366B (zh) | 应用运行环境的生成方法、装置、计算设备及存储介质 | |
| FR2970577A1 (fr) | Plateforme d'execution modulaire amelioree. | |
| CN114489927A (zh) | 一种解耦依赖文件的容器部署方法及系统 | |
| FR2998073A1 (fr) | Systeme electronique, plateforme d'execution modulaire embarquee et procede assurant le cloisonnement de regles decisionnelles parametrables | |
| US20140280767A1 (en) | Web services provided from software framework | |
| CN110852139B (zh) | 生物特征识别方法、装置、设备以及存储介质 | |
| CN114661421A (zh) | 联盟链中部署链码的方法和系统 | |
| CN1988479A (zh) | 一种记录系统信息的方法和对象桩 | |
| Bueno et al. | Quarkus Cookbook | |
| Chu et al. | Sdlib: a sensor network data and communications library for rapid and robust application development | |
| EP3411821B1 (fr) | Procédé de stockage de contenus, procédé de consultation de contenus, procédé de gestion de contenus et lecteurs de contenus |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 6 |
|
| PLFP | Fee payment |
Year of fee payment: 7 |
|
| PLFP | Fee payment |
Year of fee payment: 8 |
|
| PLFP | Fee payment |
Year of fee payment: 10 |
|
| PLFP | Fee payment |
Year of fee payment: 11 |
|
| PLFP | Fee payment |
Year of fee payment: 12 |
|
| PLFP | Fee payment |
Year of fee payment: 13 |
|
| PLFP | Fee payment |
Year of fee payment: 14 |