Fast boot sur Mini2440

Transcription

1 ENSEIRB-MATMECA 1, Avenue du Dr. Albert Schweitzer F Talence Cedex Spécialité Électronique - Option SE - 3 e Année Projet Avancé Fast boot sur Mini2440 Quentin Parrod, Fabien Forest, Jonathan Tirach, Nicolas Calmels, Jean-Baptiste Théou

2 Table des matières 1 Introduction Le projet Notre approche Les outils Compilation croisée Installation Création de la chaîne de compilation Utilisation Rootfs Construction Création de l image initramfs Busybox Configuration Application Compilation des bibliothèques Compilation de l application du Concours Linux Optimisation Optimisation de la chaîne de compilation Compilation avec la bibliothèque uclibc Configuration de uclibc Augmentation de l horloge, Timing de Nand Timing de Nand Augmentation de l horloge Optimisation du bootloader Les bootloaders évolués Les autres Optimisation de vboot Les optimisations Optimisation du noyau Partie 1 - Sans DHCP (ip static) État des lieux Conclusion - Sans DHCP Bonus - Patch de la pile

3 3.4.5 Partie 2 - Avec DHCP Conclusion - Avec DHCP Optimisation de l application Choix pour l application Analyse des sections Stack protector Unwind exceptions Suppression du code mort Piste Installation en Nor Conclusion 25 6 Références 26 7 Annexes 27 Quelques définitions 28 3

4 1 Introduction Le projet avancé de 3ème année, réalisé en équipe de 4 ou 5 personnes, a pour but de travailler sur un sujet touchant aux systèmes embarqués sur les aspects matériels et/ou logiciels. Nous allons en quelques mots présenter le projet et notre approche pour réduire le temps de boot. 1.1 Le projet Ce projet, initialement proposé par la société OpenWide dans le cadre d un concours, a été repris par notre groupe. L objectif de ce projet est d optimiser le temps de boot (démarrage à froid) d une application bien définie et cela sur la carte mini2440. L application est basée sur un noyau Linux. Les contraintes de ce projet sont spécifiées dans le cahier des charges du concours et ont été inchangées. Ces spécifications sont les suivantes : Démarrage d un noyau Linux sur une carte Mini2440 Obtention d une adresse IPv4 par DHCP Affichage de l adresse IP obtenue : Au format décimal séparé par des points Au centre de l écran en format paysage En noir sur fond rouge Avec une police non connue à l avance Avec une taille en pixel contenue dans le nom de fichier de la police Utilisation de la police de caractères TrueType (pour afficher l adresse IP) se trouvant dans la première partition (en ext4) de la carte SDHC (Sandisk 30 MB/s), et dont le nom commence par "concours-" suivi de la taille en pixel et de l extension ".ttf". Présence d une zone tactile, dans le coin inférieur droit, entraînant l affichage du nom de l auteur ou de l équipe, déclenchement de l action liée au bouton lors d un appui sur la surface de celui-ci (le reste de l écran ne doit pas déclencher cette action) Nous avons réalisé ce cahier des charges de la façon suivante, en ce qui concerne l interface graphique (page suivante) : 4

5 Figure 1.1 Interface graphique du concours 1.2 Notre approche Souhaitant maîtriser complètement notre projet, nous n avons pas voulu utiliser d outils tels que OpenEmbedded ou Buildroot, qui "cache" de notre point de vue une partie du travail, et qui donc ne sont pas appropriés dans le contexte actuel. Ensuite, d après le cahier des charges, notre système doit contenir les choses suivantes : Un noyau linux (minimal) avec les drivers pour : MMC (Memory card), LCD, TCP/IP Une bibliothèque pour gérer la police de type TTF Une bibliothèque pour gérer le tactile Un serveur DHCP Quelques outils de base pour récupérer les informations comme la taille de la police Après une recherche, nous avons fait le choix des outils suivant : Une bibliothèque pour gérer la police de type TTF : FreeType2 Une bibliothèque pour gérer le tactile : Tslib Quelques outils de base : Busybox La première partie du projet concerne donc la mise en place du projet, de façon fonctionnelle (avant toute tentative d optimisation). La seconde partie concerne nos différentes optimisations et leurs résultats. 5

6 2 Les outils 2.1 Compilation croisée La compilation croisée permet de compiler des programmes sur un hôte différent de la cible. Dans notre cas, la compilation est faite sur x86 (PC) à destination d un coeur ARM. Pour la création de la chaîne de compilation croisée, nous avons utilisé le script crosstool-ng. Il permet de compiler de A à Z une chaîne de compilation (en résumé, gcc + la bibliothèque C), avec un niveau d optimisation avancé, via l utilisation de menuconfig Installation Pour l installation, il faut récupérer la dernière version sur le site du projet puis se positionner dans le dossier "Compilation" pour pouvoir respecter l organisation présentée dans l introduction. Listing 2.1 Compilation de Crosstool-ng cp../ Sources / crosstool -ng -*. tar. bz2 tar xvzf crosstool -ng -*. tar. bz2 cd crosstool - ng -*./ configure make make install Nous avons maintenant l outil ct-ng à disposition Création de la chaîne de compilation Maintenant l outil à disposition, il faut le configurer. Pour configurer crosstool-ng, exécuter : Listing 2.2 Configuration de l outil./ ct - ng menuconfig On peut sélectionner les différents éléments de la chaîne de compilation. Une fois fait, on peut lancer la compilation. Listing 2.3 Compilation de la chaîne de compilation./ct -ng build.4 6

