CAPTRONIC Linux sur ARM. Toulouse 3 avril Éric Bénard. Organisé par

Transcription

1 Linux sur ARM Toulouse 3 avril 2013 Éric Bénard Organisé par

2

3

4 Présentation générale Principe de base d'un projet embarqué Une cible : Architecture CPU spécifique (ARM, x86, PPC...) Carte électronique comportant des périphériques adaptés à l'application Système d'exploitation, drivers & applications Un poste de développement : En général un PC sous Linux Compilation croisée : Générer sur le poste de développement des binaires qui pourront être exécutés sur la cible 4 / 42

5 Logiciels libres? Libre = licence offrant les 4 libertés suivantes : Exécuter le programme Étudier le fonctionnement du programme Redistribuer des copies du programme (don ou vente) Améliorer le programme et publier ses améliorations Exemples de licences libres : Domaine public, BSD, GPL (CopyLeft) Respecter les licences : gpl-violations.org/faq/ Liens : / 42

6 Avantages / inconvénients Base existante importante : réduit le besoin de réinventer la roue Communauté dynamique : code validé et corrigé en cas de problème mais quelle version choisir? Diversité des projets : choix important mais risque de s'y perdre Support via la communauté : efficace mais aucune garantie d'obtenir une réponse Risques juridiques surtout dans les pays autorisant les brevets logiciels Coût direct des logiciels nul mais temps d'apprentissage et d'intégration non négligeable 6 / 42

7 Linux et les autres Configuration minimale : Processeur 32 bits 4 à 8 Mo de RAM 4 à 8 Mo de Flash Alternatives libres : Sur les micro contrôleurs : FreeRTOS, ecos, RTEMS Et bien d'autres : Liens : / 42

8 Cibles possibles Toutes celles supportés par les outils GNU Alpha, ARM, AVR, Blackfin, h8, hppa, x86, ia64, m32, m68k, mips, powerpc, sh, s390, sparc, xtensa... MMU ou pas uclinux : m68k, blackfin, ARM Aujourd'hui intégré au noyau «mainline» 32 ou 64 bits Suffisamment de RAM et de Flash 8 / 42

9 Etapes Outils de compilation croisée (toolchain) Binaire ou compilé Bootloader Initialisation bas niveau du hard + debug + chargement du noyau Noyau Linux Interface hard applications Distribution embarquée (ou pas) Librairie C, librairies complémentaires, applications... 9 / 42

10 Compilation croisée outils natifs PC (x86 x86) (make, as, gcc...) permettent de compiler des outils de compilation croisée (x86 cible) (as, gcc...) les 2 outils partagent les mêmes sources, seule change leur configuration! Difficulté : ne pas mélanger les 2 ce qui peut s'avérer compliqué selon les sources à compiler paramètres en dur dans les Makefile par exemple 10 / 42

11 Outils de compilation croisée Commerciaux Windriver, Mentor, TimeSys, Montavista... Gratuits Mentor Sourcery (existe une version «lite» gratuite) Linaro : Compilé manuellement pas à pas Générés par des outils tels que : Générateur de toolchain : Crosstool-ng Frameworks de compilation croisée : Buildroot, PTXDist, OpenEmbedded / 42

12 Bootloader Fonctions de base : Bonus : Initialiser les PLL, la SDRAM, les GPIO, Charger le noyau Linux (depuis la flash en général), Exécuter le noyau Linux, Console série pour mise au point, configuration, Chargement par une liaison ethernet, Gestion des flashs (programmation, effacement), Gestion de périphériques (ex : I2C, SPI, etc...) USB : device (DFU, console) ou host (mass storage) 12 / 42

13 Les forces en présence Les 2 plus connus : U-boot : «das Universal Bootloader», initialement pour PPC, maintenant, supporte : arm, avr32, blackfin, x86, m68k, microblaze, mips, nios2, ppc, sh, sparc. Pas d'irq, pas de MMU : relativement facile à adapter et très pratique pour le débug et la mise au point RedBoot : issu de ecos, Base OS temps réel : IRQ + MMU Peu de périphériques supportés, moins pratique pour le debug, organisation des sources compliquée Liens : / 42

14 La nouvelle vague Barebox : Le meilleur de u-boot et de Linux L'esprit de u-boot avec les concepts de Linux Supporte : Driver model Menuconfig Shell Système de fichiers Device tree De nombreux ARM, blackfin, MIPS, Nios2, PPC, x86 Liens : 14 / 42

15 Configuration de Barebox 15 / 42

16 Adapter le bootloader à son électronique Choisir le bon bootloader : niveau de support du processeur sélectionné niveau de support des périphériques qui présentent un intérêt au niveau du bootloader A partir du support d'une carte de référence : Adapter les réglages PLL, RAM, IOMUX Partir d'une configuration minimaliste (console série, support flash) puis ajouter les périphériques Prévoir un moyen de «récupérer» sa carte : JTAG, BootROM série / USB, etc / 42

