Laboratoire TIMA Grenoble

Paul BESSON
Informatique Industrielle et Instrumentation Rapport de stage (quatrime anne)

Extension des services d'un systme d'exploitation embarqu

Tome principal

Anne universitaire 2009-2010 Mai-Juillet 2010

Table des matires

1 Lieu du stage
1.1 Le laboratoire TIMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Le groupe SLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 2.2 2.3 2.4 2.5 3.1 3.2 3.3 3.4 3.5 3.6 4.1 4.2 4.3 4.4 4.5 Problmatique . . . . . . . . . . . . . . . . . Structure de APES . . . . . . . . . . . . . . . Les projets SoCLib, SHAPES et EURETILE La carte ATMEL D940 . . . . . . . . . . . . . Mon travail . . . . . . . . . . . . . . . . . . . Gnralits sur les systmes de chiers . . . Description du systme de chiers FAT . . . Description du systme de chiers virtuel de Intgration du FAT dans DNA-OS . . . . . Programmation et tests . . . . . . . . . . . Analyse et rsultats . . . . . . . . . . . . . . Le format ELF . . . . . . Passage des arguments . . Description du programme Programmation et tests . Analyse et rsultats . . . . . . . . . . . . . . . . . . . . de dmarrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4
4 5 6 7 7 8 9

2 Le projet APES

3 Intgration du systme de chiers FAT

. . . . . . . . . . . . DNA-OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

10 11 13 14 17 18 19 21 22 24 25

4 Cration d'un programme de dmarrage

19

5 Conclusion Annexes A Exemple de contenu d'un chier au format ELF

26 27 27

A.1 En-tte du chier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 A.2 En-tte des sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 A.3 En-tte des segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

B Exemple de chier

ldscript

29

Chapitre 1

Lieu du stage
J'ai eectu mon stage de deuxime anne au laboratoire TIMA (Techniques de l'Informatique et de la Microlectronique pour l'Architecture des systmes intgrs) au sein du groupe SLS (System Level Synthesis ). Les paragraphes suivants dcrivent succintement le laboratoire TIMA et les sujets de recherche du groupe SLS.

1.1 Le laboratoire TIMA

TIMA est un laboratoire public de recherche sous la tutelle du Centre National de la Recherche Scientique (CNRS), de l'Institut Polytechnique de Grenoble (Grenoble INP), et de l'Universit Joseph Fourier (UJF). Les sujets de recherche couvrent la spcication, la conception, la vrication, le test, les outils et les mthodes d'aide la conception pour les systmes intgrs sur silicium. Le champ de recherche s'tend des composants de base analogiques et numriques jusqu'aux systmes multiprocesseurs sur puce et leur systme d'exploitation de base. TIMA est organis en 6 groupes de recherche :       ARIS : architecture pour systmes intgrs complexes et robustes CIS : systmes intgrs parallles MNS : micro et nano-systmes RMS : systmes ables mixtes analogiques et numriques SLS : synthse architecturale VDS : vrication et modlisation

TIMA compte une centaine de membres, y compris les doctorants, auxquels s'ajoutent de 20 30 stagiaires au second semestre de l'anne universitaire. Le laboratoire est trs international et accueille des chercheurs et des stagiaires du monde entier. Une grande partie de la recherche s'eectue dans le contexte de projets coopratifs, avec des partenaires industriels et acadmiques, nancs par des contrats rgionaux, nationaux, et europens.

1. Lieu du stage

1.2 Le groupe SLS

Pour rpondre aux questions que pose l'intgration de nombreux processeurs sur une mme puce, savoir :  Quelles sont les stratgies de simulation alternatives qui permettent la validation fonctionnelle et l'estimation de la puissance de calcul de ce type de puce ?  Comment aider le programmeur lambda tirer toute la puissance de ce genre d'architecture avec un support matriel spcique ?  Compte tenu des dicults d'intgration matriel/logiciel, quels outils de synthse et de gnration peuvent simplier et automatiser l'intgration systme ? Le groupe SLS se concentrent sur les thmes de recherche suivants :  Architecture et logiciels de CAO (Conception Assiste par Ordinateur) pour systmes multiprocesseurs sur puce et pour les rseaux intgrs sur puce,  Modlisation et techniques de simulation pour les interfaces logiciels/matriels,  Spcication et mise en uvre de logiciels embarqus,  Plateformes de prototypage recongurables pour la validation de systmes.

Chapitre 2