7 2.1.3 Utilisation La nouvelle chaîne de compilation est maintenant disponible (par défaut) dans le dossier personnel, dans le répertoire x-tools. Pour permettre une utilisation facile dans les compilations, on peut mettre en place les chemins dans le.bashrc Listing 2.4 Utilisation de la chaîne de compilation # Configuration de la chaine de compilation PATH = $HOME /x- tools /arm -<le nom de votre chaine ( none par defaut ) >- linux - < le nom de votre libraire C >/ bin : $PATH export PATH CROSS_ COMPILE = arm - < le nom de votre chaine ( none par defaut ) >- < le nom de votre libraire C >- CC ="${ CROSS_COMPILE } gcc -march =< votre architecture > -mtune =< votre processeur >" export CROSS_ COMPILE export CC Dans notre cas, avec la carte Mini2440 comme cible, cela donne : Listing 2.5 Utilisation de la chaîne de compilation PATH = $HOME /x- tools /arm - jbtheou - linux - uclibcgnueabi / bin : $PATH export PATH CROSS_COMPILE =arm - jbtheou - linux - uclibcgnueabi - CC ="${ CROSS_COMPILE } gcc -march = armv4t -mtune = arm920t " export CROSS_ COMPILE export CC La chaîne de compilation est donc maintenant pleinement utilisable. 2.2 Rootfs Nous allons maintenant créer notre système de fichier, qui sera utilisé, soit via un système de fichiers "usuel" (ext4, jffs2, etc), soit via un "système de fichiers" interne au noyau, initramfs. Dans le cadre de notre projet, nous avons fait le choix d utiliser initramfs comme système de fichiers Construction En respectant l organisation présentée en introduction, nous allons créer ce système de fichier dans le dossier rootfs. On crée tout d abord la structure standard du système de fichier de linux (page suivante) : 7

8 Listing 2.6 Création de l arborescence mkdir dev mkdir -p etc / init.d mkdir lib mkdir mnt mkdir proc mkdir sys mkdir - m 777 tmp mkdir var Nous avons le système de fichier "minimium". Il s agit de le "remplir" selon les besoins. Dans le cadre du concours, ce système de ficher est minimal. Il ne contient que le strict nécessaire (voir en Annexes) Création de l image initramfs. Pour créer une image initramfs de notre système de fichier, nous exécutons la commande suivante (en respectant toujours la structure en présentation) : Listing 2.7 Image pour l initramfs find. cpio - H newc - o >../ linux / initramfs. cpio Cette image peut être maintenant utilisée par le noyau linux. Dès qu on modifie le système de fichier (Modification d un fichier de configuration, ajout de binaire, etc), il faut recréer l image du système de fichier. 2.3 Busybox Dans l état actuel, nous avons un rootfs minimal qui nous permettra de démarrer dans le user-space. Cependant, il n est capable de rien faire. Pour avoir accès à une "trousse" minimum d applications, au sein d un seul exécutable, on utilise la boite à outils busybox Configuration Pour choisir les outils utiles, nous utilisons l outil de configuration "usuel" : Listing 2.8 Configuration make ARCH = arm menuconfig ( console ) make ARCH = arm xconfig ( graphique X) On peut compiler l outil en lui indiquant la localisation du système de fichier, pour l installation de l exécutable et des liens symboliques Listing 2.9 Compilation make ARCH = arm On installe l exécutable et les liens symboliques (qui pointe tous vers l exécutable busybox) dans le système de fichier root : 8

9 Listing 2.10 Installation make ARCH = arm CONFIG_PREFIX =$( pwd ) /../ rootfs install Nous avons donc un système de fichier avec quelques outils de base. 2.4 Application Nous avons donc un système de fichier de base, avec les exécutables fournis par busybox dont nous avons besoin. Il nous faut maintenant compiler notre programme dédié au cahier des charges du concours Compilation des bibliothèques Pour compiler notre application utilisateur, nous avons besoin de deux bibliothèques : FreeType et tslib. Freetype Nous avons configuré la bibliothèque pour contenir le strict minimum pour notre application. Une fois configurée, nous pouvons la compiler avec la commande suivante : Listing 2.11 Compilation de Freetype./ configure -- host = arm make -j2 La bibliothèque est maintenant disponible, sous le nom libfreetype.a. tslib Cette bibliothèque fonctionne sur un principe de module. Souhaitant utiliser uniquement des choses statiques sur notre système, nous avons mis en place un patch disponible sur internet pour fonctionner en statique. La compilation se passe de la façon suivante : Listing 2.12 Compilation de tslib./ autogen.sh./ configure -- host = arm --enable - linear = static --enable - dejitter = static --enable - variance = static --enable - pthres = static --enable - input = static --disable - linear - h disable - ucb1x00 --disable - corgi --disable - collie --disable - h disable - mk712 --disable - arctic2 --disable - tatung --disable - dmc --disable - touchkit make -j2 On peut voir que l on désactive tout les modules qui nous sont inutiles, et qu on positionne en statique les modules que nous souhaitons utiliser. On obtient la bibliothèque sous le nom libts.a. 9