17 Adapter le bootloader à son électronique Barebox : U-boot : arch/arm/boards/macarte/macarte.c platform_data : structures configurant les drivers Config :.config généré par : make menuconfig board/macarte/macarte.c Fonctions génériques board_init, dram_init... Config : include/configs/macarte.h (#define XYZ) 17 / 42

18 Sources : Noyau Linux «mainline» : kernel.org Constructeurs : Freescale, TI, Atmel, ST Tierce parties (Mentor, Timesys...) Doit intégrer le support de nos périphériques Périphériques classiques : mainline en général Périphériques plus complexes : noyaux constructeurs dans le meilleur de cas binaires dans le pire des cas Liens : / 42

19 Noyau Linux Même base de sources sur votre PC et sur votre cible embarquée : Facilite la mise au point des applications sur PC Toutes les parties génériques du noyau sont validés sur de nombreuses cibles Support d'un grand nombre de périphériques direct Support d'un grand nombre de protocoles et systèmes de fichiers 19 / 42

20 Noyau Linux Architectures supportées : 28 architectures dans arch Types de périphériques : 106 répertoires dans drivers Systèmes de fichiers : 71 répertoires dans fs Protocoles réseau : 54 répertoires dans net 20 / 42

21 Configuration du noyau 21 / 42

22 Adapter le noyau Linux à son électronique A partir d'une configuration proche existante : Configurer les IO (MUX, direction, niveaux par défaut) Partir d'une configuration minimaliste (console série) Ajouter les périphériques l'un après l'autre 2 méthodes selon la version du noyau : En C dans arch/arm/mach-xyz/myboard.c : Enregistrement de structures déclarant et initialisant les drivers En device tree dans arch/arm/boot/dts : Inclure le.dtsi décrivant le SOC utilisé Décrire la manière de laquelle sont utilisés les périphériques 22 / 42

23 Exemple : board.c static struct physmap_flash_data eukrea_cpuimx27_flash_data = {.width = 2, }; static struct resource eukrea_cpuimx27_flash_resource = {.start = 0xc ,.end = 0xc3ffffff,.flags = IORESOURCE_MEM, }; static struct platform_device eukrea_cpuimx27_nor_mtd_device = {.name = "physmap-flash",.id = 0,.dev = {.platform_data = &eukrea_cpuimx27_flash_data, },.num_resources = 1,.resource = &eukrea_cpuimx27_flash_resource, }; static struct platform_device *platform_devices[] initdata = { &eukrea_cpuimx27_nor_mtd_device, };.../... platform_add_devices(platform_devices, ARRAY_SIZE(platform_devices)); 23 / 42

24 Exemple : SOC Freescale i.mx28 arch/arm/boot/dts/imx28.dtsi : cpus { cpu@0 { compatible = "arm,arm926ejs"; }; }; apb@ { compatible = "simple-bus"; #address-cells = <1>; #size-cells = <1>; reg = <0x x80000>; ranges; apbh@ { compatible = "simple-bus"; #address-cells = <1>; #size-cells = <1>; reg = <0x x3c900>; ranges;.../... ssp0: ssp@ { #address-cells = <1>; #size-cells = <0>; reg = <0x x2000>; interrupts = <96 82>; clocks = <&clks 46>; fsl,ssp-dma-channel = <0>; status = "disabled"; };.../... mmc0_sck_cfg: mmc0-sck-cfg { fsl,pinmux-ids = < 0x20a0 >; fsl,drive-strength = <2>; fsl,pull-up = <0>; }; 24 / 42

25 Exemple la carte Freescale imx28-evk arch/arm/boot/dts/imx28-evk.dts /include/ "imx28.dtsi".../... / { model = "Freescale i.mx28 Evaluation Kit"; compatible = "fsl,imx28-evk", "fsl,imx28"; memory { reg = <0x x >; }; apb@ { apbh@ { ssp0: ssp@ { compatible = "fsl,imx28-mmc"; pinctrl-names = "default"; pinctrl-0 = <&mmc0_8bit_pins_a &mmc0_cd_cfg &mmc0_sck_cfg>; bus-width = <8>; wp-gpios = <&gpio2 12 0>; vmmc-supply = <&reg_vddio_sd0>; status = "okay"; }; Sources Linux : Documentation/devicetree/bindings/ 25 / 42

26 Installation du noyau En général durant le développement : Sur le PC : Compilation puis copie dans le répertoire tftp Compilation du device tree puis copie dans le répertoire tftp Sur la cible (depuis le bootloader) Chargement par tftp Écriture en flash Autres possibilités : USB device (DFU), Chargement par le port série JTAG, SDCard, Clef USB / 42

27 Démarrage du noyau Depuis le bootloader : commande boot Sous barebox : script /env/bin/boot personnalisable Sous u-boot : «scripts» dans des variables d'environnement Paramètres du noyau : (barebox : /env/config) Console série Ecran à utiliser Partitionnement de la flash 256k barebox 128k env 3M kernel - (reste de la flash) rootfs 27 / 42

28 Distribution embarquée Construite : A la main : Cross Linux From Scratch Avec un générateur : PTX Dist Buildroot OpenEmbedded / Yocto Commerciaux : (Mentor, Windriver, Montavista,...) Liens : / 42

29 Buildroot Ensemble de Makefiles et de patches qui permettent de générer un système Capable de compiler le toolchain ou d'en utiliser un binaire Relativement facile à configurer Utilisé par exemple par Google dans son projet de box fibre 29 / 42

30 OpenEmbedded / Yocto «Framework» de cross compilation Un grand chef : bitbake (écrit en python) Un livre de recettes : openembedded Pour faire un bon repas : le grand chef parcourt le livre de recette, sélectionne celles qui sont au menu, les cuisine, dresse les assiette et les sert au client. Ici le grand chef va même créer ses ustensiles! 30 / 42

31 Yocto Project? Projet «parapluie» porté par la Linux Foundation Contributions de Intel, Windriver, Mentor, etc... Sert de brique de base à ces sociétés pour construire leurs produits Différents projets associés : Bitbake / OpenEmbedded Core Outils autour d'eclipse (Application Dev Kit) Eglibc, HOB, Matchbox Infrastructure de test, de QA, etc / 42

32 OpenEmbedded Des recettes : fichiers.bb Endroit où trouver les sources (http, ftp, git, svn, file ) Comment les extraire Quels sont les patches à appliquer Comment les configurer Comment les compiler Comment les installer Comment les packager Des fichiers de configuration : Machine (architecture, optimisation, périphériques...) Distribution (version, choix parmi les outils...) 32 / 42

33 OpenEmbedded Bitbake parcourt : les recettes les fichiers de configuration Il génère un arbre de dépendances pour aboutir au résultat demandé et génère les scripts à exécuter pour effectuer chaque tâche Il parcourt cet arbre en exécutant les tâches les unes après les autres 33 / 42

34 OpenEmbedded Pour créer une image, bitbake va : Compiler les outils nécessaires (make, git ) Compiler les outils de compilation croisée (gcc ) Compiler les librairies et outils demandés dans la recette de l'image ainsi que leurs dépendances (pas forcément toutes installées) Cela peut générer un nombre important de tâches Tant que l'on ne change pas d'architecture ou de version, on capitalise les constructions Le toolchain et les librairies ne seront compilés qu'une fois! Image complète avec QT4 : ~1h30 sur Intel i7 34 / 42

35 Spécificité de la flash : Systèmes de fichiers Nombre de cycles écriture/effacement limité (10 ~ 100k) FS gérant : Wear leveling (répartition des cycles sur l'ensemble de la flash) La compression (gain d'espace) Adaptés aux flashs : jffs2 : ancien, lent sur les grosses capacités squashfs : compressé et lecture seule yaffs2 : créé pour les flashs NAND Maintenant : UBIFS (développé par Nokia) Le futur : BTRFS / 42

36 Installation du rootfs Sur le PC : Dans le répertoire tftp Sur la cible (depuis le bootloader) Chargement par tftp Écriture en flash Autres possibilités : USB device (DFU), Chargement par le port série JTAG, SDCard, Clef USB / 42

37 Utilisation du rootfs Monté par le noyau Premier binaire (init) exécuté par le noyau Arborescence unixienne classique Comme sur le PC Commandes standard Dans quelques Mo : Serveur web avec CGI Serveur SSH Démonstrateur QT ( > 40 Mo à lui seul!) 37 / 42

38 Votre application Ligne de commande ou graphique? Développement : Sdk + éditeur de texte + Makefile + code binaire QT Creator + dessin IHM + code binaire IDE : au choix (Eclipse, Anjuta, Kdevelop, QTCreator ) Debug : «juste» besoin de configurer l'ide pour utiliser les outils de compilation croisée Couche gdb/gdbserver en ligne de commande Utilisable par QTCreator, Eclipse en environnement graphique 38 / 42

39 QT Creator IDE complet Edition Code Conception IHM Compilation Debug Cross Platform 39 / 42

40 Récapitulatif, exemple d'application Bootloader Barebox / u-boot Noyau Linux Librairie Graphique QT Busybox GNU Lib C ou uclibc 40 / 42

41 Merci pour votre attention Questions / Remarques 41 / 42

42 Mentions légales EUKREA ELECTROMATIQUE SARL au capital de SIRET APE 3320C RCS Bordeaux 2004 B TVA FR Organisme de formation enregistré sous le numéro auprès du Préfet de Région d'aquitaine Eukréa est une marque déposée de Eukréa SARL. ARM est une marque déposée d'arm Limited. Linux est une marque déposée de Linus Torvalds. Windows est une marque déposée de Microsoft Corporation. Toutes les autres marques citées dans ce document appartiennent à leurs détenteurs respectifs. Eukréa s'efforce de fournir des renseignements fiables et actualisés et se réserve le droit de modifier son offre à tout moment. Le contenu de ce document n'est pas contractuel. Copyright Eukréa v130403a 42 / 42