Forums d'entraide informatique - Astuces - Conseils

LINUX
SUR ARM

Linux est de plus en plus présent dans notre vie quotidienne, dans des équipements certes techniques mais relativement communs et surtout n'ayant pas une apparence d'ordinateur.
En effet, quel est le point commun entre l'iPod d'Apple (baladeur MP3 portable), la FreeBox3 de Free (équipement offrant l'accès à l'offre internet/téléphonie/télévision), le Navigator de TomTom (système de guidage automobile), les Zaurus de Sharp (assistants personnels), les A760, A780 et E680 de Motorola (téléphones mobiles), le NSLU2 de Linksys (disque dur réseau) ?Tous embarquent, ou peuvent embarquer Linux ou pCLinux sur un processeur à coeur ARM.
1.INTRODUCTION
L'architecture ARM bien que peu connue du grand public est l'une des plus utilisées au monde. En effet, les coeursARM sont disponibles sous licence de la part d'ARM et sont intégrés par la plupart des fondeurs dans leurs propres processeurs. Les divers sondages et études de marché de www.linuxdevices. com confirment la popularité des coeurs ARM auprès des développeurs d'architectures embarquées.
Développé initialement par Acorn (fabricant britannique d'ordinateurs) entre 1983 et 1985,ARM signifie alors Acorn RISC Machine. L'ARM I est un processeur 32 bits simple, peu coûteux et est utilisé par Acorn en tant que coprocesseur du 6502 qui équipe ses ordinateurs BBC Micro. Le pari est osé mais part d'hypothèses simples : en créant un processeur RISC, le coeur serait plus petit et donc moins cher, les performances seraient théoriquement meilleures car chaque instruction s'exécuterait en un nombre de cycle réduit, et le design serait plus simple et donc plus rapide à mettre au point.
Acorn, racheté par Olivetti, sort son premier ordinateur fonctionnant intégralement sur un ARM 2 à 8 MHz en 1987. Il s'agit de l'Archimedes. Acorn est alors l'un des leaders du marché de l'informatique personnelle et éducative en Grande-Bretagne. La plupart des logiciels sont développés par des petites sociétés gravitant autour d'Acorn.
En I 989,Acorn sort l'ARM3 qui dispose de 4 kilo-octets de cache et fonctionne à 25 Mhz.VLSI, le partenaire fondeur d'Acorn parvient alors à convaincre d'autres fabricants d'utiliser la technologie ARM dans leurs produits. Cela marque les débuts d'ARM, Advanced RISC Machine, société créée par Acorn, Apple et VLSI et chargée de développer la technologie ARM. ARM développe l'ARM6 ainsi qu'un coprocesseur arithmétique flottant et un contrôleur graphique amélioré. L'objectif était,
entre autres, de créer un processeur performant et optimisé pour une utilisation nomade, l'ARM610, qui allait équiper le fameux Newton d'Apple. Petit à petit, les fabricants de semi- conducteurs font l'acquisition de licences ARM pour créer leurs nouveaux produits, souvent poussés par leurs clients, les fabricants d'équipements informatiques grands publics et d'appareils embarqués.
En ayant comme objectif permanent l'obtention de hautes performances pour un faible prix, de minimiser la consommation et de permettre de réduire les cycles de développements d'un composant personnalisé, ARM a fini par convaincre une cinquantaine de fabricants de semi-conducteurs, soit la quasi-totalité des grands noms du domaine.
Les quatre principaux coeurs actuellement disponibles sur le marché sont s l'ARM7, l'ARM9, l'ARM I I et le XScale. Des déclinaisons existent dans chaque gamme en fonction de la présence de MMU, et de divers accélérateurs. La gamme ARM I I ouvre de plus les portes du multicore (jusqu'à 4) sur ARM.
Avant d'aller plus loin, il est important de parler de deux technologies développées par ARM : le thumb qui est un jeu d'instructions 16 bits que la majorité des ARM acceptent et qui peut être intéressant pour certaines applications, le Jazelle qui est un core sachant exécuter du bytecode java qui est intéressant pour les applications de type téléphone mobile par exemple.
Les coeurs ARM ont sept modes d'exécution :
♦    User : sans privilège, pour la majorité des tâches ;
•    FIQ : interruptions de haute priorité (Fast) ;
•    IRQ : interruptions de « faible » priorité (Normale) ;
•    Superviseur : reset et SWI (software interrupt) ;
♦    Abort : violation d'accès mémoire ;
♦    Undef : instruction non définie ;
♦    System : privilèges maximum (partageant les mêmes registres que le mode User).
Le schéma suivant (directement copié d'une présentation d'un ingénieur d'Intel) présente les différents registres disponibles et notamment les registres propres à chaque mode ainsi que les registres transversaux :

•    Les flags de status : Negative, Zero, Carry, oVerflow, Q (saturation), J (mode Jazelle)
•    Les flags de gestion des interruptions :let F (respectivement 1RQ et F1Q)
•    Le flag du jeu d'instruction en cours : T (0 = ARM, I = Thumb)
•    Le mode actuel : codé sur 4 bits.
Avant d'aller plus loin, nous allons faire un rapide tour d'horizon des instructions disponibles sur un cœur ARM. Nous ne présenterons que les quelques instructions qui seront nécessaires pour comprendre la suite. Les documents disponibles à l'adresse suivante récapitulent plus précisément toutes ces instructions de manière exhaustive
http://www.armsemi.com/documentation/Instruction_Set/ index.html
Tous les exemples suivants sont issus du code source du
bootloader u-boot.
èè Instruction Branch (b) :elle permet de changer la valeur du program counter et donc d'appeler une fonction située dans la zone +/- 32 Mo de l'instruction courante. Sa dérivée est l'instruction Branch with Link (hi) qui sauvegarde auparavant l'adresse de l'instruction suivante dans le Link Register afin de pouvoir y revenir une fois la fonction appelée terminée.
Exemples
reset
aute à la fonction r eset
bl    cpu_init_crit
exécute la fonction c pu_i ni t_c r i t qui aura la possibilité de revenir à l'instruction suivante afin de continuer l'exécution de l'initialisation.
•    Instruction Move (mov) :elle permet d'affecter une valeur à un registre.
l'adresse représentée par _undef i ned_i hstructi or va contenir la valeur d'adresse de la fonctiorï'undef j n eu_ i nstructi on. L'instruction 1 dr servira à charger cette valeur dans le program counter et donc à appeler la fonction»-„,
-„
va charger dans r1 la donnée pointée par l'adresse contenue dans r?.
Idr    rø, [ri, #8]
va charger dans r la donnée pointée par l'adresse contenue dans ri + 8 octets.
Pourquoi une telle manipulation alors qu'il aurait semblé possible de faire un inov pc,adresse de la fonction undef ned_ instruction?
Tout cela est dû au codage des instructions dans la mémoire une instruction peut contenir une constante (dite « immédiate »), mais seulement 12 bits (sur les 32 de l'instruction) sont affectés à la représentation de cette constante. 11 faut donc bien penser à la valeur de la constante et à sa représentation car toutes les constantes ne peuvent être représentées de cette manière. Sur les 12 bits, les 4 premiers sont la « valeur de rotation » qui sera multipliée par deux (car il s'agit tout le temps d'un décalage d'un nombre pair de bits), les 8 suivants sont l'octet de donnée qui subit la rotation.
La donnée 32 bits représentée est donc obtenue par une rotation circulaire vers la droite (les bits en position 0 sont replacés en position 31).
Quelques exemples pour mieux comprendre :
•    #0x00008000 est représenté par : 0x80 roc 24, codé par 0xC80
•    #0x10008000 n'est pas représentable
•    #4096 est représenté par : 0x40 ror 26, codé par HxD40 ;

•    #0x00F F0000 est représenté par : 0x FF r or 16, codé par 0x8F F.
•    • Instruction Store (str) r) : elle permet de stocker à une adresse la valeur contenue dans un registre.
Exemples :
str    rl, [r0]     I
stocke dans r0 la valeur pointée par l'adresse r1.
••Les instructions complémentaires sont assez classiques (se référer au document ARM pour le jeu d'instruction complet) :
ADD :addition
SU B : soustraction MUL : multiplication AND : et logique
EOR : ou exclusif ORR u logique
BIC : bit clear
CM P : comparaison
Nous savons maintenant que l'ARM a 7 modes de fonctionnement et avons quelques notions d'assembleur, il est temps de voir comment le processeur passe d'un mode à l'autre.
La table des vecteurs est située en 0x0000 0000 ou en OxFFFF 0000. Elle fournit les pointeurs vers divers gestionnaires d'exception : Reset, Undefined Instruction, Software Interrupt, Prefetch Abort, Data Abort, IRQ et FIQ.
Lors du du démarrage d'un système le processeur va directement au vecteur de reset et exécute la fonction associée.Ainsi, en désassemblant les premières instructions d'un bootloader, on se retrouve avec la forme suivante :
00000000 <_start>:
0: ea000012 b    50 <reset>
4: e59ff014 ldr pc, [pc, #20]    20 <_undefined_instruction>
8: e59ff014 ldr pc, [pc, #20]    24 <_software_interrupt>
c: e59ff014 ldr pc, [pc, #20]    28 <_prefetch_abort>
10: e59ff014 ldr pc, [pc, #20]    2c <_data_abort>
14: e59ff014 ldr pc, [pc, #20)    30 <_not_used>
18: e59ff014 1 d r pc, [pc, #20]    34 <_irq>
lc: e59ff014 ldr pc, [pc, #20]    38 <_fiq>
Nous retrouvons bien notre table de vecteur avec un branchement vers une fonction reset en 0x0. Le traitement des autres exceptions est fait en chargeant l'adresse de la fonction à appeler dans le program counter.
2.BASES ELECTRONIQUES DISPONIBLES POUR
EMBARQUER LINUX
La majorité des grands fabricants de microprocesseurs ont fait l'acquisition d'une licence ARM et proposent des produits plus ou moins dédiés à certains marchés en fonction des périphériques qu'ils intègrent. Nous différencions les microprocesseurs des microcontrôleurs par la présence d'un bus externe d'adresses et de données sur les premiers, lequel bus offre la possibilité d'interfacer des mémoires externes et d'autres périphériques selon les besoins.
Exemple du passage entre deux modes : où x_mode = registre x du mode visé, et x = registre x du mode actuel.

En effet, ces dernières années ont vu l'arrivée de microcontrôleurs à base de cœur ARM7, l'objectif étant de concurrencer les « anciens » microcontrôleurs tels que les 8051,1es PIC,AVR ou MSP430. Mais bien entendu, pas question de faire tourner un Linux ou un pCLinux dessus vu que la majorité de ces composants intègrent seulement quelques dizaines de Ko de RAM et de Flash et n'offrent pas de possibilité d'extension (eCos ou RTEMS sont par contre des solutions qui peuvent être intéressantes pour ces processeurs). Il existe toutefois un environnement de développement libre, basé sur les outils GNU et sur Eclipse qui permet de développer sur ces microcontrôleurs. Une documentation très complète sur le sujet est disponible à l'adresse : http://www.olimex. com/dev/pdf/ARM%20Cross%20Development%20with%20Ec lipse%2Oversion%203.pdf
Fabricants proposant des microcontrôleurs ARM7 (liste non exhaustive)
Philips (gamme LPC I ), Atmel (gamme SAM7), ST (gamme STR7), Analog Devices (gamme AduC7000), OKI (gamme ML67)...
Fabricants proposant des microprocesseurs ARM7,9, XScale ou I 1
Intel (gamme Xscale —ARMv5 avec des améliorations propres à Intel et surtout une consommation optimisée et des fréquences souvent plus importantes que la concurrence), Atmel (gamme AT9 I), Philips (gamme LPC2 et 3), Freescale (ex :Motorola,gamme MX),Cirrus Logic (gamme EP93xx),TI (gamme OMAP), Samsung (gamme S3C), Sanyo, Sharp...
Toutefois, développer une carte électronique intégrant un de ces processeurs est certes faisable mais relativement long et coûteux. Il existe des solutions intermédiaires qui sont souvent basées sur des SOM : System On Modules.
De nombreux fabricants sont présents sur ce marché, je ne citerai que les plus connus.
•    Karo (www.karo-electronics.de) : constructeur allemand
offrant une gamme de modules à base de processeurs PXA de Intel (coeurs XScale)
Arcom (www.arcom.com) : constructeur anglais offrant une gamme de cartes au format PC 104 dont certaines à base de processeurs PXA et IXP de Intel
•    Gumstix (www.gumstix.com) : constructeur américain offrant une gamme de modules à base de processeurs PXA de Intel
•    Cogent (www.cogcomp.com) :constructeur américain offrant une gamme de modules à base de processeurs ARM9 de Atmel et Freescale et de processeurs PXA de Intel
•    RLC (www.rIc.com) : constructeur américain offrant une gamme de cartes à base de PXA de Intel... mais fonctionnant sous Windows CE.
Pour la suite, je me baserai sur deux kits de développements de la société dans laquelle je travaille : un kit à base de processeur AT9 I RM9200 (ARM920T 180 Mhz) de Atmel et un kit à base de processeur PXA255 (Xscale 400 Mhz) de Intel, mais les explications sont valables pour à peu près toutes les architectures de même style.
3.PRÉSENTATION DU MATÉRIEL
Deux cartes serviront de support aux exemples fournis
•    le kit AT9 I (présenté dans l'article de Pierre Ficheux dans
le hors-série précédent) :composé d'un module intégrant le processeur AT9IRM9200, 32 Mo de SDRAM, 8 Mo de Flash NOR et un PHY Ethernet 10/100 et d'une carte mère fournissant une connectique traditionnelle :5 ports série sur connecteurs SUBD9, 1 port Ethernet sur un connecteur RJ45, un connecteur SDCard/MMC, et deux connecteurs USB périphérique et hôte.
•    le kit PXA255 (photo suivante) : composé d'un module intégrant le processeur PXA255, 64 Mo de SDRAM,32 Mo de Flash NOR et d'une carte mère fournissant : I contrôleur Ethernet 10/100 sur un connecteur RJ45, 4 ports série sur des connecteurs SUBD9, 1 port USB périphérique et une interface vers un écran TFT 16 bits avec une interface pour écran tactile résistif 4 fils et un codec audio AC97.
Le kit PXA255
4.0UTILS NÉCESSAIRES
Afin de faire tourner Linux sur ces processeurs, il est nécessaire de disposer d'un certain nombre d'outils, tous disponibles sous licence GPL : les Binutils (assembleur & co) en version 2.16.x, les compilateurs (gcc & co) en version 3.4.x, une librairie C (91 lb) en version 2.3.x, tous disponibles sur internet. L'idéal est d'utiliser Crosstool (http://www. kegel.com/crosstool/) pour créer la suite d'outils adaptés pour le processeur que l'on souhaite utiliser. L'utilisation de Crosstool a été couverte par un article de Pierre Ficheux dans un numéro précédent ( http://pficheux.free.fr/articles/ Imf/cross compilation/cross_compilation images.pdf ).II n'est pas nécessaire de revenir sur le sujet.
Une dernière précision : les processeurs ARM n'ont, en général, pas de logique câblée des flottants.Ainsi les calculs flottants passent par une émulation.
Historiquement cette émulation a été confiée au noyau Linux qui installait un gestionnaire d'instruction inconnue et « attrapait » donc les instructions flottantes que le processeur ne savait exécuter, les émulait et renvoyait le résultat comme

DÉDIÉ   
   
l'aurait fait un vrai coprocesseur. Cette méthode présente l'avantage de ne pas avoir à se soucier des flottants dans ses applications et de se reposer sur le noyau qui récupérera la situation dans tous les cas. Elle présente aussi l'inconvénient d'être lente du fait du passage en exception.
Plus récemment, Nicolas Pitre a implémenté une gestion des calculs flottants suivant la norme IEEE 754 directement dans la librairie C.Cela permet d'avoir une exécution entièrement en entiers et de ne plus générer d'exception et donc d'obtenir une exécution plus performante (x7 à x9 selon les benchs utilisés) : http://www.spinics.netilists/arm/msg07268.html
Crosstool permet par défaut de générer un toolchain utilisant la librairie g 1 i bc.Si vous préférez utiliser la librairie ucl i bc (plus légère), il faudra se tourner vers les outils adéquats : http://buildroot.uclibc.org/
Enfin, il est nécessaire d'avoir installé et configure :
•    Un serveur TFTP ;
•    Un terminal série (minicom, kermit & co) ;
•    Les outils permettant de transmettre des données sur le port série (http://www.ohse.de/uwe/software/Irzsz.htm1).
5.ADAPTATION DU BOOTLOADER
L'objectif de cette étape est d'adapter un bootloader à la carte et d'en faire une version fiable qui sera installée dans le premier secteur de la flash, lequel sera ensuite protégé et, théoriquement, jamais effacé afin de ne pas risquer de perdre ce fameux premier secteur sans lequel le processeur ne peut démarrer.
Tous les processeurs ne sont pas égaux dans ce domaine :
•    Certains disposent d'une bootrom interne qui contient un firmware impossible à effacer. Ce firmware permet d'avoir une possibilité d'accès au processeur même lorsque le premier secteur de la flash externe a été effacé. C'est par exemple le cas de l'AT9 I RM9200 d'Atmel ;
•    D'autres ne savent démarrer que de la flash externe. Dans ce cas, il est nécessaire de recourir à des outils adaptés pour prendre le contrôle du processeur et programmer le premier secteur de la flash. Un tel outil est un adaptateur JTAG sur le port parallèle, relativement simple et peu coûteux à fabriquer (cf. http://jtag-arm9.sourceforge.net/hardware. html). Le logiciel JTAG, disponible à http://openwince. sf.netljtag/, permet de piloter bon nombre d'adaptateurs JTAG et reconnaît la plupart des processeurs et flashs actuellement utilisés.
5.1 POURQUOI UN BOOTLOADER ?
C'est la première étape, qui peut être considérée comme optionnelle dans certains cas, mais apparaît indispensable pour faciliter l'étape suivante du développement et surtout créer un produit stable qui peut être facilement mis à jour sans prendre de risque.
De nombreux bootloaders sont disponibles sur internet et chez certains fournisseurs de produits commerciaux, alors pourquoi avoir choisi u-boot ? Parmi tous les bootloader testés, deux sortent du lot : RedBoot du projet eCos et
u-boot, « The Universal Bootloader ». Ce dernier a été préféré pour sa simplicité et son organisation modulaire facilement compréhensible.
5.2 TOUR DU PROPRIÉTAIRE
Après avoir téléchargé et extrait les sources du bootloader, prenons le temps d'en faire un tour rapide afin de mieux comprendre l'étendue du travail à faire :
•• board : contient un répertoire par carte électronique supportée, chacun de ces répertoires comprenant les fichiers propres à sa carte, soit au minimum :
•    conf i g .mk (contenant l'adresse de base de chargement en RAM du bootloader) ;
•    nom carte.c (C contenant les initialisations « haut niveau » spécifiques à la carte) ;
•    memsetup . S ou lowl evel_i ni t .S (assembleur contenant
les initialisations « bas niveau » spécifiques à la carte) ;
•    Ma kef i le ;
•    D'autres fichiers source peuvent venir compléter cette base, selon les spécificités de la carte que l'on souhaite supporter dans le bootloader, par exemple le support de la flash dans flash .c.
•• cpu : contient un répertoire par type de processeur supporté (ARM, Xscale, PowerPC, i386, MIPS, Microblaze, Coldfire, Nios). Dans notre cas, nous nous orienterons vers le répertoire a rm720t qui correspond au cceur ARM autour duquel est conçu le processeur cible. Ce répertoire contient les fichiers propres au processeur, soit au minimum :
•    con f g . mk (contenant les flags de compilation et autres optimisations spécifiques au processeur),
•    cpu. c (fichier c contenant les fonctions « haut niveau » propres au processeur :    ni t, cl eanup_before_l i nux,
d o_r e s et, gestion du coprocesseur et du cache),
•    serial*.c (fichier c offrant l'accès à au moins un port série du processeur : seri al_setbrg, serial _i ni t, serial _putc, seri a l_t stc, seri al_getc, seri al_puts),
•    sta rt S (fichier assembleur contenant les fonctions « bas niveau » propre au processeur et qui se retrouvera en adresse 0, c'est-à-dire qui sera exécuté à la mise sous tension de l'équipement : démarrage, appel des fonctions critiques d'initialisation du processeur (Cache, MMU, PLL & co en général), appel des fonctions propres à la carte initialisant notamment le contrôleur mémoire; relocation du bootloader en SDRAM, initialisation de la pile, exécution du code générique du bootloader).
•• common :contient les fichiers génériques du bootloader, à savoir les commandes exécutables ou le support générique de certaines fonctions ou périphériques.
•• drivers : contient les drivers de périphériques plus ou moins génériques (contrôleurs Ethernet, USB...)
é• lib arch : un répertoire par architecture, comprenant des fonctions génériques (« main » de l'architecture, fonctions communes à tous les processeurs de l'architecture...)