10 2.4.2 Compilation de l application du Concours Une fois nos deux bibliothèques disponible, on peut compiler notre application : Listing 2.13 Compilation de notre application arm - jbtheou - linux - uclibcgnueabi - gcc - static - ffunction - sections - fdata - sections -Wl,--gc - sections Concours.c -march = armv4t -mtune = arm920t -I../ freetype2 /. -I../ freetype2 / include / -I../ tslib / -I../ tslib / src -I../ tslib / tests -L../ freetype2 / objs /. libs / - lfreetype -L../ tslib / src /. libs / -lts -Wall -Os -o Concours Il ne nous reste plus qu a insérer notre application dans le rootfs Listing 2.14 Copie dans le rootfs cp Concours../ rootfs / bin Notre système de fichier contient maintenant le nécessaire pour fonctionner correctement, en respectant le cahier des charges. Avant d insérer le rootfs, on "strip" les exécutables, c est-à-dire on retire les entêtes disponibles dans le format ELF (Le format de nos exécutables). Ainsi, on perd des capacités des débuggages, mais on gagne encore un peu de place. Comme nous avons modifié le rootfs, il faut recréer l initramfs, via la commande : Listing 2.15 Regénération de l initramfs cd../ rootfs find. cpio - H newc - o >../ linux / initramfs. cpio La prochaine étape permet de compiler le noyau, avec le rootfs fonctionnel. 2.5 Linux Nous avons pour le moment une chaîne de compilation, et un système de fichier minimal. Il faut maintenant compiler le noyau linux, avec les optimisations souhaitées. Pour ce faire, on exécute la commande "usuel" : Listing 2.16 Configuration make menuconfig ( Affichage standard ) make xconfig ( Affichage evolue avec une interface qt) make gconfig ( Affichage evolue avec une interface gtk ) Il s agit de configurer le noyau selon les besoins. Dans le cas de la Mini2440, il existe un fichier de configuration par défaut. Pour le charger, il faut exécuter la commande : Listing 2.17 Initialisation make mini2440_ defconfig Pour utiliser le système de fichier en initramfs que nous avons défini précédemment, il faut juste ajouter, via la commande de configuration vu ci-dessus, l option et le chemin dans 10

11 Listing 2.18 Configuration -- > General setup -- > Initial RAM filesystem and RAM disk ( initramfs / initrd ) support -- > Initramfs source file : initramfs. cpio On peut créer l image du noyau (ici une image non compressée) via la commande : Listing 2.19 Création de l image make Image - j4 11

12 3 Optimisation Durant ce projet, le principe de base avant toute optimisation d ordre technique (modification, patch, etc), est le principe du strict minimum. Tous les outils utilisés sur la cible contiennent juste le nécessaire pour leur exécution, sans code superflu. De plus, ils sont compilés en statique sans les options de débug (-g). 3.1 Optimisation de la chaîne de compilation Dans le cas de l optimisation de la chaîne de compilation croisée, nous avons utilisé une bibliothèque C plus légère que glibc, la bibliothèque par défaut. Nous vous présentons comment utiliser cette bibliothèque Compilation avec la bibliothèque uclibc Dans un but d optimisation de la chaîne de compilation, nous avons fait le choix de la bibliothèque uclibc. En effet, elle est optimisée pour présenter une empreinte mémoire plus faible. Il faut donc faire le choix dans le menuconfig de crosstool-ng (Revoir la page sur la compilation de crosstool-ng). Une fois le choix fait, lancer une première fois la compilation via la commande (Le.4 permet de lancer 4 processus en parrallèle). Listing 3.1 Construction./ct -ng build.4 Il va télécharger les paquets, puis commencer la compilation. Lors de l accès aux sources de uclibc, il donne une erreur, l absence du fichier de configuration. Il faut tout d abord configurer uclibc, puis donner le lien à crosstool-ng Configuration de uclibc Pour accéder aux sources de uclibc, il faut se rendre à : Listing 3.2 Dossier cd. build / src / uclibc * On configure uclibc via la commande 12

13 Listing 3.3 Configuration make menuconfig Une fois la configuration effectuée, il la sauvegarde dans le fichier.config. Il suffit maintenant de revenir sur la configuration de crosstool-ng : Listing 3.4 Configuration de crosstool-ng cd../../.../ ct - ng menuconfig Et dans le menu C-Library, mettre le chemin suivant dans le champs pour le fichier de configuration : Listing 3.5 Configuration de crosstool-ng./ build / src / uclibc -< mettre la version >/. config La compilation devrait maintenant fonctionner jusqu au bout. 3.2 Augmentation de l horloge, Timing de Nand Timing de Nand Par défaut, les timings d accès à la Nand (Configuré dans le bootloader) sont les plus lents possibles (Comptabilité avec toutes les marques de Nand). Dans notre cas, on optimise les timings d accès pour avoir le temps le plus court. Listing 3.6 Timing de nand # define TACLS 0 # define TWRPH0 1 # define TWRPH Augmentation de l horloge Par défaut (Configuration "normal" des bootloaders), le s3c2440 fonctionne à 405 Mhz. Hors le ARM920t, le coeur ARM embarqué dans le SoC, peux fonctionner à 533 Mhz sans overclocking. On peut donc augmenter la cadence du processeur. Cependant, on souhaite conserver notre timing de la Nand, car le temps le plus long reste la copie, donc l augmentation de l horloge doit être limité. Listing 3.7 Configuration initiale S3C244X : core MHz, memory MHz, peripheral MHz Après différents tests, on peut augmenter la cadence du CPU jusqu à Mhz sans avoir à modifier les temps d accès à la Nand. On gagne donc de la vitesse de calcul pour l initialisation de Linux. 13