Le projet APES
Durant mon stage, j'ai travaill sur le projet APES (APplication Elements for System on chips ) [1] [2]. Ce projet s'intgre dans des projets plus importants que sont SoCLib, SHAPES et EURETILE (projets nancs par l'Agence Natianale de la Recherche et la Communaut Europenne).

APES est un ensemble de composants logiciels destins faciliter le dveloppement d'applications embarques pour des systmes multiprocesseurs (homognes ou htrognes) sur puce.

2.1 Problmatique
Pour obtenir la puissance de calcul ncessaire aux applications embarques modernes, les concepteurs de ces applications s'appuient de plus en plus sur des systmes multiprocesseurs (MP-SoC 1 ) ou intgrant plusieurs processeurs de type dirent (plateformes htrognes dites HMP-SoC 2 ) sur puce. Pour raliser une application sur ce type de plateforme, le dveloppeur peut au choix : 1. Programmer sparment chaque processeur 2. Utiliser un systme d'exploitation de haut niveau La premire solution demande un travail long et fastidieux qui n'est pas envisageable mme pour une application de taille moyenne. De plus, l'application dveloppe n'est pas portable. La deuxime solution ore la portabilit est la simplicit de programmation mais oblige l'utilisation d'un systme lourd qui demande de nombreux calculs supplmentaires et entraine une utilisation mmoire beaucoup plus importante. Le framework APES se veut un compromis entre ces deux solutions. Il est n de la ncessit d'orir une couche logicielle la plus gnrique possible (c'est dire capable de fonctionner sur des plateformes trs direntes) et ore de nombreuses fonctionnalits tout en restant peu gourmand en ressources matrielles.
1. 2.

Multi-Processor System-on-Chip Heterogeneous Multi-Processor System-on-Chip

2. Le projet APES

2.2 Structure de APES

APES est construit autour d'une architecture souple, divis en couche (gure 2.1), base sur des composants logiciels : 1. La couche d'abstraction du matriel (HAL, Hardware Abstraction Layer ) qui intgre des composants logiciels spciques la plateforme permettant l'accs aux registres du processeur notamment. 2. Le systme DNA-OS 3 constitu de trois composants logiciels principaux formant le noyau et de plusieurs modules permettant d'tendre ses fonctionnalits. 3. L'application qui repose sur le systme d'exploitation et qui peut inclure des bibliothques de fonctions.
main() Librairies

Application
Noyau Modules

DNA-OS HAL

Figure 2.1  Structure de APES

Avec cette structure, le code du systme d'exploitation et de l'application sont indpendants du matriel. Il sut d'inclure la compilation les composants logiciels utiles (bibliothques et modules) utiles pour l'application et les composants logiciels spciques la plateforme (HAL et pilotes de priphriques). En cas de changement de matriel seuls les composants logiciels de la couche HAL et les pilotes sont modier mais l'application et DNA-OS ne sont pas impacts. APES ore donc une architecture logicielle portable et modulaire puisque qu'il sut de slectionner uniquement les composants logiciels dont on a besoin en fonction de notre application et de l'architecture matrielle.

2.3 Les projets SoCLib, SHAPES et EURETILE

APES est utilis au sein de trois projets plus importants dcrits succinctement ci-aprs.

2.3.1 SoClib
SoClib est une plateforme de simulation ddie au dveloppement matriel et logiciel d'architecture MP-SoC et HMP-SoC. SoClib est capable de simuler une large varit de processeurs. Des composants logiciels APES sont dj crits pour fonctionner avec la plupart de ces processeurs.
3. DNA's Not just Another Operating System

2. Le projet APES

2.3.2 SHAPES
SHAPES est un projet europen qui a pour but de construire un ensemble de tuiles bases sur des architectures multiple processeurs htrognes pour faire tourner des applications demandant de lourds calculs (simulation de physique nuclaire, traitement du signal, . . .). APES ore la possibilit d'utiliser la mme application pour chaque tuiles indpendamment des spcicits matrielles.

2.3.3 EURETILE
EURETILE est la suite du projet SHAPES. Il a pour but d'associer un grand nombre de tuiles du projet SHAPES pour excuter des calculs en parallle. Ce projet soulve comme principaux problmes le chargement des programmes et la dtections des erreurs matrielles.

2.4 La carte ATMEL D940

Outre les tests eectus sur le simulateur SoClib, la validation des composants de APES se fait sur la carte ATMEL DIOPSIS 940HF (gure 2.2), l'une des tuiles du projet SHAPES. Cette carte de type HMP-SoC, fabriqu par ATMEL Roma est dote d'un processeur RISC (Reduced Instruction Set Computer ) de type ARM9 associe un DSP (Digital Signal Processor ) MagicV. Cette carte intgre galement de nombreux priphriques de communication (Ethernet, USB, RS232, . . .) et un lecteur de carte mmoire Secure Digital.

Figure 2.2  La carte ATMEL DIOPSIS 940HF

2. Le projet APES

2.5 Mon travail

Mon travail au sein du projet APES a t d'crire un nouveau composant logiciel pour tendre les fonctionnalits de DNA-OS. Ces nouvelles fonctionnalits tant utilises par la suite par un programme de dmarrage que j'ai galement d crire.

2.5.1 Le composant logiciel FAT

Ce composant logiciel doit permettre la prise en charge du systme de chiers FAT (File Allocation Table ) de Microsoft au sein de DNA-OS. Le systme de chiers FAT est trs prsent sur les supports amovibles. Son intgration est indispensable pour pouvoir lire des chiers sur un priphrique de stockage et plus particulirement le contenu d'une carte mmoire Secure Digital partir de la carte D940. Ce composant logiciel est un module du systme d'exploitation li au noyau par le VFS (Virtual File System ). Ces lments sont dcrits au chapitre 3. Outre le programme de dmarrage, cet composant logiciel pourra tre utilis dans de nombreuses applications impliquant la lecture de donne dans un chier et terme l'criture de donnes.

2.5.2 Le programme de dmarrage

Le programme de dmarrage est une application qui a pour but de charger aux bons emplacements mmoires de la plateformes le code excuter. Il est ncessaire pour faciliter et automatiser le chargement d'un programme, qu'il peut tre fastidieux de faire manuellement sur une architecture htrogne et qui n'est pas envisageable en environnement de production ou sur une architecture tuiles comportant des centaines de tuiles. Le programme de dmarrage ralis est dcrit au chapitre 4.

10

Chapitre 3

Intgration du systme de chiers FAT

Pour comprendre la mise en uvre du premier objectif, il est ncessaire d'avoir quelques notions concernant les systmes de chiers. C'est l'objet du paragraphe 3.1. Le paragraphe 3.2 dcrit le systme de chiers FAT qu'il a fallu implmenter en tenant compte du VFS (Virtual File System ) dj prsent dans DNA-OS. Celui-ci sera dcrit au paragraphe 3.3. Enn, le paragraphe 3.4 rsumera le travail ralis pour intgrer cette nouvelle fonctionnalit dans DNA-OS.

3.1 Gnralits sur les systmes de chiers

Un systme de chiers (le system en anglais, abrg FS) est une structure de donnes permettant de stocker les informations et de les organiser dans des chiers sur une mmoire secondaire (disque dur, carte mmoire, cl USB, CD-ROM, etc.). Il ore l'utilisateur une vue abstraite sur ses donnes et permet de les localiser partir d'un chemin d'accs. Les systme de chiers les plus utiliss sont le NTFS (New Technology File System ) sous Windows, l'ext (extended le system ) sous Linux et le FAT (File Allocation Table ) pour les supports amovibles.

3.1.1 Secteurs et blocs

La majorit des priphriques de stockage crivent et lisent les donnes par secteur (sector en anglais) (correspondant gnralement une puissance de 2 octets). Le systme de chiers est en charge de l'organisation de ces secteurs en chiers et rpertoires et de garder une trace de l'tat de ces secteurs pour pouvoir accder aux donnes grce un chemin d'accs ou crire de nouvelles donnes. De plus, compte-tenu de la taille de plus en plus importante des priphriques de stockage, les systmes de chiers actuels regroupent les secteurs physiques en blocs (appels cluster ). Ces blocs reprsentent la taille minimale d'un chier sur le disque. Elle est gnralement de 4 kilooctets sur un disque-dur ou une carte mmoire.

3.1.2 Concept d'inode ou entre

Un inode est une structure de donnes reprsentant un chier ou un rpertoire. Il est dirent selon le systme de chiers mais il contient en gnral le nom du chier ou du rpertoire,

3. Intgration du systme de chiers FAT

11

ses mtadonnes (taille, type, date de modication, permissions. . .) et l'adresse du dbut des donnes (qui pourront tre d'autres inodes s'il s'agit d'un rpertoire).

3.2 Description du systme de chiers FAT

Le systme de chiers FAT a t invent par Microsoft [3] pour les systmes DOS en 1980. Il a volu au travers des version FAT12, FAT16 et FAT32 pour les plus connues (o le chire reprsente la puissance en base 2 du nombre de blocs de donnes utilisables) Il a t repris dans les premires versions de Windows et est encore grandement utilise pour les supports amovibles dans sa dclinaison FAT32. Son fonctionnement est relativement simple par rapport d'autre systmes de chiers plus rcents, ce qui explique son utilisation dans de nombreux appareils portatifs (tlphones, baladeurs, appareils photo, etc).

3.2.1 Structure du FAT

L'organisation des secteurs sur une partition FAT est donne par la gure 3.1. Un volume FAT est organis de la manire suivante : le premier secteur appel Volume ID est suivi par des secteurs rservs puis deux copies de la FAT proprement parl. Enn, la majorit du volume est occup par les blocs de donnes. Ces lments sont dcrits dans la suite du paragraphe.
Volume ID Secteur rservs FAT

Copie de la FAT

Blocs de donnes

Espace inutilis

Figure 3.1  Structure d'un volume FAT

Le Volume

ID

Le Volume ID est le premier secteur de la partition. Il contient des informations permettant de dcrire la partition (version du FAT, taille des blocs, adresse du rpertoire racine, etc.).

Les blocs
Les blocs occupent la majorit de l'espace et contiennent les donnes des chiers ou des entres s'il s'agit de rpertoires. Une entre, dnie sur 32 octets, contient le nom, les mtadonnes du chier et le numro du bloc contenant les donnes s'il s'agit d'un chier o des entres s'il s'agit d'un rpertoire. Une telle entre impose un nom de chier limit 8 caractres pour le nom et 3 pour l'extension.

12

3. Intgration du systme de chiers FAT

Pour grer des noms plus longs, plusieurs autres entres contenant le nom complet prcde cette ultime entre.

La FAT
La FAT est un immense tableau d'adresses avec autant de cases que de blocs de donnes (l'indice du tableau correspond au numro du bloc). La valeur contenu dans la case est galement un numro de bloc (correspondant au bloc de donne suivant ou -1 pour le dernier bloc ou 0 si le bloc est libre). La taille d'une case est de 32 octets pour le FAT32, d'o la limitation du nombre de blocs. Si l'on considre un chier de 8 kilo-octets, il occupe donc deux blocs de donns. Si le premier bloc de donnes du chier est le numro 0x1000 et le second et 0x2000, alors, dans la FAT, on pourra lire l'indice 0x1000 la valeur 0x2000 et l'indice 0x2000 la valeur -1 puisqu'il n'y plus de blocs de donnes pour ce chier. La FAT est donc indispensable pour accder tous les blocs d'un chier, c'est pour cela qu'une copie est prsente. Si un secteur est illisible dans la premire FAT, l'information est disponible dans la deuxime.

3.2.2 Accs aux donnes

L'accs aux donnes (illustre par la gure 3.2) se fait en partant du rpertoire racine (root cluster ) dont l'adresse est lisible dans le Volume ID. Il faut ensuite parcourir les entres du bloc racine la recherche du nom du chier ou du sous rpertoire. Si une correspondance est trouve, la lecture de l'entre donne le numro du bloc o sont enregistres les donnes ou les entres du sous rpertoire suivant. La lecture dans la FAT permet de connatre le numro du bloc de donnes suivant du chier.
bloc racine (0x2) bloc "dossier" (0x100) bloc "chier" (0x400)

FAT
entres ... 0x400 : 0x500 ... 0x500 : 0x501 0x501 : -1 ...

/ dossier dossier2 image

dossier dossier3 chier

Blocs

Figure 3.2  Accs aux donnes d'un chier sur un volume FAT

3. Intgration du systme de chiers FAT

13

3.3 Description du systme de chiers virtuel de DNA-OS

3.3.1 Principe d'un systme de chiers virtuel
Un systme de chiers virtuel (en anglais Virtual File System abrg VFS) est une couche logicielle permettant de faire coexister plusieurs systmes de chiers concrets de faon transparente pour les processus utilisateurs. Les VFS permettent d'intgrer dans une arborescence unique (dans n'importe quel dossier spci par l'utilisateur) le contenu d'une mmoire secondaire. Les VFS sont trs prsents dans les systmes Linux et sont l'opposs de la notion de volume que l'on trouve sous les systmes Windows. Le VFS est responsable de l'intgration d'un priphrique dans l'arborescence (processus de montage) et il fait le lien entre l'utilisateur (fonction open(), read(), write()) et le priphrique avec son systme de chiers propre (gure 3.3) qui impose des accs aux secteurs dans un ordre particulier pour lire ou crire des donnes.

Application

read()

vfs_read() OS fs_read()

FS

Figure 3.3  Place du VFS entre l'utilisateur et le priphrique

3.3.2 Principales structures de donnes du VFS de DNA-OS
Structure volume
Cette structure de donnes permet d'identier un volume (une partition ou un priphrique avec un FS propre) au sein du VFS. Elle est cre lors du montage et contient principalement : Un numro d'identiant unique du volume. Le type (FAT, ext, NTFS) du volume. Un ensemble de pointeurs vers les fonctions d'accs propres au FS. Certaines donnes du FS (le contenu du Volume ID pour une partition FAT par exemple).  L'identiant du vnode racine.    

14

3. Intgration du systme de chiers FAT

Structure vnode
La structure vnode (pour virtal inode ) reprsente un inode dans le VFS. Elle contient principalement :  Un numro d'identiant unique du vnode au sein du VFS.  L'identiant du volume auquel il est ratach.  Les donnes de l'inode rl du FS.

3.3.3 Principales fonctions du VFS de DNA-OS

 vfs_mount() : Cette fonction permet d'intgrer un volume l'arborescence. Elle prend comme paramtres le volume monter (sous forme de chaine de caractres), le chemin du dossier dans lequel intgrer le volume (dit le rpertoire de montage) et le type du volume. Pendant son excution, cette fonction appelle la fonction FS_mount() propre au FS du volume.  vnode_walk() : Cette fonction parcourt un chemin d'accs pour retourner le vnode du chier/rpertoire sur lequel il pointe. Cette fonction est automatiquement appele par vfs_open() (dcrite ci-aprs). Pendant son excution, cette fonction appelle la fonction FS_walk() pour rellement parcourir l'arborescence du priphrique.  vnode_get() et vnode_put() : Ces fonctions sont en charge de la cration/supprssion en mmoire des vnodes. Elles font le lien avec les fonctions FS_vnode_read() et FS_vnode_destroy() qui sont en charge de crer un inode en lisant sur le priphrique puis de le librer quand il n'est plus ncessaire.  vfs_open() : L'appel cette fonction est provoque par l'appel de la fonction open() standard. Elle analyse le chemin pass en paramtre grce vnode_walk() puis appelle la fonction FS_open() sur le vnode retourn vnode_walk(). Cette fonction retourne un descripteur de chier.  vfs_read() et vfs_write() : Ces fonctions, appeles par les fonctions read() et write() standard, font le lien avec FS_read() et FS_write(). L'avantage d'un VFS est que toutes les fonctions de gestion de chiers ne sont crire qu'une fois. Seule les fonctions FS_*() sont spciques au FS.

3.4 Intgration du FAT dans DNA-OS

La premire partie de mon travail a donc t de dvelopper les fonctions propres au systme de chiers FAT32 pour les intgrer au VFS de DNA-OS. Pour me faciliter la tche, je suis parti d'une bibliothque [4] existante permettant de lire un priphrique format en FAT16/32. Cependant, cette bibliothque ralise pour fonctionner sur microcontrleur (sans systme d'exploitation) ne prend pas du tout en compte la notion de VFS. En eet, la bibliothque utilise recre les fonctions usuelles de gestions de chier (open(), read(), write(), etc.) indpendantes de la librairie C standard. Cela a dont demand un long travail pour diviser les tches excutes par les fonctions de cette bibliothque an d'crire les fonctions propres au FAT intgrer au VFS de DNA-OS. Comme l'criture sur une partition FAT32 n'est pas prioritaire (le but tant de lire la carte mmoire pour charger le programme de dmarrage) , j'ai seulement crit les fonctions ncessaires pour le montage du volume et la lecture.

