Architecture Matériel du gilet
Choix du processeur ARM Le processeur devra gerer de multiple threads en paralleles. Nous n'aurons pas forcément besoin d'un système temps réel mais nous aurons besoin d'un système capable de switcher entre les processus rapidement, et de preference assez rapide (pour gerer l'affichage sur l'écran OLED couleur) et pouvant entrer dans des modes d'économie d'énergie. Il devra gerer en parrallele:
* Gestion d'un menu
* Gestion d'un clavier capacitif
* Un écran OLED couleur 160*120px
* Un module GPS
* un module de communication satelite
Nous avons choisi de ne pas développer notre propre système d'exploitation (qui se chargeraient de gerer les threads, les mémoires allouées pour chaque processus). Nous allons utiliser le noyau Linux et donc notre système devra être compilable sur notre architecture/processeur.
Pourquoi Linux a besoin d'une MMU?
1. Basculer d'une fonction à une autre rapidement 2. Implement Copy on write Paging. ( speeds up forking ) 3. Fonction de mémoire partagée entre les différents processus ( IE Shared libraries ) 4. Allocation de mémoire dynamique pour les processus
Comment cela fonctionne t'il? Un CPU a une petite mémoire dédié à mapper les liens entre les adresses virtuelles aux adresse physique dans la RAM. C'est la “Translation Look-aside Buffer” ou TLB. A chaque fois que le CPU doit lire dans la RAM, il passe par la MMU (Memory Management Unit). La MMU fait le lien entre l'adresse virtuelle et l'adresse physique situé dans une mémoire externe. Exemple:
1. Le CPU doit lire l'adresse 0x00100000 dans un registre r3 2. La MMU cherche dans la TLB et détermine que c'est en réalité à l'adresse 0x8f100000 situé dans la RAM 3. La MMU lit la mémoire externe, et le CPU reçoit les données de l'adresse 0x8f100000
Sources : http://www.euglug.org/Sept-05-Embedded-linux-euglug.pdf
Famille de processeur, pourquoi prend on l'ARM7? La famille ARM7 est une gallerie de processeur 32-bit RISC à faible puissance. Les coeurs de ces microprocesseurs sont optimisés pour les couts et l'aspect faible consommation. Ils offrent jusqu'a 130MIPs, la famille ARM7 incorpore la tecnologie "Thumb 16-bit instruction set" qui permet d'utiliser (mapper) directement des instructions 32 bits sans trop de perte de performance tout en utilisant un système 8/16 bits à faible cout.
Fonctionnalités
* Integer processor
* Synthesizable version of the ARM7TDMI processor
* Synthesizable core with DSP and Jazelle TM technology enhancements for Java acceleration
* Cached core with Memory Management Unit (MMU) supporting operating systems including Windows CE, Palm OS, Symbian OS and Linux
Choix de l'architecture Listes des architectures utilisant des processeurs ARM : Cette liste nous permet de sélectionner précisément notre architecture. Sources : http://www.gnuarm.com/ArmDevices_frame.html
Architecture Hardware sélectionnée Processeur ARM7 Cirrus Logic Sites : http://www.cirrus.com/en/products/pro/detail/P139.html http://www.cirrus.com/en/pubs/proDatasheet/EP7312_F1.pdf Choix de la mémoire Estimation de la mémoire nécessaire: Taille de :
* Linux
* OpenGL
* GPS+Telephone Satelite
* Menu/Image
Type de technologie Mémoire flash et principe de fonctionnement Source : http://www.cs.tau.ac.il/~stoledo/Pubs/flash-survey.pdf Composant : http://www.farnell.com/datasheets/99338.pdf Clavier Capacitif L'avantage étant de pouvoir fabriquer un truc étanche très facilement, y a plus qu'une entrée de câble et rien d'autre. Site : http://www.omron.com/ecb/products/touch/4ch.html Choix de l'écran Ecran OLED Couleur 160*120px Linux
Présentation de Linux pour les systèmes embarqués
Qu'est-ce que µClinux? µClinux "MicroController? Linux" est un fork du noyau de Linux pour les micro-contrôleurs sans Memory Management Unit (MMU). Il est maintenant intégré dans la branche principale de développement du noyau Linux 2.6. Il concerne cependant uniquement le système d'exploitation, ce projet a aussi produit une librairie standart C appellé uClibc (maintenu séparément). Cette librairie a été développé spécifiquement pour les systèmes embarqués.
Et uClibc? Cette librairie standart en C est beaucoup plus petite que la GNU C Library, et à peu près toutes les applications fonctionnant avec la glibc sont compatibles. Afin de porter son application de glibc à uClibc, il suffit juste de recompiler le code source. uClibc supporte les libraires partagées et les threads. Il fonctionne à la fois sur un Linux standart ainsi que sur un système sans MMU. Processeur supporté :alpha, amd64, ARM, Blackfin, cris, h8300, hppa, i386, i960, ia64, m68k, mips/mipsel, PowerPC, SH, SPARC, and v850 processors. uClic Executables are slightly smaller too: C program Compiled with shared libraries Compiled statically glibc uClibc glibc uClibc Plain “hello world” 4.6 K 4.4 K 475 K 25 K Busybox 245 K 231 K 843 K 311 K You also have to copy the uClibc files from the toolchain to the /lib directory in the target root filesystem. Site : http://uclibc.org/downloads/
Fonctionnalités Linux : BusyBox? BusyBox? est un programme contenant des versions simplifiées de nombreuses applications systèmes UNIX dans un seul petit fichier exécutable. Il remplace la plupart des utilitaires systèmes GNU tel que cat, ls, and rm. Le GNU Core Utilities ou coreutils est donc remplacé par ce programme. Ces utilitaires ont néanmoins une quantités plus limité d'options par rapport à leur version GNU. La suite BusyBox? fournis une suite de programmes systèmes assez complète pour de petits systèmes embarqués. Site : http://busybox.net/download.html
Qu'allons nous utiliser pour développer notre Linux ARM? Etant donnée que nous allons utilisé un ARM7 disposant d'une MMU, nous n'allons pas utiliser µClinux, de plus il faudrait trouver une version compatible avec notre architecture ARM. Nous allons donc compiler notre propre noyau Linux. En revanche nous allons utiliser uClibc pour minimiser l'empreinte mémoire, il faudra choisir la version ARM. Nous allons certainement utiliser aussi BusyBox? bien que ce ne soit pas une priorité et nécessaire pour le fonctionnement global de notre système. Version ARM de la uClibc : http://uclibc.org/downloads/
Chaine de compilation ARM, et Cross-Compilation Procédure pour compiler un noyau Linux pour processeur ARM Comme pour toutes les architectures différentes du x86, le noyau Linux doit être patché afin de fonctionner sur notre plateforme spécifique. Cela consiste a télécharger et patcher les fichiers fournis par le fabriquant de processeurs/micro-contrôleurs sur la version du noyau Linux qui convient. On retrouve donc des patchs pour l'architecture ARM pour la branche 2.4 ainsi que 2.6 de Linux.
A-t'on besoin de patcher notre noyau Linux 2.6? Depuis la version 2.6 du noyau Linux (2.6.0-test2 exactement), il n'ya plus besoin de patch -rmk ou -vrs à utiliser pour compiler notre noyau ARM. En effet, l'architecture ARM est inclue directement dans la branche du noyau 2.6.
Qu'est-ce que la cross-compilation? Lorsque l'on va compiler notre noyau, il faut que celui la soit exécutable sur notre système embarqué. L'idée de la cross-compilation est d'utiliser la puissance du processeur hote (x86) pour compiler des programmes (ou le noyau Linux) pour notre système embarqué qui utilise une architecture différente (ARM). Cela signifie que la machine qui compilera notre programme ne pourra pas exécuter nativement celui-ci, il est compilé pour un autre processeur.
Les avantages sont multiples:
* Rapidité de compilation multiplié par un facteur de 100 voir plus (dépend du processeur ARM cible, et de votre PC)
* Moins de problèmes pour prévoir la mémoire nécessaire pour la compilation
Pour compiler le noyau Linux ou un programme qui devra être exécuter sur le système embarqué, il va falloir installer la Linux ARM toolchain.
Qu'est-ce que l'ARM Linux toolchain? L'ARM Linux toolchain est tout simplement la chaine de compilation complète permettant de créer notre noyau Linux sur une plateforme embarqué. Celle-ci comprend entre-autre gcc-arm. Il faut télécharger les sources de GCC pour le recompiler avec les options spécifique ARM. GCC t-arm-elf permet d'activer les options ARM :
* marm/mthumb (arm or thumb code generation)
* mlittle-endian/mbig-endian (little or big endian architectures)
* mhard-float/msoft-float (hardware or software fpu instructions)
* mno-thumb-interwork/mthumb-interwork (arm-thumb modes interworking)
* mcpu=arm7 (arm7 targets without hardware multiply)
Compilation de l'ARM Linux toolchain ( ligne de commande) Téléchargement de GCC-4.1 toolchain
* binutils-2.17.tar.bz2 13.1MB?
* gcc-4.1.1.tar.bz2 37.3MB?
* newlib-1.14.0.tar.gz 7.61MB
* insight-6.5.tar.bz2 20.4MB?
Etapes de compilation : Il suffit de suivre les instructions données sur le site web, avec ces lignes de codes : --prefix=/usr/local export PATH="$PATH:/usr/local/bin" Sources : http://www2.pt.tu-clausthal.de/~alexp/arm/index.html#gnuarm
La méthode ci dessus permet de compiler votre programme avec la librarie C newlibc. Pour compiler notre GCC toolchain, il ne faut pas oublier de prendre en compte la librairie uClibc, ce qui implique une autre méthode de compilation pour notre uClibc toolchain.
Comment compiler un programme pour ARM? Pour compiler un programme pour une architecture ARM, il suffit d'utiliser notre gcc-arm précédement installé et de spécifier le processeur cible avec "-mcpu". Exemple :
* arm-elf-gcc -mcpu=arm7tdmi -mthumb -O2 -g -c hello_world.c
* arm-elf-gcc -mcpu=arm7tdmi -mthumb -o hello_world hello_world.o -lc
Compilation de l'ARM Linux toolchain par Buildroot Qu'est-ce que Buildroot? Buildroot est un ensemble de fichiers "Makefile" et de patchs permettant de créer un système grâce à la cross compilation, ainsi que des librairies, des applications, le noyau Linux et le système de fichier. Il peut créer tout notre système Linux embarqué et sauvegarder notre configuration dans un seul fichier ".config" situé à sa racine. On va utiliser la chaine de compilation uClibc, qui va nous permettre de compiler des programmes pour produire des fichiers binaires lié à la uClibc. La chaine de cross compilation consiste en un compilateur gcc, un assembleur et linker : binutils, et une librairie C : uClibc.
Builroot a deux avantages en plus de l'automatisation de la compilation :
* L'utilisation de Buildroot permet de lier le compilateur gcc et la librairie uClibc.
* Buildroot créer automatiquement le système de fichier root et tous les outils necessaire tels que BusyBox?
Librairies Requises pour exécuter Buildroot
gcc, g++
* ncurses (apt-get install libncurses5-dev)
* bison
* flex
* texinfo
* svn ( apt-get install subversion)
* autoreconf ( sudo apt-get install autoconf2.13)
* automake ( sudo apt-get install automake)
* buildroot ( svn co svn://uclibc.org/trunk/buildroot)
* mkimage ( sudo apt-get install jigit)
* libtool (apt-get install libtool)
*
Preliminaries checks
This part is normaly not required on following distribution: ??
This part is required on: Ubuntu 6.04, KUbuntu 6.10 or more
* Be sure to have libtool package installed (tested with 1.5.22-4 & 1.5.24-1 versions).
Otherwise you will have following errors:
configure.ac:25: error: possibly undefined macro: AC_DISABLE_STATIC
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:26: error: possibly undefined macro: AC_ENABLE_SHARED configure.ac:27: error: possibly undefined macro: AC_LIBTOOL_DLOPEN configure.ac:28: error: possibly undefined macro: AC_PROG_LIBTOOL
Comment configurer Buildroot? Copier notre fichier ARM920T.config dans le dossier buildroot puis Tout d'abord on va créer le menu de configuration $make menuconfig
Pour configurer indépendament chaque sous menu plus précisément après avoir crée ce menu, il faut activer la compilation du noyau Linux puis : $make linux26-menuconfig $make uclibc-menuconfig $make busybox-menuconfig
Parametres de compilation de BusyBox? - uClibc BusyBox? $make busybox-menuconfig Pour réduire au maximum le processus de forking dans le shell ( cela demande beaucoup de temps processeur, et donc est lent), il convient de parametrer BusyBox? pour appeler dès que possible les applets. Par exemple, meme un simple echo dans le shell de BusyBox? est en fait un fork syscall. Shells => Standalone shell in busybox configuration
uClibc $make uclibc-menuconfig Choisir de compiler la librairie de manière statique Cross Compilé. Choosing to build a statically, “crosscompiled” executable, a uClibc toolchain instead of the standard glibc one. Le fichier devrait faire approximativement 250ko.
$make linux26-menuconfig
Paramètres spécifiques à notre plateforme BuildRoot? Architecture = arm Modèle = arm720t EABI Pourquoi? EABI pour processeur ARM signifie (embedded application binary interface). Cette spécification permet d'exécuter beaucoup plus rapidement les opérations floatantes de manière logicielles, puisque beaucoup de processeur ARM ne possèdent pas de FPU hardware. Nous allons préféré le mode EABI au mode OABI puisque notre processeur ARM ne possèdera pas d'unité de calcul floatantes.
Build options Gnu Target suffix : "linux_uclibc" Add '_nofpu' suffix for softfloat toolchains Strip => Sstrip
Toolchain C++ Cross Compiler Toolchain Use software floating point by defaut Avant de compiler, nous allons rappatrier tous les fichiers nécessaire pour la compilation d'internet $make source
Puis vient le processus de compilation global de la chaine de compilation ARM, il dure très longtemps ( minimum 30 minutes sur un processeur AMD3800) : $make
Une fois la compilation terminé, notre compilateur gcc optimisé avec la librairie uClibc compilé pour ARM se situe dans : buildroot/build_arm/staging_dir/usr/bin
Comment compiler depuis n'importe quel endroit? On remarque le nom de notre compilateur "arm-linux-gcc" qui pointe sur "arm-linux-uclibcgnueabi-gcc". Pour pouvoir compiler de n'importe ou sans avoir à tapper l'emplacement de notre chaine de compilation, il suffit de faire: export PATH="$PATH:/CheminBuildroot?/build_arm/staging_dir/usr/bin" On peut désormais appeler "arm-linux-gcc" depuis n'importe quel endroit pour compiler nos fichiers. Compilation du noyau Linux pour ARM Telechargement du noyau Noyau Linux 2.6.25 Puis décompresser : tar xvf linux-2.6.25.tar.bz2
Configuration de l'environnement compilant le noyau Généralement, l'architecture sur laquelle est compilée le nouveau noyau Linux est la même que celle du système qui va le compiler. Nous allons changer des options de compilations de notre noyau en modifiant le fichier "Makefile". Il faut éditer le fichier "Makefile" avec Kwrite :
Sur les noyaux linux 2.6.x : ARCH ?= $(SUBARCH) CROSS_COMPILE ?=
Changer par : ARCH ?= arm CROSS_COMPILE ?= /usr/local/bin/arm-linux-
En remplaçant "/usr/local/bin/arm-linux-" avec le chemin de notre chaine de compilation GCC ARM ( ARM Linux toolchain).
Pour plus d'informations, lire "README and linux/Documentation/arm/README". Source : http://www.arm.linux.org.uk/docs/kerncomp.php
Configuration du code source du noyau Pour le noyau Linux 2.6, utiliser <typedemachine>_config pour sélectionner une architecture, ex : bash$ ep7312_config ( Cirrus Logic EP7312 Dev. Board - Site : http://armboot.linuxsourcelinuxforge.net/) bash$ make ep7312_config Note: Pour changer de configuration ultérieurement avec make xxx_config, supprimer le fichier linux/.config juste avant d'exécuter cette commande.
Initialisation d'une configuration minimale du noyau : make allnoconfig
Pour configurer plus précisément notre noyau et sélectionner chaques propriétés que notre noyau devra utiliser nous allons modifier le fichier ".config". Ce fichier peut être aussi sous la forme "arch/arm/configs" si l'on utilise une distribution d'un vendeur. Pour modifier spécifiquement notre noyau, utiliser au choix :
* menuconfig est un front-end basé sur ncurses.
* xconfig est un front-end utilisant gconf. Il nécessite les librairies Qt et X pour fonctionner.
Diminution de la taille du noyau et son utilisation de la RAM Pour diminuer la taille du noyau on peut utiliser un ensemble de fichiers de configurations Makefile "CONFIG_EMBEDDED" qui va :
* Retirer les messages du noyau ( printk, BUG, panic...)
* Supprimer les inlines excessif ( rapidité diminué mais la taille aussi)
* Supprimer les allocations dynamique de mémoire excessives
* Allocation de mémoire dynamique slob au lieu de slab ( plus efficient au niveau de l'espace mémoire pour de petit système)
* Réduction des structures de données du noyau ( possible perte de performance)
General Setup => Configure Standart Feature for Small Systems ( à partir du noyau Linux 2.6.13.4)
Sans CONFIG_EMBEDDED Raw: 1205956 bytes Compressed: 515045 bytes Avec CONFIG_EMBEDDED Raw: 766153 bytes Compressed: 323788 bytes Gain d'espace de 37%! Source : http://elinux.org/Linux_Tiny
Compiler le code source du noyau Pour compiler un nouveau noyau : bash$ make clean bash$ make dep (non nécessaire sur le noyau 2.6) bash$ make zImage bash$ make modules Les deux dernieres lignes de commande permettent de compiler le noyau ainsi que ses modules.
Installer un noyau Linux Cross Compiler Les modules de notre nouveau noyau seront installés dans le répertoire : "/lib/modules/x.y.z" sur le système cible, bien que ce soit différent sur le système hote, nous appellons le chemin du système cible : $TARGETDIR.
Installer les modules dans $TARGETDIR : bash$ make modules_install INSTALL_MOD_PATH=$TARGETDIR
Cela placera les modules dans "$TARGETDIR/lib/modules/x.y.z" sur le système hote, qui pourront être placé dans un système de fichier (ext3, fat32 ^^), ou transferrer sur la machine cible. On ne doit pas installer les modules du noyau directement sur le système root hote ( ex: en ommettant de mettre INSTALL_MOD_PATH ou en mettant $TARGETDIR = "/"), puisqu'ils sont incompatible avec votre propre noyau et rendront votre système non bootable.
Le noyau compiler sera disponible dans"$HOME/linux/arch/arm/boot/zImage" et les informations de débuggage du noyau dans : "$HOME/linux/System.map". C'est important de garder le fichier "System.map", il contient les informations/symboles du noyau, qui sont necéssaire pour debugger ou analyser un problème. Source: http://www.linux-arm.org/LinuxKernel/WebHome#System_requirements Comment Compiler Need for stripping Compiled executables and libraries contain extra information which can be used to investigate problems in a debugger. This was useful for the tool developer, but not for the final user. To remove debugging information, use the strip command. This can save a very significant amount of space! gcc o hello hello.c (output size: 4635 bytes) arm-linux-strip hello (output size: 2852 bytes, 38.5%) Don't forget to strip libraries too! sstrip: “super strip” http://muppetlabs.com/~breadbox/software/elfkickers.html Goes beyond strip and can strip out a few more bits that are not used by Linux to start an executable. Can be used on libraries too. Minor limitation: processed libraries can no longer be used to compile new executables. Can also be found in toolchains made by Buildroot (optional)
Hello World Regular 4691 B stripped 2904 B (-38 %) sstripped 1392 B (-70 %)
Système de fichier Nous allons maintenant créer un système de fichier pour notre système embarqué Linux. Les différents systèmes de fichiers disponibles :
* cramfs, read-only, simple et space-efficient.
* romfs, read-only, originnelement conçu pour Linux, space-efficient, système de fichiers avec petit block de données.
* JFFS2, système de fichier avec log, pour une utilisation sur des mémoires flash dans les systèmes embarqués.
* SquashFS, read-only, système de fichier compresser pour Linux, pour archiver ses données, il utilise de petits block de mémoire ou un faible overhead est nécessaire.
Comment mettre Linux sur une mémoire Flash ( MTD Driver)? Ce driver MTD permet de placer un système Linux sur différent types de mémoire, spécialement des mémoires Flash/RAM. Le but de ce projet (MTD Driver) est de fournir un driver pour les nouvelles mémoire, en fournissant une interface générique entre les drivers hardware et la couche haute du système. Le MTD a besoin de connaitre le format utilisé comme le FTL, FFS2, etc., et fournira les routines pour read, write and erase.
La Memory Technology Device peut être monter avec les systèmes de fichiers : jffs, jffs2 et cramfs. Il supporte aussi la mémoire Flash de type NOR. La taille du bus Flash est le nombre de puces mémoires nécessaire pour mettre en place le bus peuvent être configuré manuellement ou automatiquement. Source : http://www.linux-arm.org/LinuxFilesystem/WebHome
Utiliser un système de fichier rapide Pour un système de fichier readonly, utiliser SquashFS au lieu de CramFS ( beaucoup plus lent, obsolete) NAND flash : Si on ne souhaite pas de compression, utiliser yaffs2 au lieu de jffs2 ( beaucoup plus lent, consomme beaucoup plus de RAM) ARM Linux Development Platforms
Linux sur une architecture Cirrus Logic ARM : http://arm.cirrus.com/docs/2.6/index.html Patch ARM en fonction des architectures : http://www.linux-arm.org/LinuxPlatform/WebHome Linux BootLoader?
Un noyau ARM Linux ne peut pas être démarrer sans un minimum de paramètres spécifiques pour initialiser le system tel que :
1. Configurer la mémoire du systeme 2. Charger l'image du noyau à une certaine addresse mémoire 3. Possiblité de charger un RAM disk 4. Passer les parametres de boot au noyau 5. Obtenir le type de machine du noyau ARM Linux 6. Entrer les valeurs correctes dans le registre
Comment faire notre BootLoader? ? Source : http://www.simtec.co.uk/products/SWLINUX/files/booting_article.html
Optimiser le démarrage du Boot Bootchart est un outil d'analyse de la perfomance du processus de boot de Linux. Il enregistre les ressources utilisées pour chaque processus ainsi que leur durée d'exécution. Cela permet d'avoir un rendu visuel de la chaine d'appel des processus sous forme PNG, SVG, ou EPS.
Bootchart est un script Shell exécuter par le noyau durant la phase Init. Il fonctionne en background et enregistre toutes les informations a propos des processus, les statistiques CPU et du disque a partir du dossier /proc. Les données sont enregistrées dans la mémoire et sont enregistré sur le disque une fois le boot terminé. Source : http://www.bootchart.org/
http://arm.cirrus.com/docs/2.6/index.html Emuler notre architecture ARM Linux
QEMU est une machine virtuelle (ou émulateur de système) libre qui permet de faire tourner un ou plusieurs systèmes d'exploitation (ou seulement des processus) sur un système d'exploitation déjà installé sur la machine. Il peut émuler dans un mode utilisateur, il peut exécuter des applications compilées pour d'autres CPU tel que : x86, ppc, arm, sparc Source : http://bellard.org/qemu/
Logged as root: Creating a mount point: mkdir /mnt/rootfs Mounting the root filesystem image: mount -o loop rootfs.img /mnt/rootfs Copying the busybox file structure into the mounted image: rsync -a busybox/_install/ /mnt/rootfs/ chown -R root:root /mnt/rootfs/ Flushing the changes into the mounted filesystem image: sync
Using the qemu emulator as a bootloader (no need to copy the kernel to the target storage) qemu \ -m32 \ Amount of memory (MB) in the emulated target -hda rootfs.img \ Contents of the emulated hard disk -kernel linux2.6.12/arch/i386/boot/bzImage \Kernel image -append "root=/dev/hda clock=pit" \Kernel command line Optimisation de Linux L'objectif est d'améliorer la vitesse d'exécution de tout notre système, sa taille, son cout et son énergie utilisé.
Améliorer la vitesse d'exécution Désactiver la sortie de la console L'affichage des données relative a l'execution du boot prend du temps. La sortie de la console n'est pas nécessaire sur notre systeme finis. Elle peut etre désactivé par le mot clé "quiet" en argument au noyau Linux Cela supprimera de la console tous les messages écrit par printk, ils pourront néanmoins etre lu grace a la commande "dmesg" car ils sont bufferisé. Exemple : root=/dev/ram0 rw init=/startup.sh quiet Benchmarks: Réduit la durée d'exécution du boot de 30 a 50%!
Calibration du delay A chaque boot, le noyau Linux calibre la fonction delay a l'aide d'une boucle. Cette mesure produit une loops_per_jiffy (lpj) valeur. Cette opération prend environ 25 jiffies (1 jiffy = temps entre deux interruptions de timer). Sur un système embarqué, cela peut prendre environ 250ms! Cette mesure n'a besoin d'être effectué qu'une seul fois sur un système embarqué, il suffit de mesure la durée de cette boucle et sa valeur lpj associé et entrer cette valeur lors du démarrage du noyau Linux.
Procédure : Booter Linux avec le parametre loglevel=8 Calibrating using timer specific routine... 187.59, BogoMIPS (lpj=937984) Pour les prochains boot, démarré Linux avec l'option lpj = 937984
Exécuter directement le noyau Linux sur la flash Quand le noyau est exécuté sur place, le bootloader n'a pas besoin de : Lire le noyau à partir de la flash Décompresser le noyau Ecrire le noyau dans la RAM
Avec cette procédure on peut esperer jusqu'a 500 milliseconds de gain de temps. Source : http://elinux.org/Kernel_XIP
Ne pas effectuer d'allocation dynamique de mémoire Ne pas allouer de mémoire dynamique et l'allouer/la gerrer nous meme. Cela permet de s'affranchir de tous les mécanismes de mémoire dynamique ( gain de vitesse et de place).
Imaginons que l'on ait 32Mo de RAM
1. On boot le noyau avec mem=30 2. Le noyau pourra utiliser les 30 premiers Mo de la RAM 3. Le driver pourra dorénavant utiliser les 2Mo restant : 4. buf = ioremap ( 0x1e00000, /* Start: 30 MB */ 0x200000 /* Size: 2 MB */ );
Les drivers critiques sont aussi assuré d'avoir la quantité de RAM dont ils ont besoin.
Prelinking Lorsqu'une application fonctionne en utilisant les librairies partagées, le dynamic linker a beaucoup de travail a effectuer ( mappage d'addresse). Cela peut consommé beaucoup de temps pour les programmes utilisant de nombreuses librairies partagées. Si votre système ne change pas, le linker effectue à chaque fois les meme opérations pour executer votre programme. Le Prelinking consiste a simplifier les connections entre la librairie et le programme. Cela peut etre utilisé pour réduire le temps de démarrage d'un systeme Linux. Source : http://elinux.org/Pre_Linking
Désactiver la synchronisation de l'horloge La synchronisation de l'horloge avec la RTC ( RealTime? Clock) au boot peut prendre jusqu'a 1s! Cela peut etre désactivé, pouvant causer une erreur de une seconde par rapport au temps correct. Ce n'est pas une erreur critique dans de nombreux systeme etant donnée que l'horloge peut etre synchroniser plus tard avec une source externe. Source : http://elinux.org/RTC_No_Sync
Reduire la consommation de mémoire Réduire l'utilisation de la RAM du noyau Il faut booter sans l'utilisation de sysfs. Source : http://www.selenic.com/linux-tiny/index.cgi/BootingWithoutSysFs
XIP Noyau (eXecute In Place) Le code du noyau n'est pas copié dans la RAM, ce qui nous fait gagner au moins 500ko de mémoire RAM.
Remplacer initrd par initramfs Le fait de remplacer init ramdisks (initrd) par initramfs permet de gagner beaucoup de mémoire RAM. Les avantages de ramfs par rapport a ramdisk :
* No block, filesystem and VFS driver overhead
* No duplication in RAM
* Files can be removed (reclaiming RAM) after use.
Initramfs: ramfs archive embedded in the Linux kernel file.
Optimisation des librairies Examine entièrement le systeme de fichier du systeme embarqué, et trouve toutes les occurences des librairies partagée, puis recompile les librairies partagées en ne gardant que les objets/fonctions nécessaire pour faire fonctionner les applications. Source : http://libraryopt.sourceforge.net/
Sources de toutes ces optimisations : http://free-electrons.com/doc/embedded_linux_optimizations.pdf Librairie d'affichage DirectFB
http://free-electrons.com/doc/embedded_linux_multimedia.pdf