14 Listing 3.8 Configuration finale S3C244X : core MHz, memory MHz, peripheral MHz 3.3 Optimisation du bootloader L optimisation du bootloader est un élément important dans notre projet. C est la partie qui effectue les initialisations de très bas niveau (Mémoire, Nand, CPU, etc). Il existe deux types de bootloader : Les évolués Les autres Les bootloaders évolués Les bootloaders évolués sont des bootloaders qui embarquent les fonctionnalités supplémentaires, non requises pour le démarrage de l OS. Par exemple, on peut citer : U-boot Barebox (aka U-boot v2). Ces bootloaders se séparent en deux parties : Une partie commune (Les fonctionnalités supplémentaires) Une partie propre au matériel (Initialisation) Ces bootloaders sont très pratiques durant le développement. En effet, on peut charger un noyau depuis le réseau, formater la Nand, avoir accès à un terminal pour interagir sur la configuration, etc. Dans notre optique d optimisation, ils sont trop lourds. On peut toujours optimiser en retirant des fonctionnalités, mais ils ne sont pas fait pour être très rapides, ils sont fait pour être très fonctionnels. De plus, cette façon de procéder n est pas optimale. On peut retirer des choses, mais on a assez difficilement une visibilité globale du fonctionnement et retirer certaines parties peut être assez compliqué, car le logiciel n a pas été prévu pour ça. Il vaut donc mieux partir du minimum, et construire dessus Les autres Les autres constituent les bootloaders "simples", c est-à-dire qui ne réalisent que les opérations suivantes, sans possibilités d interagir : Initialisation du matériel Récupération du noyau (ROM, Flash, etc) Exécution du noyau Ces bootloaders sont très efficaces, mais très dépendants du matériel, avec des capacités limitées. Cependant, sur notre carte, la mémoire Nor embarque un bootloader évolué qui permet de récupérer le noyau via USB et de mettre à jour le bootloader sur la Nand. On peut donc se contenter d un bootloader très limité, mais très efficace sur la Nand. Nous avons utilisé ce type de bootloaders dans notre projet. 14

15 Comme on ne reinvente pas la roue quand elle existe, nous nous sommes basé sur le projet vboot disponible sur le site de FriendlyARM. Nous avons optimisé le code pour répondre à notre besoin, en initialisant uniquement le strict minimum Optimisation de vboot Même si vboot est un bootloader léger, il n est pas forcement optimisé à son maximum (selon notre application bien évidemment). Pour s en convaincre, voici trois sorties du très pratique logiciel tstamp, qui permet d horodater les sorties sur UART (coté PC). Le temps 0 correspond à l envoi du caractère "CR" par le bootloader (Juste après la configuration de l UART). La seconde ligne est la première sortie sur UART de linux. La version initiale de vboot (Disponible sur le site FriendlyARM), en supprimant la vérification de l entête de la zimage (On n utilise pas d image compressé) Listing 3.9 Configuration initiale : : Linux version FriendlyARM ( breizhpc@ breizhpc - laptop ) ( gcc version ( prerelease ) ( crosstool - NG ) ) # 564 Thu Nov 17 20: 32: 01 CET 2011 Le temps passé dans le bootloader (+ temps d envoi des caractères) est donc de 773 ms. La version précédente très légèrement modifiée : On ne copie plus 0x octets depuis la Nand, mais juste la taille du noyau (dans l exemple, ). Listing 3.10 Configuration intermédiaire : : Linux version FriendlyARM ( breizhpc@ breizhpc - laptop ) ( gcc version ( prerelease ) ( crosstool - NG ) ) # 564 Thu Nov 17 20: 32: 01 CET 2011 Le temps n est plus que de 336 ms. On affiche déjà un gain de 56.5 % en utilisant juste la bonne taille pour la copie. La version actuelle du bootloader (Largement modifiée, on détaille les modifications dans la suite) Listing 3.11 Configuration finale : : Linux version FriendlyARM ( breizhpc@ breizhpc - laptop ) ( gcc version ( prerelease ) ( crosstool - NG ) ) # 564 Thu Nov 17 20: 32: 01 CET 2011 Le temps n est plus que de 176 ms. On affiche un gain de 47.6 % par rapport au cas précédent, et de 77.2 % par rapport au cas initial. En collant au plus près des besoins, on peut donc gagner un temps considérable Les optimisations Pour se rendre compte des optimisations dans le bootloader, le plus simple reste encore de regarder le code. Autrement, les différents axes sont : 15

16 Simplification au maximum (Pas d ATAGS, tout en statique dans le noyau) Initialisation du strict minimum (Juste les ports utiles, etc) Adaptation des timings (CPU, Flash, etc) Maximum du code en assembleur directement (Plus de contrôle sur le code) 3.4 Optimisation du noyau Dans cette partie, nous allons détailler les différentes étapes d optimisations du noyau, avec leurs impacts en terme de temps et de taille. On utilise le noyau linux disponible sur le site de friendlyarm. On utilise pour système de fichier root un initramfs optimisé, de taille (352 Ko) octets. On travaille uniquement avec des archives non compressées (linux+initramfs) Partie 1 - Sans DHCP (ip static) Conditions initiales On compile le noyau, en l adaptant à la carte via la commande : Listing 3.12 Initialisation make mini2440_ defconfig On rajoute uniquement dans la configuration la localisation de l initramfs. On obtient un noyau final de (4.3 Mo) octets. Etape 1 : Retrait des drivers inutiles Dans un premier temps, on supprime les drivers inutiles pour notre application : 16