3. Intgration du systme de chiers FAT

15

3.4.1 Problmatique d'ouverture d'un chier pour l'intgration dans le VFS

Pour lire le contenu d'un chier enregistr sur un volume FAT, il est ncessaire d'obtenir le numro du bloc o sont crites les donnes (montr prcdemment sur la gure 3.2). Dans la bibliothque, cela est ralis par la fonction fatlib_open() qui prend en paramtre un chemin et retourne le numro du premier bloc de donnes pour tre pass fatlib_read(). L'algorithme de cette fonction est donn ci-dessous (gure 3.4). 1. 2. 3. 4. 5. Dcouper le chemin selon "/" Chercher l'lment dans les entres du blocs parents Aller au bloc de l'lment trouv Recommencer les tapes 2 et 3 pour tous les lments Retourner la dernire entre lue
fatlib_open("/dossier/chier") 1. / dossier / chier 2.
/ - dossier - dossier2 bloc parent de "dossier" (bloc racine) entres

bloc parent de "chier" (bloc "dossier") dossier - chier - chier2

3.

entre retourne

4.
5.
chier | mtadonnes | 0x1234

numro du premier bloc de "chier"

Figure 3.4  Algorithme d'ouverture d'un chier par la bibliothque

Le mcanisme d'ouverture d'un chier dans DNA-OS est illustr par la gure 3.5. En analysant les gures 3.4 et 3.5, on comprend qu'il est ncessaires de sparer en deux tapes distinctes les processus de recherche des entres et lecture sur le disque de ces entres, ainsi que de crer un objet inode qui sera manipul par les fonctions du VFS.

3.4.2 L'inode d'un volume FAT

Comme l'exige le VFS, l'exploration de la partition partir d'un chemin, doit se faire en deux temps : 1. Lecture de l'inode (fonction fatfs_read_vnode()) 2. Recherche de l'entre (fonction fatfs_walk())

16

3. Intgration du systme de chiers FAT

open("/dossier/chier")
programme principal

- recherche de "dossier" dans inode_racine - retourner l'identiant de "dossier"

vfs_open("/dossier/chier") vfs_walk("/dossier/chier")

fs_walk(inode_racine, "dossier") fs_read_vnode(identiant de "dossier")

fs_walk(inode_dossier, "chier") fs_read_vnode(identiant de "chier")

