Linux embarqué

Transcription

Linux embarqué

7
Modélisation et mise en place
du projet
Une fois que l’on sait ce qu’il possible de faire, la modélisation est l’étape de mise
en forme des idées, de concrétisation schématique, d’imagination avant développement. Un projet doit répondre à une problématique initiale : on doit tracer les
grandes lignes architecturales, et penser dès le début aux problèmes graves qui
pourraient survenir par la suite. Certains choix peuvent sembler prématurés, mais
il n’en est rien : penser au système de fichier et à l’allure générale du système permet
d’estimer les futures possibilités d’intégration de logiciels – et donc la couverture
fonctionnelle envisageable –, tout autant que d’entrevoir le système de mises à jour.
Certains réflexes sont à mettre en place, une approche rigoureuse et en harmonie
avec le modèle du Libre pourront garantir le succès du projet. Pour finir, une revue
des différentes sources externes d’informations a pour but de rendre autonome et
de donner une dynamique dans le travail autour du Libre dans l’embarqué.
Définir la problématique
La définition d’une problématique relative à Linux embarqué est la même que pour
tout projet embarqué. Les contraintes supplémentaires à intégrer sont celles du
support matériel, de l’espace mémoire (vive et de stockage) et des performances :
il faut veiller à ce qu’une des nombreuses solutions Linux que nous avons déjà
évoquées puisse répondre aux fonctionnalités souhaitées du projet, sans quoi il
faudra réviser l’ensemble du système pour que les deux aspects matériel et logiciel
puissent s’accorder. En milieu industriel, dans une optique de production, il est
inutile d’essayer de repousser par soi-même les limites du système Linux, surtout
lorsqu’on débute : si un projet n’est recensé nulle part, la probabilité que cela ne
soit pas possible est très fortement probable (dans le cadre d’un budget concevable).
© 2011 Pearson Education France – Linux embarqué – Gilles Blanc
LE.indb 147
08/11/11 16:47
148
Penser son projet
Partie 2
Apprendre à schématiser son projet
"Un bon croquis vaut mieux qu’un long discours", disait Napoléon. Déjà pratiqué
en embarqué tant au niveau matériel que logiciel, le schéma sous forme de blocs
logiques, représentant autant de "briques logicielles", parfois même de "sousbriques", est devenu très à la mode et très pertinent pour le modulaire Linux. On
le nomme block diagram. Il donne une vue d’ensemble du système très agréable à
comprendre et très synthétique. On note cependant régulièrement des vues de l’esprit assez contestables quant à la réalité technique.
D’une manière générale, on fait figurer le bootloader juste au-dessus du matériel,
puis le noyau et ses modules, sur lequel repose le système de base, et enfin les
couches applicatives de plus haut niveau.
Les schémas-blocs des Figures 7.1 à 7.4 sont issus de documentations officielles et
donnent une idée de ce qu’il est possible d’envisager en termes de représentation
(adaptés pour des raisons d’impression).
User Experience
Netbook
Application Framework
Clutter and M Libraries
Handset
Application Framework
MeeGo Touch Framework
Other
Application
Framework
MeeGo APIs
Core OS
Security
Security Frameworks
and Enablers
System
Device State and Resource
Policy mgmt, Sensor, Context
Essentials
Base Essentials
Communications
Telephony, IM, Connection
Management, Bluetooth
Data Management
Metadata Storage
Location
Location Framework
Multimedia
Multimedia related
enables and drivers
Qt
Qt, QtWRT, Qt Mobility
SW Management
Package management
and Software Lifecycle
Graphics
X11, Open GL, Input,
and Display Drivers
Personal Info Mgmt
Calendar, Contacts,
Bacup and Sync
Kernel
Linux Kernel
and core drivers
Hardware Adaptation
Figure 7.1
Architecture de MeeGo (©meego.com).
LE.indb 148
08/11/11 16:47
Chapitre 7
Modélisation et mise en place du projet
149
APPLICATIONS
Home
Contacts
Phone
Browser
...
APPLICATION FRAMEWORK
Activity
Manager
Package
Manager
Window
Manager
Telephony
Manager
Content
Providers
Resource
Manager
View
System
Location
Manager
LIBRARIES
Notification
Manager
ANDROID RUNTIME
Surface
Manager
Media
Framework
SQLite
Core
Libraries
Open GL / ES
FreeType
WebKit
Dalvik Virtual
Machine
SGL
SSL
libc
LINUX KERNEL
Display Driver
Camera Driver
Flash Memory Driver
Binder (IPC) Driver
Keypad Driver
WiFi Driver
Audio Drivers
Power Management
Figure 7.2
Organisation d’Android (http://code.google.com/android/images/
system-architecture.jpg).
Network
Services
Control
Services
Internet
Services
Connection
Management
CAN
Webkit
libpv
IP Autoconfig
Visual
Services
Media
Services
QT
gstreamer
JSON-D-Bus
Bridge
Camera
Middleware
Layer
Codecs
Audio
Settings Database
System Libraries
Message Bus
gconf
glib, libudev...
D-Bus
Glibc - POSIX
Driver
Driver
Driver
Linux Kernel
System
Layer
OS
Layer
Driver
Driver
Driver
Figure 7.3
Vue d’un système Linux embarqué industriel par Pengutronix (http://www.pengutronix.de/
development/web/index_en.html).
LE.indb 149
08/11/11 16:47
150
Penser son projet
Partie 2
Web Browser
IM
Terminal
Book Reader
(Stylus Applications)
net
(others)
Contacts
Messages
Application Manager
core
Search
(others)
Dialer
Main Menu
Media Player
Clocks
(others)
(Finger Applications)
X11
Applications
(3rd Party Applications)
UI
PIM
(OpenMoko Application Framework)
udev
blueZ
dbus
GSM
matchbox
GTK+2
kdrive 7
libX11
GPS
Linux Core Services
(Linux User Interface)
Linux 2.6 Kernel & Device Drivers
Mobile Handset Hardware
Figure 7.4
Architecture d’OpenMoko (http://www.theinquirer.net/inquirer/news/1026841/
a-truly-linux-phone-gps-debuts).
Comprendre l’environnement hardware
La principale différence qui distingue l’informatique embarquée de l’informatique "standard" est la connaissance nécessaire du système matériel. Si le pertinent
Dijkstra disait que "l’informatique ne relève pas plus des ordinateurs que l’astronomie des téléscopes", pour l’embarqué il faut faire une exception.
Un système embarqué comporte de nombreuses subtilités par rapport à un système
matériel "standard". Sans pouvoir être exhaustif, on peut débroussailler les principales caractéristiques et permettre d’éviter les pièges.
Un environnement matériel peut être découpé comme suit :
■
Un CPU pour les calculs et les Entrées/Sorties (I/O), autour duquel tout est
organisé. Il peut proposer :
U une gestion poussée de sa consommation électrique;
U un ou plusieurs cœurs.
LE.indb 150
08/11/11 16:47
Chapitre 7
151
NOTE
Un fort bon aperçu de l’architecture ARM, en français, par François Armand : http://
www.pps.jussieu.fr/~armand/M2_SEM/Supports_Cours/03_ArchProc_4p.pdf.
■
De la RAM : très rarement plus de 256 Mo.
■
Un stockage des données sur différents supports, le plus souvent de la mémoire
flash.
■
Des entrées-sorties à usage général (General Purpose Input Output, GPIO) :
sous forme de paire de "pins", on peut faire passer ou non du courant (de 2 à
5 V), soit en entrée (détection) soit en sortie (commande).
■
Un bus de communication I²C (ou I2C), pour les communications assez lentes
(un fil de données, un fil d’horloge).
■
Un port JTAG (abus de langage pour Boundary Scan ou TAP) : accédant directement aux fonctionnalités bas niveau du CPU, il est possible de scruter son
fonctionnement, de déboguer du logiciel (par points d’arrêt matériels et lecture
des registres ou de la mémoire), ou encore de programmer la mémoire flash
(c’est-à-dire d’écrire des données dessus).
■
Des bus UART (Universal Asynchronous Receiver Transmitter), RS-232 ou
port série : il s’agit d’un port ancestral simple et efficace, très utilisé, supporté
par tous les CPU et présent sur quasiment toutes les cartes, mais dont l’encombrement peut le faire disparaître au profit de ports physiques plus "ramassés",
par exemple sur la BeagleBoard de TI, qui nécessite un adaptateur ; la plus
récente BeagleBoard-xM possède bien en revanche un classique port DE-9M,
plus courant et donc plus pratique.
■
Un bus USB : peu nombreuses sont à présent les cartes qui ne gèrent pas le très
pratique et rapide Universal Serial Bus (certains CPU de la gamme OMAP de
TI proposent de transformer nativement les bus UART en USB). Il en existe
deux versions (1.1 et 2.0 en embarqué, bientôt 3.0) et trois sortes sont rencontrées sur les cartes :
U USB hôte ou maître ou concentrateur : il gère la configuration et les trans-
ferts de données lors de la connexion (typiquement ce que l’on trouve sur
un PC, ce port alimente en 5 V) ;
U USB esclave ou device ("gadget" sous Linux) : l’autre côté du port (typique-
ment, une clé USB ; ce port nécessite d’être alimenté pour fonctionner), avec
lequel la communication va être établie (une carte peut à la fois comporter
un USB esclave et un USB maître) ;
LE.indb 151
08/11/11 16:47
152
Penser son projet
Partie 2
U USB On-The-Go (OTG) : c’est une extension de USB 2.0 (uniquement) que
l’on peut configurer logiciellement pour être utilisé en tant que maître ou en
tant qu’esclave, sachant que sur le bus il ne peut y avoir qu’un seul maître
à la fois.
■
Un lecteur de carte SD : de plus en plus présent, il permet d’étendre les capacités de stockage, mais aussi de démarrer un système entier dessus.
■
Un port Ethernet ou RJ45 : de plus en plus présent, ce standard de la connectique réseau est essentiellement, en embarqué, du 10/100 Mbit/s (attention à
l’absence d’auto-négociation, qui impose dès lors soit un câble droit soit un
câblé croisé).
Certaines cartes sont très génériques, elles proposent des "modules" sous forme de
cartes-filles, qui peuvent permettre, par exemple, de changer le CPU.
La technologie flash est très particulière :
■
L’organisation du stockage se fait par blocs, et une écriture implique d’effacer
un bloc (c’est-à-dire mettre tous ses octets à 0xFF – ou tous les bits à "1" –, et
non à 0x0 comme on pourrait le penser) avant de fixer les données modifiées,
stockées un moment en RAM.
■
Le nombre de cycles d’écriture par bloc limite sa durée de vie.
■
Il existe de la flash NOR et de la flash NAND :
U la NOR est lente en écriture, mais permet d’adresser aléatoirement et rapi-
dement n’importe quelle position : elle permet le XIP (eXecute In Place :
exécution sans avoir à recopier le binaire en mémoire RAM);
U la NAND est plus rapide, mais ne dispose que d’un accès séquentiel aux
données, sans être garantie à 100 % ;
U la NOR est de bien meilleure qualité mais beaucoup plus chère que la
NAND. Cette dernière permet donc de disposer de bien plus d’espace
de stockage. C’est ainsi que certaines plateformes matérielles proposent
simultanément, par exemple, 1 Mo de NOR et 64 Mo de NAND.
■
La représentation mémoire de la flash est sur le même plan d’adressage que la
RAM, ce qui peut permettre le XIP sur de la flash NOR, si le noyau est configuré pour et que le système de fichiers supporte la fonctionnalité.
Il est nécessaire de lire le manuel du CPU contenu dans le BSP. Il s’agit souvent
d’un document très long, de l’ordre de 300 à 400 pages, dont il faut rapidement tirer
les informations essentielles dès que l’on veut développer au sein du noyau ou que
l’on doit s’attaquer à la phase de démarrage.
Le démarrage d’un tel système nécessite un chargeur d’amorçage ou bootloader.
Nous allons étudier plus avant l’architecture ARM à titre d’exemple.
LE.indb 152
08/11/11 16:47
Chapitre 7
153
Le bootloader gère en réalité peu de choses absolument nécessaires au démarrage
d’un noyau Linux. Le CPU démarre à l’adresse 0x0 (on verra plus loin l’astuce qu’il
met en place pour cela lorsque la flash n’est pas de type NOR : le Steppingstone).
Le bootloader est alors exécuté. Il exécute un certain nombre d’instructions similaires au démarrage de Linux, afin de gérer plus ou moins complètement la carte.
Un bootloader complet dispose d’une console d’administration, gère le réseau, etc.
Surtout, il permet de modifier la ligne de commande du noyau, et de pointer vers le
noyau qui nous intéresse (s’il y en a plusieurs) avant de le démarrer.
Pour la phase de démarrage, le bootloader copie le noyau à une certaine adresse
en RAM, calculée pour convenir à la copie (il faut qu’il y ait la place) et pour que
le noyau puisse correctement se décompresser sans s’écraser lui-même. L’adresse
de décompression est codée dans les fichiers de support de l’architecture, et donc
compilée dans le noyau. Puis, le bootloader initialise les différents registres du
CPU :
■
r0=0 : le registre 0 doit être à zéro (convention Linux) ;
■
r1=362 : ceci est un numéro d’architecture propre à Linux et reporté dans le
bootloader (sous formes de macros C), ici le SBC2440 ;
■
r2=0 : le registre 2 pointe vers les options de ligne de commande (0 signifie
au noyau d’utiliser la ligne de commande compilée d’après la configuration du
noyau) ;
■
sp=0x33D50000 : le registre pointant sur le sommet de pile d’exécution ;
■
pc=0x33D50000 : le registre pointant sur l’instruction à exécuter ;
■
lr=0x33D50000 : le registre pointant sur l’adresse de retour après appel de
procédure.
En réalité, les registres sp, pc et lr sont gérés par l’instruction assembleur d’appel de
procédure bl. Le bootloader U-Boot utilise intelligemment un pointeur de fonction
(en langage C) dont l’adresse est le noyau Linux en RAM, avec comme paramètre
0, le numéro d’architecture et le pointeur vers la ligne de commande. Le compilateur traduit donc cette simple instruction en correspondance avec ce qui a été
énoncé plus haut.
Avec une sonde JTAG, il faut bien procéder manuellement après l’arrêt du CPU, puis
demander son redémarrage. Depuis le débogueur gdb1, cela donne les instructions :
(gdb)
(gdb)
(gdb)
(gdb)
(gdb)
target remote localhost:3333
load ./S3C2440/linux-2.6.25/arch/arm/boot/compressed/vmlinux 0x33D50000
set $r0=0
set $r1=362
set $r2=0
1. La mise en place de l’environnement de développement et l’utilisation de ces outils seront étudiés
au Chapitre 13, Maîtriser GDB et gdbserver.
LE.indb 153
08/11/11 16:47
154
(gdb)
(gdb)
(gdb)
(gdb)
Penser son projet
Partie 2
set $sp=0x33D50000
set $pc=0x33D50000
set $lr=0x33D50000
c
Pour la configuration particulière de l’adressage de la flash et de la RAM, toujours
sur architecture ARM, on peut se reporter par exemple à cet extrait de schéma
(Figure 7.5), issu la documentation du Samsung S3C2440.
Figure 7.5
Organisation de
la mémoire sur
S3C2440.
0xFFFF_FFFF
Not used
0x6000_0000
SFR Area
0x4800_0000
0x4000_0FFF
0x4000_0000
BootSRAM (4KB)
SDRAM
(BANK7, nGCS7)
0x3800_0000
0x3000_0000
0x2800_0000
0x2000_0000
0x1800_0000
SDRAM
(BANK6, nGCS6)
SROM
(BANK5, nGCS5)
SROM
(BANK4, nGCS4)
SROM
(BANK3, nGCS3)
SROM
(BANK2, nGCS2)
0x1000_0000
0x0800_0000
0x0000_0000
SROM
(BANK1, nGCS1)
SROM
(BANK0, nGCS0)
On peut voir un découpage par tranches inégales, avec un étalement sur 4 Go
d’adressage à la fois de la flash ("SROM") et de la RAM ("SDRAM"), ce qui
implique des zones discontinues. Il faut y faire particulièrement attention lorsqu’on
charge en mémoire un noyau Linux, avant l’initialisation de la MMU, c’est avec
l’aide d’une sonde JTAG ou depuis le bootloader, que ce soit lui qui fasse la copie
du fichier-noyau ou que celui-ci soit chargé à travers le port série ou le réseau. En
effet, la zone de chargement en mémoire doit être contiguë depuis la flash.
De même, un autre piège pour ces architectures ne disposant pas de flash NOR est
le mécanisme de Steppingstone : 4 Ko de début de flash NAND sont copiés en RAM
pour démarrer, puis le CPU remappe les adresses pour qu’elles correspondent au
schéma ci-dessus ; cette opération s’effectue automatiquement dès que le pointeur
LE.indb 154
08/11/11 16:47
Chapitre 7
155
d’instruction dépasse 0x1000. Il ne faut donc en aucun cas utiliser les adresses à
partir de 0x0 pour démarrer un noyau via le JTAG ou lorsque le bootloader copie
en RAM le noyau avant de le démarrer : il ne rentrerait pas de toute façon, 4 Ko
correspondant à peine à une taille maximale de bootloader, au-delà de laquelle il
est obligé de se gérer en tranches ou stages. En revanche, l’adresse 0x33D50000,
citée dans l’exemple au-dessus, convient tout à fait pour le chargement du noyau ;
une autre adresse correctement calculée pourrait tout aussi bien fonctionner.
Jongler avec les systèmes de fichiers, premières
considérations architecturales
Premières approches
L’enregistrement des données utilisables par le système doit se faire selon une
procédure prédéterminée, un format de stockage selon un algorithme déterministe :
ce que l’on nomme "système de fichiers" (File System, FS en abrégé). Traditionnellement, dans l’embarqué, cette notion était inutile, ou réduite à son état le plus
simple : si les données ne sont pas "codées en dur" (directement dans le noyau),
elles sont fixées naïvement en contigu, et accolées au noyau, formant ce qui est
appelé un "blob" (binary large object).
Avec l’apparition de mémoire flash de stockage de tailles de plus en plus importantes, la possibilité d’enregistrer des données est apparue. Le noyau doit alors
présenter la possibilité de lire une table pointant vers les fichiers. Si le système de
fichiers supporte l’écriture, les fichiers seront forcément fractionnés, ce qui impose
un mécanisme plus complexe pour les gérer, plus coûteux en temps et en espace
de stockage.
Linux est encore une fois particulier : le noyau gère quantité de systèmes de fichiers,
adaptés pour certaines utilisations spécifiques, évidemment pour le bureau ou les
serveurs (ext3, ext4, ReiserFS, XFS, Btrfs, etc.), mais aussi pour l’embarqué. Ces
derniers systèmes de fichiers sont très particuliers, et en réalité peu répandus ;
si Linux en possède plusieurs, répondant à diverses problématiques, les systèmes
libres *BSD n’en possèdent aucun : les systèmes de fichiers FFS et UFS ne sont
utilisables que sur disque dur ou assimilé, CompactFlash par exemple, mais pas
directement sur de la mémoire flash.
Sur PC, chaque système de fichiers est contenu dans une "partition" dédiée, de type
IBM : dans la table des partitions, qui en contient quatre, les trois premières sont
nécessairement "primaires", puis un système de "partitions étendues" prend le relai.
Ce système primitif persiste malheureusement encore, même si des évolutions se
dessinent.
LE.indb 155
08/11/11 16:47
156
Penser son projet
Partie 2
NOTE
Seuls les systèmes *BSD ou Solaris s’en sont affranchis : c’est le système de slices, chacun
comportant un système de fichiers, et tous contenus dans une seule partition.
En utilisant EFI à la place du BIOS, le système de partitionnement est différent : il s’agit
du GPT.
Cependant, dans la plupart des systèmes embarqués, où la flash est adressable
directement depuis le CPU, Linux donne la possibilité de gérer dynamiquement
le partitionnement. Ce mécanisme et les considérations concernant le partitionnement seront étudiés plus tard, lorsque l’on se penchera sur la phase d’intégration
(Chapitre 12). On peut en tout cas considérer les systèmes de fichiers indépendamment du système de partitionnement sous-jacent.
Problématique
Le choix du ou des systèmes de fichiers à mettre en place pour une solution de
Linux embarqué doit intervenir très tôt dans la conception du projet. En effet, ce
choix a un impact sur l’organisation même du système.
Si le système est destiné à être stocké sur disque dur ou sur SSD2 – http://www.
linux-mag.com/cache/7590/1.html – la problématique est proche de celle des
serveurs. Il convient donc de se renseigner sur les systèmes de fichiers du moment
(par exemple ext4, Btrfs ou NILFS – New Implementation of a Log-structured File
System, à partir du noyau 2.6.30), sur leurs performances respectives, leur robustesse (en cas de coupure de courant, surtout au milieu d’une écriture de données),
leurs caractéristiques3, ainsi que sur les retours des utilisateurs. Il en va de même
pour une cible disposant d’une CompactFlash, c’est-à-dire géré par un contrôleur
de type IDE (interface TrueIDE), sur les plateformes x86 de type serveur (pour des
net appliances), faisant figure de disque SSD à bas coût. Le partitionnement est
alors de type IBM (on utilise la commande fdisk), et les systèmes de fichiers, là
encore, sont typiques d’une distribution standard "bureautique" ou "serveur".
NOTE
Pour les disques bon marché, Btrfs (dit aussi ButterFS) est alors recommandable pour sa
gestion de la compression, utile sur des Netbook ou TabletPC sur base Atom disposant
de peu d’espace disque : on peut ainsi doubler la taille du système stocké.
2. Essentiellement pour des plateformes de type PC, PowerPC ou PowerQUICC, intégrées dans des
châssis protégés, notamment des coupures de courant.
3. Notamment, est-ce que le système de fichiers (surtout s’il est récent) est supporté par le bootloader employé ? Dans le cas contraire, il ne pourra être utilisé que pour du stockage, et non pour
une partition système contenant le noyau (il est possible de dédier une partition à /boot).
LE.indb 156
08/11/11 16:47
Chapitre 7
157
Figure 7.6
Organisation
simple des partitions sur x86.
M
B
R
système Linux
[boot loader, noyau]
données
En réalité, le problème prend tout son sens avec l’immense majorité des machines
munies de mémoire de stockage flash, directement liées au CPU4 (sur architecture
ARM, MIPS ou SH4 par exemple). Les systèmes de fichiers sont alors gérés sous
Linux par le système MTD (Memory Technology Devices).
NOTE
Voir à ce sujet les URL :
m
http://www.linux-mtd.infradead.org/ ;
m
http://www.righthandtech.com/embedded-linux-managing-memory.php.
Un système de fichiers reposant, de par sa conception, sur MTD n’est pas utilisable
par IDE ; en revanche, il est possible d’utiliser n’importe quel système de fichiers
sur MTD, quoique cela soit une très mauvaise idée s’il n’a pas été pensé pour.
NOTE
Voir à ce propos : http://www.linux-mtd.infradead.org/faq/general.html#L_ext2_mtd.
Grâce au nouveau système UBI, il est cependant plus facile d’obtenir un système de
fichiers adressant la problématique flash à partir d’un système de fichiers "standard"
(voir plus bas).
Comme on l’a vu, la technologie flash est particulière, et implique de devoir utiliser
des systèmes de fichiers capables, lorsqu’ils supportent l’écriture, de niveler les
données écrites, afin d’optimiser le nombre de cycles d’écriture possibles (il s’agit
du wear leveling), et capable de ne pas perdre de données en cas de coupure brutale
du courant, ce qui n’est jamais à exclure sur ce type de machines, ne disposant
parfois pas même de bouton d’arrêt "logiciel", ou pouvant subir une coupure de
batterie inopinée.
Il faut d’abord se demander où sera stocké le noyau : sur une partition ou directement, "en dur" (hors système de fichiers) sur la flash ? La première solution est
moins sécurisée, un peu moins pratique à mettre en place, mais plus flexible sur le
long terme. On pourra en effet remettre à jour le noyau plus tard (pour ajouter des
fonctionnalités ou pour corriger de rares failles de sécurité) sur le même firmware
que l’ensemble du système, au lieu de procéder indépendamment. La seconde solution est élégante, le gestionnaire de démarrage (bootloader) se charge de pointer
sur une adresse de la mémoire flash, et le noyau est simplement chargé en RAM ou
4. Dans la littérature anglaise, on trouve les adjectifs bare ou raw.
LE.indb 157
08/11/11 16:47
158
Penser son projet
Partie 2
gardé sur la flash sans copie en RAM si l’on fait appel au XIP. Ce dernier définit
dynamiquement les différentes partitions sur le système grâce à ses options dans sa
ligne de commande (passée par le bootloader ou compilée statiquement).
NOTE
Il s’agit là du XIP pour le noyau, qui se configure indépendamment de celui pour l’espace utilisateur évoqué précédemment.
Il faut ensuite considérer l’espace de flash dont on dispose, et ce que l’on voudrait y
mettre : cela imposera l’utilisation ou non d’un système de fichiers compressé. Un
tel FS est plus consommateur en ressources de calcul mais peut faire gagner de 25
à 70 % de taille mémoire ! La limite de mémoire flash n’est pas la seule à pouvoir
orienter vers le choix de la compression. Il se peut qu’une mise à jour de firmware
impose un envoi via le réseau, ce qui implique de considérer les éléments suivants :
■
Le temps de transfert : par exemple sur un module GPRS, sans 3G.
■
Le coût de transfert : par exemple les forfaits téléphoniques avec Internet,
même "illimités", sont limités en données avant bridage ou coupure.
■
L’utilisation de la bande passante : la mise à jour simultanée à 4 h du matin
de quelques centaines de milliers de modems ADSL a ainsi été abandonnée
pour une solution désynchronisée.
■
L’espace mémoire disponible sur cible : sur un système Android, le firmware
est stocké sur la flash avant d’être appliqué lors du redémarrage, avec retour en
arrière possible, soit autant de multiplication de l’occupation d’espace mémoire
à prévoir.
On peut cependant, avant son envoi, compresser un firmware qui serait constitué
d’un système de fichiers non-compressé, et le décompresser directement sur la
flash une fois qu’il est chargé en RAM – autant dire que ce type d’opération ne peut
pas être effectué par un simple bootloader : on considèrera les politiques à mettre
en œuvre pour ce genre de mises à jour complexes au Chapitre 14. Il faut alors
considérer le temps d’écriture sur la flash, autant de temps durant lequel la machine
n’est probablement pas accessible, ce qui peut énerver plus d’un utilisateur, ou être
gênant pour le rendu d’un service qui ne doit souffrir que peu d’interruptions. C’est
aussi sans compter qu’une coupure de courant durant la phase de flashage impliquera de télécharger de nouveau le firmware.
Enfin, il faut se demander si l’on veut garder un accès en écriture sur le système
même. En effet, cela peut présenter un risque de sécurité (possibilité de modifier
des fichiers sur le système en cas d’intrusion, et donc de détourner l’usage de l’appareil ou le faire planter) ainsi qu’un potentiel risque de corruption des données. Un
système en lecture seule (read-only, RO) a aussi l’avantage, lorsqu’il est compressé
(c’est quasiment toujours le cas lorsque l’on met en œuvre ce type de solution), de
prendre bien moins de place qu’un FS en lecture-écriture (read-write, RW).
LE.indb 158
08/11/11 16:47
Chapitre 7
159
NOTE
Un système de fichiers compressé est basiquement une archive compressée : initramfs
est une archive cpio compressée par gzip. L’utilitaire 7zip sait ouvrir des images
CramFS et SquashFS.
En outre, il est monté beaucoup plus vite au démarrage, réduisant considérablement les temps de chargement. Il est cependant plus long ensuite lors des accès,
puisqu’une phase de décompression est nécessaire. Pour une partition système, cela
n’est pas vraiment un problème.
NOTE
Le montage consiste à faire reconnaître, à l’aide de l’appel système mount un système
de fichiers au noyau, qui l’associe alors à un point d’accès (ou point de montage) dans
l’arborescence des répertoires.
Figure 7.7
Partionnement
simple sur flash
(système de type
ARM), noyau
séparé de la partition principale.
boot loader
noyau
système Linux
NOTE
Sur les schémas, les zones grisées correspondent au padding. On se reportera au
Chapitre 14 pour des explications quant à ces zones mémoires inutilisées de tampon.
De plus, ces schémas ne sont pas à l’échelle, ils ne sont que la représentation de la
succession des différents blocs de données.
Le plus souvent, la méthode la plus propre consiste à scinder le système sur deux
partitions :
■
La première contient les exécutables et les fichiers de configuration qui constituent le coeur du système : elle est en lecture seule (RO).
■
La seconde contient les fichiers de configuration modifiés, les exécutables
rajoutés pour étendre le système, tout ce qui peut être stocké ou modifié : elle
est en accès-complet (RW).
Entre les deux, des liens dynamiques sont mis en place, pour donner la possibilité de modifier certains fichiers de configuration du système choisis (il est aussi
possible d’utiliser les fonctionnalités avancées de montage sous Linux, en "surchargeant" un répertoire par un autre à la volée, ou encore d’utiliser UnionFS ou aufs,
qui permettent de "fusionner" virtuellement des systèmes de fichiers).
LE.indb 159
08/11/11 16:47

Linux embarqué

Transcription

Documents pareils

Architecte Logiciel

Offres de stages

Administrateur Systèmes Linux

DCEmu sous Linux - MetaGames-EU

Formation Linux embarqué

Télécharger la fiche pdf

Fiche Jouez sous Linux

Stage Ingénieur: Développement Logiciel Embarqué

Linux Install Party