17 Driver Wifi Driver MTD Driver RTC etc On supprime aussi les systèmes de fichiers inutiles : ext2, ext3, etc. On met en correspondance le noyau avec nos besoins (Type de LCD, support du ext4, etc). On désactive dans la partie kernel hacking les outils de trace (utile pour l optimisation) et l utilisation du debugfs (plus généralement, tout les outils de debug). On désactive le chargement des modules (On souhaite obtenir un noyau statique). C est la première étape de l optimisation. La mise en conformité des attentes de notre produit, et des drivers chargés. La taille du noyau résultat est considérablement réduit, tout comme le temps de chargement (Voir graphique final). Etape 2 : Service TCP/IP Au niveau des services réseaux, nous n avons besoin que de la pile TCP/IP et des sockets. On supprime tout le reste (Multicast, etc.) Etape 3 : Finalisation du retrait des drivers A cette étape, nous avons presque fini de nettoyer notre noyau avec les drivers inutiles. Par analyse du log, on voit que deux drivers nous ont échappé : DMA et sdhci. On les supprime. Notre noyau colle maintenant parfaitement à nos besoins. On peut encore pousser l optimisation. Etape 4 : Simplification de noyau - Partie 1 Pour simplifier le noyau, on supprime les éléments suivants : La gestion du power management Les formats de binaires autre que ELF Les appels système Kexec La possibilité d utiliser des exécutables compilés avec THUMB Etape 5 : Simplification du noyau - Partie 2 Sachant que notre application utilisateur est très simple (Pas de communication avec d autres applications, etc), on peut retirer tous les éléments du noyau dédié à la communication entre tâches : Swap, IPC, Queue IO policy Data Integrity Relayfs A ce niveau, toutes les modifications possibles de base ont été faites. 17

18 Etape 6 : Option Embedded Dans le noyau, la sélection de l option Embedded permet de modifier plus finement le noyau. On choisit pour la gestion du noyau SLOB, un ordonnanceur bien plus léger et simple On retire toutes les nouvelles options, sauf printk pour permettre d obtenir les traces. Avec ces modifications, nous avons fait le maximum d optimisation pour notre cas via la commande menuconfig. Etape 7 : Calibration loop Dans l initialisation du noyau, on peut voir qu il effectue à chaque démarrage une boucle de calibration. Listing 3.13 Calibration loop Calibrating delay loop BogoMIPS ( lpj =528384) Or cette calibration dépend du matériel, et notre matériel est fixe. On fixe donc la valeur dans les arguments de boot (lpj=528384). Ceci permet de gagner environ 100 ms. Etape 8 : Mem size Notre carte embarque 64M de Ram. Au tout début de son initialisation, Linux traite cet espace mémoire pour préparer son arrivée. Dans notre cas, notre système nécessite peu de mémoire. On fonctionne très bien avec 4M de Ram. On peut donc réduire la taille donnée à Linux par un argument de boot (mem=4m) État des lieux A ce stade, pour ne pas avancer dans le noir, on utilise un outil de trace fourni par le noyau. Il permet de tracer les initcall, avec le temps mis par chacun. Pour l utiliser : Rajouter l option pour avoir les symboles dans les options du menu Embedded Rajouter la fonction de Tracer dans les kernel hacking Rajouter les arguments suivants pour le boot : printk.time=1 initcall_debug Augmenter la mémoire à 16M On obtient le graphique suivant (page suivante) : 18

19 On peut voir que les postes les plus longs sont : s3c_arch_init : L initialisation de l architecture (11,773 ms) inet_init : L initialisation des composants réseaux (29,708 ms) populate_rootfs : Mise en place du système de fichier root (22,412 ms) s3c2410fb_init : Initialisation du framebuffer (21,612 ms) s3c2440_serial_init : Initialisation de l interface série (13,647 ms) dm9000_init : Initialisation du contrôleur réseau (11,580 ms) s3c2410ts_init : Initialisation du touchscreen (11,398 ms) Pour un temps total de sec sur sec. On peut donc explorer les drivers pour voir si, dans notre cas précis, on peut les optimiser. Optimisation de s3c2440_serial_init A la fin, ce driver n est plus utile. En effet, les sorties sur UART ne sont utiles dans notre cas que pour du débug. Aucune modification n est utile ici car il sera supprimé. Optimisation de inet_init Lors de la configuration du réseau, on ne peut pas, a priori, intervenir facilement sur les services chargés (TCP,UDP,ARP,ICMP,etc). La stack TCP/IP n est pas prévue dans une idée modulaire. Dans notre cas, on souhaite uniquement communiquer via UDP (DHCP s appuie sur la couche de transport UDP). A défaut de retirer les sources de TCP & Co, ce qui serait long pour un gain de temps a priori négligable, on va retirer les initialisations de tous les services mis à part le service UDP dans le fichier af_inet.c (Initialisation du réseau). Ainsi, on obtient : 29,708 7,738 ms Le gain est conséquent, pour un effort minime. 19