- va au bloc de "dossier" - enregistre ses entres - retourne inode_dossier

fs_open(inode_chier)

Figure 3.5  Algorithme d'ouverture d'un chier par DNA-OS

Ces deux tapes sont rptes pour chaque rpertoire du chemin. Cette faon de procder oblige considrer deux types d'inodes : un pour les rpertoires et un pour les chiers. tre parcourues par fatfs_walk(). Outre les lments communs classiques d'un inode (identiant, mtadonnes, etc.), un inode rpertoire contient galement l'ensemble des entres qu'il contient, an qu'elles puissent

De plus, compte tenu de la structure du systme FAT, pour accder facilement une entre de rpertoire pour en lire son contenu, il a t dcid que l'identiant d'un inode (entier de 64 bits retourn par fatfs_walk()) serait compos du numro de bloc du rpertoire parent sur les 32 bits de poids fort et le numro de l'entre dans le rpertoire pour les 32 bits de poids faible.

3.4.3 Description des fonctions du composant logiciel FATFS

Les principales fonctions ncessaire la lecture d'un volume FAT sont :  fatfs_mount() : Cette fonction lit le volume id grce aux fonctions incluses dans la bibliothque et construit la structure de donnes fatfs, puis lit le vnode racine et l'enregistre en mmoire.  fatfs_read_vnode() : Cette fonction enregistre les mtadonnes de l'lment (chier ou rpertoire) dsign par l'identiant pass en paramtre. Si l'entre lue est un rpertoire, les entres qu'il contient sont galement misent en mmoire. Cette fonction utilise la bibliothque pour lire les secteurs dans l'ordre en tenant compte de la FAT.  fatfs_walk() : Cette fonction cherche l'entre correspondante au nom donn en paramtre dans le vnode pass en paramtre et retourne l'identiant de l'entre trouve telle que dni prcdemment.  fatfs_open() : Cette fonction est prvue normalement pour vrier les permissions d'accs un chier. Or, comme le systme de chiers FAT ne gre pas cette fonctionnal-

3. Intgration du systme de chiers FAT

17

it, cette fonction se contente de retourner les mtadonnes du chier partir du vnode correspondant.  fatfs_close() : Comme la fonction fatfs_open() ne cre pas d'objet en mmoire, cette fonction ne fait rien.  fatfs_read() : A partir des mtadonnes donnes par fatfs_open(), cette fonction lit sur le disque les secteurs contenant les octets compris entre oset et oset + nombre d'octet qui sont des paramtres. Comme pour fatfs_read_vnode(), cette fonction utilise la bibliothque pour tenir compte de la FAT.

3.5 Programmation et tests

La programmation (en langage C) a dmarr plusieurs semaines aprs la dcouverte du sujet, le temps de comprendre la structure globale de DNA-OS et du fonctionnement de son VFS. Plusieurs jours ont galement t ncessaires pour se familiariser avec la structure du systme de chiers FAT et le fonctionnement de la bibliothque. De plus, dcider de la manire de reprsenter un inode FAT pour sparer le parcours d'un chemin en deux fonctions lmentaires pris plus de temps que la programmation elle-mme. Les fonctions ont t crites dans l'ordre mentionns ci-dessus et testes dans le mme ordre puisqu'elles sont dpendantes des prcdentes. Le test des fonctions programmes s'est d'abord fait sur simulateur avant de les valider en excutant un programme de test sur la carte ATMEL D940.

3.5.1 Test sur simulateur

Le simulateur mule une architecture similaire celle de la carte ATMEL, sur laquelle est excute DNA-OS. Un composant logiciel spcique de DNA-OS permet d'accder des chiers du systme hte lorsque DNA-OS est excut sur un simulateur. J'ai utilis cette fonctionnalit pour accder un chier de donnes brutes (chier raw data obtenu par la commande dd de Linux) format en FAT32. La premire tape a t d'acher le contenu du Volume ID de ce volume virtuel aprs le montage pour tester le bon fonctionnement de fatfs_mount(). J'ai ensuite cr des dossiers et chiers (via Linux) sur le volume virtuel pour tester les fonctions fatfs_read_vnode() et fatfs_walk(). J'ai ach l'cran le contenu des secteurs lus ainsi que les valeurs retournes par les fonctions et compar le contenu de ces secteurs avec ceux retourns par les fonctions de la bibliothque (dans sa version d'origine) pour l'accs au mme chier sur le mme volume. Pour tester les dernires fonctions fatfs_open() et fatfs_read() et valider les prcdentes, j'ai vri que les donnes lues (provenant d'un chier texte) depuis mon application de test excute par DNA-OS tait bien celles contenues dans le chier.

3.5.2 Test sur la carte ATMEL D940

volume ID, j'ai ralis le dernier test eectu sur le simulateur mais cette fois avec DNA-OS et
Aprs avoir vri que le montage du volume se faisait correctement par achage du mon application excuts sur la carte ATMEL (les donnes provenant de la carte mmoire SD formate en FAT32 insre dans le lecteur de carte de la carte D940).

18

3. Intgration du systme de chiers FAT

Enn, le test ultime pour valider le composant logiciel FATFS a t d'excuter un serveur HTTP lger sur la carte ATMEL et d'accder un mini site web depuis le rseau, dont le contenu tait stock sur la carte SD.

3.6 Analyse et rsultats

3.6.1 Rsultats et amliorations possibles
A l'heure actuelle, grce au composant logiciel programm, le systme DNA-OS est capable d'accder un chier, enregistr sur un priphrique format en FAT32, et de lire les donnes qu'il contient. Cependant, lors de la ralisation du deuxime objectif (qui demandait la lecture de chier d'une centaines de kilo-octet) il est apparu que la lecture de ce chier par la carte D940 prenait plusieurs secondes, tout comme la montage du volume. Il est apparu galement, lors de la validation du composant logiciel, que l'accs un chier dont le chemin faisait rfrence au rpertoire parent (contenait  .. ) tait beaucoup plus long. La cause de ces problmes n'a pas t clairement identie et peut venir du composant logiciel FATFS ou du pilote du lecteur de carte de la plateforme D940. Malgr le soin apport lors de l'criture du code et les nombreuses modications de la bibliothque pour l'allger, le code du composant reprsente environ 2000 lignes et une taille compil d'environ 8 kilo-octets ce qui alourdi grandement DNA-OS et reste problmatique pour son utilisation dans le programme de dmarrage. Grce l'utilisation de la bibliothque de Rob Riglar, qui gre de faon transparente la lecture des secteurs en tenant compte de la FAT et les nuances entre FAT16 et FAT32, le composant logiciel FATFS est capable de lire aussi bien des partitions formates en FAT16 qu'en FAT32. Cependant, aucun test n'a t fait avec des partions en FAT16 du fait que ce systme de chiers est beaucoup plus rarement utilis que le FAT32. Concernant l'criture de donnes sur une partition FAT, celle-ci ne faisait pas partie du premier objectif car elle tait inutile pour la ralisation du programme de dmarrage. De plus, le mcanisme d'criture de chiers sur un volume FAT est beaucoup plus compliqu que la simple lecture. Pour une bonne intgration, la programmation des fonctions lis l'criture demanderait au moins autant de temps que la programmation des fonctions de lecture, ce qui n'aurait pas permis la ralisation du deuxime objectif. En rsum, on peut dire, que le premire objectif du stage a t rempli bien que des amliorations peuvent tre apportes pour obtenir un composant logiciel plus rapide l'excution et un code compil plus lger. Dans un second temps, la prise en charge de l'criture pour se composant peut tre dveloppe.

19

Chapitre 4

Cration d'un programme de dmarrage

