Amorçage du système Cours #2 - ELE-674 Systèmes embarqués avancés
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
ELE-674
Systèmes embarqués avancés
Cours #2
Amorçage du système
Bruno De Kelper
Site internet :
http://www.ele.etsmtl.ca/academique/ele674/
Cours # 2 ELE674 – Systèmes embarqués avancés 1
Plan d’aujourd’hui
1. Amorçage d’un système
1. Démarrage du CPU
2. Démarrage sur un PC
3. Démarrage sur un système embarqué
4. Partie OS de l’amorçage
2. Conception du système
1. Survol des composantes du système
2. Chargeur d’amorçage (BootLoader)
3. Noyau du système d’exploitation
4. Système de fichiers
3. Outils de conception du système
1. Émulation avec QEMU
2. Conception du système avec BuildRoot
Cours # 2 ELE674 – Systèmes embarqués avancés 2
Cours # 1 ELE784 - Ordinateurs et programmation système 1
Amorçage d’un système
1.1 - Démarrage du CPU
RAM Flash
Lorsque l’alimentation
est appliquée, le CPU Alimentation
se réveille sans rien
connaitre de son
environnement. ? ?
La seule chose qu’il ?
connait est sa ROM
ROM
interne.
? ?
?
Celle-ci contient un peu
de code qui permet de Port série
commencer l’initialisation
Ethernet
du système
Cours # 2 ELE674 – Systèmes embarqués avancés Port USB 3
Amorçage d’un système
1.2 - Démarrage sur un PC Beaucoup de l’environnement
du CPU est connu d’avance
BIOS ou équivalent
• Initialise les composantes du système, tels que les
contrôleurs :
RAM, interruptions, bus PCI, …
• Fournit un pilote de base pour le Disque Dur.
• Se charge en mémoire
• Démarre le chargement du « BootLoader » :
Peut être d’assez
• Pour finir, le BIOS se met en mode « service ».
grosse dimension
• Sert essentiellement à démarrer l’OS et disparait ensuite
BootLoader • Linux GRUB, LILO, …
• Windows NTLDR, …
Cours # 2 ELE674 – Systèmes embarqués avancés 4
Cours # 1 ELE784 - Ordinateurs et programmation système 2
Amorçage d’un système
1.3 - Démarrage sur un système embarqué
Le CPU « saute » à une L’environnement du CPU est très
adresse bien précise de variable, d’un système à un autre
la ROM ROM code
• Initialise quelques composantes essentielles du CPU :
Horloge, Mémoire-interne, Périphériques de base
• Cherche un dispositif contenant un BootLoader valide.
• Charge le BootLoader trouvé en mémoire-interne :
SD Flash NAND, NOR
ROM-interne assez petite • Pour finir, le ROM code se retire du système.
(initialisée par le fabricant)
• Fait le gros de l’initialisation du système :
BootLoader • Bus, cache et Mémoire externe
• Principaux périphériques du système
• Interruptions, …
Linux + (ARM, PowerPC)
• Charge et décompresse l’OS en mémoire
• Son travail fait, le BootLoader disparait du système
U-Boot • Linux RedBoot, Yamon, Grub, LILO, U-Boot, …
Cours # 2 ELE674 – Systèmes embarqués avancés 5
Amorçage d’un système
1.4 - Partie OS de l’amorçage
2
Monte
Système 1 Initialise
Loader
fonctionnel Système
Boot
Noyau RootFS Init prêt
paramètres
de
démarrage
3
4
• Finalise l’initialisation tel • Le 1er RootFS provient d’un fichier « initrd »
que le MMU (virtualisation Système de fichier « initramfs »
de la mémoire), … chargé dans un « RAM Disk »
• Récupère, décompresse et • Ce RootFS contient :
installe le RootFS. • Fichiers des modules et pilotes du système
• Exécute « linuxrc », démarre • Fichiers des librairies et de configurations
les pilotes et les Daemons. • Outils, logiciels, …
• Démarre la 1ière tâche : INIT • Surtout, le RootFS permet la « virtualisation » du
système voir les composantes du système
comme des « fichiers virtuels »
Cours # 2 ELE674 – Systèmes embarqués avancés 6
Cours # 1 ELE784 - Ordinateurs et programmation système 3
Conception du système
2.1 - Survol des composantes du système
• Choisir un BootLoader U-Boot
Boot • Configurer le BootLoader Datasheet
Loader • Compiler le BootLoader Toolchain
• Choisir un emplacement de stockage NAND, SD,
UART, USB
• Choisir un Noyau Linux
• Configurer le Noyau Requis du système
Noyau
• Compiler le Noyau Toolchain NAND, SD,
• Choisir un emplacement de stockage UART, USB,
NFS
NAND, SD,
• Choisir un emplacement de montage NFS, RAM
RootFS • Choisir un type de RootFS Linux
• Configurer et peupler le RootFS Requis du système
Cours # 2 ELE674 – Systèmes embarqués avancés 7
Conception du système
2.2 - Chargeur d’amorçage
2.2.1 - Rôle et défis d’un chargeur d’amorçage
Rôle :
• Le rôle du chargeur d’amorçage (BootLoader) est de rendre le système
suffisamment fonctionnel pour que d’autres programmes puissent être exécutés.
• Au démarrage, le CPU est dans un état prédéfini et commence son exécution à
une adresse bien précise dans la mémoire permanente du système.
• Aucunes des composantes du système ne sont fonctionnelles, y compris la
mémoire RAM, et c’est le rôle du BootLoader de leur « insuffler la vie ».
Défis :
• Au début de son exécution, le BootLoader n’a pas accès ni à de la mémoire RAM
pour stocker ses données, ni à une pile.
• Une 1ière tâche du BootLoader est de rendre disponible la mémoire RAM et la pile,
en initialisant correctement le contrôleur de DRAM et en configurant le CPU.
• Sa 2ième tâche importante est de se copier lui-même dans la mémoire RAM, afin de
poursuivre son exécution plus aisément.
• Finalement, le BootLoader doit récupérer le Noyau, selon l’emplacement où celui-
ci se trouve, le décompresser et l’installer dans la mémoire RAM.
Cours # 2 ELE674 – Systèmes embarqués avancés 8
Cours # 1 ELE784 - Ordinateurs et programmation système 4
Conception du système
2.2 - Chargeur d’amorçage
2.2.2 - Choix d’un chargeur d’amorçage
• Souvent, le chargeur d’amorçage (BootLoader) est fournit par le fabricant de la
plateforme de développement utilisée.
• Par contre, si celui-ci est bien adapté pour l’architecture matérielle de la
plateforme de développement, il ne l’est pas nécessairement pour un système
personnalisé.
• Dans la plupart des cas, un BootLoader doit être choisit et adapté à un Design
spécifique de système embarqué.
• De nombreux BootLoader sont disponibles, tant commercialement que
publiquement (à code ouvert).
• De ceux-ci, certainement le plus populaire pour les projets basés sur Linux est
Das U-Boot, communément appelé U-Boot, de Wolfgang Denk (DENX Software
Engineering).
• À la base, U-Boot a été développé spécifiquement pour les systèmes embarqués
basé sur les ARM et PowerPC, mais supporte maintenant une vaste gamme de
processeurs.
Cours # 2 ELE674 – Systèmes embarqués avancés 9
Conception du système
2.2 - Chargeur d’amorçage
2.2.3 - Chargeur d’amorçage U-Boot
• U-Boot est disponible à partir de plusieurs sources, dont la principale est :
http://www.denx.de/wiki/U-Boot
• Outre sa grande popularité pour les systèmes embarqués basés sur Linux, U-Boot
a les avantages suivants :
• Est très configurable • Bien documenté
• Est capable d’amorcer un Noyau à • Supporté par une large communauté
partir de différentes sources :
• Support pour une vaste gamme de
TFTP IDE SCSI UART processeurs :
USB NAND NOR SD ARM AVR32 Blackfin
• Supporte une vaste gamme de Motorola 68K Microblaze
systèmes de fichiers :
Cramfs ext2 FAT Xilinx MIPS NIOS
JFFS2 … NIOS2 PowerPC Super-H
• Fournit un interpréteur de • Fournit une riche gamme de
commandes (shell) commandes
Cours # 2 ELE674 – Systèmes embarqués avancés 10
Cours # 1 ELE784 - Ordinateurs et programmation système 5
Conception du système
2.2 - Chargeur d’amorçage
2.2.4 - Configurer U-Boot Pour une plateforme supportée
• U-Boot a été adapté pour plus de 300 plateformes U-Boot
différentes et de nombreux processeurs include
configs
• Pour configurer et compiler U-Boot pour une de ces plateformes, il suffit
d’exécuter les commandes suivantes :
1 make mrproper Pour faire le ménage
2 make omap3630sdp_config Pour établir la configuration
Réfère à une règle du fichier Makefile de U-Boot
3 make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- all
Architecture du CPU Compilateur « croisé » à utiliser
• Ces commandes font référence aux inscriptions suivantes du Makefile de U-Boot :
omap3630sdp_config : unconfig
@./mkconfig $(@:_config=) arm omap3 omap3630sdp
Réfère au fichier de configuration : include/configs/omap3630sdp.h
Cours # 2 ELE674 – Systèmes embarqués avancés 11
Conception du système
2.2 - Chargeur d’amorçage
2.2.4 - Configurer U-Boot Pour une plateforme non-supportée
• Pour une nouvelle plateforme, le mieux est d’abord d’identifier une plateforme
existante similaire et si possible de l’utiliser comme point de départ.
• Il s’agit ensuite de procéder aux étapes suivantes : Plateforme omap3630sdp
comme point de départ
copier
1
/include/configs/omap3630sdp.h fichier /include/configs/omap3630NEW.h
2
copier
/board/omap3630sdp répertoire /board/omap3630NEW
3 Ajouter la règle suivante au fichier Makefile :
omap3630NEW_config : unconfig
@./mkconfig $(@:_config=) arm omap3 omap3630NEW
• Pour finir, il s’agit de modifier les fichiers « clonés » selon les caractéristiques de
la nouvelle plateforme et selon les besoins.
• Ce dernier point requière une bonne connaissance de la plateforme matérielle et
du processeur qu’elle contient (voir Datasheets du CPU et des composantes).
Cours # 2 ELE674 – Systèmes embarqués avancés 12
Cours # 1 ELE784 - Ordinateurs et programmation système 6
Conception du système
2.2 - Chargeur d’amorçage
2.2.4 - Configurer U-Boot Pour un CPU non-supportée
• Pour un nouveau processeur, le travail de configuration est beaucoup plus ardu et
requière une connaissance profonde du fonctionnement du nouveau CPU.
• Ici aussi, le mieux est d’abord d’identifier un CPU existant similaire et si possible
de l’utiliser comme point de départ.
• Aux étapes précédentes s’ajoute alors l’étape suivante : Processeur OMAP3
comme point de départ
copier
2.1
/cpu/omap3 répertoire /cpu/omap3NEW
• Certains fichiers de ce répertoire sont en code Assembleur et s’occupe des toutes
premières phases de démarrage du processeur (ex. : start.S).
• Pour finir, il s’agit de modifier les fichiers « clonés » selon les caractéristiques de
la nouvelle plateforme, du nouveau processeur et selon les besoins.
Cours # 2 ELE674 – Systèmes embarqués avancés 13
Conception du système
2.2 - Chargeur d’amorçage
2.2.4 - Configurer U-Boot
• U-Boot est principalement par le « fichier de configuration » adapté pour la
plateforme choisie :
/include/configs/.h
• Ce fichier contient de nombreuses déclarations prenant les formes suivantes :
Options configurables par l’usager qui active
#define CONFIG_XXXX
des fonctionnalités spécifiques.
Réglages spécifiques, souvent de type
#define CONFIG_SYS_XXXX
« réglages matériels ».
#define CONFIG_CMD_XXXX Incorporation de commandes standards
choisies à la liste des commandes exécutables.
• Par exemple, certaines déclarations usuelles :
CONFIG_ETHADDR CONFIG_SYS_CONSOLE_INFO_QUIET
CONFIG_IDENT_STRING CONFIG_SYS_CLK_FREQ
CONFIG_BOOTDELAY CONFIG_CMD_FLASH
CONFIG_BOOTCMD CONFIG_CMD_DHCP
Cours # 2 ELE674 – Systèmes embarqués avancés 14
Cours # 1 ELE784 - Ordinateurs et programmation système 7
Conception du système
2.2 - Chargeur d’amorçage
2.2.5 - Utiliser U-Boot
• U-Boot fournit jusqu’à 70 commandes standards servant à contrôler ses actions.
Obtenir de l’aide sur Afficher les variables
help printenv
les commandes
exemples
Quelques
d’environnement
Démarrer le code se Copie de la mémoire RAM
bootm cp
trouvant en mémoire vers la mémoire Flash
loadb Charger en mémoire à Charger un Noyau à
l’aide du lien série bootp
partir d’un site DHCP
• Ces commandes sont accessibles grâce à l’interpréteur de commandes de U-Boot.
• Pour finir, U-Boot exige de recevoir le Noyau dans un certain format et fournit un
script qui permet de faire la conversion : Adresse mémoire
Type d’OS du chargement
Nom du
Architecture Type de fichier
script
mkimage –A arm –O linux –T kernel –a 0x30008000
Note :
Les Noyaux Linux –e 0x30008000 –n zImage uImage
récents font cette Fichier résultant
conversion. Adresse mémoire Fichier à
du point d’entrée convertir
Cours # 2 ELE674 – Systèmes embarqués avancés 15
Conception du système
2.2 - Chargeur d’amorçage
2.2.6 - Cas particulier : Amorçage d’un OMAP de Texas Instruments
• Les processeurs OMAP de TI utilisent une séquence d’amorçage en 4 étapes :
(voir http://omappedia.org/wiki/Bootloader_Project)
Power ON
ROM interne RAM interne RAM externe RAM externe
Vecteur
ROM
de X-Loader U-Boot Noyau
code
Reset
BootLoader divisé en 2 morceaux
• La raison de cette division du BootLoader est de fournir un BootLoader « minimal »
pouvant être chargé dans la petite mémoire RAM interne du processeur.
ROM
X-Loader U-Boot
code
SYSBOOT
GPIO pins
• Initialise une configuration • Attribue les fonctionnalités • Finalise l’initialisation de
minimale des horloges, de la des signaux externes base du système
mémoire et des périphériques
• Initialise les horloges et la • Établit les arguments de
• Cherche un dispositif ayant mémoire externe démarrage du Noyau
une image d’amorçage valide
• Charge U-Boot dans la • Démarre le Noyau à
• Charge X-Loader dans la mémoire externe et le partir de son image
mémoire interne et le démarre démarre
Cours # 2 ELE674 – Systèmes embarqués avancés 16
Cours # 1 ELE784 - Ordinateurs et programmation système 8
Conception du système
2.3 - Noyau du système d’exploitation
2.3.1 - Rôle et défis du Noyau
Rôle :
• Le Noyau est le cœur du système et rend accessible l’ensemble des ressources
du système aux applications-usagers.
• Il s’assure de maintenir la cohérence et la stabilité du système, tout en assurant
un accès performant aux ressources.
• Il offre un interface d’accès (API) standardisé aux ressources, afin de rendre le
système indépendant des caractéristiques sous-jacentes des ressources.
Défis :
• Au début de son exécution, le Noyau reçoit du BootLoader un système partiellement
fonctionnel et il doit en compléter l’initialisation.
• L’initialisation étant terminée, le Noyau se place en mode « service », mais reste en
mémoire pendant toute la « vie » du système.
• Le Noyau d’un système embarqué doit limiter ses fonctionnalités aux seules qui sont
vraiment requises car l’espace-mémoire est habituellement très limité.
• Finalement, le Noyau doit offrir des mécanismes efficaces qui permettent au système
de répondre aux évènements dans les délais spécifiés.
Cours # 2 ELE674 – Systèmes embarqués avancés 17
Conception du système
2.3 - Noyau du système d’exploitation
2.3.2 - Choix d’un Noyau
• De nombreux Noyaux conçus spécifiquement pour les systèmes embarqués sont
disponibles, tant commercialement que publiquement ou même artisanales.
• À prime abord, ce qu’on recherche d’un Noyau, ce sont ses fonctionnalités et sa
capacité d’être adapté à une plateforme spécifique (configurable).
• Mécanismes de réponse aux évènements
• Gestion des ressources et outils disponibles
Fonctionnalités
• Interfaces d’accès aux ressources
• Robustesse, fiabilité, prédictibilité
• Taille et charge imposés par le Noyau
Configurable • Prise en charge des ressources spécifiques
• Extensibilité, adaptabilité, …
• Mais de nombreuses autres considérations rentrent en ligne de compte dans le
choix d’un Noyau :
Compatibilité
Documentation Outils
Coûts
Dépendance
Support Réutilisation
Disponibilité Standards
Base de connaissance
Cours # 2 ELE674 – Systèmes embarqués avancés 18
Cours # 1 ELE784 - Ordinateurs et programmation système 9Conception du système
2.3 - Noyau du système d’exploitation
2.3.2 - Choix d’un Noyau
Critères Commerciale Publique
Coûts Achat de licence, Royautés Gratuit, Achat de version « clé en main »
Support Support « expert », contrat de support Communauté, Version « clé en main »
Compatibilité Spécifique à l’architecture Très varié (CPU 32 bits et +)
Disponibilité Limitée, Marché d’échelle illimitée
Documentation Limitée par la propriété commerciale Très vaste, peut manquer de fiabilité
Base de Bassin de clientèle Vaste communauté
connaissance
Réutilisation Limitée Très grande
Outils Propriétaires Variés et publiques
Standards Certains standards repectés Établit des standards
Dépendance Grande vis-à-vis le fournisseur Aucune
Pour toutes ces raisons et d’autres, Linux s’impose de plus en plus comme choix
privilégié pour les nouveaux projets de systèmes embarqués au près des entreprises
Cours # 2 ELE674 – Systèmes embarqués avancés 19
Conception du système
2.3 - Noyau du système d’exploitation
2.3.3 - Noyau Linux pour système embarqué
• Il n’y a pas de Noyau-Linux spécifiquement conçu pour les systèmes embarqués.
• Linux étant très « configurable », il se prête bien à ce type de système. En fin de
compte, Linux-embarqué est un Noyau-Linux customisé.
• Par contre, Linux n’est pas bien adapté pour les petits systèmes embarqués, dont
les ressources sont très limitées.
• CPU 32 bits
Linux
embarqué ≥ •
•
Mémoire ROM 32 MB
Mémoire RAM 64-128 MB
• Outre ces limitations, Linux est bien adapté à une très large gamme de
plateformes et fournit une infrastructure solide de réseau (très recherché dans les
systèmes embarqués modernes).
• Pour les aspects de contraintes Temps-Réel, Linux est très performant pour le
respect de contraintes dites « fermes » et « molles ».
• Certains ajouts à Linux, tels que Xenomai et la patch Real-Time, permettent de
s’approcher grandement du respect de contraintes Temps-Réel dites « dures ».
Bien que beaucoup de la patch Real-Time a trouvé sont
chemin dans le Noyau-Linux officiel, ces dernières années
Cours # 2 ELE674 – Systèmes embarqués avancés 20
Cours # 1 ELE784 - Ordinateurs et programmation système 10Vous pouvez aussi lire