20 Autre Il semble compliqué de gagner du temps sur l optimisation de ces modules, sachant de plus que le ratio gain/temps sera très défavorable. On gagne donc 35,617 ms en supprimant le driver série + la modification de la pile IP. Dernière optimisation : Suppression du printk Notre noyau est déjà bien optimisé. Il reste une grosse optimisation : La suppression des printk. L envoi des messages de debug via UART prend beaucoup de temps, et de place dans le noyau. Maintenant que notre noyau est optimisé et que nous n avons plus à le modifier, on peut supprimer les printk. Cette suppression nous permet de gagner 200 ms Conclusion - Sans DHCP à Au niveau du temps, on passe de : Listing 3.14 Sortie initiale : : Linux version ( breizhpc@ breizhpc ) ( gcc version ( prerelease ) ( crosstool - NG ) ) #6 Wed Dec 7 19: 54: 51 CET : CPU : ARM920T [ ] revision 0 ( ARMv4T ), cr = c : CPU : VIVT data cache, VIVT instruction cache : Machine : FriendlyARM Mini2440 development board [...] : Freeing init memory : 516 K : eth0 : link down : s3c - sdi s3c sdi : running at 399 khz ( requested : 400 khz ) : s3c - sdi s3c sdi : running at khz ( requested : khz ) : s3c - sdi s3c sdi : running at khz ( requested : khz ) : mmc0 : new SDHC card at address a : mmcblk0 : mmc0 : a741 SD08G GiB : mmcblk0 : p : mount : mounting / dev / block / mmcblk0p1 on / mnt / sdcard failed : Unknown error : ls: / mnt / sdcard / concours -*: Unknown error : Application user ( null ) HOME =/ : : Please press Enter to activate this console. eth0 : link up, 100 Mbps, full - duplex, lpa 0 xcde1 Listing 3.15 Sortie finale : : Application user / mnt / sdcard / concours ttf 20

21 Grâce à l optimisation du temps de chargement du noyau et de sa taille (Dans l exemple de fin, la taille de copie optimisée est mise en place dans le bootloader), on gagne 80% du temps de chargement. Au travers de ces différentes optimisations, le temps de chargement est réduit de façon importante, et la taille du noyau diminue elle aussi. Sachant que le temps passé dans le bootloader est linéaire à la taille de l image, c est une donnée très importante Bonus - Patch de la pile Par défaut, dans la pile TCP/IP de linux, nous n avons pas le choix des protocoles. En effet, dans une utilisation "normale" de linux, nous avons 99% de chance d avoir besoin du protocole TCP si on active la pile. Cependant dans notre cas, le cahier des charges demande uniquement au chapitre connectivité de pouvoir faire une acquisition d adresse via DHCP. Le protocole DHCP utilise la couche UDP pour son transport. Nous avons donc mis en place une possibilité de configuration des protocoles embarqués dans la pile via menuconfig. Comme il serait très compliqué de rendre réellement modulaire les protocoles dans la pile, nous avons utilisé de fausses définitions (vides) des fonctions utilisées par TCP par exemple lorsque l on désactive le protocole TCP (voir le fichier de patch du noyau). Ainsi, en conservant uniquement le protocole UDP, on gagne en place et en temps d initialisation. Cependant, hors du cadre du concours, ce patch a peu de sens, car il existe très peu de systèmes fonctionnant uniquement sur UDP Partie 2 - Avec DHCP Le cahier des charges demande de récupérer une adresse IP par DHCP. L une des solutions est d utiliser le client DHCP présent dans busybox. Cependant, il se déclenche au dernier moment (user space). Nous avons préféré mettre en place l autoconfiguration ip du noyau. Il existe un module qui permet de demander une adresse DHCP dans l espace noyau (ipconfig). L intérêt de cette solution est que l on peut déclencher la demande bien plus tôt, et donc accélérer le démarrage de l application. Par défaut, l envoi de la requête DHCP bloque le démarrage du noyau, jusqu à obtention de l adresse. Il existe un système introduit dans le noyau pour faire fonctionner une initialisation de façon asynchrone. Nous avons mis en place cette méthode. Ainsi, le démarrage est plus rapide. Pour augmenter encore la vitesse de démarrage, nous avons remonté dans l ordre chronologique des initialisations, l initialisation du driver ethernet et le lancement de la requête en définissant de nouveau niveaux d initcall. En effet, l ordre des initialisations est défini par le niveau d initcall. Par exemple, la macro module_init correspond au niveau 6. Nous avons donc défini deux nouveaux initcall : Listing 3.16 Nouveau initcall earlydeviceinitcall earlyconfiginitcall Ainsi, les deux sont chargés plus tôt, et on optimise encore le temps. 21