La principale fonction du programme de dmarrage (bootloader ) et de charger le binaire de l'application aux bons emplacements mmoire de la plateforme. Il convient donc de savoir comment est organis le code binaire dans l'excutable gnr par le compilateur (paragraphe 4.1). Dans le but d'obtenir plus de modularit, il a t dcid que le programme de dmarrage soit capable de dmarrer la mme application avec des options direntes. Le paragraphe 4.2 dtaille le formalisme et la mthode pour transmettre ces arguments. Le paragraphe 4.3 dcrit le programme ralis.

4.1 Le format ELF

ELF (Executable and Linkable Format ) [5] est un format de chier informatique binaire utilis pour l'enregistrement de code compil. Il est depuis 1999 le type de chier excutable sur tous les systmes de type UNIX. C'est galement dans ce format que sont compils les applications incluant DNA-OS et les autres composants de APES. Chaque chier ELF est constitu d'un en-tte xe, puis de segments et de sections. Les segments contiennent les informations ncessaires l'excution du programme contenu dans le chier, alors que les sections contiennent les informations pour la rsolution des liens entre fonctions et le replacement des donnes.

4.1.1 Les sections

Les sections, identies par un nom unique, peuvent contenir du code machine, du texte, des symboles, des informations de r-allocation pour la rsolution des liens, etc. Les sections sont dcrits par une structure de donnes contenant principalement les champs suivants :  name : Le nom de la section.  type : Le type de la section.  oset : La position du code de la section depuis le dbuts du chier.

20

4. Cration d'un programme de dmarrage

 address : L'adresse de la section en mmoire aprs chargement.  size : Le nombre d'octets du segment dans le chier.  ags : Des attributs x, r ou w si la section, contient du code qui doit tre excut (une section contenant du code machine), est accessible en lecture ou en criture (pour une section contenant des variables). Ces structures sont rassembles dans un tableau en dbut de chier ELF.

Le format ELF dnit un certain nombre de sections standard. Les principales sections que l'on retrouve dans un excutable intgrant DNA-OS sont :  .bss : Cette section contient les variables non initialises.  .data et rodata : Pour les variables initialises. Dans la section .rodata les sections sont accessibles en lecture seulement.  .text : Le code machine des instructions du programme.  .shstrtab et .strtab : Ces sections contiennent les noms des sections et des symboles.  .symtab : Cette section contient la table des symboles. Dans un excutable intgrant DNA-OS, on trouve galement les sections particulires suivantes :  .reset et .excep : Ces sections contiennent le code d'initialisation et les vecteurs d'interruption.  .hal et os_config : Ces sections contiennent les valeurs des symboles propres la HAL et la conguration de DNA dnies dans le chier de commande de l'diteur de lien (nomm ldscript, voir paragraphe 4.1.3).

4.1.2 Les segments

Comme nous cherchons charger le binaire nal seuls les segments (ou program header ) nous intressent. Les segments sont en fait des regroupements de sections avec des attributs particuliers. Les segments sont dcrits par une structure de donnes contenant principalement les champs suivants :  type : Le type du segment qui peut signier entre autres, que le segment est ignorer, contient des notes (informations de versions, etc.), possde des informations pour l'dition de liens dynamique o est du code machine. C'est ce dernier cas qui nous intresse ici.  oset : La position du code du segments depuis le dbuts du chier.  virtual address : L'adresse virtuelle du dbut du segment. Cette valeur est intressante si le programme est charg par un systme d'exploitation dot d'une MMU (Memory Management Unit ) et capable d'excuter plusieurs applications en parallle.  physical address : L'adresse physique laquelle le segment doit tre charg. Dans notre cas une seule application est charge et elle inclut le systme d'exploitation dans son binaire. Cette donc cette valeur qui nous intresse.  le size : Le nombre d'octets du segment dans le chier.  memory size : Le nombre d'octets que doit occup le segment en mmoire. Si le segment doit contenir des variables non initialises, la taille du segment dans le chier sera dirente de la taille rserve en mmoire. Ces structures sont rassembles dans un tableau en dbut de chier ELF.

4. Cration d'un programme de dmarrage

L'annexe A montre le contenu d'un chier ELF.

21

4.1.3 Le chier ldscript

Lors du processus de compilation, au moment de l'dition des liens entre les dirents chiers objets intermdiaires, l'diteur de liens s'appuie sur un chier, appel ldscript (voir annexe B), qui dcrit l'organisation mmoire de l'excutable nal (emplacement des sections, point d'entr du programme, etc.). Dans ce chier ldscript peuvent tre spcis des symboles faisant rfrences des adresses mmoires reprsentant des objets particuliers (informations de dbogage, fonctions, variables, etc.). L'ajout de symboles, en plus de ceux crs automatiquement grce au code source (variables et fonctions utilises par le programme) permet de crer des objets en mmoire sans le faire dans le programme mais qui peuvent tre utiliss par celui-ci. Ce mcanisme est utilis dans le noyau de DNA-OS pour certaines structures globales, mais galement par le programme de dmarrage pour transmettre des paramtres au programme charger.

4.1.4 Accs aux structures

L'accs aux structures se fait l'aide d'une bibliothque [6] qui fournit les accesseurs permettant la lecture des principales informations des segments et sections partir de l'adresse pointant sur la premier octet du chier ELF. Cela impose d'avoir pralablement copi en mmoire la totalit du chier ELF depuis le priphrique de stockage. J'ai complt cette bibliothque par l'ajout de certains accesseurs manquants dont j'avais besoin. J'ai galement ajout un ensemble de fonctions permettant la lecture des symboles contenus dans le ELF, utile pour le passage des arguments.

4.2 Passage des arguments

Le programme de dmarrage ore la possibilit de passer des arguments aux composants du noyau de DNA-OS an de le dmarrer avec des options direntes. Ces options sont renseignes dans un chier texte selon le format suivant :
# Une ligne commenant par # est un commentaire # Le premier mot d'une ligne constitue l'option. # Tous les caractre suivants les caractres d'espacements # aprs le nom de l'option constitue son paramtre. option1 paramtre de l'option 1 option2 paramtre de l'option 2 # Une option peut ne pas avoir de paramtre. option3

Ce chier est lu et analys par le programme de dmarrage an de remplir la structure de donnes suivante :

22
struct _dna_arg { int argc; char * arg_opt[]; char * arg_param[]; };

4. Cration d'un programme de dmarrage

O argc est un entier reprsentant le nombre d'arguments, arg_opt est un tableau de chanes de caractres dont chaque lment est le nom d'une option et arg_param est galement un tableau de chanes de caractres dont chaque case contient le paramtre de l'option. Les tableaux arg_opt et arg_param sont indics dans le mme ordre. Si une option n'a pas de paramtre associ, le paramtre enregistr est une chane vide (contenant le caractre nul \0). L'adresse mmoire o est enregistre cette structure est ensuite copie l'adresse pointe par le symbole DNA_ARG_ADDR pour que le programme charg en ait connaissance. Cette adresse est ensuite passe chaque fonction de DNA-OS qui est libre d'analyser le contenu de la structure pour vrier si une option la concerne.

4.3 Description du programme de dmarrage

Comme un programme de dmarrage est trs dpendant du systme sur lequel il s'excute, il a t dcid de l'crire lui-mme sous la forme d'une application utilisant des composants APES an de bncier de tous les avantages de APES.

4.3.1 Structure du programme de dmarrage

L'organigramme du programme est donn par la gure 4.1. Le programme commence par traiter les arguments. Il lit et analyse le chier des arguments pour crer en mmoire et remplir la structure _dna_arg. Dans un second temps, le programme lit l'intgralit du chier ELF et copie tel-quel son contenu en mmoire. C'est aprs, grce aux accesseurs de la bibliothque, que le programme va slectionner les sections charger pour les copier leurs adresses physiques. Enn, le programme va chercher le symbole DNA_ARG_ADDR pour remplacer sa rfrence par l'adresse de la structure _dna_arg avant de sauter au point d'entre du programme charg. Comme le but du programme de dmarrage est de copier en mmoire le binaire de l'application, le programme doit d'abord tre capable de lire ce binaire situ sur un priphrique de stockage. C'est une des raisons pour laquelle le composant FATFS a t crit. En crivant le programme de dmarrage sous forme d'application APES, avec le composant FATFS il est ais de lire le binaire contenu sur une carte mmoire formate en FAT32. Il en est de mme pour le chier contenant les arguments. La bibliothque ELF permet d'accder aisment aux segments utiles l'excution du programme (ceux de type PT_LOAD). Elle permet galement l'accs au symbole DNA_ARG_ADDR. Enn, le saut au point d'entre du programme (adresse de la premier instruction) permet de stopper l'excution du bootloader et dmarrer l'application excuter.