22 3.4.6 Conclusion - Avec DHCP à : Avec nos optimisations, on passe de : Listing 3.17 Nouveau initcall : : Application user / mnt / sdcard / concours ttf Listing 3.18 Nouveau initcall : : Application user / mnt / sdcard / concours ttf On gagne donc beaucoup de temps avec nos modifications. Cependant, par rapport à nos 450 ms, on peut voir que le DHCP prend énormément de temps. Cela est du au temps de mise en place du link up. Malheureusement, nous n avons trouvé aucun moyen pour réduire ce délai, qui semble être un délais d activation matérielle. 3.5 Optimisation de l application Choix pour l application Pour l application, nous avons fait le choix de ne pas utiliser de "sur-couche" graphique (QT, GTK, etc) pour faire le plus léger possible. On s appuie directement sur le framebuffer, c est-à-dire que l on écrit directement dans la mémoire dédié à la vidéo. On utilise FreeType2 pour la gestion de la police TTF, et la bibliothèque tslib pour la gestion du tactile Analyse des sections Pour réduire la taille des exécutables, il peut être utile de vérifier le code généré en assembleur. On peut le faire à l aide de l outil suivant : Listing 3.19 Appel dessasembleur arm - jbtheou - linux - gnueabi - objdump -D Ainsi, nous avons pu remarquer dans le code assembleur qu il y avait deux types de sections rajoutés automatiquement par le compilateur : Des appels liés à l option Stack-protector Des appels liés à la gestion des exceptions (unwind). Par exemple (page suivante) : 22

23 Listing 3.20 Exemple d appel unwind 0002 f1a4 < gnu_unwind_frame >: 2 f1d8 : ebffff0b bl 2 ee0c < gnu_ unwind_ execute > 2 f27c : 652 f7475 strvs r7, [pc, # -1141]! ; 2 ee0f < gnu_unwind_execute +0x3 > Stack protector Pour le premier cas, nous avons rajouté l option gcc -fno-stack-protector lors de nos compilations, et décoché la case correspondante dans la configuration de uclibc (autrement, la bibliothèque est compilée avec cette option, ce qui ajoute de facto les sections). Cette option de gcc permet de ne pas utiliser la fonction de protection de la "stack", dont nous n avons pas besoin ici Unwind exceptions Pour le second cas, il semble que ces exceptions fassent parties de l AEABI. Après quelques recherches, nous avons pas trouvé de moyen simple de les retirer proprement. Nous avons donc mis en place dans nos deux executables (busybox et Concours) de fausses définitions des sections en questions. C est une modification pas très propre, mais fonctionnelle dans notre cas. Par exemple, sur l exécutable Concours, on peut observer le gain en taille : Listing 3.21 Comparaison - rwxr - xr - x. 1 root root Dec 22 10: 52 Concours - avec - unwind - rwxr - xr - x. 1 root root Dec 22 10: 51 Concours - sans - unwind On gagne donc 26k. Ce qui n est pas négligable, sachant qu il y a un gain aussi avec busybox Suppression du code mort La compilation peut générer du code mort (Variables inutiles, etc). Il existe une option dans le linker qui permet de supprimer ce code mort : Le garbage collector (Ramasse miette). On l active de la façon suivante dans une compilation : Listing 3.22 Garbage collector -Wl,--gc - sections Et pour être certain que le garbage collector puisse faire son travail, on met le maximum de choses dans des sections séparées via les options : Listing 3.23 Séparer dans des sections - ffunction - sections - fdata - sections Nous avons mis en place ces options dans toutes nos compilations pour être sur de n embarquer que le nécessaire. 23

24 4 Piste 4.1 Installation en Nor Sachant que notre noyau fait au final 1.7 Mo, il rentre dans les 2 Mo de la Nor. Sachant que la Nor est directement adressable par le CPU, on peut retirer la copie du noyau vers la RAM. En utilisant la technique d exécution sur place (XIP), on peut gagner du temps. Sachant que la principale lourdeur au niveau code du bootloader provient de la copie de donnée depuis la Nand, on peut aussi simplifier le bootloader. Par manque de temps, nous n avons pas mis en place cette solution. 24

25 5 Conclusion Au travers de ce projet, nous avons pu aborder quelques solutions d optimisations pour les plateformes à base de Linux. Comme nous avons pu le voir, l optimisation est un problème très dépendant de la plateforme, de l application, des contraintes. Cependant, l approche que nous avons eu est une approche reconductible, qui se base sur les aspects suivants : Une analyse du cahier des charges Des tests à chaque étapes, pour évaluer leurs influences La juste mesure : n embarquer que le nécessaire Nous avons pu voir qu avec de l optimisation, nous pouvions gagner un facteur très important sur les temps de démarrage, ce qui est un facteur non négligeable dans nombre d applications. Ce projet résonne donc au delà son cadre. Il nous a permis d acquérir des bases et des méthodes pour réaliser des systèmes embarqués qui ne font pas que fonctionner, mais qui fonctionne au mieux des capacités qui nous sont fournies. 25

26 6 Références Comme dans tout projet open source, l information est disponible à de nombreux endroits, et il est souvent nécessaire de voir de multiples sources pour comprendre complètement un problème, une technique, etc. De ce fait, ces références sont non complètes, et comme d habitude lors d un projet, le maître mot est la recherche sur internet, pour ne pas réinventer la roue lorsqu elle existe. Idée de l utilisation de nouveau initicall, et de l utilisation des fonctions asynchrone : Pour le démarrage, le blog de notre enseignant à l ENSEIRB, Patrick Kadionik : Le groupe du concours (Merci pour l outil flashimg, les patchs, etc!) : groups.google.com/group/concours-linuxembedded Les exemples fournis avec tslib, qui nous ont servit de base pour l application utilisateur. Pour retirer la gestion des unwinds, de façon un peu brutal : org/viewtopic.php?f=2&t=2944 Nous tenions à dire un grand merci à toutes les personnes qui donnent de leurs temps pour des projets libres, et qui fournisse des outils de grandes qualités : Linux, crosstool-ng, busybox, etc. Enfin, un remerciement appuyé à la société Open Wide, pour l organisation de ce concours, qui nous a permis d apprendre beaucoup autour du Linux embarqué. 26

27 7 Annexes Listing 7.1 Contenu du rootfs [ root@ breizhpc rootfs ]# ls - Rl.: total 40 drwxr - xr - x. 2 root root janv. 10: 49 bin drwxr - xr - x. 4 root root janv. 10: 46 dev drwxr - xr - x. 3 root root janv. 10: 46 etc lrwxrwxrwx. 1 root root 9 14 janv. 10: 48 init - > sbin / init drwxr - xr - x. 3 root root janv. 10: 46 mnt drwxr - xr - x. 2 root root janv. 10: 46 proc drwxr - xr - x. 2 root root janv. 10: 48 sbin drwxr - xr - x. 2 root root janv. 10: 46 sys drwxrwxrwx. 2 root root janv. 10: 46 tmp drwxr - xr - x. 4 root root janv. 10: 48 usr drwxr - xr - x. 2 root root janv. 10: 46 var./ bin : total rwxr - xr - x. 1 root root janv. 10: 48 busybox - rwxr - xr - x. 1 root root janv. 10: 49 Concours lrwxrwxrwx. 1 root root 7 14 janv. 10: 48 grep - > busybox lrwxrwxrwx. 1 root root 7 14 janv. 10: 48 hush - > busybox lrwxrwxrwx. 1 root root 7 14 janv. 10: 48 ls - > busybox lrwxrwxrwx. 1 root root 7 14 janv. 10: 48 mount - > busybox lrwxrwxrwx. 1 root root 7 14 janv. 10: 48 sh - > busybox./ dev : total 8 drwxr - xr - x. 2 root root janv. 10: 46 block drwxr - xr - x. 2 root root janv. 10: 46 input./ dev / block : total 0./ dev / input : total 0./ etc : total 12 -rwxr -xr -x. 1 root root janv. 10:46 fstab drwxr -xr -x. 2 root root janv. 10:46 init.d - rwxr - xr - x. 1 root root janv. 10: 46 inittab 27

28 ./ etc / init.d: total 4 -rwxr -xr -x. 1 root root janv. 10:46 rcs./ mnt : total 4 drwxr - xr - x. 2 root root janv. 10: 46 sdcard./ mnt / sdcard : total 0./ proc : total 0./ sbin : total 0 lrwxrwxrwx. 1 root root janv. 10: 48 ifconfig - >../ bin / busybox lrwxrwxrwx. 1 root root janv. 10: 48 init - >../ bin / busybox./ sys : total 0./ tmp : total 0./ usr : total 8 drwxr - xr - x. 2 root root janv. 10: 48 bin drwxr - xr - x. 3 root root janv. 10: 46 local./ usr / bin : total 0 lrwxrwxrwx. 1 root root janv. 10:48 cut ->../../ bin / busybox./ usr / local : total 4 drwxr - xr - x. 3 root root janv. 10: 46 tslib./ usr / local / tslib : total 4 drwxr - xr - x. 2 root root janv. 10: 46 etc./ usr / local / tslib / etc : total 4 -rwxr -xr -x. 1 root root janv. 10:46 ts. conf./ var : total 0 28

29 Quelques définitions ATAGS Arguments donnés par le bootloader au noyau Linux pour lui transmettre des informations sur la machine (Mémoire, ligne de commande pour le boot, etc.). 16 Buildroot Outil de génération automatique de linux embarqué. 5 DHCP Service réseau qui permet, entre autre, l acquisition d une adresse IP. 4 DMA Direct Memory Access, c est un périphérique qui permet de gérer la mémoire sans utiliser de temps CPU. 17 ELF Format portable pour exécutable. Format principal sur les noyaux récents. 10 ext4 Système de fichier pour Linux. 4, 7 gcc Compilateur C issu du projet GNU. 6 IPC Inter-processus communication. C est une norme pour faire communiquer des processus. 17 IPv4 Version de la norme IP, qui fourni des adresses du type jffs2 Système de fichier adapté aux mémoires de type Flash.. 7 MTD Memory Technology Device, c est le driver qui permet d interagir avec les mémoires de type Flash. 17 Nand Type de mémoire Flash. 13, 14 29

30 Nor Un autre type de mémoire Flash. 14 OpenEmbedded Outil de génération automatique de linux embarqué. 5 RTC Real Time Clock, une horloge temps réel. 17 SDHC Secure Digital High Capactity, nouvelle norme pour les carte mémoires de type SD. 4 SoC System on chip. C est une puce contenant un micro-contrôleur, avec des périphériques supplémentaires. 13 Swap Permet d augmenter les capactiés de mémoires en effectuant un tampon sur un disque dur.. 17 TCP/IP Utilisé pour décrire la bibliothèque contenant le nécessaire pour utiliser le réseau. 17 THUMB Jeux d instruction compressé proposé par ARM.. 17 TrueType Type vectoriel de police de caractère. 4 tstamp Petit utilitaire qui permet d horodater les sorties faites sur UART. 15 UART Protocole de communication sur port série. 19 UDP Protocole de communication réseau