4. Cration d'un programme de dmarrage

start

23

Lire le chier des arguments

Crer et remplir la structure _dna_arg

Lire le chier ELF

Copier les segments de type PT_LOAD leur adresse physique Chercher le symbole DNA_ARG_ADDR Copier l'adresse de _dna_arg l'adresse pointe par DNA_ARG_ADDR Sauter au point d'entre du programme charg

Figure 4.1  Organigramme du programme de dmarrage

4.3.2 Espace mmoire du programme de dmarrage et du programme charg
Pour s'excuter et copier l'intgralit du chier ELF, le bootloader a lui aussi besoin d'espace mmoire. De plus la copie des segments leurs adresses physiques ne doit pas craser les instructions du programme en cours d'excution. Cependant, certains segments doivent se trouver imprativement une adresse physique donne. C'est le cas des segments contenant les vecteurs d'interruptions et le code d'initialisation. Cela n'est pas gnant de les craser car au moment de la copie le code d'initialisation a dj t excut. Pour remplacer les vecteurs d'interruptions, il sut de masquer pralablement les interruptions (d'autant que le bootloader est un programme simple qui n'est pas sens les utiliser). Le ldscript du bootloader et de l'application sont donc dirents et l'espace utilisable par l'application est divis par deux. C'est un des points amliorer.

4.3.3 Spcicit et gnricit

Le dveloppement du programme de dmarrage s'est fait pour la carte D940 et a t test directement sur celle-ci. L'application de test ( charger) dont je me suis servi n'utilise que le processeur principal. Bien qu'un bootloader soit forcment propre la plateforme sur laquelle il s'excute, le fait qu'il soit en lui mme une application APES le rend trs gnrique. Les dirences qui pourraient apparatre avec une autre architecture ne seraient pas au niveau du code mais au niveau des

24

4. Cration d'un programme de dmarrage

composants intgrs l'application, du compilateur utilis et du chier ldscript utilis lors de l'dition des liens. La spcicit du bootloader ne se fait rellement que dans ce chier. Pour le cas d'application utilisant deux processeurs htrognes, le bootloader serait identique. Puisque dans la majorit des cas, le processeur a accs la mmoire du processeur secondaire. Dans le cas de tuiles le procd peut tre plus compliqu. On peut imaginer deux cas : 1. Rassembler tous les binaires sur une carte mmoire et un bootloader principal irait charger chaque binaire sur la bonne tuile puis ensuite dmarrer chaque tuile. 2. Chaque tuile possde son propre bootloader qui chargerait le binaire de l'application. Quelque soit la solution envisage, le programme que j'ai dvelopp ore une structure simple (contenue dans environ 400 lignes de code) et facilement modiable pour ajouter le cas chant, le chargement d'autres binaires pour d'autres processeurs.

4.3.4 Problmatique du chargement du programme de dmarrage

Dans le cas d'un systme embarqu et de APES, l'application charger intgre le systme d'exploitation. Le programme de dmarrage est donc le premier programme excut et il devrait pouvoir se lancer sans intervention ds la mise sous tension de la plateforme. Sur la D940, la documentation prcise seulement que le systme ira charger l'adresse 0 de la mmoire un chier binaire nomm BOOT.BIN de moins de 40 kilo-octects si celui-ci est prsent sur une carte mmoire insre dans le lecteur. Bien que la modularit apporte par ce framework a pour but de fournir des applications lgres, il n'a pas encore t possible d'obtenir un binaire, intgrant tous les composants indispensables, susamment petit. Pour l'instant, le lancement du bootloader se fait par le port du dbogueur de la carte D940. C'est le second point amliorer.

4.4 Programmation et tests

La programmation (en langage C) du bootloader a commenc aprs avoir valid le composant FATFS et aprs avoir tudi pendant quelques jours le format ELF. J'ai commenc par travailler sur la bibliothque ELF en uniformisant les fonctions disponibles et en ajoutant les fonctions permettant l'accs aux symboles. J'ai ensuite crit le programme de dmarrage selon l'algorithme de la gure 4.1, d'abord sans le passage des paramtres. Une fois cette premire version valide, j'ai ajout la prise en charge des paramtres selon la mthode dcrite au paragraphe 4.2. Le dveloppement et la validation du programme s'est faite directement sur la carte D940. Le simulateur excutant le programme beaucoup moins rapidement que la plateforme, il tait fastidieux de devoir attendre plusieurs minutes pour lire et copier entirement le binaire de l'application charger, pour tester les tapes suivantes du bootloader. L'application de test ( charger) utilise lors du dveloppement, que j'ai crite, se contentait d'acher un message l'cran intervalles rguliers (grce une interruption). Cela a permis de s'assurer que les segments contenant les vecteurs d'interruptions taient bien pris en compte par le nouveau programme.

4. Cration d'un programme de dmarrage

25

Une fois ce test concluant, j'ai test le bootloader sur le simulateur. La seule modication a t de re-compiler l'application de test et le programme de dmarrage avec le ldscript du simulateur. Un dernier test a consist utiliser le bootloader pour charger une application plus lourde, contenant le serveur Web lger dont il est question dans le chapitre prcdent.

4.5 Analyse et rsultats

Le programme ralis est fonctionnel pour la carte D940. Peu de modications sont ncessaires (uniquement dans le chier de commande de l'diteur de liens) pour l'adapter une autre architecture (comme le montre l'essai avec le simulateur). Cela pourrait tre conrm avec d'autres essais sur d'autres cartes ou avec des application utilisant tous les processeurs de la carte. Il pourrait galement tre intressant de faire des essais avec une architecture tuiles en utilisant une des solutions cites au paragraphe 4.3.3. Toutefois, l'heure actuelle, le programme de dmarrage prsente deux dfauts. Le premier, majeur, est de ne pas pouvoir se lancer la mise sous tension de la plateforme (ou aprs un reset ). La solution n'est pas vidente car ce processus est trs dpendant de la plateforme. Cependant, la correction de ce dfaut devra passer par une rduction de la taille du code compil du programme de dmarrage (cela surait pour la carte D940). On peut aussi imaginer un bootloader primaire dpendant de la plateforme qui irait charger le programme de dmarrage, gnrique, ralis. Le second dfaut est que l'espace de l'application est divis par 2. La solution pourrait tre d'optimiser les chiers ldscript de l'applications et du bootloader en prenant garde que l'espace disponible pour le bootloader soit susant pour charger l'application et que le chargement du code de l'application n'altre pas l'excution du bootloader. Le premier dfaut peut tre relativis dans le cas d'architecture tuiles si l'on opte pour la solution 1 du paragraphe 4.3.3, puisque un seul chargement manuel serait ncessaire pour dmarrer les applications sur chaque tuile (contrairement un chargement manuel pour chaque tuile sans programme de dmarrage). En rsum, on peut dire que le deuxime objectif est globalement rempli puisque le programme de dmarrage ralis est capable de charger une application intgrant DNA-OS (avec passage de paramtres) sur un systme embarqu. Le programme ralis est simple et gnrique, et peut fonctionner pour d'autres architecture sans demander de grosses modications. Enn, il est facilement adaptable pour des architectures base de tuiles.

26

Chapitre 5

Conclusion
Ce stage, eectu au laboratoire TIMA, portait sur l' Extension des services d'un systme d'exploitation embarqu  et tait compos de deux objectifs : la prise en charge du systme de chiers FAT32 par le systme d'exploitation embarqu et la ralisation d'un programme de dmarrage. Ce stage s'inscrivait dans le projet APES visant fournir des outils logiciels facilant la programmation d'applications pour systmes embarqus. La plus grande dicult du premier objectifs, qui devait permettre au systme d'exploitation DNA-OS de pouvoir accder des chiers contenus sur un priphrique format en FAT, rsidait dans la dirence de formalisme entre le VFS de DNA-OS intgr au noyau et la bibliothque utilise, dont le composant logiciel programm dpend. A l'heure actuelle, le composant logiciel est fonctionnel en lecture mais pourrait tre optimis pour s'excuter plus rapidement et occup moins de place en mmoire. Le second objectif consistait en la ralisation d'un programme dont le but est de charger une application sur le systme embarqu. Ce programme peut servir de base pour la ralisation d'un programme de dmarrage plus volu capable de charger une application s'xcutant sur une architecture complexe base de tuiles. A l'heure actuelle, le frabiquant de la carte de test n'a pas transmis les informations necssaires pour permettre au programme de dmarrage de se lancer automatiquement. Cependant, celui-ci est capable de charger une application sur un systme embarqu. Il a t conu sous forme d'application intgrant DNA-OS ant d'tre le plus gnrique possible. Ces travaux, s'intgrant au projet APES, sont diuss librement (license GNU General Public License) et seront disponible sur le site du laboratoire (http ://tima-sls.imag.fr/ ) partir du mois de septembre 2010.

27

Annexe A

Exemple de contenu d'un chier au format ELF

La commande readelf sous un environnement UNIX permet d'acher de manire lisible le contenu d'un chier ELF. Appliqu sur le binaire d'une application compile pour la plateforme D940 (avec le ldscript de l'annexe B) on obtient les sorties d'cran suivantes.

A.1 En-tte du chier

ELF Header : Magic : 7 f 45 4 c 46 01 01 01 61 00 00 00 00 00 00 00 00 Class : ELF32 Data : 2 ' s complement , little endian Version : 1 ( current ) OS / ABI : ARM ABI Version : 0 Type : EXEC ( Executable file ) Machine : ARM Version : 0 x1 Entry point address : 0 x300000 Start of program headers : 52 ( bytes into file ) Start of section headers : 870608 ( bytes into file ) Flags : 0 x2 , has entry point , GNU EABI Size of this header : 52 ( bytes ) Size of program headers : 32 ( bytes ) Number of program headers : 8 Size of section headers : 40 ( bytes ) Number of section headers : 23 Section header string table index : 20

A.2 En-tte des sections

Section Headers : [ Nr ] Name [ 0] [ 1] . debug_aranges [ 2] . debug_info Type NULL PROGBITS PROGBITS Addr 00000000 00000000 00000000 Off 000000 028910 02 af60 Size 000000 002650 057752 ES Flg Lk Inf Al 00 0 0 0 00 0 0 8 00 0 0 1

Annexes

A. Exemple de contenu d'un chier au format ELF

[ 3] . debug_abbrev PROGBITS 00000000 0826 b2 01206 f 00 0 0 1 [ 4] . debug_line PROGBITS 00000000 094721 02220 a 00 0 0 1 [ 5] . debug_ranges PROGBITS 00000000 0 b692b 000 ab8 00 0 0 1 [ 6] . debug_str PROGBITS 00000000 0 b73e3 009 bfc 01 MS 0 0 1 [ 7] . debug_frame PROGBITS 00000000 0 c0fe0 003 f18 00 0 0 4 [ 8] . debug_loc PROGBITS 00000000 0 c4ef8 00 b488 00 0 0 1 [ 9] . debug_pubnames PROGBITS 00000000 0 d0380 002 fd7 00 0 0 1 [10] . comment PROGBITS 00000000 0 d3357 001488 00 0 0 1 [11] . reset PROGBITS 00300000 008000 000020 00 AX 0 0 16 [12] . excep PROGBITS 00300020 008020 0001 c0 00 AX 0 0 16 [13] . text PROGBITS 20800000 010000 012564 00 AX 0 0 16 [14] . rodata PROGBITS 20812568 022568 000878 00 A 0 0 4 [15] . data PROGBITS 20812 de0 022 de0 005 ac4 00 WA 0 0 16384 [16] . os_config PROGBITS 208188 a8 0288 a8 000034 00 WA 0 0 1 [17] . hal PROGBITS 208188 e0 0288 e0 000030 00 WA 0 0 1 [18] . bss NOBITS 20822910 02 a910 001100 00 WA 0 0 4 [19] . ARM . attributes ARM_ATTRIBUTES 00001488 0 d47df 000010 00 0 0 1 [20] . shstrtab STRTAB 00000000 0 d47ef 0000 e1 00 0 0 1 [21] . symtab SYMTAB 00000000 0 d4c68 006500 10 22 1199 4 [22] . strtab STRTAB 00000000 0 db168 002 bff 00 0 0 1 Key to Flags : W ( write ) , A ( alloc ) , X ( execute ) , M ( merge ) , S ( strings ) I ( info ) , L ( link order ) , G ( group ) , x ( unknown ) O ( extra OS processing required ) o ( OS specific ) , p ( processor specific )

A.3 En-tte des segments

Program Headers : Type LOAD LOAD LOAD LOAD NULL NULL NULL LOAD Offset 0 x008000 0 x008020 0 x010000 0 x022568 0 x000000 0 x000000 0 x028910 0 x02a910 VirtAddr 0 x00300000 0 x00300020 0 x20800000 0 x20812568 0 x20823a10 0 x20820910 0 x00000000 0 x20822910 PhysAddr 0 x00300000 0 x00300020 0 x20800000 0 x20812568 0 x20823a10 0 x20820910 0 x00000000 0 x20822910 FileSiz 0 x00020 0 x001c0 0 x12564 0 x063a8 0 x00000 0 x00000 0 xabecf 0 x00000 MemSiz 0 x00020 0 x001c0 0 x12564 0 x063a8 0 x00000 0 x00000 0 x00000 0 x01100 Flg R E R E R E RW R R R RW Align 0 x8000 0 x8000 0 x8000 0 x8000 0 x1 0 x1 0 x8 0 x8000

Section to Segment mapping : Segment Sections ... 00 . reset 01 . excep 02 . text 03 . rodata . data . os_config . hal 04 05 06 . debug_aranges . debug_info . debug_abbrev . debug_line . debug_ranges . debug_str . debug_frame . debug_loc . debug_pubnames . comment 07 . bss

29

Annexe B

Exemple de chier ldscript

Ci-aprs est visible le chier ldscript utilis pour la compilation d'une application sur la platefrome D940. Dans ce chier ldscript, on distingue trois parties : 1. MEMORY : Cette partie permet de dnir les zones mmoire utilisables. 2. PHDRS : Cette partie dnit les segments et leur types. 3. SECTIONS : Cette partie dcrit toutes les sections du programme. Pour chaque section il est prcis quel zone mmoire et quel segments elle est ratache. Pour certaine sections, des symboles sont dnis directement dans le ldscript.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

ENTRY ( _start ) STARTUP ( crt0 . o ) GROUP ( - lc - lgcc ) MEMORY { reset : ORIGIN = 0 x00300000 , memory : ORIGIN = 0 x20800000 , } PHDRS { reset PT_LOAD ; excep PT_LOAD ; text PT_LOAD ; data PT_LOAD ; heap PT_NULL ; stack PT_NULL ; debug PT_NULL ; bss PT_LOAD ; } SECTIONS { . debug_aranges 0 x0 : { *(. debug_aranges *) } : debug . debug_info 0 x0 : { *(. debug_info *) } : debug . debug_abbrev 0 x0 : { *(. debug_abbrev *) } : debug . debug_line 0 x0 : { *(. debug_line *) } : debug . debug_ranges 0 x0 : { *(. debug_ranges *) } : debug

LENGTH = 0 x0000C000 LENGTH = 0 x00800000

Annexes
30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69

B. Exemple de chier ldscript

. debug_str 0 x0 : { *(. debug_str *) } : debug . debug_frame 0 x0 : { *(. debug_frame *) } : debug . debug_loc 0 x0 : { *(. debug_loc *) } : debug . debug_pubnames 0 x0 : { *(. debug_pubnames *) } : debug . pdr 0 x0 : { *(. pdr *) } : debug . comment 0 x0 : { *(. comment *) } : debug . gnu . attributes 0 x0 : { *(. gnu . attributes *) } : debug . reset 0 x00300000 : { *(. reset ) } > reset : reset . excep ALIGN (0 x8 ) : { *(. excep ) } > reset : excep . init 0 x20800000 : { *(. init *) } > memory : text . ctors ALIGN (8) : { *(. ctors *) } > memory : text . text ALIGN (8) : { *(. text *) } > memory : text . fini ALIGN (8) : { *(. fini *) } > memory : text . dtors ALIGN (8) : { *(. dtors *) } > memory : text . jcr ALIGN (8) : { *(. jcr *) } > memory : text . sdata ALIGN (8) : { *(. sdata *) *(. scommon *) } > memory : data . sbss ALIGN (0 x8 ) : { *(. sbss *) } > memory : bss . rodata ALIGN (0 x8 ) : { *(. rodata *) } > memory : data . reginfo ALIGN (0 x8 ) : { *(. reginfo *) } > memory : data . data ALIGN (0 x8 ) : { *(. data *) *(. glue_7 *) *(. eh_frame *) } > memory : data . os_config ALIGN (0 x8 ) : { OS_N_DRIVERS = .; LONG (0 x2 ) OS_DRIVERS_LIST = .; LONG ( d940_system_module ) LONG ( d940_mmc_module ) OS_N_FILESYSTEMS = .; LONG (0 x3 ) OS_FILESYSTEMS_LIST = .; LONG ( rootfs_module ) LONG ( devfs_module ) LONG ( fatfs_module ) OS_N_MODULES = .; LONG (0 x1 ) OS_MODULES_LIST = .; LONG ( mmc_module ) /* LONG ( mbr_module ) */ OS_THREAD_STACK_SIZE = .; LONG (0 x8000 ) OS_KERNEL_HEAP_ADDRESS = .; LONG ( ADDR (. kheap ) ) OS_KERNEL_HEAP_SIZE = .; LONG (0 x100000 ) OS_DNA_ARG_ADDR = .; LONG (0 x0 ) ; } > memory : data . hal ALIGN (0 x8 ) : { APP_ENTRY_POINT = .; LONG ( _main ) ; CPU_OS_ENTRY_POINT = system_kickstart ; CPU_SVC_STACK_ADDR = ABSOLUTE ( ADDR (. sysstack ) ) ;

70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87

Annexes
88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117

31
= ABSOLUTE ( ADDR (. irqstack ) ) ; = ABSOLUTE ( ADDR (. fiqstack ) ) ;

CPU_IRQ_STACK_ADDR CPU_FIQ_STACK_ADDR

CPU_BSS_START = .; LONG ( ADDR (. bss ) ) CPU_BSS_END = .; LONG ( __hal_bss_end ) PLATFORM_BMX_BASE = .; LONG (0 xFFFFEE00 ) PLATFORM_AIC_BASE = .; LONG (0 xFFFFF000 ) PLATFORM_DBGU_BASE = .; LONG (0 xFFFFF200 ) PLATFORM_PIOA_BASE = .; LONG (0 xFFFFF400 ) PLATFORM_PIOB_BASE = .; LONG (0 xFFFFF600 ) PLATFORM_PIOC_BASE = .; LONG (0 xFFFFF800 ) PLATFORM_PMC_BASE = .; LONG (0 xFFFFFC00 ) PLATFORM_SYSC_BASE = .; LONG (0 xFFFFFD00 ) PLATFORM_MCI_BASE = .; LONG (0 xFFFA8000 ) } > memory : data . sysstack ALIGN (0 x8 ) + 0 x8000 : { } > memory : stack . fiqstack ALIGN (0 x8 ) + 0 x1000 : { } > memory : stack . irqstack ALIGN (0 x8 ) + 0 x1000 : { } > memory : stack . bss ALIGN (0 x8 ) : { *(. bss *) *(. rel *) *( COMMON ) __hal_bss_end = .; } > memory : bss . kheap ALIGN (0 x8 ) : {} > memory : heap } . uheap ALIGN (0 x8 ) + 0 x100000 : { _end = .;} > memory : heap

32

Table des gures

2.1 Structure de APES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 La carte ATMEL DIOPSIS 940HF . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8

3.1 Structure d'un volume FAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2 Accs aux donnes d'un chier sur un volume FAT . . . . . . . . . . . . . . . . . 12 3.3 Place du VFS entre l'utilisateur et le priphrique . . . . . . . . . . . . . . . . . . 13 3.4 Algorithme d'ouverture d'un chier par la bibliothque . . . . . . . . . . . . . . . 15 3.5 Algorithme d'ouverture d'un chier par DNA-OS . . . . . . . . . . . . . . . . . . 16 4.1 Organigramme du programme de dmarrage . . . . . . . . . . . . . . . . . . . . . 23

33

Bibliographie
[1] X. Gurin, F. Ptrot,  A System Framework for the Design of Embedded Software Targeting Heterogeneous Multi-Core SoCs , in 20th IEEE International Conference on

Application-specic Systems, Architectures and Processors (ASAP'09), Boston (Ma), USA, July 7-9, IEEE Computer Society, pages 153-160, 2009 [2] X. Gurin, Approche ecace de dveloppement de logiciel embarqu pour des systmes multiprocesseurs sur puce, thse de doctorat, Grenoble Universits, Mai 2010 [3] Microsoft Corporation,  FAT: General Overview of On-Disk Format  in Hardware White Paper, Version 1.02, 1999

[4] Rob Riglar, FAT16 / FAT32 File IO Library, http://www.robs-projects.com/, Mai 2010 [5] Tool Interface Standards (TIS),  Executable and Linkable Format (ELF) , in Portable Formats Specications, Version 1.1, 1993 [6] University of New South Wales, LibELF, http://www.cse.unsw.edu.au/, Juin 2010

Etudiant : Entreprise : Adresse complte : Tlphone :

BESSON Paul Laboratoire TIMA 46, avenue Flix Viallet 38031 GRENOBLE Cedex +33 4 76 57 45 86

3i4

Tlcopie : +33 4 76 57 49 81

Responsable administratif : BORRIONE Dominique Directrice Tlphone : +33 4 76 57 49 82 Ml : Dominique.Borrione@imag.fr Matre de stage : Tlphone : Ml : Tuteur enseignant : Tlphone : Ml :
ROUSSEAU Frdric +33 4 76 57 46 41 Professeur

Frederic.Rousseau@imag.fr

LAVAULT Yves +33 4 56 52 00 60

yves.lavault@imag.fr

Titre : Extension des services d'un systme d'exploitation embarqu Rsum :

Pour faciliter la programmation d'applications destines tre excutes sur des systmes embarqus architecture htrogne, le laboratoire TIMA a imagin l'environnement de dveloppement APES (APplication Elements for System on chips ). Cet environnement comprend un ensemble de composants logiciels incluant un systme d'exploitation lger appel DNA-OS. Le premier objectif de ce stage consiste en la programmation d'un nouveau composant logiciel pour l'environnement APES permettant au systme d'exploitation DNA-OS de lire des donnes contenues sur une mmoire secondaire (carte mmoire) formate selon le systme de chiers FAT (File Allocation Table ). Le second objectif consiste en la ralisation d'une application utilisant le composant nouvellement conu pour crire un programme de dmarrage capable de charger le binaire d'une application depuis une carte mmoire et lancer son excution sur le systme embarqu.