Conception d’un systèmeembarqué pour la supervision des ateliers Projet de Fin d’Etude Réaliser par : YOUSSEF FARES Encadrer par : Mr. Laurent Laffont La société TEMIS Mr. Hamdi Abdelaziz L’école national des ingénieurs de Sousse 2008 Youssef Fares L’ecole national des ingénieurs de Sousse 07/06/2008 ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Table de matière 2 ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Table de matière 3 Remerciement Avant d’entamer ce rapport de projet de fin d’études, je tenais à exprimer mon sincère gratitude envers tous ceux qui m’ont aidé ou ont participé au bon déroulement de ce projet. Je tenais à remercier : - Toute ma famille qui m’a été toujours la garante d’une existence paisible et d’un avenir radieux, mon père, ma mère, mon frère Idris mes sœurs Marieme et Samia. - Tous ceux qui sont toujours dans mes pensées. - Ceux qui ont fait de leur mieux pour me soutenir durant ce travail : Mon oncle Moktar et sa femme Mon oncle Hedi Mes adorables amis : Meher mokadem, Kahled hajaji, Lassed Hajem, Mohamed Brahem, Hamdi Bn-Hdajmbarek - La société TEMIS qui m’a accueilli. Je devais remercier Mr. Laurent Laffont pour sa générosité, sa compréhension et son aide inestimable et Mr. Laurent Terrier le directeur de l’entreprise. Je suis reconnaissant également à M. Hamdi Abdelaziz, mon encadreur sans oublier tout mes professeurs, dont J’exprimons mes sentiments de gratitude à tous mes professeurs et à tous ceux qui m’ont aidé ou encadré pour m’avoir transmis leur savoir et leur savoir faire dans les meilleures conditions possibles. ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Table de matière 4 Table de matière Table de matière................................................................................................................................................ 4 Table de figures ................................................................................................................................................. 7 Table des Images ............................................................................................................................................... 8 Table de tableaux .............................................................................................................................................. 8 Introduction ...................................................................................................................................................... 9 Section 1 Présentation..................................................................................................................................... 10 Chapitre 1 Présentation de TEMIS et son produit IGM50..................................................................................... 10 1 Présentation de TEMIS................................................................................................................................. 10 2 Le produit IGM50......................................................................................................................................... 10 Chapitre 2 Le système IGM50 ............................................................................................................................. 11 1 Principe de fonctionnement ......................................................................................................................... 11 2 Le terminale IGM50..................................................................................................................................... 13 Section 2 Présentation et définition des besoins............................................................................................... 15 chapitre 1. Le concept IGM2.O : Idée et Objectifs .......................................................................................... 15 1 L’idée de projet IGM2.0................................................................................................................................ 15 2 L’objectifs de IGM2.0 ................................................................................................................................... 15 2.1 Objectifs............................................................................................................................................ 15 2.2 Description de concept IGM2.0.......................................................................................................... 16 chapitre 2. Présentation de terminale IGM2.0............................................................................................... 18 1 Présentation ................................................................................................................................................ 18 2 IGM2.0 est un système embarqué................................................................................................................ 19 2.1. Caractéristiques de systèmes embarqués..................................................................................... 19 Faible coût........................................................................................................................................... 19 Faible consommation .......................................................................................................................... 19 Faible encombrement et faible poids................................................................................................... 19 Fonctionnement en Temps Réel (Réponse de temps) .......................................................................... 19 Environnement.................................................................................................................................... 20 2.2. Architecture générale de IGM2.0................................................................................................. 20 Section 3 Outils de développement.................................................................................................................. 22 1 Introduction................................................................................................................................................. 22 Chapitre 1 Les environnements de développement ............................................................................................ 22 1 Définitions ................................................................................................................................................... 22 ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Table de matière 5 2 ELDK- Embedded Linux Development Kit...................................................................................................... 24 3 Buildroot...................................................................................................................................................... 24 4 OpenEmbedded........................................................................................................................................... 25 5 Poky Linux.................................................................................................................................................... 25 Pourquoi poky ? .................................................................................................................................. 26 Chapitre 2 La carte et les autres outils ................................................................................................................ 26 1 La carte AT91SAM9260-EK ........................................................................................................................... 26 2 Les autres outils ........................................................................................................................................... 27 2.1 QEMU Emulateur L’environnement d’émulation............................................................................... 27 2.2 SVN un logiciel de gestion de versions.............................................................................................. 28 2.3 NFS.................................................................................................................................................... 28 Section 4 Solutions techniques......................................................................................................................... 29 chapitre 1. Linux notre système d’exploitation embarqué............................................................................. 29 1 Pour quoi un système d’exploitation............................................................................................................ 29 2 Pourquoi Linux ? .......................................................................................................................................... 29 2.1 Prix.................................................................................................................................................... 29 2.2 "Source code" disponible et gratuit ................................................................................................... 30 2.3 Beaucoup de pilotages et outils de développement disponibles ........................................................ 30 2.4 Plein d'applications............................................................................................................................ 30 2.5 Support de réseau ............................................................................................................................. 30 2.6 La multitude des architecture supporté ............................................................................................. 30 2.7 Le marché.......................................................................................................................................... 31 Chapitre 2 Linux un système d’exploitation pour l’embarqué, comment ? .......................................................... 32 1 Introduction................................................................................................................................................. 32 2 Architecture de linux.................................................................................................................................... 32 2.1 Chargeur de démarrage ou le bootloader .......................................................................................... 33 2.2 Noyau................................................................................................................................................ 33 2.3 Pilotes de périphérique...................................................................................................................... 34 2.4 Système de fichiers............................................................................................................................ 34 2.5 Bibliothèques (Librairies) ................................................................................................................... 34 2.6 Utilitaires de base.............................................................................................................................. 34 2.7 Les applications ................................................................................................................................. 34 3 Optimisation ................................................................................................................................................ 34 ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Table de matière 6 3.1 L’optimisation de système de fichier.................................................................................................. 35 3.2 Suppression du swapping .................................................................................................................. 36 3.3 Optimisation de noyau ...................................................................................................................... 36 chapitre 2. Les applications et les paquets nécessaires .................................................................................. 38 1 Introduction................................................................................................................................................. 38 2 Les applications............................................................................................................................................ 38 2.1 BusyBox............................................................................................................................................. 38 2.2 TinyLogin........................................................................................................................................... 38 2.3 Temix –webkit ................................................................................................................................... 39 Définitions........................................................................................................................................... 39 Pour quoi webkit ?............................................................................................................................... 39 2.4 Serveur web ...................................................................................................................................... 39 3 Les paquets.................................................................................................................................................. 39 3.1 Base-files........................................................................................................................................... 39 3.2 Initscripts........................................................................................................................................... 40 3.3 xserver-Kdrive-fbdev ......................................................................................................................... 40 3.4 nfs-utils ............................................................................................................................................. 40 3.5 libération-fonts.................................................................................................................................. 40 3.6 Xinit................................................................................................................................................... 40 3.7 Netbase............................................................................................................................................. 40 3.8 Udev.................................................................................................................................................. 40 Section 5 Développement ................................................................................................................................ 41 1 Introduction................................................................................................................................................. 41 Chapitre 1 Construction de linux et les applications embarqués.......................................................................... 41 1 Poky, Comment utiliser ?.............................................................................................................................. 41 1.1 Installation des paquets nécessaires .................................................................................................. 41 1.2 Téléchargement de Poky ................................................................................................................... 42 1.3 Compiler et exécuter une image........................................................................................................ 42 2 Le portage de linux....................................................................................................................................... 43 2.1 Etape 1.............................................................................................................................................. 43 2.2 Etape2............................................................................................................................................... 44 2.3 Etape 3.............................................................................................................................................. 45 3 Ajout des applications et des paquets......................................................................................................... 45 ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Table de figures 7 3.1 Construction de temix-webkit............................................................................................................ 45 3.2 Configuration de busybox.................................................................................................................. 45 4 Compilation ................................................................................................................................................. 45 Chapitre 2 Programmations web et réseaux........................................................................................................ 46 1 Programmation web .................................................................................................................................... 46 1.1 Le Démo web- igm2.0........................................................................................................................ 46 1.2 JavaScript et les raccourcis des boutons............................................................................................. 47 1.3 Ajax, récupérer les valeurs des capteurs ............................................................................................ 47 2 Programmation réseaux............................................................................................................................... 47 Chapitre 3 Configuration de la carte et test......................................................................................................... 48 1 Configuration de la carte.............................................................................................................................. 48 1.1 Chargement de AT91Bootstrap sur la carte........................................................................................ 48 1.2 Chargement de u-boot ...................................................................................................................... 50 2 Test.............................................................................................................................................................. 51 2.1 Monter et flasher le noyau ................................................................................................................ 51 2.1.1 Configuration de u-boot.............................................................................................................. 51 2.1.2 Pour flasher linux........................................................................................................................ 52 2.1.3 Pour télécharger le fichier de système par nfs............................................................................. 52 2.2 Lancer les applications....................................................................................................................... 53 Conclusion....................................................................................................................................................... 55 Bibliographie................................................................................................................................................... 56 Section 6 Les ANNEXES..................................................................................................................................... 57 Chapitre 1 Annexe A........................................................................................................................................... 57 Chapitre 2 ANNEXE B .......................................................................................................................................... 65 Chapitre 3 ANNEXE C ................................................................................................... Erreur ! Signet non défini.0 Table de figures Figure 1-1 principe de fonctionnement d’IGM5O........................................................................................................................................................ 11 Figure 2-1 le projet IGM2.0............................................................................................................................................................................................ 16 Figure 2-2 le terminale IGM2.0 et ses modules............................................................................................................................................................ 18 Figure 2-3 Topologie d'un Système Embarqué............................................................................................................................................................. 20 Figure 3-1 la compilation croisé..................................................................................................................................................................................... 23 Figure 3-2 Sato Desktop - Une capture d'écran à partir d'un ordinateur exécutant Poky built image .................................................................... 25 Figure 4-1 Le développement des OSs Embarqués, En 2004....................................................................................................................................... 31 ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Table des Images 8 Figure 4-2 l'architecture de linux................................................................................................................................................................................... 32 Figure 4-3 Optimisation de Linux................................................................................................................................................................................... 35 Figure 5-1 démarrage de u-boot.................................................................................................................................................................................... 51 Table des Images Image 1-1 logiciel de suivi de production...................................................................................................................................................................... 12 Image 1-2 Suivre de l'état de machine.......................................................................................................................................................................... 12 Image 1-3 Le terminal IGM50 ........................................................................................................................................................................................ 13 Image 1-4 Le terminal IGM50 modifié........................................................................................................................................................................... 13 Image 3-1 la carte dévaluation AT91SAM9260EK ........................................................................................................................................................ 26 Image 5-1l'image de bureau de poky sato.................................................................................................................................................................... 43 Image 5-4 un désigne imaginé d’IGM2.0....................................................................................................................................................................... 46 Image 5-2 menu Arrêts d’IGM2.0 .................................................................................................................................................................................. 46 Image 5-3 menu principale d’IGM2.0............................................................................................................................................................................ 46 Image 5-5 La position de jumper 7 sur la carte ............................................................................................................................................................ 48 Image 5-7 La fenêtre de SAM-BA................................................................................................................................................................................... 49 Image 5-6 Exécution de SAM-BA ................................................................................................................................................................................... 49 Image 5-8 le Flash Memory map ................................................................................................................................................................................... 50 Image 5-9 temix-webkit exécuter sur la carte mais exporter saur le pc..................................................................................................................... 54 Image 5-10 connexion à la carte à partir de PC............................................................................................................................................................ 54 Image 6-1 : simulation de system-temix sous qemu.................................................................................................................................................... 69 Table de tableaux Tableau 4-1 Les architectures supporté par linux .................................................................................................... 30 Tableau 4-2 comparaison bootloaders.................................................................................................................... 33 Tableau 4-3 Taille de TinyLogin............................................................................................................................... 38 Tableau 4-4 le système de fichier respectant le standard........................................................................................ 40 Tableau 5-1 Les paquets à installer pour utiliser poky ............................................................................................. 41 ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Introduction 9 Introduction L’objet de ce rapport est le stage de fin d’étude réalisé en troisième année à l’école national des ingénieurs de Sousse. Le stage était au sein de la société TEMIS. Dans l'objectif de satisfaire les nouveaux besoins clients et de s'intégrer dans les nouvelles technologies, la société TEMIUS démarre un projet de réalisation d'un nouveau terminal, dont le sujet de mon projet de fin d’étude. Dans ce cadre je suis appelé, sur une carte avec microcontrôleur ARM9, de mettre en œuvre : - Un système d’exploitation linux - un écran TFT avec dalle tactile - un lecteur RFID - le pilotage d'entrées/sorties logiques et d'entrées analogiques - Réaliser un prototype de terminal avec les logiciels suivants: - serveur web - communication TCP/IP avec la supervision - interface graphique via un navigateur Web embarqué ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Présentation 10 Section 1 Présentation Chapitre 1 Présentation de TEMIS et son produit IGM50 1 Présentation de TEMIS La société TEMIS est un bureau d’étude créée en 1997 et situé à la Roche sur Forn (haute Savoie), elle comptabilise au total un effectif de 7 personnes, dont le capital est d’environ 50 000€. TEMIS est un bureau d’étude spécialisé dans l’informatique 50% et l’électronique 35% mais également dans la mécanique 15%. Ils imaginent, conçoivent et créent tout types de produits ayant un lien avec l’un des trois domaines cités. Ils programment des logiciels, pratiquent le hardware et le software, conçoivent des circuits imprimés, utilisent la CAO en 3D et peuvent fournir des prototypes du projet aux clients le souhaitant. Bien entendu ceci n’est qu’un aperçu de leurs compétences mais résume bien les principales. Ses clients sont des entreprises de la Vallée de l’Arve tel que FCMP, Perrotton, Meister France ou encore Sopil, mais on peut également compter dans ses clients de grandes sociétés comme Somfy, SEB, ou encore Tefal mais aussi des sociétés étrangères tel que Swissvoice, ou ALSTOM. Bien que travaillant pour de nombreux clients, l’activité principale de la société est l’IGM50. C’est un produit de supervision d’atelier entièrement fourni par TEMIS. Le design mais surtout la programmation de cet appareil a totalement été créée par cette société. Il équipe de nombreuses sociétés de la Vallée de l’Arve travaillant dans les domaines du décolletage, de l’imprimerie ou encore de la découpe laser. Actuellement ce produit se répand de plus en plus partout en France mais également à l’étranger (Suisse, Espagne). 2 Le produit IGM50 Le système IGM50 est un système d’interface de gestion de machines qui a pour but de visualiser en temps réel l’état d’un parc de production et de mémoriser un historique de l’état des machines. Cet historique peut être ensuite analysé pour déterminer les causes d’arrêt les plus fréquentes et calculer les indicateurs relatifs à la qualité de production de chaque machine ou d’un ensemble. Le système IGM50 permet de faire le lien entre le GPAO 1 à l’atelier de production les ordre de fabrication (OF) sont transmis de la GPAO vers l’IGM50 qui les transmet lui-même aux operateurs. Le système IGM50 rend compte de l’état d’avancement des OF. Toutes les saisies de renseignements sur les OF (nombre de pièces produites, rebuts,…) sont automatisées Depuis sa conception, IGM50 a permis : - La mise en place d’une gestion des contrôles de qualité. - La possibilité de suivre une production à partir d’un débit ou d’une vitesse au lieu d’un comptage d’unités produites. - La gestion d’un planning des OF mis à jour en temps réel en fonction de l’état d’avancement des produits en cours. - La possibilité de visualiser en temps réel l’évolution d’indicateurs statistiques de production grâce au tableau de bord. 1 Gestion de production assistée par ordinateur ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Présentation 11 Chapitre 2 Le système IGM50 1 Principe de fonctionnement Concentrateur Le concentrateur IGM50 scrute tous les terminaux connectés au bus et envoie les informations au PC de supervision. Il renvoie toutes les informations avec un horodatage prècis. Il permet également d'enregistrer les cartes à puce pour les opérateurs. Logiciel de Supervision Le PC d'atelier supervise en temps réel toutes les machines connectées. Il enregistre dans la base de données toutes les informations recueillies dans l'atelier. Ceci permet de visualiser en temps réel l'état de chaque machine: les quantités produites, les arrêts et leurs causes, les performances. Toutes les données enregistrées servent à réaliser les analyses de production, calculer les indicateurs de production. Logiciel d'Analyse Le logiciel d'analyse traite les informations de la base de données issues de l'atelier en temps réel et les filtre selon vos critères de choix. Il vous permet de connaître et d'optimiser l'utilisation de vos machines. Il analyse les temps d'arrêt et de production. Il suit et mesure la productivité des machines, ateliers, ilôts,... Il calcule les indicateurs de production normalisés: TRS, TRG, TRE, Taux de charge, Disponibilité opérationnelle, SMED,... Logiciel de Planning Equivalent d'un planning mural, il visualise l'état d'avancement des OF et se met à jour en temps réel. Il vous permet de prévoir votre production et optimiser l'occupation de vos machines. Il récupère les informations des OF et les ordonne sur les machines, et permet de déplacer des productions d'une machine à l'autre d'un coup de clic. Il permet de simuler des productions à venir. Il indique les retards à prévoir en fonction des aléas dans l'atelier. Logiciel Gestion Automatique des OF Mini base article pour les systèmes non reliés à une GPAO. Créez votre base article très simplement. Générez vos OF vers les machines. Permet un lancement ordonnancement très efficace. Génère des fichiers Excel pour impression. Terminal IGM50 Le terminal sert d'interface : entre les utilisateurs et l'IGM50, entre les machines et l'IGM50. Il compte les pièces fabriquées, mesure les temps de cycle machine. Il mesure les temps de fonctionnement, les temps d'arrêt. Il permet la saisie des causes d'arrêts. Il permet de sélectionner l'OF à réaliser. Il enregistre les opérateurs par leur carte à puce. Logiciel Tableau de Bord Sélectionnez les indicateurs de votre choix. Visualisez leur évolution en temps réel. Il vous permet de mesurer d'un coup d'oeil l'évolution des performances et de les comparer. 4 écrans de visualisation : TRS, MTBF, MTTR, causes d'arrêt, bilans de production,... Comparez : machine par machine, par équipe, par jour, par semaine, par mois,... Montrez leurs performances à vos opérateurs. Figure 1-1 principe de fonctionnement d’IGM5O ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Présentation 12 Visualisation instantanée de l'état des machines par groupes suivant la configuration de l'atelier. Information en temps réel sur l'avancement de la production : - référence OF et pièce, - avancement de la production visualisée graphiquement, - durée estimée de l'OF en cours par rapport à la cadence réelle de la machine, - contrôle du temps de cycle instantané, TRS, cadence,… - causes d'arrêts renseignées. L'état de la machine et de la production S’affiche instantanément : Visualisation des groupes de machines Accès au détail d’une machine Contrôle de l'avancement de la production Etat des machines en temps réel Image 1-1 logiciel de suivi de production Image 1-2 Suivre de l'état de machine ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Présentation 13 2 Le terminale IGM50 Son nombre limité de boutons, son lecteur de carte à puce et son afficheur permettent un apprentissage rapide, une utilisation simple et conviviale. Il permet aussi de gérer les prises et fin de poste, contrôle,… Nature des entrées (exemples) Comptage des pièces produites Marche machine Détection défaut Rebuts Nature des sorties (exemples) Alarme lumineuse sur contrôles, Pilotage (arrêt machine) Voyants d’alarme Carte à mémoire : Changement O.F. avec visualisation des O.F. suivants. Indicateurs lumineux : - fin d’O.F. Choix du fonctionnement : - production 5 groupes de 15 causes d’arrêt paramétrables Visualisation : - références de O.F. en cours - quantité de pièces produites - identité de l’opérateur, - temps de cycle instantané - référence pièce Rebuts - 4 entrées (Informations machines) - 2 sorties (Signalisations ou commandes) Carte à mémoire : Changement O.F. avec visualisation des O.F. suivants. Indicateurs lumineux : - fin d’O.F. Clavier de saisie des quantités produites, des rebuts … Choix du poste de travail ; Choix de l’opération en cours ; Visualisation : - références de O.F. en cours - quantité de pièces produites - identité de l’opérateur - référence pièce Rebut - 3 entrées - 2 sorties (Signalisations ou commandes) - 1 liaison bus RS 485 Image 1-3 Le terminal IGM50 Image 1-4 Le terminal IGM50 modifié ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Présentation 14 Ce terminal gère 1 à 8 postes de travail. Son nombre limité de boutons, son lecteur de carte à puce et son afficheur permettent un apprentissage rapide, une utilisation simple et conviviale. Fonctions principales Choix d’un OF et d’une opération sur l’OF (chargé depuis la supervision avec les quantités à produire) Entrée des pièces produites et des rebuts au clavier ou sur entrée Comptage automatique du temps passé sur chaque opération et suivi par équipes à la supervision Boutons de causes d’arrêt et causes d’absences (programmables). ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Présentation et définition des besoins 15 Section 2 Présentation et définition des besoins chapitre 1. Le concept IGM2.O : Idée et Objectifs 1 L’idée de projet IGM2.0 L e projet IGM2.0 ou plutôt le concept IGM2.0 est basé sur l’idée de migrer vers le web ou précisément vers les applications web (la source de l’idée été le projet WEB2.0 2 , pour cela la notation 2.0). La question que se pose alors : C’est quoi les applications web ? On dit que ces sont ; comme il les définit le site Bitpipe.com 3 ; des logiciels stockés sur un serveur et acheminés par internet ou intranet et basé sur les protocoles web (http, ftp,…), elles sont habituellement une combinaison d'une ou plusieurs pages Web interactives qui peuvent invoquer et intégrer les Navigateurs de coté client, et de bash, C, PHP, Access ou Bases de données SQL Server…, de coté serveur. Et wikipedia 4 les définit comme des applications livrées aux utilisateurs à partir d'un serveur web par un réseau tel que l’Internet ou l’Intranet. Et pour être claire et concret on peut donner des exemples des applications web, et on trouve comme un vrais exemple, Google avec son paquet Google-documents, les services de calcules, de création de PDF, agenda ..., offerts par des sites sont aussi des applications web. Mais pour quoi les applications web ? 2 L’objectifs de IGM2.0 2.1 Objectifs Aujourd'hui, les entreprises doivent être communicantes : elles ont des fournisseurs, des clients, des partenaires, des équipes internes et des équipes qui se déplacent sur terrain. L'entreprise doit pouvoir communiquer aisément avec chacun de ces partenaires qui constituent son environnement. Le logiciel qui fonctionne seul sur le pc sur lequel il est installé, n'est plus capable de répondre aux besoins de communications nécessaires à la compétitivité de l'entreprise. Quelles sont aujourd'hui les solutions offertes pour bénéficier d'une application permettant un travail collaboratif ? Il est toujours possible de faire réaliser un logiciel sur mesure. Mais ce développement est important (il devra notamment implémenter un protocole de communication). De plus, il faudra installer le logiciel sur tous les ordinateurs des personnes qui devront l'utiliser. Si des mises à jour sont nécessaires, il faudra diffuser disquettes,CD-ROM. Pour remédier à ces inconvénients, tout en conservant la même base, il est aujourd'hui possible d'utiliser une nouvelle technologie : la fédération d'applications. Dans une architecture de ce type, l'application fonctionne sur un serveur centralisé. Les utilisateurs accèdent à l'application sur le serveur comme des clients. 2 http://fr.wikipedia.org/wiki/Web2.0 3 www.Bitpipe.com 4 www.wikipédia.org ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Présentation et définition des besoins 16 Les mises à jour s'en trouvent simplifiées puisque l'application est centralisée sur un serveur. Pour l'utilisateur, c'est complètement transparent. Un double clic sur l'icône et l'application est lancée. Cette technologie reste néanmoins coûteuse puisque en plus du développement de l'application il faut mettre en place l'architecture fédérée qui repose sur des applicatifs propriétaires onéreux. Ces solutions ne fonctionnent qu'avec certaines versions de Windows. Autre inconvénient, les protocoles de fédérations sont gourmands en bande passante. Attention à votre réseau ! Quant à utiliser cette technologie via Internet, mieux vaut prévoir de gros tuyaux. Un autre choix est de réaliser un logiciel suivant une architecture web. Dans une architecture web, l'application s'exécute sur un serveur et les utilisateurs se connectent au serveur en utilisant leur navigateur internet. Cette architecture présente de nombreux avantages : Les pages web sont légères, ne satureront pas le réseau et permettent une utilisation nomade de l'application. Les mises à jour sont toujours simples puisque centralisées sur un serveur. Les serveurs web sont bon marché puisque le plus part des serveurs sont des produits libres donc gratuits. Il n'est pas nécessaire de développer une interface de communication et on bénéficie de la plateforme du navigateur web qui gère l'affichage des pages. L'application peut alors être utilisée de n'importe quelle ordinateur (PC Windows, mac, linux), Pocket PC ou même téléphone. Il suffit que l'appareil possède un navigateur internet, ce qui constitue une solution universelle d'utilisation. Pas d’installation juste un navigateur web C'est donc naturellement que les entreprises se sont tournées vers les applications web. Aujourd'hui la majorité des nouveaux projets de Système d'information sont des projets web. 2.2 Description de concept IGM2.0 Figure 2-1 le projet IGM2.0 ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Présentation et définition des besoins 17 Serveur IGM: Le serveur IGM (matériel et logiciel) va jouer les rôles : D’un serveur web normale pour gérer les communications et partager les données et les bases de données. Un serveur d’application ; tous les applications sont centralisées et installées sur ce serveur, et tous les autres terminaux et postes accèdent à ces applications par réseaux. Machine : c’est la machine dans l’usine Pc industriel (Pc industriel) : C’est un ordinateur qui va contrôler et émuler les terminaux. Terminal IGM2.0 : c’est le nouveau terminal qui va remplacer IGM50 Les méthodes de communications : Http : est un protocole de communication client-serveur développé pour le World Wide Web. RS232 : est une norme standardisant un port de communication de type série. RS485 : est une norme qui définit les caractéristiques électriques de la couche physique d'une interface numérique sérielle. La transmission se fait sur une ligne électrique, pratiquement une paire torsadée, par des variations de tension en mode différentiel. TCP/IP : est un ensemble de logiciels développés au fil des années (depuis les années 70) qui constituent un "langage universel" de communication informatique à travers le monde. chapitre 2. Présentation de terminale IGM2.0 1 Présentation Cette décision de migrer vers les applications web va exiger des modifications de base au niveau des architectures matérielles et logicielles nouvelle stratégie de communication et l’intégration de nouveaux méthodes et solutions de communication. Toute entreprise cherche à maintenir son position dan poursuivre les évolutions technologies et les intégrer dans ces produits. Dans ces deux cadres je suis appelé à reconcevoir le terminal IGM50 en IGM2.0. Figure Image ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Présentation et définition des besoins Présentation de terminale IGM2.0 Cette décision de migrer vers les applications web va exiger des modifications de base au niveau des matérielles et logicielles des terminaux et au niveau de communication par l’installation d’une nouvelle stratégie de communication et l’intégration de nouveaux méthodes et solutions de communication. Toute entreprise cherche à maintenir son position dans le marché et battre ses concourants, doit poursuivre les évolutions technologies et les intégrer dans ces produits. Dans ces deux cadres je suis appelé à reconcevoir le terminal IGM50 en IGM2.0. Figure 2-2 : le terminale IGM2.0 et ses modules Image 2-1 premier designe pour le terminal IGM2.0 ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Présentation et définition des besoins 18 Cette décision de migrer vers les applications web va exiger des modifications de base au niveau des et au niveau de communication par l’installation d’une nouvelle stratégie de communication et l’intégration de nouveaux méthodes et solutions de communication. s le marché et battre ses concourants, doit ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Présentation et définition des besoins 19 Alors, ma tache consiste précisément à intégrer un os embarquée sur un microcontrôleur avec un serveur web et un navigateur embarquée et la gestion des entrées/sorties de microcontrôleur tout en respectant les contraintes de cout, de consommation, de taille, et des ressources limités (mémoire….), or la conception et le développement des modules de communication dépendra de l’évolution et l’avancement de projet. 2 IGM2.0 est un système embarqué Il est clairement remarquable que notre terminal IGM2.0 répond pratiquement à la définition de Patrice Kadionik 5 pour le système embarqué : Un Système Embarqué, c'est une combinaison de matériels et logiciels permettant de remplir une ou plusieurs fonctions spécifiques avec des contraintes plus ou moins sévères tel que la consommation, la température, la taille, les performances... et. [Patrice Kadionik, 2004]. 2.1. Caractéristiques de systèmes embarqués Alors, notre terminal est un système embarqué, il se caractérise par suit par : Faible coût Un assez grand nombre de produits d’embarqué sont sur les marchés où l'utilisateur ne veut pas payer le supplémentaire pour la performance ou fonctionnalité de plus, Les concepteurs ont donc dû concevoir avec des rapports optimaux entre le prix et la performance Le résultat de ceci est que les ressources disponibles sont minimaux possibles. C’est pour quoi un système embarqué a rarement plus de quelques Méga octets de mémoire disponible. Faible consommation La minimisation de la consommation est essentielle pour les systèmes autonomes afin de maximiser l'autonomie des batteries. Une consommation excessive augmente le prix de revient du système embarqué car il faut alors des batteries de forte capacité. Or pour IGM2.0 la consommation ne présente pas critère très dur care le terminale va être branché directement sur le secteur. Faible encombrement et faible poids Ils doivent cohabiter sur une faible surface électronique analogique et numérique. Fonctionnement en Temps Réel (Réponse de temps) Les applications embarquées, comme des applications de système de contrôle, sont événement conduit et doivent répondre rapidement à ces événements. Peut être, Un système embarque a besoin des opérations de calcul doivent être faites en réponse à un événement extérieur. C’est une caractéristique pour quelques domaines spéciaux. 5 Ingénieur ENSEIRB et Docteur en Science de l'Université Bordeaux 1 http://doc.fedora-fr.org/wiki/Utilisateur:PatriceKadionik Image 2-2 l'interface graphique de terminal IGM2.0 ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Présentation et définition des besoins 20 Environnement Ils sont soumis à de nombreuses contraintes dictées par l'environnement telles que la température, l’humidité, les vibrations, les chocs, les variations d’alimentation, les interférences RF, la corrosion, l'eau, le feu, les radiations…etc. Cette caractéristique est importante pour IGM2.0 car il va fonctionner dans un environnement industriel. 2.2. Architecture générale de IGM2.0 Comme vous savez l'architecture de système normal, un ordinateur se compose de trois couches: Application, Système d'exploitation, et Matériel. De même, un système embarque dispose de 3 couches. Chaque couche a la même fonctionnalité qu'un système normal. Mais, Il y a des différences de sous composants du système. Les deux premières couches, Il s'agit du logiciel. Il est possible de modifier ces composants logiciels, et aussi ajouter ou supprimer ses modules au besoin dépendant du but de système. Cependant, Ce n'est pas un système qui contient tous les composants comme le système complet. Car le but de conception est de servir quelques tâches spécifiques, et de concentrer à un unique travail. Le système d'exploitation est une couche logicielle sur laquelle on va se placer l'ensemble des applications lancées par les utilisateurs. Il comprend les librairies pour le développement, des drivers permettant aux applications d'accéder à des périphériques évolués, peut-être les interfaces pour contrôler les éléments. La conception de l’OS se base forcément sur le matériel visant à optimiser la performance… etc. La dernière couche, Il s'agit du matériel. C'est-à-dire qu'un ensemble des éléments physiques employés pour le traitement de données. Les composants matériels sont limités et peut-être il y aurait un composant dédié aux tâches spécifiques. Figure 2-3 Topologie d'un Système Embarqué Entrées: - Les capteurs/convertisseurs (pression, compteur, vitesse...) - Le clavier, boutons poussoirs (wifi, radio...) - Le lecteur de tags. ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Présentation et définition des besoins 21 Sorties: - écrans LCD tactile. - les LED témoins. - les sorties des commandes. Mémoire de mass : (La détaille dans la section $4.3.1) - FLASH. - L'utilisation de ROM. - Le disque à distance Ex: NFS, TFTP. IHM: Normalement, Il est un dispositif qui sert à communiquer entre l'humain et la machine. C’est l’écran avec les dispositifs «TouchScreen» et les boutons. ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Outils de développement 22 Section 3 Outils de développement 1 Introduction Après avoir spécifié les différents besoin de notre projet, nous présenterons dans cette section les différents outils matériels et logiciels utilisés dans le développement. Je vais présenter en premier lieux les outils logiciel tel que les environnements de développement (ELDK, Buildroot, Poky…) et en deuxième lieu les matériels (carte) et dans une dernière partie les autres outils que sont indépendant de projet. Chapitre 1 Les environnements de développement 1 Définitions La plupart des développeurs utilisent un PC x86 (Linux ou Windows) comme poste de travail et il est donc nécessaire de mettre en place des outils permettant de développer du code non-x86 sur un PC, mais avant de discuter ça, on parlera de la terminologie qui concerne le développement .Il s’agit d’un environnement de développement croisé avec deux entités à distinguer : La cible (Target-System) est la plate-forme matérielle qui va accueillir l'OS et le ou les applicatifs embarques. En fait, La cible est un système cible sur lequel On veut mis en place l’OS, ou bien l'application. Elle est caractérisée par l'architecture des processeurs que peut être IntelX86, MIPS, ARM, SuperHitachi-SH…etc. L'hôte de développement (Host-Development) est la plate-forme de développement sur la quelle sont mis au point les différentes parties logicielles de la cible. En fait, C'est une machine hôte (host) pour le développement et la mise au point. Simplement, lors de la création d'un OS Embarqué ou d'une application embarquée, On écrit "code source" et compile directement les sources sur ce host de développement. Comme le développement de logiciel ordinaire, les développeurs de système embarqué ont besoin des compilateurs, des interpréteurs, les linkers, les IDE, et d'autres outils de développement. Les outils pour les développeurs de système embarqués sont différents. Car ils fonctionnent sur une architecture différente lors de la construction des applications pour le système cible. C'est pourquoi ces outils s'appellent souvent des chaînes de compilation croisée en anglais "cross-platform development tools" ou "cross-development tools". La compilation croisée ( cross-compile ) est un processus de création des logiciels pour le système (microprocesseurs) cible en utilisant un machine hôte avec les outils tel que compilateur, bibliothèque C, etc … La chaîne de compilation croisée est très importants pour développer Linux embarqué Elle se compose des composants suivants: 1. binutils: un ensemble d'outils de manipulation de fichiers binaires comme : ld, gas, etar.. 2. compilateur C/C++:GCC et débogueur GDB 3. bibliothèque C : Glibc, Dietlibc, uClibc ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Outils de développement 23 Figure 3-1 la compilation croisée Dans le cas de la compilation croisée, ces différents outils, ainsi que le compilateur, seront exécuté sous linux dans un environnement x86 mais le code généré sera d'un type différent (ARM). Il est donc nécessaire de compiler le paquetage à partir des sources en spécifiant de nouvelles options de génération. La génération de la chaîne de compilation croisée est peut être possible à la main mais les applications pour les systèmes cibles est souvent fastidieuse car elle peut que l'application a beaucoup des dépendances et de même ces dépendances ont des dépendances, etc.., exemple : Exemple fichiers dépendances pour un simple terminal matchbox-terminal : Digraph depends {"matchbox-terminal" [label="matchbox-terminal 0:0.0+svnr1612 -r0\n/home/yf/ youssef/test1/pinky-3.1/meta/packages/matchbox-terminal/matchbox-terminal_svn.bb"]: "matchbox-terminal" -> "pkgconfig-native" "matchbox-terminal" -> "libtool-cross" "matchbox-terminal" -> "autoconf-native" "matchbox-terminal" -> "libtool-native" "matchbox-terminal" -> "vte" "matchbox-terminal" -> "virtual/arm-poky-linux-gnueabi-gcc" "matchbox-terminal" -> "shasum-native" "matchbox-terminal" -> "gnu-config-native" "matchbox-terminal" -> "gtk+" "matchbox-terminal" -> "virtual/libc" "matchbox-terminal" -> "automake-native" … "vte" -> "pkgconfig-native" "vte" -> "libtool-cross" "vte" -> "autoconf-native" "vte" -> "libtool-native" "vte" -> "gnome-common" "vte" -> "intltool-native" "vte" -> "virtual/arm-poky-linux-gnueabi-gcc" "vte" -> "shasum-native" ….. "autoconf-native" -> "shasum-native" "autoconf-native" -> "gnu-config-native" "autoconf-native" -> "m4-native" "autoconf-native" -> "gnu-config-native" …. des aplications exucitables sur les systemes ciblses la chaines de compilation croisée les outils de compilations de hote ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Outils de développement 24 Et aussi elle peut qu’elle nécessite des patchs en fonction des architectures. De ce fait, l'utilisateur non averti risque de disposer d'une chaîne erronée et il est donc conseillé d'utiliser des outils spécialisés. Dans cette partie, nous allons présenter quatre solutions open sources disponibles utilisables sur Linux x86. Je vais choisir un de ces outils et expliquerais également comment mettre en œuvre cet outil sur plate- forme linux. 2 ELDK- Embedded Linux Development Kit ELDK - Embedded Linux Development Kit, est un paquet qui contient les outils nécessaire pour développer en linux embarqué: - outils de compilation (le compilateur, l'assembler, le linker etc..), sont des outils pour générer le code pour l'architecture visé. - native-tools et native-libraries sont des outils utilisés pour compiler des programmes à exécuter sur des systèmes embaqués. - Des codes sources et des fichiers binaire pour linux. ELDK est développé par DENX Software, société de consulting Linux située en Allemagne. Le fondateur, Wilfried Denk, est un professionnel de talent, contribuant à de nombreux projets open source dont RTAI 6 . Le produit est disponible sous forme de paquetages RPM binaires ou sources. Il est également possible de télécharger l'image ISO du CDROM contenant les binaires ou les sources 7 . ELDK permet de mettre en place une chaîne de compilation utilisable sur un PC Linux x86 pour des cibles PowerPC, MIPS ou ARM. Cet outil fournit également une distribution que l'on peut utiliser comme root- filesystem à travers d'un montage NFS. Cette technique permet de faciliter la mise au point car il n'est pas nécessaire de mettre à jour systématiquement la cible. La version de noyau fournie par ELDK est la 2.4.25 améliorée par DENX principalement pour la plate-forme PowerPC. Vous trouvez à titre de formation une méthode de mettre en œuvre un Linux sous ARM avec ELDK dans l’annexe B. 3 Buildroot Buildroot est un ensemble de Makefile et patches qui permettent de générer facilement une chaîne de compilation croisée et un système de fichiers racine de votre cible. Buildroot automatise la mise en place d'un système de fichiers racine avec tous les outils nécessaires comme busybox. Il rend beaucoup plus facile que de le faire à la main. Buildroot automatise la génération de la chaine de compilation grâce à l'utilisation de Makefile, et il dispose d'une collection de correctifs pour chaque version gcc et binutils pour les faire fonctionner sur la plupart des architectures. Pour télécharger Buildroot utilisant SVN, il vous suffit de suivre les règles décrites sur la page http://buildroot.uclibc.org/subversion.htm Pour les impatients, voici un lien rapide: 6 Real Time Application Interface http://www.rtai.org 7 ftp://mirror.switch.ch/mirror/eldk/eldk/ svn co svn://uclibc.org/trunk/Buildroot ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Outils de développement 25 Buildroot se caractérise par un bel outil de configuration graphique similaire à celle que vous pouvez trouver dans le noyau Linux ou dans Busybox. Notez que vous pouvez construire tout comme un utilisateur normal. Il n'est pas nécessaire d'être root pour configurer et l'utilisation de Buildroot. 4 OpenEmbedded OpenEmbedded est un outil qui permet aux développeurs de créer un Linux pleinement utilisable pour divers systèmes embarqués. Il a été conçu pour être en mesure de traiter différentes architectures matérielles et d'utiliser des outils pour accélérer le processus de compilation. Actuellement, il peut fonctionner sur toutes les distributions Linux, et des plans sont en place afin de lui permettre de travailler sous Windows. Essentiellement, le projet maintient et développe une collection de recettes BitBake. Les bitbakes constitués des sources URL du paquet, les dépendances et les options de compilation ou d'installation. Pendant le processus de constructions, les recettes sont utilisés pour suivre les dépendances, le cross-compiler et le paquetage de paquets susceptible d'être installé sur le périphérique cible. Il est également possible de créer des images complètes, composé de système de fichiers racine et du noyau. 5 Poky Linux Poky est une plateforme open source. Il est un environnement de développement logiciel dédié pour linux. Il aide à la conception, le développement, la construction, le débogage, la simulation complète de logiciels modernes utilisant Linux, il est fondé sur l’environnement OpenEmbedded. Poky a été configuré pour: Fournir des programmes open-source pour Linux. Créer des paquets stable, en se basant sur de OpenEmbedded et qui peuvent être facilement et de manière fiable intégrer sur des systèmes embarqué. Soutenir une large gamme des architectures x86 et ARM. Poky est avant tout une plate-forme qui génère des images de fichier-system (filesystem images) basée sur des logiciels open source tels que le serveur X Kdrive, le gestionnaire de fenêtres Matchbox, la boîte à outils GTK + et le bus de system D-Bus message. Des nombreux types des images peuvent être générés par poky, et de plus il est complètement adapté avec l’émulateur QEMU pour les architectures x86 et ARM. Figure 3-2 : Sato Desktop - Une capture d'écran à partir d'un ordinateur exécutant Poky built image ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Outils de développement 26 Poky a de plus en plus une communauté open-source soutenu par un support commercial assuré par le principe développeur et mainteneur de Poky, OpenedHand Ltd. Pourquoi poky ? Le choix de l’environnement ce n’est pas facile. Avec une petite recherche sur internet on trouve que Buildroot, OpenEmbedded et Poky sont le plus populaire mais les développeurs conseillent d’utiliser OpenEmbedded avec sa commande magique bitbake, par contre on à choisis poky tout d’abord car il se base sur OpenEmbedded et de plus je l’ai trouvais plus structuré et simple à manipuler. Chapitre 2 La carte et les autres outils 1 La carte AT91SAM9260-EK AT91SAM9260EK est un kit d’évaluation d’Atmel qui est conçue pour l’évaluation des programmes tournant sur le microcontrôleur AT91SAM9260 de Atmel à cœur ARM9. L’AT91SAM9260EK est équipé d'un AT91SAM9260 (217-ball LFBGA paquet) ainsi que les éléments suivants: 64 Mo de mémoire SDRAM 256 Mo de mémoire NANDFlash Mémoire Data flash d’Atmel EEPROM série DHT un port USB type A deux ports USB hôte interfaces type B un port de communication série pour le debug un port MODEM série de communication un autre port de communication série avec RTS / CTS JTAG / CIE interface de débogage un port Ethernet 100 Base TX avec trois LEDs d'état un audio dac AT73C213 d’Atmel une puissance LED à usage général deux boutons poussoirs configurable une entrée bouton-poussoir pour le Wake up un bouton-poussoir de réinitialisation un Data flash, SD / MMC quatre connecteurs d'expansion (PIOA, PIOB, PIOC, capteur d'image) un de type BGA EBI expansion empreinte connecteur une pile Lithium Battery Cell de retenue de 12 mm taille des cellules Image 3-1 la carte dévaluation AT91SAM9260EK ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Outils de développement 27 2 Les autres outils 2.1 QEMU Emulateur L’environnement d’émulation Qemu est un émulateur de matériel, capable de simuler une architecture x86, et partiellement les architectures PPC, ARM et SPARC. Qemu émule tout, y compris le microprocesseur, c'est pourquoi il est souvent plus lent que le système hôte. Cependant, la « virtualisation » vous permet de rentabiliser le temps processeur libre en multipliant les OS. QEMU a deux modes de fonctionnement: - Emulation complète du système .Dans ce mode, QEMU émule un système complet (par exemple un PC), y compris le processeur (un ou plusieurs processeurs) et les divers périphériques. C’est une bonne manière pour lancer différents systèmes d'exploitation sans formater, partitionner ou redémarrer le PC ou pour déboguer le code système. - Emulation en mode utilisateur. Dans ce mode, QEMU pouvez lancer les processus établis pour un CPU sur un autre CPU. Il peut être utilisé pour lancer le Wine 8 ou pour faciliter cross-compilation et cross- debugging. Pour le mode complète Qemu supporte les architectures suivantes : PC (x86 ou processeur x86_64) ISA PC (old style PC without PCI bus) ISA PC (ancient PC sans bus PCI) PREP (PowerPC processor) PREP (processeur PowerPC) G3 BW PowerMac (PowerPC processor) PowerMac G3 BW (processeur PowerPC) Mac99 PowerMac (PowerPC processor, in progress) Mac99 PowerMac (processeur PowerPC) Sun4m/Sun4c/Sun4d (32-bit Sparc processor) Sun4m/Sun4c/Sun4d (32-bit Sparc processeur) Sun4u (64-bit Sparc processor, in progress) Sun4u (64-bit Sparc processeur, en cours) Malta board (32-bit and 64-bit MIPS processors) Malte bord (32-bit et 64-bit processeurs MIPS) ARM Integrator/CP (ARM) ARM Integrator / CP (ARM) ARM Versatile baseboard (ARM) ARM Versatile plinthe (ARM) ARM RealView Emulation baseboard (ARM) ARM RealView Emulation plinthe (ARM) Spitz, Akita, Borzoi and Terrier PDAs (PXA270 processor) Spitz, Akita, Terrier Barzoï et assistants personnels (processeur PXA270) Luminary Micro LM3S811EVB (ARM Cortex-M3) Luminaire Micro LM3S811EVB (ARM Cortex-M3) Luminary Micro LM3S6965EVB (ARM Cortex-M3) Luminaire Micro LM3S6965EVB (ARM Cortex-M3) Freescale MCF5208EVB (ColdFire V2). Freescale MCF5208EVB (ColdFire V2). Arnewsh MCF5206 evaluation board (ColdFire V2). Arnewsh MCF5206 évaluation bord (ColdFire V2). Palm Tungsten|E PDA (OMAP310 processor) Palm Tungsten PDA (processeur OMAP310) 8 Une application sous linux permet de lancer des programmes Windows (http://www.winehq.org) ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Outils de développement 28 Pour le mode utilisateur Qemu émule x86, PowerPC, ARM, 32-bit MIPS, Sparc32/64 et ColdFire (m68k). Cet outil me permet d’émuler le système d’exploitation construit avant de le charger sur la carte. 2.2 SVN un logiciel de gestion de versions Un logiciel de gestion de versions agit sur une arborescence de fichiers afin de conserver toutes les versions des fichiers, ainsi que les différences entre les fichiers. Ce système permet par exemple de mutualiser un développement. Un groupe de développeurs autour d'un même développement se servira de l'outil pour stocker toute évolution du code source. Le système gère les mises à jour des sources par chaque développeur, conserve une trace de chaque changement. Ceux-ci sont, en bonne utilisation, chaque fois accompagnés d'un commentaire. Le système travaille par fusion de copies locale et distante, et non par écrasement de la version distante par la version locale. Ainsi, deux développeurs travaillant de concert sur une même source, les changements du premier à soumettre son travail ne seront pas perdus lorsque le second, qui a donc travaillé sur une version non encore modifiée par le premier, renvoie ses modifications. Cet outil m’a énormément aidé aux cours de mon développement par le visionnement de mes modifications et il permet aussi de présenter le changement entre les versions. 2.3 NFS Network File System (NFS) est un moyen de partager des fichiers entre plusieurs machines sur un même réseau comme si les fichiers se trouvaient sur votre disque dur local.L'idée de base de NFS est de permettre à un ensemble quelconque de clients et de serveurs de partager un même système de fichiers. Ce partage de fichiers s'effectue d'une façon aussi transparente que possible. D'une manière générale, les clients et les serveurs sont sur le même réseau local mais il est possible d'exécuter nfs à travers un réseau à longue distance. Il est important de noter que les clients et les serveurs sont des machines distinctes. NFS permet à toute machine d'être à la fois client et serveur sauf dans le cas d'un pc où nfs ne lui permet pas de jouer le rôle d'un serveur à cause de sa structure mono-tâche. Cet outils m’a permet de partager le système de fichier de la carte on le montant en local que me simplifie les modifications le copier/coller directe en local au lieu de charger à chaque fois le système de fichier sur la carte. ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Solutions techniques 29 Section 4 Solutions techniques chapitre 1. Linux notre système d’exploitation embarqué 1 Pour quoi un système d’exploitation Pourquoi intégrer tout un système d’exploitation sur le terminal et pas des programmes en dur qui répond directement à nous besoins ? Le système d’exploitation, est multitâche. Il est possible d’y exécuter plusieurs processus qui se partagent les ressources de la machine. Il peut, en effet, stopper, à tout moment, n’importe quelle application pour passer la main à la suivante. Le plus intéressant dans un système d’exploitation est qu’il va nous faciliter la communication et la gestion de matériel, imaginer qui on va faire la gestion des mémoires et les interruptions d’une application; comme un navigateur web; manuellement, c’est fastidieuse ! On trouve une multitude des systèmes d’exploitation pour l’embarquée, les uns sont gratuits et open source et les autres non,…. Quelques OS Embarqué très connu : Palm OS pour le handheld Ses applications comprennent - Gestion de la mémoire simplifiée, - Gestion de bases de données et de l'écran, - Fournissement de la bibliothèque mathématique - Fournissement des applications minimalistes. Symbian OS pour la téléphonie, - Gestion des contacts, - gestion de réseaux divers (SMS, Bluetooth, GSM,TCP/IP), - gestion multimédia - Supporte la technologie Java (Java Phone) Windows Embarqué : - Les applications dérivées du Windows Alors Pourquoi intégrer Linux dans notre système embarqué quant il existe cette multitude d’autres systèmes d’exploitation ? 2 Pourquoi Linux ? Cette partie apporte les éléments de réponse à cette question. 2.1 Prix Tout d'abord, La raison économique est souvent tenue compte, et puis on n'a pas peur de dire le prix. Linux est gratuit et sans royalties à payer pour chaque produit vendu à base de Linux, ce qui est important pour des systèmes destinés à être fabriqués en grande série, et où chaque coût supplémentaire doit être évité. Toutes les distributions Linux sont disponibles gratuitement au téléchargement par Internet, D'ailleurs, les outils de développement d'un Linux comme les compilateurs, le IDE, la bibliothèque…etc sont disponibles à faible coût ou gratuits parce que fonctionner en terme de GNU. Donc les coûts de mise en œuvre de Linux sont réduits. Un avantage de prix par rapport aux autres OS. ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Solutions techniques 30 2.2 "Source code" disponible et gratuit Linux est un logiciel libre, Donc le code source est disponible au public. Cela donne le pouvoir aux utilisateurs d'utiliser ce logiciel comme ils l'entendent. On peut ainsi voir directement à travers les fichiers sources ce que fait le noyau Linux voire modifier son comportement au besoin. C'est très bien pour la construction d'un Linux embarqué. 2.3 Beaucoup de pilotages et outils de développement disponibles Les pilots sont importants dans une situation où les composants électroniques évoluent rapidement, les constructeurs n'ont pas le temps de fournir les pilotes logiciels pour tous les systèmes d'exploitation existants. Maintenant, Linux offre l'avantage nombreux pilotes existent souvent en modèle "Open Source", et sont donc facilement modifiables ou adaptables, si le besoin s'en faisait sentir. Pour développer une application, Il est nécessaire d'avoir les outils comme les compilateurs, IDE, et le déboguer. Linux supporte le GCC, GDB four déboguer et beaucoup de IDE. Pour le développement de OS Embarqué, la chaîne de développement qui s'appelle "cross-compilation" en anglais (compilation pour une machine cible différente de la machine qui sert à générer un programme) est très importante. La communauté de Linux Embarqué fournit suffisamment les outils de développement nécessaires. 2.4 Plein d'applications L’application étant supporté par LINUX est beaucoup diverse, On peut chercher une application adaptée pour votre domaine. D’ailler, l’utilisation est aussi gratuite. 2.5 Support de réseau La capacité de réseau sera indispensable pour la connectivité IP dans l'embarqué. Linux le très bon support en réseaux. Il supporte le plus nombreux de protocoles possibles de réseau testés été prouvés depuis des années comme suit. Cela permet à votre système d’être interopérabilité. TCP/IP réseau. Routage /Firewalling. Serveur de Telnet SMB, NFS. Protocoles WAN:X.25, AX.25, HDLC et ATM. 2.6 La multitude des architecture supporté Linux fonctionne sur un grand nombre d'architecture, mais non toutes les architectures sont utilisées dans le linux embarqué : • DEC Alpha http://www.alphalinux.org • Processeur ARM et StrongARM http://www.arm.linux.org.uk http://www.uclinux.org • Hitachi SuperH http://www.m17n.org/linux-sh • i386 (x86) • http://www.linux.org • Motorola 68K • http://www.linux-m68k.org • http://www.uclinux.org • IA-64 • http://www.linuxia64.org • Processeur MIPS • http://www.oss.sgi.com/mips • Motorola PowerPC • http://www.linuxppc.org • Sparc (32 et 64 bits) • http://www.ultralinux.org Tableau 4-1 Les architectures supporté par linux ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Solutions techniques 31 2.7 Le marché Figure 4-1 Le développement des OSs Embarqués, En 2004 9 Selon VDC (www.vdc.com), qui a étudié sur des plateformes de matériel, des logiciels, Linux, Java, et logiciel ouvert de source, et des outils de développement. Il conclut que Linux Embraqué se développe très rapidement. On utilise de plus en plus linux pour la stratégie de développement de ses produits. Et Linux embarqué, aujourd’hui, est un premier choix. 9 http://www.linuxdevices.com/articles/AT4036830962.html ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Solutions techniques 32 Chapitre 2 Linux un système d’exploitation pour l’embarqué, comment ? 1 Introduction La construction d’un linux pour l’embarqué se base sur linux normale mais avec des modifications qui les exigent le matériel et l’objectif de système embarqué. Alors c’est quoi ces modifications et pourquoi ? 2 Architecture de linux A partir les caractéristiques et l'architecture du LINUX en général, on peut donner un exemple sur l'architecture logicielle d'un Linux Embarqué car elle va être notre base pour le développement. Figure 4-2 l'architecture de linux Chargeur de démarrage Noyau Système de fichiers Bibliothèques (librairies) Utilitaires de base Pilotes Applications Ces composants Peut-être sont présentés ou non dans les différents systèmes. Cela dépend de l’architecture cible et l’objectif de système. Les applications utilisent un ensemble de l'APIs fourni par le noyau, Donc le noyau de linux va être porté avec un peu ou pas de changements. Cela permet de réutiliser les logiciels existence pour Linux embarqué. Le noyau doit pouvoir charger et/ou accéder à un file-system en mémoire local ou en réseau par NFS 10 ou FTP 11 . Un Système de Fichiers doit être présent dans Linux embarqué. 10 NFS ou Network File System est un Protocole de communication développé par Sun Microsystems qui permet à un Ordinateur d'accéder à un système de fichier via un Réseau. 11 FTP est un Protocole de communication destiné à l'échange de fichiers sur un Réseau TCP/IP ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Solutions techniques 33 Pourtant, les services exportés par le noyau sont souvent incapables pour être employés directement par des applications. Au lieu de cela, les applications se basent sur des bibliothèques qui fournir les APIs familiers et services abstraits qui communique avec le noyau pour obtenir la fonctionnalité désirée. La bibliothèque principale employée par la plupart des applications de Linux est la bibliothèque de GNU C. Pour les systèmes embarqués de Linux, La librairie GNU peut être remplacée en autre bibliothèque. 2.1 Chargeur de démarrage ou le bootloader Le bootloader est un petit programme nécessaire pour tout système embarqué baser sur des OSs et qui est chargé de : • Initialisation matérielle – CPU, mémoire, (mémoire flash) • Commandes de monitoring ou tests (optionnels) – Accès mémoire – Accès flash • Chargement de fichiers • Mise à jour du système • Chargement du noyau – Décompression • Chargement (optionnel) de système ``root'' initial provisoire (initrd) Et on trouve plusieurs types de bootloader ces qui sont générale tel que syslinux, blob, u-boot qui j’ai le utilisé pour le développement, et grup …et ces qui sont spécifique au matériel et qui nécessite de configurations particuliers et parfois ils exigent même les adresses des mémoires. Logiciel Architecture de processeurs Types d’amorçage Description LILO x86 - Disque Dur - Mémoire de Flash Le bootloader principal pour le Disque commun sous Linux GRUB x86 - Disque Dur - Mémoire de Flash - DOC - TFTP, NFS Une version avancée de LILO U-BOOT Tous Tous les types le bootloader universel basé sur ARM-Boot, pour presque tous les processeurs embarqués : REDBOOT Tous Tous Développé par RedHat Tableau 4-2 comparaison bootloaders J’ai travaillé avec u-boot car le plus adapter pour l’embarqué et on plus pour l’ARM et aussi car il offre la possibilité de charger le noyau et le système de fichier par réseau avec NFS ou FTP qui m’a trop facilité le développement. 2.2 Noyau Le noyau est le composant le plus important du système d'exploitation. Son but est de contrôler le matériel d'une façon logique et il fournit les services de bas niveau aux utilisateurs de haut niveau. Comme avec autre Unix, Linux conduit des dispositifs, contrôle des accès d'I/O, gestion de processus, gestion de la ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Solutions techniques 34 mémoire, manipule la distribution des signaux (ils nécessitent peut être des patchs) chargement de système de fichier, et on trouve souvent des noyaux avec des pilotes compiler en dur. 2.3 Pilotes de périphérique Vous n'avez pas besoin d'écrire vos pilotes de zéro. Vous pouvez réutiliser le code de pilotes libres similaires. Les pilotes peuvent être compilés statiquement dans le noyau ou comme des modules à charger par l’utilisateur après le démarrage de noyau, et le choix entre le deux dépond de système embarqué et ces ressources. Les pilotes sont chargés à la gestion de ressource matérielle (E/S mémoire, E/S ports, les interruptions …) en assurant les communications entre les matériels et la couche supérieur. 2.4 Système de fichiers Un système de fichiers est un format de stockage des fichiers sur des supports tels que le disque dur, la disquette, le cd-rom et autres mémoires de masses. Les systèmes de fichiers les plus connus sur les architecture x86 sont FAT16, FAT32, NTFS (formats Windows), et Ext2 pour Linux ou encore ISO 9660 (le format des cd-rom). Si Windows ne reconnaît que son propre système de fichier, en plus du système des cd- rom, Linux a la possibilité de lire et écrire sur un grand nombre de système de fichiers provenant d’Os multiples. Lorsque l’on travaille avec un système d’exploitation de type Unix comme Linux, on ne peut pas supprimer son système de fichier. Celui-ci fait intégralement parti du processus de fonctionnement de l’ensemble de l’Os. 2.5 Bibliothèques (Librairies) Ces sont les bibliothèques nécessaires pour le bon fonctionnement de système tel que glibc2, libc5 … et aussi on peut trouver des bibliothèques additionnels pour le réseau ou le graphique … 2.6 Utilitaires de base Ces sont les applications de base tel que le SHEL, les éditeurs de texte, la gestion de utilisateurs, etc …. 2.7 Les applications Ces sont les applications nivaux utilisateur comme les jeux, les éditeurs des images, etc …. D’après la définition de système embarqué ; que est un système aves des ressources matériel réduit et qui va remplir une tache bien déterminé ; on peut penser à optimiser notre linux pour répondre aux contrainte matériel (mémoire), mais comment ? On éliminant tout qui n’est pas nécessaire pour exécuter notre tache. 3 Optimisation La construction d’un système Linux embarqué passe par l’analyse du système Linux standard. Cette analyse permet de déterminer les parties modifiables afin d’optimiser le système d’exploitation. L’optimisation n’ira pas dans le sens des performances (vitesse d’exécution), mais dans celui de la taille occupée en mémoire vive et en mémoire de masse. En effet, à l’heure actuelle bien des systèmes embarqués sont équipé des mémoires (vive RAM et de masse FLASH) de capacité importante (pour notre système est équipé de 64M pour le RAM et 256M pour le FLASH). Mais, encore le coût prohibitif de la mémoire (RAM et de masse) impose de trouver des solutions quant à la diminution de la taille de stockage de l’Os. L’optimisation du système passe par la réduction des différents blocs qui constituent le système d’exploitation Linux. Il s’agit d’opérer, une transformation au nivaux du noyau que peut subir une optimisation en vue d’être débarrassé des pilotes de périphériques inutiles, même la partition de swap peut judicieusement être remise en question, etc. ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Solutions techniques 35 Figure 4-3:Optimisation de Linux 3.1 L’optimisation de système de fichier Discuter du choix d’un système de fichier et du logiciel permettant au système d’exploitation de le gérer peut paraître inutile lors d’une configuration standard d’un Pc de bureau. Et Lorsqu’on parle d’un système embarqué, il faut avoir à l’esprit, qu’il évolue dans des conditions très rudes que nous faire pensé à bien choisir le type de système et l’adapter sans perdre le standard et la philosophie du système de fichier de linux (Unix).Linux supportant un nombre impressionnant de systèmes de fichiers, or je vais juste présenter trois que parais bien adapter pour l’embarqué. Ext2 : Il s’agit du système de fichier le plus utilisé actuellement sous Linux. Son utilisation sur des stations de travail ou des serveurs ne pose aucun problème. En utilisant un système de redondance des structures vitales, il permet souvent de retrouver un système cohérent après un arrêt forcé, grâce à un utilitaire semi-automatique du nommé e2fsck. Initrd : L’une des options précieuses de Linux consiste dans la possibilité de créer de petite image de boot en utilisant le système de fichiers initrd. Initialement destiné à simplifier la procédure d’installation, le système de fichier initrd permet de charger un petit système de fichiers en mémoire vive depuis son lieu de stockage. Ce système de fichier est compressé au format gzip. Le noyau le décompresse en RAMDisk12 au moment du démarrage. Avant la création du système initrd il était impossible de démarrer Linux d’un support quelconque sans que le driver pour ce support n’ait été préalablement compilé avec le noyau. Avec initrd un petit système de fichiers contenant les drivers essentiels et les scripts de démarrage est chargé avec le noyau. Ce dernier décompresse le système de fichiers et exécute un fichier nommé linuxrc. Ce script met en place les drivers manquants pour compléter la procédure de démarrage. Lorsque le script se termine le système de fichiers initrd est démonté, la mémoire occupée est libérée et la procédure d’initialisation du système se poursuit d’une façon normale. Il est alors concevable de détourner le système initrd afin qu’ils deviennent le système de fichier d’une machine embarquée : • Comme le noyau, le système de fichier initrd est compressé et donc ne prend pas beaucoup de place en stockage. 12 Le RAMDisk permet d’obtenir une partition similaire à celle rencontrée sur une mémoire de masse en mémoire vive. ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Solutions techniques 36 • Le système de fichier et le noyau peuvent être fusionnés pour ne former plus qu’un seul gros fichier. • La mémoire de masse, par exemple une mémoire Flash, peut être réduite à son minimum. Remarque : Pour utiliser initrd, le noyau doit-être compilé avec les options pour le RAM disque. JFFS2 : Le Journaling Flash File System 2 fut développé à l’origine pour les mémoires Flash qui, imposent quelques contraintes de gestion. Pour s’accommoder au mieux de la limite du nombre de modifications d’une zone de données, ce système de fichiers ne réécrit jamais les données au même emplacement, et garde toujours les versions antérieures cohérentes des données en cours de modification. Ce système de fichier fut développé pour des systèmes embarqués aux ressources limitées. Il parait que le système de fichiers le mieux adapté aux machines embarquées est le JFFS2. Il n’a cependant pas était possible de le tester. En effet, il parait qu’il est mal adapté avec qemu. En présence de ce problème, l’emploi du système de fichier Ext2 semble être une solution. Et avec la possibilité de le monter en local et le monter sur la carte par NFS ce que me permet de le modifier sans que je suis obliger chaque fois à la charger, et tant que je suis encore en phase de développement et test. ===> Alors l’emploi du système de fichier Ext2 est solution avantageuse dans mon cas. 3.2 Suppression du swapping On alloue sous Linux un espace mémoire nommé zone de swap. Cet espace est réservé en mémoire de masse, le disque dur dans le cas d’un système de bureau. Le swapping s’acquitte de deux fonctions majeures : • Augmenter l’adressage réellement utilisable par un processus ; • Augmenter la quantité de mémoire vive dynamique (ce qui reste de mémoire vive une fois que le code du noyau et les structures de données statiques ont été initialisées) pour charger les processus Le swap est utile lorsque le noyau manque dangereusement de mémoire. Le noyau garde toujours une petite réserve de pages mémoire libres qui ne peuvent être utilisées que par les fonctions les plus critiques. Ceci s’avère essentiel pour éviter les pannes système qui pourrait se produire lorsqu’une routine du noyau appelée en vue de libérer des ressources n’est pas en mesure d’obtenir la zone de mémoire dont elle a besoin pour réaliser sa tâche. Lors de la conception d’un système embarqué, les fonctionnalités exactes sont définies dans la première phase d’un projet. Connaissant avec précision les applications qui s’exécutent sur le système, le concepteur peut prévoir une quantité de mémoire suffisante sans devoir recourir aux services du swapping. L’optimisation de la taille du système d’exploitation soulève la question de l’utilité de la zone de swap. La suppression de celle-ci entraînerait un gain de place appréciable L’utilisation de la mémoire vive sans swapping augmente également les performances du système en termes de rapidité. ===> La suppression de la zone de swapping est automatiquement par défaut par poky. 3.3 Optimisation de noyau L’optimisation du noyau se fait par deux nivaux, le premier et de bien configurer le fichier de configuration du noyau pour se débarrasser de tout que est inutile comme les pilotes intitules, et le deuxième est la compression du noyau. Pour la compression du noyau il faut préciser le type de compression soit zImage ou bzImage au moment de compilation, or le deuxième type ne donne pas un intérêt para port le premier. ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Solutions techniques 37 Traditionnellement, les pilotes de périphériques intègrent le noyau, ce pour plusieurs raisons. En premier lieu, la plupart ont besoin d’interagir de façon spécifique avec le matériel, ce que seul le noyau permet. Ce système pose évidemment certains problèmes. Tout d’abord, à chaque ajout de nouveau matériel l’administrateur doit reconstruire le noyau pour y inclure les nouveaux périphériques. Pour y remédier, Linux reconnaît les pilotes chargeables, ajoutés ou supprimés de la mémoire lors du fonctionnement du système. Ces pilotes, qui constituent toujours une partie du noyau, sont compilés séparément et valider qu’au moment de leur utilisation. Pour que le noyau soit à même d’utiliser les modules, une option de compilation spécifique doit être sélectionnée. Si cela est possible, il est préférable dans le cadre d’un système embarqué de compiler les pilotes comme des modules. Ceci n’est malheureusement pas toujours possible, il faut savoir que certains drivers ne peuvent pas être utilisés sous forme de module. Il s’agit plus particulièrement des pilotes de périphériques utiles au démarrage du système (Le pilote du contrôleur IDE dans le cas d’un système x86.). Dans tout le cas la taille du noyau dépend de l’utilité du système final. C’est en compilant le noyau avec les options désirées que le volume précis peut être défini. ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Solutions techniques 38 chapitre 2. Les applications et les paquets nécessaires 1 Introduction Dans le même cadre d’avoir un linux fonctionnelle avec le minimum de taille, il faut bien choisir les applications et les paquets que respectent cette contrainte et répondre au bien fonctionnement de système. Les applications sont les programmes accessibles par l’utilisateur directe or les paquets sont les programme nécessaires pour le noyau et le bon fonctionnement de notre système. Les applications et les paquets sont bien choisir suivant les objectifs de notre système. 2 Les applications 2.1 BusyBox BusyBox combine des versions "allégées" de nombreux utilitaires Unix en un exécutable unique et de petite taille. En effet, chaque fichier exécutable individuel contient un en-tête de chargement, dont la taille est loin d’être négligeable par rapport aux instructions du programme proprement dit. BusyBox permet de remplacer la plupart des utilitaires qui se trouvent dans les paquets fileutils, shellutils, findutils, textutils, modutils, grep, gzip, tar, etc. Il représente un environnement POSIX assez complet pour petits systèmes ou systèmes embarqués. BusyBox a été écrit avec pour objectif une optimisation de taille et une utilisation de ressources limitées. Commandes standards BusyBox 1500[ko] Commandes utiles 190[ko] busybox 1500[ko] total 190[ko] total Tableau 2: Taille de BusyBox Malheureusement, les commandes Shell incorporée ne possède pas toutes les options des commandes externes équivalentes. Cependant, elles s’avèrent plus que suffisantes. L'outil est aussi extrêmement modulaire, ainsi il est facile d’inclure ou d’exclure des commandes à la compilation. Cela permet de l'adapter facilement à chaque type de système embarqué. Sa taille est d’approximativement 200 [ko]. 2.2 TinyLogin TinyLogin fonctionne selon le même principe que BusyBox. Il complète généralement ce dernier, en fournissant des commandes Shell complémentaires pour la gestion des connexions utilisateurs. Il s’agit des commandes addgroup, adduser, getty, login, passwd, su, sulogin. Commandes standards TinyLogin 0 /usr/sbin/addgroup 24[ko] /usr/sbin/adduser 16[ko] /sbin/getty 36[ko] /bin/login 28[ko] /usr/bin/passwd 24[ko] /bin/su 12[ko] /sbin/sulogin 40[ko] ./TinyLogin* 140[ko] total 40[ko] total Tableau 4-3 Taille de TinyLogin ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Solutions techniques 39 2.3 Temix –webkit Temix-webkit est notre navigateur embarqué, il est basé sur le navigateur (moteur de rendu) webkit. Pour qu’on soit claire il vaut mieux définir quelques notions. Et ensuite je vais expliquer le choix de webkit. Définitions Navigateur : Un navigateur web est un logiciel conçu pour consulter le World Wide Web. Techniquement, c'est au minimum un client HTTP. Le navigateur web est composé d'un moteur de rendu des standards du web, d'une interface utilisateur et accessoirement d'un gestionnaire d'extensions appelées plugins. Un moteur de rendu : Un moteur de rendu HTML est un composant logiciel de base qui permet aux logiciels d'afficher les éléments d'une page web. Ils sont de ce fait le cœur des navigateurs web. Les standards du Web est une expression désignant différentes technologies et protocoles utilisés sur le Web et en particulier ceux définis par le W3C sous forme de recommandations. Webkit 13 est une bibliothèque de fonctions permettant aux développeurs d'intégrer facilement un moteur de rendu de pages web dans leurs logiciels. Originellement réservée au système d'exploitation Mac OS X (à partir de la version 10.3 Panther), elle a été portée vers Linux et Windows. Webkit est un fork du moteur de rendu KHTML du projet KDE utilisé notamment dans le navigateur Konqueror. Elle intègre deux sous-bibliothèques : WebCore et JavaScriptCore correspondant respectivement à KHTML et KJS. Il passe avec succès le test Acid2 14 et il a obtient 100% au test Acid3 depuis le 27 mars 2008. Pour quoi webkit ? Dans notre recherche d’un navigateur embarqué on a définit quelque critères qu’il doit les respecter, il doit être on open source, intègre le CGI, JavaScript, XML et CSS, et testé sur l’embarqué. En se basant sur la page de comparaison entre les navigateurs web sur wikipedia 15 on trouve que les navigateurs basé sur webkit sont bien placés et intégre le CGI, le JavaScript et …. Et encore webkit est très répondue dans l’embarqué surtout sous IPhone avec le navigateur safari basé sur webkit. 2.4 Serveur web Nos besoins nous exigent un simple serveur web de base et ce qu’il nous offre busybox on activant l’option HTTPD dans le fichier de configuration de busybox. 3 Les paquets 3.1 Base-files Ce paquet contient l'arborescence de fichiers de base d'un système linux, ainsi que plusieurs fichiers importants, tels que /etc/host.conf 16 , /etc/issue, /etc/motd 17 , /etc/profile, /etc/nsswitch.conf 18 , entre autres. Il est nécessaire pour construire le système de fichier de notre OS linux. 13 http://en.wikipedia.org/wiki/WebKit 14 Les testes Acid2/3 ceux-ci sont destinés à la vérification du respect des standards du web par les navigateurs internet. 15 http://en.wikipedia.org/wiki/Comparison_of_web_browsers 16 Le fichier /etc/host.conf contient des informations spécifiques pour la configuration de la bibliothèque de résolution de noms. 17 "motd" signifie "message of the day", et il contient généralement des messages destinés aux utilisateurs concernant l'administration du système (ajout de périphériques, arrêts prévus du système, nouvelles versions de logiciels, etc...). 18 Fichier de configuration des bases de données systèmes et des services de noms. ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Solutions techniques 40 Tableau 4-4 le système de fichier respectant le standard 3.2 Initscripts Ces scripts de ce paquet initialisent un système standard GNU/Linux Debian au moment du démarrage et le stoppent au moment de l'arrêt ou du redémarrage. 3.3 xserver-Kdrive-fbdev Ce paquet contient le pilote pour le "fbdev" ou le « frame buffer device » en anglais qui permet à libGGI 19 ou tout programme utilisant libGGI d’afficher sa sortie sur le frame buffer du noyau. Le frame buffer est le moyen habituel de l'affichage graphique sur la plupart des architectures i386 et, pour i386. 3.4 nfs-utils Ce paquet contient les bibliothèques nécessaires pour l’utilisation du service NFS (Network File Service). 3.5 libération-fonts Ce paquet contient bibliothèques de fonts qui seront utile pour afficher de texte dans notre navigateur. 3.6 Xinit Ce paquet contient startx et xinit qui sont des programmes qui facilitent le démarrage d'un serveur X, et le chargement d’une session X 3.7 Netbase Ce paquet fournit l'infrastructure nécessaire pour les bases d'une mise en réseau TCP/IP. 3.8 Udev Ce paquet contient le gestionnaire de périphériques udev. Sa fonction principale est de gérer les périphériques dans le répertoire /dev. 19 General Graphics Interface libraries ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Développement 41 Section 5 Développement 1 Introduction Maintenant nous somme prêt à aborder la partie pratique après toutes ces définitions. Dans une première partie on va parler du développement (construction) de linux et les applications embarqués et en deuxième partie de le développement web et réseaux et pour la dernière pour la partie de la configuration de hardware et test. Chapitre 1 Construction de linux et les applications embarqués Comme on va utiliser l’environnement poky il est indispensable de savoir comment l’utiliser, et pour cela on va commencer cette partie avec une petite introduction sur utilisation de poky (quick Start on anglais) 1 Poky, Comment utiliser ? Poky répond pratiquement à nous besoin (si on veut ne pas dire complètements) comme un environnement de développement dédié linux embarqué, et avec ses outils avancés, sa structuration, sa flexibilité il va nous permettre de configurer et personnaliser aux moindres détails nous applications. 1.1 Installation des paquets nécessaires ==> Il faudra installer les paquets suivants : build-essential python diffstat texinfo texi2html cvs subversion wget gawk help2man bochsbios (only to run qemux86 images) Tableau 5-1 Les paquets à installer pour utiliser poky Pour les installer vous pouvez ajouter debian.o-hand.com à APT sources : Puis ajoutez: Puis lancez la commande suivante : vim /etc/apt/sources.list deb http://debian.o-hand.com etch/ deb http://debian.o-hand.com unstable/ deb http://debian.o-hand.com edgy/ deb http://debian.o-hand.com feisty/ deb http://debian.o-hand.com gutsy/ apt-get install qemu poky-depends poky-scripts ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Développement 42 1.2 Téléchargement de Poky ==> Vous pouvez le télécharger: Soit en ligne de commande : Soit à partir de cet lien http://pokylinux.org/releases/ 1.3 Compiler et exécuter une image Apres le téléchargement de Poky, décompressez le dossier : Pour lancez la compilation une l’image poky-image-sato par exemple il suffit de tapez ces commandes : ==> Il est de préférence de compiler poky-image-minimal (bitbake poky-image-minimal) pour que ne prendre pas beaucoup de temps. ==> Les images / noyaux construites par Poky sont placés dans le /tmp/deploy/images. On peut également télécharger des images et des noyaux : Le Poky QEMU noyau (zImage * * qemu *. bin) et le système de fichier image compressé (poky-image-*- qemu *. ext2.bz2) que vous aurez besoin de le décompresser avec 'bzip2-d'. Celles-ci sont disponibles à partir de la dernière publication sur http://pokylinux.org/releases/blinky-3.0/ ou de l'autobuilder sur http://pokylinux.org/autobuild/poky/. Pour l'exécution (simulation) il faut : Télécharger les scripts poky-scripts dans le but de simplifier et automatiser le lancement de qemu. wget http://pokylinux.org/releases/pinky-3.1.tar.gz tar zxvf pinky-3.1.tar.gz cd pinky-3.1/ source poky-init-build-env bitbake poky-image-sato REMARQUE : Ce processus aura besoin d'un accès Internet, et d'environ 9 Go d'espace disque disponible, et vous devriez vous attendre d'environ 4 - 5 heures suivant le débit de connexion (pour téléchargement) et caractéristique de l’ordinateur (pour la compilation). cd pinky-3.1/ source poky-init-build-env bitbake poky-image-sato apt-get install qemu poky-scripts ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Développement 43 Puis lancez : $ poky-qemu <kernel> <image> Exemple : Image 5-1l'image de bureau de poky sato 2 Le portage de linux Pour construire un linux pour un système (machine) sous Poky il faut passer par trois étapes : Etape 1 : ajout et la configuration de la nouvelle machine ; la machine ici représente la carte de développement. Etape 2 : configuration de noyau. Etape 3 : configuration de poky 2.1 Etape 1 Ajouter un fichier at91sam9260ek.conf sous le répertoire meta/conf/machine/ avec tous les détails de la carte vous trouvez le fichier dans l’annexe A. Dans ce fichier il faut mentionner : - Le type de processeur dans la variable TARGET_ARCH 20 = "arm" - Liste des architecture compatible avec le processeur PACKAGE_EXTRA_ARCHS = "armv4 armv4t armv5te" - Le type de l’image de noyau KERNEL_IMAGETYPE = "zImage" - Le fichier de configuration de linux pour la carte PREFERRED_PROVIDER_virtual/kernel = "linux- at91sam9260ek" 20 Voir les définitions des variables dans l’annexe C poky-qemu zImage-qemuarm.bin poky-image-sato-qemuarm.ext2 ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Développement 44 - La console de débogage SERIAL_CONSOLE = "115200 ttyS0" - Les fichiers de configuration général require conf/machine/include/qemu.inc require conf/machine/include/tune-arm926ejs.inc Ajouter le nom de la carte dans la liste de machines compatibles dans le fichier linux- rc.inc sous le répertoire meta/packages/linux/ sous la variable COMPATIBLE_MACHINE Créer le fichier linux-at91sam9260ek.bb dans le repertoire meta/packages/ dont voila son contenue : Les fichiers *.bb sont généralement appelés les «recettes». En général, une recette contient des informations sur un paquet ou une application tels que, les sources de téléchargement (SRC_URI 21 ), tous les correctifs qui s'imposent, les options de configuration spéciale, la méthode de compilation si il nécessite une compilation particulier etc …. 22 2.2 Etape2 Pour la configuration de noyau il faut juste de : Editer le fichier qemu.inc 21 Voir Annexe C 22 Voir Annexe C COMPATIBLE_MACHINE = '(collie|poodle|c7x0|akita|spitz|tosa|hx2000|qemuarm| qemux86|bootcdx86|htcuniversal|zylonite|at91sam9260ek)' require linux-rp.inc # Mark archs/machines that this kernel supports DEFAULT_PREFERENCE = "-1" DEFAULT_PREFERENCE_cm-x270 = "1" DEFAULT_PREFERENCE_em-x270 = "1" DEFAULT_PREFERENCE_mpc8313e-rdb = "1" DEFAULT_PREFERENCE_mpc8323e-rdb = "1" SRC_URI = "${KERNELORG_MIRROR}pub/linux/kernel/v2.6/linux-2.6.23.tar.bz2 \ file://defconfig-at91sam9260ek " S = "${WORKDIR}/at-linux-2.6.23" do_configure() { rm -f ${S}/.config cp ${WORKDIR}/defconfig-at91sam9260ek ${S}/.config oe_runmake oldconfig } PCMCIA_MANAGER = "pcmciautils" PREFERRED_PROVIDER_xserver = "xserver-kdrive" GUI_MACHINE_CLASS = "bigscreen" GPE_EXTRA_INSTALL += "gaim sylpheed" IMAGE_FSTYPES ?= "ext2" ROOT_FLASH_SIZE = "128" IMAGE_ROOTFS_SIZE_ext2 ?= "128000" # Don't include kernels in standard images RDEPENDS_kernel-base = "" ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Développement 45 Les variables qu’il faut les voir sont : - IMAGE_FSTYPES définit le type de système fichier - ROOT_FLASH_SIZE la taille de flash - IMAGE_ROOTFS_SIZE_ext2 et la taille de système de fichier dans cette cas pour ext2 car on a utilisé le EXT2 23 2.3 Etape 3 Apres l’ajout de notre machine Il faut indique Poky à quel est le nom de la machine cible, et qu’il faut le mentionner dans le fichier local.conf sous le répertoire build/conf/ avec la variable MACHINE. 3 Ajout des applications et des paquets 3.1 Construction de temix-webkit Comme on a défendit au dessus temix-webkit se base sur webkit et on cherche à créer un navigateur : - léger qui prend pas beaucoup de mémoire - Il n’affiche que les pages web (pas de barre de menu) Et pour développer ça je utiliser les langages GTK2+ et C et vous trouvez le code sources de la page temix- webkit.c dans l’annexe A. 3.2 Configuration de busybox Nous avons besoin d’un serveur web de base et on a dit que busybox intègre un serveur léger est stable que est HTTPD. Pour configurer busybox avec ce service aller sous pinky/meta/packages/busybox /busybox- 1.xx/ et ouvrir le fichier defconfig et chercher CONFIG_HTTPD et de commenter le et mettre devant un y. 4 Compilation Apres la sélection et la configuration des paquets à compiler et aussi la configuration de linux on va lancer la construction de notre système (compilation). Et pour faire ça sous avec poky il faut créer une recette (fichier .bb) sous le dossier meta/packages/image et que en va l’appeler temix-web-2.bb dont voila son contenu : Dans la variable IMAGE_INSTALL on met tous les paquets et les applications à compiler. Pour la variable ROOTFS_POSTPROCESS_COMMAND, on demande ici à poky d’effacer le fichier temporaire de paquetage. 23 Voir la section solution # # Copyright (C) 2008 OpenedHand Ltd. # IMAGE_INSTALL = "base-files base-passwd busybox initscripts xinit xserver-kdrive-fbdev nfs- utils liberation-fonts netbase sysvinit tinylogin udev temix-webkit" # remove not needed ipkg informations ROOTFS_POSTPROCESS_COMMAND += "remove_packaging_data_files" Chapitre 2 Programmations web 1 Programmation web 1.1 Le Démo web- igm2.0 La démo web-igm2.0 est la version 0 de l’interface graphique (menu) de notre terminale, c’est un ensemble des pages web (XML et Html) affiché par notre navigateur web embarqué. Il s’agit ici de la programmation juste le code de fichier principale.xml et terminal.xsl et les autres page principale.xml. Image 5-3 menu principale d’IGM2.0 ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES web et réseaux igm2.0 est la version 0 de l’interface graphique (menu) de notre terminale, c’est un ensemble des pages web (XML et Html) affiché par notre navigateur web embarqué. Image 5-4 un désigne imaginé d’IGM2.0 programmation web pur avec XML, HTML et xslt (XSL), dont vous trouvez dans juste le code de fichier principale.xml et terminal.xsl et les autres pages sont de Image 5-2 menu Arrêts d’IGM2.0 ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Développement 46 igm2.0 est la version 0 de l’interface graphique (menu) de notre terminale, c’est un ensemble des web pur avec XML, HTML et xslt (XSL), dont vous trouvez dans l’annexe A sont de même modèle que ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Développement 47 1.2 JavaScript et les raccourcis des boutons Comme on n’a pas des boutons suffisantes sur la carte 24 pour configurer les raccourci on a les simulé avec le clavier. Et pour faire ça on utiliser le langage JavaScript qui nous permet de récupérer les codes de touches et suivant cette idée on a créé une fonction que se lance à l’ouverture de chaque page web et qui : Détecte tout les liens dans la page Détecte le bouton enfoncé Faire le lien entre les liens et les boutons (les boutons (code) sont choisis à paravent). Elle ouvre ce lien s’il existe Vous trouvez le code de la fonction dans le fichier terminal.xsl dans l’annexe A 1.3 Ajax, récupérer les valeurs des capteurs Pour la récupération de la valeur d’un capteur (vitesse ou compteur de pièces) on a utilisé Ajax pour mettre à jour le champ de compteur. On va récupérer la valeur de deux capteur ; u n pour le nombre de pièces fabriques et l’autre pour l’état de la machine. L’idée consiste à créer une fonction qui envoi une requête http au serveur fonctionnant sur la carte par la méthode XMLHttpRequest. Le serveur quand il détecte cette demande il exécute un script bash (ou un programme) dans le dossier cgi-bin, cette script va renvoyer une page XML comme réponse. Ensuite il suffit d’analyser cette page par un code JavaScript pour récupérer la valeur de capteur. Et avec la méthode setTimeout on va contrôler l’exécution de cette fonction chaque les n millisecondes suivant la fréquence de capteur le débit de connexion réseaux. RQ : Pour simuler les deux capteurs on a utilisé le deux boutons ; une pour le capteur de comptage et l’autre pour l’état de la machine. Etant donné qui la page XML est créé par un programme LISTEN qui tourne sur la carte en arrière plans et qui écoute les boutons et à chaque appuis sur un bouton on incrémente le compteur correspondant. Vous trouvez dans l’annexe A, le code source de programme LISTEN et dans la page terminal.xsl le code de la fonction de la mise à jour. 2 Programmation réseaux Pour cette parte est en cours de développement au moment de taper ces lignes, mais on a arrivé à envoyer la valeur de compteur et l’état de la machine var la base de donné de serveur IGM (serveur rails) avec la commande curl PUT : Et récupérer le numéro d’OF par la commande curl La réponse de serveur est une page XML et pour recéperez la valeur il faut analyser cette page. ===> Vous trouvez également les codes de scripts bash qui automatise tous la synchronisation dans l’annexe A. 24 Voir les caractéristiques de la carte dans la section outils de développements curl -H "Accept: text/xml" -X PUT -d "cpt_pieces= 256" "etat_machine= 1" http://192.168.10.14 :8080/machines/1.xml curl -H "Accept: text/xml" http://192.168.10.14 :8080/ordre_fabrications/1.xml ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Développement 48 Chapitre 3 Configuration de la carte et test 1 Configuration de la carte Comme on a décrit au dessus que u-boot est notre chargeur (bootloader) et par suit il faut l’installer sur la carte. Mais on à besoin sur la carte d’un autre programme qui va lui-même charger u-boot, ce programme est nommé AT91Bootstrap. AT91Bootstrap est une première étape d'amorçage qui fournissent un ensemble d'algorithmes pour gérer l’initialisation de matériels (GPIO, Horloge, SDRAM, etc) et pour télécharger votre application principale de certaines mémoire flash (Data Flash, FlashNand,…) à la mémoire principale et à la démarrer. AT91Bootstarp est utilisé ici pour configurer le matériel et charger et exécuter le chargeur U-Boot nécessaire pour le démarrage de système d’exploitation (charger et lancer le noyau). Et pour charger AT91Bootstrap et u-boot sur la carte on va utiliser le programme SAM-BA. 1.1 Chargement de AT91Bootstrap sur la carte Mais, avant tout il faut se connecter à la carte via le port série. Vous pouvez utiliser le programme minicom 25 , et si vous ne l’avez pas vous pouvez le télécharger : sudo aptitude Install minicom. Télécharger l’AT91Bootstarp pour la carte AT91sam9200ek - Les sources de AT91Bootstrap est téléchargeable à partir de site de ATMEL : Et vous trouvez également de documentation sur la méthode de la compilation et la configuration. - Dans le cas d’utilisation standard (configuration standard pour le chargement de u-boot de la DataFlash) d’AT91Bootstarp ; comme notre cas ; on peut télécharger le fichier .bin compilé configuré pour des différentes cartes à partir : Chargement Avant de commencer les étapes de chargement il faut vérifier : J7 doit être ouvert (BMS = 1) pour démarrer à partir Boot ROM Image 5-5 La position de jumper 7 sur la carte 25 est un programme de contrôle de modem et d'émulation de terminal pour linux http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4093 ftp://www.linux4sam.org/pub/at91bootstrap/AT91Bootstrap1.8/ ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Développement 49 la mise sous tension de la carte vérifier la connexion USB Les étapes de chargement : Télécharger SAM-BA : http://www.atmel.com/dyn/products/ faq_card.asp?faq_id=1981 Lancer SAM-BA Dans les menus déroulent sélectionner la connexion USB et la carte AT91SAM9260EK Connecter Une fenêtre s’affiche Image 5-7 La fenêtre de SAM-BA 1. Choisir ou AT91Bootstrap va être chargé dans notre cas c’est le DataFlash 2. Initialiser le DataFlash on choisir Enable Dataflash on CSO dans le menu Scripts puis exécuter. Image 5-6 Exécution de SAM-BA ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Développement 50 3. Puis choisir Send boot file, pour envoyer les fichiers de démarrage, puis appuyez sur Exécuter 4. Il faut indiquer l’adresse 0x0 et la taille du fichier 0x1000. 5. Sélectionnez le fichier binaire at91bootstrap et appuyez sur Send File. 6. Fermer SAM-BA et débranchez le câble USB 1.2 Chargement de u-boot Pour u-boot c’est pratiquement les mêmes étapes qu’AT91Bootstrap Télécharger l’U-Boot pour la carte AT91sam9200ek Le lien pour les sources : http://www.atmel.com/dyn/products/app_notes.asp?family_id=605 Le lien pour le fichier .bin : ftp://www.linux4sam.org/pub/uboot/u-boot-1.1.5_atmel_1.5/u-boot- 1.1.5_atmel_1.5_at91sam9260ek.bin Chargement Les mêmes étapes justes il faut choisir le fichier u-boot.bin à charger et changer l’adresse de chargement à 0x08400. Image 5-8 le Flash Memory map Et voila un très bon site que décrivent toutes les étapes pour charger un linux sur les cartes Atmel AT91SAMxxxxek : http://www.linux4sam.org/twiki/bin/view/Linux4SAM/GettingStarted ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Développement 51 2 Test 2.1 Monter et flasher le noyau 2.1.1 Configuration de u-boot Au moment de mettre en tension la carte ou on appuis sur le bouton de reset on aura cette démarche : Figure 5-1 démarrage d’u-boot Et pour configurer u-boot il faut passer en mode console en appuyant sur Entrer (voir le figure). Connecter la carte avec le PC de développement (serveur) avec le câble ethernet Configurer le Pc en serveur Définir l'adresse MAC de la carte réseau (attention, on ne peut pas la réécrire à la suite de la commande saveenv. Attention, le saveenv est nécessaire . Si on veut utiliser les fonctions NFS-ROOT de linux setenv ethaddr 00:12:34:56:78:9A saveenv Sudo ifconfig eth0 :1=192.168.10.1 Sudo /etc/init.d/dhcp-server start ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Développement 52 Configurer u-boot pour télécharger l'image noyau via tftp 26 et la booter: Pour lancer: 2.1.2 Pour flasher linux Définir les scripts de flash (ici uImage est le kernel) pour flasher : 2.1.3 Pour télécharger le fichier de système par nfs définir la variable bootargs Rq : il faut ajouter le répertoire /home/yf/image dans le fichier d’export de nfs /etc/exports copier le noyau flasher dans l’adresse 20000000 pour booter 26 C’est le protocole FTP minimisé setenv ipaddr 192.168.10.6; setenv serverip 192.168.10.1; setenv loadaddr 20000000 setenv bootfile uImage setenv rootfs /home/lla/sandbox/temix/rootfs setenv go setenv bootargs console=ttyS0,115200 root=/dev/nfs rw ip=bootp nfs-root=\$(serverip):\$(rootfs)\; tftp \$(loadaddr) \$(bootfile)\; bootm \$(loadaddr) saveenv run go setenv flash-kernel tftp 20000000 uImage \; cp.b 20000000 D0030000 100000 setenv flashit erase D0030000 D03FFFFF \; run flash-kernel saveenv run flashit Bootargs=debug console=ttyS0,115200 root=/dev/nfs rw ip=bootp nfs-root=192.168.10.1:/home/yf/image cp.b D0030000 20000000 100000 bootm 20000000 ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Développement 53 2.2 Lancer les applications Lancer le serveur web o Il faut copier le pages web crée (voir le démo web-igm2.0) dans le système de fichier. o Créer le dossier cgi-bin sous la racine et copier dans ce dossier le script bash qui va renvoyer la page XML (voir Ajax, récupérer les valeurs des capteurs). o Lancer le serveur (busybox httpd) sous la racine. Lancer du programme LISTEN (voir Ajax, récupérer les valeurs des variables) Le programme LISTEN doit être compilé avec poky (compilateur de poky) puis le copier dans le système de fichier sous /usr/bin. Lancer le programme temix-webkit Comme on n’a pas d’écran (pour le moment) on va exporter l’affichage sur le PC de développement : o Connecter la carte avec le PC avec connexion ethernet o Configurer le Pc (voir Pour flasher linux) o Taper sur le terminal de la carte o Sur le Pc taper o Puis sur la carte Source : étant le dossier ou se trouvent les pages web sous la racine Busybox httpd –p 8080 listen & temix-webkit –h 640 –w 480 –u http://192.168.10.6/source/principal.html Export DISPLAY=192.168.10.1 :0 xhost + Image 5-9 temix ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES temix-webkit exécuter sur la carte mais exporter saur le pc Image 5-10 connexion à la carte à partir de PC ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Développement 54 webkit exécuter sur la carte mais exporter saur le pc ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Conclusion 55 Conclusion Dans le cadre de mon stage je devais reconcevoir le terminal IGM50 en IGM2.0. Comme expliqué précédemment cela a nécessité la mettre en œuvre sur une carte d’evaluation, un système d’exploitation linux, un écran TFT avec dalle tactile, un lecteur RFID, le pilotage d'entrées/sorties logiques et d'entrées , analogiques, serveur web, communication TCP/IP avec la supervision, interface graphique via un navigateur Web embarqué. Au terme de ces 16 semaines les parties suivantes sont achevées: - Intégration un système d’exploitation linux. - le pilotage d'entrées/sorties logiques et d’entrées, analogiques - serveur web - communication TCP/IP avec la supervision, - interface graphique via un navigateur Web embarqué. Pendant la durée de ce stage, j'ai bien pu mettre en pratique les connaissances acquises durant mes études à l’ENISO. D'un point de vue plus personnel, ce stage m'a permis d'être confronté aux réalités du monde du travail et également appris l'importance du travail en équipe et l'intérêt de la communication. ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Bibliographie 56 Bibliographie Livre : Linux système programming Robert Love Embedded linux primer Christopher Hallinan Linux Device Driver Corbet, Rubini & Kroah-Hartman Embedded linux système Designe and Developement Raghavan & Lad & Neelakandan Articles : EMBEDDED LINUX Gaspoz Frédéric en 2002. Linux embarqué : le projet uClinux - Patrice Kadionik, 2003 Embarquez Linux! ou Linux Everywhere - Pierre Ficheux, 2004 Les Systèmes Embarqués Linux pour l’embarqué - Patrice Kadionik. Embedding Linux in a Commercial Product, Joel R.Williams Survey of Embedded OS - Catherine Lingxia Wang, Bo Yao, Yang Yang, Zhengyong Zhu. Sites internet http://www.arm.linux.org.uk http://www.uclinux.org http://www.linux.org http://pokylinux.org/releases/ http://www.atmel.com www.linux4sam.org http://www.denx.de/ http://freeelectrons.com/ http://linuxdevices.com http://www.w3.org ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Les ANNEXES 57 Section 6 Les ANNEXES Chapitre 1 Annexe A Le fichier terminal.xsl : /******************************* Le fichier terminal.xsl *************************************/ <?xml version="1.0" encoding="ISO-8859-1"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:template match="/"> <html> <head> <title>IGM2.0</title> <link type="text/css" rel="stylesheet" media="screen" href="terminal.css"/> <link type="text/css" rel="stylesheet" media="screen" href="default- colors.css"/> <link rel="alternate stylesheet" type="text/css" href="bw-colors.css" title="black and white" /> <script type='text/javascript'> /* head javascript code*/ /*matrix of code Keyboard buttons*/ shortkeys = { "leftpage": [65, 81, 87, 90, 83, 88], "rightpage": [79, 76, 59, 80, 77, 49], "controls": [86, 66, 78] }; mapping = {}; /* this function detecte the button code and teste if the code exixte in the matrix shortkeys */ function on_key_up(key) { if (mapping.hasOwnProperty(key)) { window.location.assign(mapping[key]); } } /*this function detecte all link-page and fill the mapping table */ function fillmapping(rootelement) { r = document.getElementById(rootelement); if (r) { b = r.getElementsByTagName('a'); for(i=0;i!=b.length;i++) { var key = shortkeys[rootelement][i]; mapping[key] = b[i].attributes.getNamedItem('href').nodeValue; } } } function map_shortcuts() { for (var page in shortkeys) { fillmapping(page); } print_mapping(); } /* this function print the shortcuts matrix */ function print_mapping() { var div_mapping = document.getElementById('mapping'); for (var k in mapping) { var newdiv = document.createElement('div'); newdiv.innerHTML = String.fromCharCode(k) + ": "+ mapping[k]; div_mapping.appendChild(newdiv); } } ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Les ANNEXES 58 /**************************** Suite du fichier terminal.xsl *******************************************************************/ var t; http = new XMLHttpRequest(); /* the timer function */ function start_timer() { t=setTimeout("request_compt()",5000); } function request_compt() { http.open('GET', '/cgi-bin/testajax', true); http.setRequestHeader("Cache-Control", "no-cache"); http.onreadystatechange = voir_compteur; http.send(null); } function voir_compteur() { if(http.readyState == 4) { if(http.status == 200) { rx = http.responseXML; var current_compteur = rx.getElementsByTagName('bp3').item(0) / .getElementsByTagName("push_count") / .item(0).firstChild.nodeValue; var current_etat = rx.getElementsByTagName("bp4").item(0) / .getElementsByTagName("machine_state") / .item(0).firstChild.nodeValue; var current_compteur_bp4 = rx.getElementsByTagName('bp4').item(0) / .firstChild.nodeValue; /* pour le current_compteur_bp4 n'est pas utilisé */ info_etat = document.getElementById("info-Etat") info_compteur = document.getElementById("info-Compteur"); if (info_compteur) { compteur_value = info_compteur.childNodes.item(3); compteur_value.innerHTML = current_compteur; } if (info_etat) { machine_etat = info_etat.childNodes.item(3); var etat = ""; if (current_etat == "0") { etat = "Arret"; } else etat = "En marche"; machine_etat.innerHTML = etat; } start_timer(); } } } function run_scripts() { map_shortcuts(); start_timer(); } </script> </head> <body onload='run_scripts()' onkeyup='on_key_up(event.keyCode);'> <xsl:apply-templates /> <div id="mapping"> </div> </body> </html> ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Les ANNEXES 59 /**************************** Suite du fichier terminal.xsl******************************************************************/ </xsl:template> <xsl:template match="screen"> <div id="screen"> <xsl:apply-templates/> </div> </xsl:template> <xsl:template match="leftpage"> <div id="leftpage"> <xsl:apply-templates/> </div> </xsl:template> <xsl:template match="rightpage"> <div id="rightpage"> <xsl:apply-templates/> </div> </xsl:template> <xsl:template match="innerpage"> <div id="innerpage"> <xsl:apply-templates/> </div> </xsl:template> <xsl:template match="fullscreen"> <div id="fullscreen"> <xsl:apply-templates/> </div> </xsl:template> <xsl:template match="info"> <div class="info" id="info-{@name}"> <div class="info-name"> <xsl:value-of select="@name" /> </div> <div class="info-text"> <xsl:apply-templates/> </div> </div> </xsl:template> <xsl:template name="include-action-buttons"> <div class="action-button" > <a href="{@target}"><img src="button.png" /></a> </div> <xsl:if test="ancestor::fullscreen"> <div class="action-button-alternate"> <a href="{@target}"><img src="button.png" /></a> </div> </xsl:if> </xsl:template> <xsl:template match="action"> <div class="action" id="action-{@id}"> <div class="action-text"> <xsl:choose> <xsl:when test="@selected" > <div class="selected"> <a href="{@target}"><xsl:value-of select="@name"/></a> </div> </xsl:when> <xsl:otherwise> <a href="{@target}"><xsl:value-of select="@name"/></a> </xsl:otherwise> </xsl:choose> </div> <xsl:apply-templates/> <!-- <xsl:call-template name="include-action-buttons"/> --> </div> </xsl:template> ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Les ANNEXES 60 /********************************** le fichier principal.xml ***************************************/ <?xml version="1.0" encoding="ISO-8859-1"?> <?xml-stylesheet type="text/xsl" href="terminal.xsl"?> <screen> <leftpage> <info name="Etat">PRODUCTION</info> <info name="OF">1234556</info> <info name="Phase">10-a</info> <info name="Compteur">246 pièce(s)</info> <info name="Opérateur">R. Dubois</info> <info name="Carte">345945</info> </leftpage> <rightpage> <action name="CHANGEMENT OF" target="changement_of.xml" /> <action name="REGLAGE" target="principal-reg.xml" /> <action name="PRODUCTION" target="principal.xml" /> <action name="ARRETS" target="arrets.xml" /> <action name="QUANTITES" target="quantites.xml" /> <action name="CONTROLES" target="controles.xml" /> </rightpage> <controls> <control name="pagedown" target="principal-2.xml"/> </controls> </screen> Le fichier at91sam9260-ek /*********************Le fichier at91sam9260-ek *******************************/ #@TYPE: Machine #@NAME: qemu ARM Emulator setup #@DESCRIPTION: Machine configuration for running an ARM system under qemu emulation TARGET_ARCH = "arm" PACKAGE_EXTRA_ARCHS = "armv4 armv4t armv5te" require conf/machine/include/qemu.inc require conf/machine/include/tune-arm926ejs.inc KERNEL_IMAGETYPE = "zImage" SERIAL_CONSOLE = "115200 ttyS0" PREFERRED_PROVIDER_virtual/kernel = "linux-at91sam9260ek" Le fichier listen.c /***************************** Le fichier listen.c *****************************************/ /***********************************************************************************************/ /* TEMIS */ /* Need to create an header here (lla) */ /***********************************************************************************************/ #include <sys/epoll.h> #include <stdio.h> #include <stdlib.h> #include <fcntl.h> #include <errno.h> #include <unistd.h> #include <string.h> #include <linux/input.h> #include "listen_bp.h" static void fatal_error(const char *message) { perror(message); abort(); } ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Les ANNEXES 61 /***************************** suite de listen.c **************************************************/ /* key_stat_writer functions */ void key_stat_writer_init(struct key_stat_writer *ks){ ks->sfd = creat("/tmp/keystat", 0644); if (ks->sfd == -1) fatal_error("open"); ks->bp3_push_count = 0; ks->bp4_push_count = 0; ks->machine_state = 0; _key_stat_writer_update_file(ks); } void key_stat_writer_close(struct key_stat_writer *ks){ close(ks->sfd); } void key_stat_writer_on_key_pressed(struct key_stat_writer *ks, int key){ switch(key){ case BTN_0: ks->bp3_push_count++; break; case BTN_1: ks->bp4_push_count++; ks->machine_state = ks->machine_state == 0 ? 1 : 0; break; default: printf("key pressed %d\n", key); return; break; } _key_stat_writer_update_file(ks); } void _key_stat_writer_update_file(struct key_stat_writer *ks){ char string[255]; int n =sprintf(string,"<?xml version='1.0' encoding='ISO-8859-1'?>\n" "<keystats>\n" "<bp3><push_count>%d</push_count></bp3>\n" "<bp4>\n" "<push_count>%d</push_count>\n" "<machine_state>%d</machine_state>\n" "</bp4>\n" "</keystats>", ks->bp3_push_count, ks->bp4_push_count, ks->machine_state); pwrite(ks->sfd, &string, n, 0); } Le fichier temix-webkit.bb DESCRIPTION = "Multi-platform web browsing application." LICENSE = "GPL" SECTION = "x11" DEPENDS = "libxml2 glib-2.0 gtk+ libglade webkit-gtk curl gconf js libowl" PN = "temix-webkit" PV = "0.1" PR = "r5" SRCREV = "HEAD" SRC_URI = "svn://yf:iftm1mdp@serveur/svn/igm2.0/poky/src;module=${PN};proto=http \ file://link-with-g++.patch;patch=1" S = "${WORKDIR}/temix-webkit" EXTRA_OECONF = "--enable-libowl" inherit autotools pkgconfig gconf ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Les ANNEXES 62 do_configure_prepend() { touch ${S}/src/dummy.cpp } FILES_${PN} += "${datadir}/web-temix" Le fichier temix-webkit.c /********************* Le fichier temix-webkit.c *********************************/ #ifdef HAVE_CONFIG_H #include <config.h> #endif #include <gtk/gtk.h> #include <webkit.h> #include "web-temix.h" #ifdef HAVE_LIBOWL #include <owlwindowmenu.h> #endif static void create_page (Web2Data *data, const gchar *url) { GtkRcStyle *rcstyle; WebKitWebFrame *frame; GtkWidget *page, *scroll, *label, *button, *image, *hbox, *vpaned; label = gtk_label_new ("Empty page"); button = gtk_button_new (); image = gtk_image_new_from_stock (GTK_STOCK_CLOSE, GTK_ICON_SIZE_MENU); gtk_button_set_focus_on_click (GTK_BUTTON (button), FALSE); gtk_button_set_relief (GTK_BUTTON (button), GTK_RELIEF_NONE); /* Reduce button padding */ rcstyle = gtk_rc_style_new (); rcstyle->xthickness = 0; rcstyle->ythickness = 0; gtk_widget_modify_style (button, rcstyle); g_object_unref (rcstyle); /* This can make the tabs smaller but is a bit hacky... */ /*gtk_icon_size_lookup_for_settings (gtk_settings_get_default (), GTK_ICON_SIZE_MENU, &width, &height); gtk_widget_set_size_request (button, width + 2, height + 2);*/ gtk_container_add (GTK_CONTAINER (button), image); hbox = gtk_hbox_new (FALSE, 6); gtk_box_pack_start (GTK_BOX (hbox), label, TRUE, TRUE, 0); gtk_box_pack_end (GTK_BOX (hbox), button, FALSE, FALSE, 0); gtk_widget_show_all (hbox); page = webkit_web_view_new (); frame = webkit_web_view_get_main_frame (WEBKIT_WEB_VIEW (page)); g_object_set_data (G_OBJECT (frame), "label", label); g_signal_connect (frame, "title_changed", G_CALLBACK (title_changed_cb), data); g_signal_connect (page, "load_started", G_CALLBACK (load_started_cb), data); g_signal_connect (page, "load_progress_changed", G_CALLBACK (load_progress_changed_cb), data); g_signal_connect (page, "load_finished", G_CALLBACK (load_finished_cb), data); if (url) webkit_web_view_open (WEBKIT_WEB_VIEW (page), url); scroll = gtk_scrolled_window_new (NULL, NULL); gtk_scrolled_window_set_policy (GTK_SCROLLED_WINDOW (scroll), GTK_POLICY_AUTOMATIC, GTK_POLICY_AUTOMATIC); ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Les ANNEXES 63 /*************************** suite de temix-webkit **************************************************/ gtk_container_add (GTK_CONTAINER (scroll), page); vpaned = gtk_vpaned_new (); gtk_paned_pack2 (GTK_PANED (vpaned), scroll, TRUE, FALSE); gtk_widget_show_all (vpaned); g_object_set_data (G_OBJECT (button), "child", vpaned); g_signal_connect (button, "clicked", G_CALLBACK (close_clicked_cb), data); gtk_notebook_insert_page (GTK_NOTEBOOK (data->pages_notebook), vpaned, hbox, gtk_notebook_get_n_pages ( GTK_NOTEBOOK (data->pages_notebook)) - 1); g_idle_add ((GSourceFunc)set_page, data); } int main (int argc, char *argv[]) { GtkWidget *toolbar, *vbox, *menu; Web2Data data; int wi, hi ; const gchar *adr; gtk_init (&argc, &argv); webkit_init (); data.main_window = gtk_window_new (GTK_WINDOW_TOPLEVEL); adr = argv[2]; vbox = gtk_vbox_new (FALSE, 0); if (menu) { #ifdef HAVE_LIBOWL owl_set_window_menu_item (GTK_WINDOW (data.main_window), GTK_MENU_ITEM (menu)); #else gtk_box_pack_start (GTK_BOX (vbox), menu, FALSE, TRUE, 0); #endif } if (argc > 1) { if (strcmp(argv[1],"petit")==0) { wi = 200; hi = 200; } else if (strcmp(argv[1],"moyen")==0) { wi = 400; hi = 400; } else { wi = 480; hi = 640; } } gtk_box_pack_start (GTK_BOX (vbox), data.pages_notebook,TRUE, TRUE, 0); gtk_box_pack_start (GTK_BOX (vbox), toolbar, FALSE, TRUE, 0); gtk_widget_show (vbox); gtk_container_add (GTK_CONTAINER (data.main_window), vbox); g_signal_connect (data.main_window, "destroy", G_CALLBACK (quit_cb), &data); gtk_window_set_default_size (GTK_WINDOW (data.main_window), wi, hi); gtk_widget_show (data.main_window); gtk_main (); return 0; } ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Les ANNEXES 64 Le code bash de programme xml_extract qui va analyser le fichier xml #!/bin/sh #!/bin/bash ## faire entrer les id en 1er paramètre (id1:id2) et le fichier xml en 2eme paramètre sreg="" ereg="" for i in `echo $1|sed 's/:/ /g'`; do sreg=$sreg".*<"$i"[^>]*>" ereg="<\/"$i">.*"$ereg done sedreg="s/"$sreg"\(.*\)"$ereg"/\1/g" cat $2 | tr -d '\n' | sed $sedreg Le code bash de programme qui va envoyer les valeurs de capteurs #!/bin/sh while true; do comp_b3=`xml_extract bp3:push_count /tmp/keystat` comp_b4=`xml_extract bp3:push_count /tmp/keystat` etat=`xml extract bp4:machine_state /tmp/keystat` curl -X PUT -d "machine[cpt_pieces]=$comp_b4" -d "machine[etat]=$etat" http://192.168.10.14:3000/machines/2.xml curl -X PUT -d "machine[etat]=$etat" http://192.168.10.14:3000/machines/1.xml curl -X PUT -d "machine[cpt_pieces]=$comp_b3" http://192.168.10.14:3000/machines/1.xml sleep 5 done ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Les ANNEXES 65 Chapitre 2 ANNEXE B Procédure de mise en œuvre de linux embarqué avec ELDK : Les étapes sont: Installer le toolkit ELDK Configurer et compiler un noyau linux Mettre en place l'environnement d'émulation A noter qu’il est indispensable d’avoir une connexion internet pour télécharger les outils nécessaire. Préparation : créer un répertoire de travail (ex: /home/user/embedded-linux) Installer ELDK pour armet les outils nécessaires Voir http://www.denx.de/wiki/view/DULG/ELDKInitialInstallation Monter l'iso du CD téléchargé sur le site de ELDK et exécuter le script d'installation. Exemple pour installer eldk dans ~/embedded-linux : Il faut ensuite changer les droits des programmes qui doivent être installés SETUID avec le script ELDK_FIXOWNER: Il faut enfin créer les devices: On peut alors démonter l'iso Installer qemu : Tester la compilation croisée pour ARM: La compilation croisée nécessite de définir les variables d'environnements ARCH qui indique l'architecture pour laquelle compiler, ici arm CROSS_COMPILE qui indique le préfixe des outils de compilation croisée à utiliser, ici arm-linux- (qui est installé via eldk) mkdir -p /home/user/embedded-linux/eldk mkdir /tmp/eldkiso sudo mount -o loop /repertoire_ou est_telechargee_l_iso/arm-2007-01-21.iso /tmp/eldkiso /tmp/eldkiso/install -d /home/user/embedded-linux/eldk/ arm cd /home/user/embedded-linux/eldk sudo /tmp/eldkiso/ELDK_FIXOWNER -a arm sudo /tmp/eldkiso/ELDK_MAKEDEV -a arm umount /tmp/eldkiso sudo aptitude install qemu ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Les ANNEXES 66 PATH pour rajouter les répertoires ou se trouvent les outils de compilation croisée, ici /home/user/embedded-linux/eldk/usr/bin et /home/user/embedded-linux/eldk/bin Le script eldk_init permet d'automatiser cette configuration d'environnement: Sinon: Après on peut tester un programme en C, par exemple hello.c : Compiler le programme comme ceci: Pour tester le programme sur le PC, il faut traduire les instructions arm en instructions x86, ce que peut faire qemu (il faut lui donner le chemin ou se trouve l'interpréteur pour l'architecture ARM): Compiler un noyau pour arm Le fichier de configuration noyau dans subversion (Rq : cette adresse est une adresse local ; dans le serveur de l’entreprise). http://serveur/trac/browser/sandbox/lla/temix/files/configs/config-2.6.19.2?rev=19 pour changer les options du noyau, taper make menuconfig (plante si les headers de ncurses ne sont pas installés. Pour les installer : sudo aptitude install ncurses-dev). source /home/user/embedded-linux/eldk/eldk_init arm export ARCH=arm export CROSS_COMPILE=arm-linux- export PATH=/home/user/embedded- linux/eldk/usr/bin:/home/user/embedded-linux/eldk/bin:$PATH #include <stdio.h> int main(int argc, char **argv) { printf("Hello World\n"); return 0; } arm-linux-gcc -o hello hello.c qemu-arm -L /home/user/embedded-linux/eldk/arm/ hello Hello World cd ~/embedded-linux/eldk/arm/usr/src/linux svn export -r 19 http://serveur/svn/sandbox/lla/temix/files/configs/ config-2.6.19.2 cp config-2.6.19.2 .config make ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Les ANNEXES 67 La commande de 2eme ligne n’est applicable que si vous êtes connecté au serveur de l’entreprise, cependant vous pouvez télécharger la configuration à partir d’internet et lancer les lignes ; 1, 3 (cp le-chemin- de-fichier-config .config), 4. L’image du noyau sera dans ~/embedded-linux/eldk/arm/usr/src/linux/arch/arm/boot/zImage. Préparer l'environnement de simulation Installer et configurer un serveur NFS : Installer Éditer le fichier de configuration /etc/exports: On ajoutant cette ligne : Puis redémarrer le serveur Nfs: On peut tester le bon fonctionnement de Nfs comme ceci: Vérifier si le montage local a bien fonctionné (voir si le répertoire test_nfs contient le répertoire arm) puis démonter le répertoire: Installer et configurer un réseau virtuel Note: Il est nécessaire que le noyau hôte soit configuré avec l'option Universal TUN/TAP device driver puis de charger le module tun. Il faut installer vde (Virtual Distributed Ethernet, http://vde.sourceforge.net ). sudo aptitude install nfs-kernel-server sudo vi /etc/exports /home/user/embedded-linux/eldk/arm *(rw,sync,no_root_squash) sudo /etc/init.d/nfs-kernel-server restart cd /tmp mkdir test_nfs sudo mount -t nfs 127.0.0.1:/home/user/embedded-linux/eldk/arm test_nfs sudo umount /tmp/test_nfs sudo modprobe tun sudo aptitude install vde2 ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Les ANNEXES 68 allow bootp; subnet 192.168.10.0 netmask 255.255.255.0 { option routers 192.168.10.2; option domain-name-servers 1.2.3.4; } host qemu-embed { hardware ethernet 52:54:00:12:34:57; fixed-address 192.168.10.3; option root-path "/home/user/embedded-linux/eldk/arm"; } Configurer l'interface réseau virtuelle tap0 dans /etc/network/interfaces Et ajouter ces lignes : Pour activer l'interface (pour activer l'interface au démarrage, rajouter auto tap0 dans /etc/network/ interfaces): Si on veut faire fonctionner l'interface tap0 sans avoir les droits root, il faut se rajouter dans le group vde2-net. Installer et configurer le serveur DHCP Configurer le serveur via /etc/dhcp3/dhcpd.conf: Et ajouter ces lignes : Puis redémarrer le serveur DNS: sudo vi /etc/network/interfaces iface tap0 inet static address 192.168.10.2 netmask 255.255.255.0 network 192.168.10.0 broadcast 192.168.10.255 vde2-switch - sudo ifup tap0 sudo adduser user vde2-net sudo aptitude install dhcp3-server sudo vi /etc/dhcp3/dhcpd.conf sudo /etc/init.d/dhcp3-server restart ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Les ANNEXES 69 Mettre en place l'environnement d'émulation Lancer qemu avec les options suivantes: On peut aussi émuler une liaison série sur laquelle est redirigée la console linux, ce qui permet de se rapprocher du travail sur une vrai carte: Image 6-1 : simulation de system-temix sous qemu vdeq qemu-system-arm -net vde,vlan=0,sock=/var/run/vde2/tap0.ctl \ -net nic,vlan=0,macaddr=52:54:00:12:34:57, model=smc91c111 \ -M versatilepb -m 16 \ -kernel /home/user/embedded-linux/eldk/arm/usr/src/ linux/arch/arm/boot/zImage \ -append "root=/dev/nfs rw ip=dhcp nfsroot= 192.168.10.2: /home/user/embedded- linux/eldk/arm" vdeq qemu-system-arm -net vde,vlan=0,sock=/var/run/vde2/tap0.ctl \ -net nic,vlan=0,macaddr=52:54:00:12:34:57, model=smc91c111 \ -M versatilepb -m 16 \ -kernel /home/user/embedded-linux/eldk/arm/usr/src/ linux/arch/arm/boot/zImage \ -append "root=/dev/nfs rw ip=dhcp nfsroot= 192.168.10.2: /home/user/embedded- linux/eldk/arm" console=ttyAMA0" \ -nographic ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES Les ANNEXES 70 Chapitre 3 ANNEXE C 1.5. Post Install Scripts 2. Customising Images 2.1. Customising Images through a custom image .bb files 2.2. Customising Images through custom tasks 2.3. Customising Images through custom IMAGE_FEATURES 2.4. Customising Images through local.conf 3. Porting Poky to a new machine 3.1. Adding the machine configuration file 3.2. Adding a kernel for the machine 3.3. Adding a formfactor configuration file 4. Making and Maintaining Changes 4.1. Bitbake Collections 4.2. Committing Changes 4.3. Package Revision Incrementing 5. Modifying Package Source Code 5.1. Modifying Package Source Code with quilt 4. Platform Development with Poky 1. Software development 1.1. Developing externally using the Poky SDK 1.2. Developing externally using the Anjuta plugin 1.3. Developing externally in QEMU 1.4. Developing externally in a chroot 1.5. Developing in Poky directly 1.6. Developing with 'devshell' 1.7. Developing within Poky with an external SCM based package 2. Debugging with GDB Remotely 2.1. Launching GDBSERVER on the target 2.2. Launching GDB on the host computer 3. Profiling with OProfile 3.1. Profiling on the target 3.2. Using OProfileUI 1. Reference: Directory Structure 1. Top level core components 1.1. bitbake/ 1.2. build/ 1.3. meta/ 1.4. meta-extras/ 1.5. scripts/ 1.6. sources/ 1.7. poky-init-build-env 2. build/ - The Build Directory 2.1. build/conf/local.conf 2.2. build/tmp/ 2.3. build/tmp/cache/ 2.4. build/tmp/cross/ 2.5. build/tmp/deploy/ 2.6. build/tmp/deploy/deb/ 2.7. build/tmp/deploy/images/ 2.8. build/tmp/deploy/ipk/ 2.9. build/tmp/rootfs/ 2.10. build/tmp/staging/ 2.11. build/tmp/stamps/ 2.12. build/tmp/work/ 3. meta/ - The Metadata 3.1. meta/classes/ 3.2. meta/conf/ 3.3. meta/conf/machine/ 3.4. meta/conf/distro/ 3.5. meta/packages/ 3.6. meta/site/ 2. Reference: Bitbake 1. Parsing 2. Preferences and Providers 3. Dependencies 4. The Task List 5. Running a Task 6. Commandline 7. Fetchers 3. Reference: Classes 1. The base class - base.bbclass 2. Autotooled Packages - autotools.bbclass 3. Alternatives - update-alternatives.bbclass 4. Initscripts - update-rc.d.bbclass 5. Binary config scripts - binconfig.bbclass 6. Debian renaming - debian.bbclass 7. Pkg-config - pkgconfig.bbclass 8. Distribution of sources - src_distribute_local.bbclass 9. Perl modules - cpan.bbclass 10. Python extensions - distutils.bbclass 11. Developer Shell - devshell.bbclass 12. Packaging - package*.bbclass 13. Building kernels - kernel.bbclass 14. Creating images - image.bbclass and rootfs*.bbclass 15. Host System sanity checks - sanity.bbclass 16. Generated output quality assurance checks - insane.bbclass 17. Autotools configuration data cache - siteinfo.bbclass 18. Other Classes 4. Reference: Images 5. Reference: Features 1. Distro 2. Machine 3. Reference: Images 6. Reference: Variables Glossary Glossary 7. Reference: Variable Locality (Distro, Machine, Recipe etc.) 1. Distro Configuration 2. Machine Configuration 3. Local Configuration (local.conf) 4. Recipe Variables - Required 5. Recipe Variables - Dependencies 6. Recipe Variables - Paths 7. Recipe Variables - Extra Build Information 8. FAQ 9. Contributing to Poky 1. Introduction 2. Bugtracker 3. Mailing list 4. IRC 5. Links 10. OpenedHand Contact Information Index Chapter 1. Introduction Table of Contents 1. What is Poky? 2. Documentation Overview 3. System Requirements 4. Quick Start 4.1. Building and Running an Image 4.2. Downloading and Using Prebuilt Images 5. Obtaining Poky 5.1. Releases 5.2. Nightly Builds 5.3. Development Checkouts 1. What is Poky? Poky is an open source platform build tool. It is a complete software development environment for the creation of Linux devices. It aids the design, development, building, debugging, simulation and testing of complete modern software stacks using Linux, the X Window System and GNOME Mobile based application frameworks. It is based on OpenEmbedded but has been customised with a particular focus. Poky was setup to: Provide an open source Linux, X11, Matchbox, GTK+, Pimlico, Clutter, and other GNOME Mobile technologies based full platform build and development tool. Create a focused, stable, subset of OpenEmbedded that can be easily and reliably built and developed upon. Fully support a wide range of x86 and ARM hardware and device virtulisation Poky is primarily a platform builder which generates filesystem images based on open source software such as the Kdrive X server, the Matchbox window manager, the GTK+ toolkit and the D-Bus message bus system. Images for many kinds of devices can be generated, however the standard example machines target QEMU full system emulation (both x86 and ARM) and the ARM based Sharp Zaurus series of devices. Poky's ability to boot inside a QEMU emulator makes it particularly suitable as a test platform for development of embedded software. An important component integrated within Poky is Sato, a GNOME Mobile based user interface environment. It is designed to work well with screens at very high DPI and restricted size, such as those often found on smartphones and PDAs. It is coded with focus on efficiency and speed so that it works smoothly on hand-held and other embedded hardware. It will sit neatly on top of any device using the GNOME Mobile stack, providing a well defined user experience. The Sato Desktop - A screenshot from a machine running a Poky built image Poky has a growing open source community backed up by commercial support provided by the principle developer and maintainer of Poky, OpenedHand Ltd. 2. Documentation Overview The handbook is split into sections covering different aspects of Poky. The 'Using Poky' section gives an overview of the components that make up Poky followed by information about using and debugging the Poky build system. The 'Extending Poky' section gives information about how to extend and customise Poky along with advice on how to manage these changes. The 'Platform Development with Poky' section gives information about interaction between Poky and target hardware for common platform development tasks such as software development, debugging and profiling. The rest of the manual consists of several reference sections each giving details on a specific section of Poky functionality. This manual applies to Poky Release 3.1 (Pinky). 3. System Requirements We recommend Debian-based distributions, in particular a recent Ubuntu release (7.04 or newer), as the host system for Poky. Nothing in Poky is distribution specific and other distributions will most likely work as long as the appropriate prerequisites are installed - we know of Poky being used successfully on Redhat, SUSE, Gentoo and Slackware host systems. On a Debian-based system, you need the following packages installed: build-essential python diffstat texinfo texi2html cvs subversion wget gawk help2man bochsbios (only to run qemux86 images) Debian users can add debian.o-hand.com to their APT sources (See http://debian.o-hand.com for instructions on doing this) and then run "apt-get install qemu poky-depends poky-scripts" which will automatically install all these dependencies. OpenedHand can also provide VMware images with Poky and all dependencies pre-installed if required. Poky can use a system provided QEMU or build its own depending on how it's configured. See the options in local.conf for more details. 4. Quick Start 4.1. Building and Running an Image If you want to try Poky, you can do so in a few commands. The example below checks out the Poky source code, sets up a build environment, builds an image and then runs that image under the QEMU emulator in ARM system emulation mode: $ wget http://pokylinux.org/releases/pinky-3.1.tar.gz $ tar zxvf pinky-3.1.tar.gz $ cd pinky-3.1/ $ source poky-init-build-env $ bitbake poky-image-sato $ runqemu qemuarm Note This process will need Internet access, about 3 GB of disk space available, and you should expect the build to take about 4 - 5 hours since it is building an entire Linux system from source including the toolchain! To build for other machines see the MACHINE variable in build/conf/local.conf which also contains other configuration information. The images/kernels built by Poky are placed in the tmp/deploy/images directory. You could also run "poky-qemu zImage-qemuarm.bin poky-image-sato-qemuarm.ext2" within the images directory if you have the poky-scripts Debian package installed from debian.o-hand.com. This allows the QEMU images to be used standalone outside the Poky build environment. To setup networking within QEMU see the QEMU/USB networking with IP masquerading section. 4.2. Downloading and Using Prebuilt Images Prebuilt images from Poky are also available if you just want to run the system under QEMU. To use these you need to: Add debian.o-hand.com to your APT sources (See http://debian.o-hand.com for instructions on doing this) Install patched QEMU and poky-scripts: $ apt-get install qemu poky-scripts Download a Poky QEMU release kernel (*zImage*qemu*.bin) and compressed filesystem image (poky- image-*-qemu*.ext2.bz2) which you'll need to decompress with 'bzip2 -d'. These are available from the last release or from the autobuilder. Start the image: $ poky-qemu <kernel> <image> Note A patched version of QEMU is required at present. A suitable version is available from http://debian.o-hand.com, it can be built by poky (bitbake qemu-native) or can be downloaded/built as part of the toolchain/SDK tarballs. 5. Obtaining Poky 5.1. Releases Periodically, we make releases of Poky and these are available at http://pokylinux.org/releases/. These are more stable and tested than the nightly development images. 5.2. Nightly Builds We make nightly builds of Poky for testing purposes and to make the latest developments available. The output from these builds is available at http://pokylinux.org/autobuild/ where the numbers represent the svn revision the builds were made from. Automated builds are available for "standard" Poky and for Poky SDKs and toolchains as well as any testing versions we might have such as poky-bleeding. The toolchains can be used either as external standalone toolchains or can be combined with Poky as a prebuilt toolchain to reduce build time. Using the external toolchains is simply a case of untarring the tarball into the root of your system (it only creates files in /usr/local/poky) and then enabling the option in local.conf. 5.3. Development Checkouts Poky is available from our SVN repository located at http://svn.o-hand.com/repos/poky/trunk; a web interface to the repository can be accessed at http://svn.o-hand.com/view/poky/. 'trunk' is where the deveopment work takes place and you should use this if you're after to work with the latest cutting edge developments. It is possible trunk can suffer temporary periods of instability while new features are developed and if this is undesireable we recommend using one of the release branches. Chapter 2. Using Poky Table of Contents 1. Poky Overview 1.1. Bitbake 1.2. Metadata (Recipes) 1.3. Classes 1.4. Configuration 2. Running a Build 3. Installing and Using the Result 3.1. USB Networking 3.2. QEMU/USB networking with IP masquerading 4. Debugging Build Failures 4.1. Task Failures 4.2. Running specific tasks 4.3. Dependency Graphs 4.4. General Bitbake Problems 4.5. Building with no dependencies 4.6. Variables 4.7. Other Tips This section gives an overview of the components that make up Poky following by information about running poky builds and dealing with any problems that may arise. 1. Poky Overview At the core of Poky is the bitbake task executor together with various types of configuration files. This section gives an overview of bitbake and the configuration files, in particular what they are used for, and how they interact. Bitbake handles the parsing and execution of the data files. The data itself is of various types; recipes which give details about particular pieces of software, class data which is an abstraction of common build information (e.g. how to build a Linux kernel) and configuration data for machines, policy decisions, etc., which acts as a glue and binds everything together. Bitbake knows how to combine multiple data sources together, each data source being referred to as a 'collection'. The directory structure walkthrough section gives details on the meaning of specific directories but some brief details on the core components follows: 1.1. Bitbake Bitbake is the tool at the heart of Poky and is responsible for parsing the metadata, generating a list of tasks from it and then executing them. To see a list of the options it supports look at bitbake --help. The most common usage is bitbake packagename where packagename is the name of the package you wish to build (from now on called the target). This often equates to the first part of a .bb filename, so to run the matchbox-desktop_1.2.3.bb file, you might type bitbake matchbox-desktop. Several different versions of matchbox-desktop might exist and bitbake will choose the one selected by the distribution configuration (more details about how bitbake chooses between different versions and providers is available in the 'Preferences and Providers' section). Bitbake will also try to execute any dependent tasks first so before building matchbox-desktop it would build a cross compiler and glibc if not already built. 1.2. Metadata (Recipes) The .bb files are usually referred to as 'recipes'. In general, a recipe contains information about a single piece of software such as where to download the source, any patches that are needed, any special configuration options, how to compile the source files and how to package the compiled output. 'package' can also used to describe recipes but since the same word is used for the packaged output from Poky (i.e. .ipk or .deb files), this document will avoid it. 1.3. Classes Class (.bbclass) files contain information which is useful to share between metadata files. An example is the autotools class which contains the common settings that any application using autotools would use. The classes reference section gives details on common classes and how to use them. 1.4. Configuration The configuration (.conf) files define various configuration variables which govern what Poky does. These are split into several areas, such as machine configuration options, distribution configuration options, compiler tuning options, general common configuration and user configuration (local.conf). 2. Running a Build First the Poky build environment needs to be setup using the following command: $ source poky-init-build-env Once the Poky build environment is setup, a target can now be built using: $ bitbake <target> The target is the name of the recipe you want to build. Common targets are the images (in meta/packages/images/) or the name of a recipe for a specific piece of software like busybox. More details about the standard images are available in the image reference section. 3. Installing and Using the Result Once an image has been built it often needs to be installed. The images/kernels built by Poky are placed in the tmp/deploy/images directory. Running qemux86 and qemuarm images is covered in the Running an Image section. See your board/machine documentation for information about how to install these images. 3.1. USB Networking Devices commonly have USB connectivity. To connect to the usbnet interface, on the host machine run: modprobe usbnet ifconfig usb0 192.168.0.200 route add 192.168.0.202 usb0 3.2. QEMU/USB networking with IP masquerading On Ubuntu, Debian or similar distributions you can have the network automatically configured. You can also enable masquerading between the QEMU system and the rest of your network. To do this you need to edit /etc/network/interfaces to include: allow-hotplug tap0 iface tap0 inet static address 192.168.7.200 netmask 255.255.255.0 network 192.168.7.0 post-up iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.7.0/24 post-up echo 1 > /proc/sys/net/ipv4/ip_forward post-up iptables -P FORWARD ACCEPT This ensures the tap0 interface will be up everytime you run QEMU and it will have network/internet access. Under emulation there are two steps to configure for internet access via tap0. The first step is to configure routing: route add default gw 192.168.7.200 tap0 The second is to configure name resolution which is configured in the /etc/resolv.conf file. The simplest solution is to copy it's content from the host machine. USB connections to devices can be setup and automated in a similar way. First add the following to /etc/network/interfaces: allow-hotplug usb0 iface usb0 inet static address 192.168.0.200 netmask 255.255.255.0 network 192.168.0.0 post-up iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24 post-up echo 1 > /proc/sys/net/ipv4/ip_forward post-up iptables -P FORWARD ACCEPT and then to configure routing on the device you would use: route add default gw 192.168.0.202 usb0 4. Debugging Build Failures The exact method for debugging Poky depends on the nature of the bug(s) and which part of the system they might be from. Standard debugging practises such as comparing to the last known working version and examining the changes, reapplying the changes in steps to identify the one causing the problem etc. are valid for Poky just like any other system. Its impossible to detail every possible potential failure here but there are some general tips to aid debugging: 4.1. Task Failures The log file for shell tasks is available in ${WORKDIR}/temp/log.do_taskname.pid. For the compile task of busybox 1.01 on the ARM spitz machine, this might be tmp/work/armv5te-poky- linux-gnueabi/busybox-1.01/temp/log.do_compile.1234 for example. To see what bitbake ran to generate that log, look at the run.do_taskname.pid file in the same directory. The output from python tasks is sent directly to the console at present. 4.2. Running specific tasks Any given package consists of a set of tasks, in most cases the series is fetch, unpack, patch, configure, compile, install, package, package_write and build. The default task is "build" and any tasks this depends on are built first hence the standard bitbake behaviour. There are some tasks such as devshell which are not part of the default build chain. If you wish to run such a task you can use the "-c" option to bitbake e.g. bitbake matchbox-desktop -c devshell. If you wish to rerun a task you can use the force option "-f". A typical usage session might look like: % bitbake matchbox-desktop [change some source in the WORKDIR for example] % bitbake matchbox-desktop -c compile -f % bitbake matchbox-desktop which would build matchbox-desktop, then recompile it. The final command reruns all tasks after the compile (basically the packaging tasks) since bitbake will notice the the compile has been rerun and hence the other tasks also need to run again. You can view a list of tasks in a given package by running the listtasks task e.g. bitbake matchbox-desktop -c listtasks. 4.3. Dependency Graphs Sometimes it can be hard to see why bitbake wants to build some other packages before a given package you've specified. bitbake -g targetname will create depends.dot and task-depends.dot files in the current directory. They show which packages and tasks depend on which other packages and tasks and are useful for debugging purposes. 4.4. General Bitbake Problems Debug output from bitbake can be seen with the "-D" option. The debug output gives more information about what bitbake is doing and/or why. Each -D option increases the logging level, the most common usage being "-DDD". The output from bitbake -DDD -v targetname can reveal why a certain version of a package might be chosen, why bitbake picked a certain provider or help in other situations where bitbake does something you're not expecting. 4.5. Building with no dependencies If you really want to build a specific .bb file, you can use the form bitbake -b somepath/somefile.bb. Note that this will not check the dependencies so this option should only be used when you know its dependencies already exist. You can specify fragments of the filename and bitbake will see if it can find a unique match. 4.6. Variables The "-e" option will dump the resulting environment for either the configuration (no package specified) or for a specific package when specified with the "-b" option. 4.7. Other Tips Tip When adding new packages it is worth keeping an eye open for bad things creeping into compiler commandlines such as references to local system files (/usr/lib/ or /usr/include/ etc.). Tip If you want to remove the psplash boot splashscreen, add "psplash=false" to the kernel commandline and psplash won't load allowing you to see the console. It's also possible to switch out of the splashscreen by switching virtual console (Fn+Left or Fn+Right on a Zaurus). Chapter 3. Extending Poky Table of Contents 1. Adding a Package 1.1. Single .c File Package (Hello World!) 1.2. Autotooled Package 1.3. Makefile-Based Package 1.4. Controlling packages content 1.5. Post Install Scripts 2. Customising Images 2.1. Customising Images through a custom image .bb files 2.2. Customising Images through custom tasks 2.3. Customising Images through custom IMAGE_FEATURES 2.4. Customising Images through local.conf 3. Porting Poky to a new machine 3.1. Adding the machine configuration file 3.2. Adding a kernel for the machine 3.3. Adding a formfactor configuration file 4. Making and Maintaining Changes 4.1. Bitbake Collections 4.2. Committing Changes 4.3. Package Revision Incrementing 5. Modifying Package Source Code 5.1. Modifying Package Source Code with quilt This section gives information about how to extend the functionality already present in Poky, documenting standard tasks such as adding new software packages, extending or customising images or porting poky to new hardware (adding a new machine). It also contains advice about how to manage the process of making changes to Poky to achieve best results. 1. Adding a Package To add package into Poky you need to write a recipe for it. Writing a recipe means creating a .bb file which sets various variables. The variables useful for recipes are detailed in the recipe reference section along with more detailed information about issues such as recipe naming. The simplest way to add a new package is to base it on a similar pre-existing recipe. There are some examples below of how to add standard types of packages: 1.1. Single .c File Package (Hello World!) To build an application from a single file stored locally requires a recipe which has the file listed in the SRC_URI variable. In addition the do_compile and do_install tasks need to be manually written. The S variable defines the directory containing the source code which in this case is set equal to WORKDIR, the directory BitBake uses for the build. DESCRIPTION = "Simple helloworld application" SECTION = "examples" LICENSE = "MIT" SRC_URI = "file://helloworld.c" S = "${WORKDIR}" do_compile() { ${CC} helloworld.c -o helloworld } do_install() { install -d ${D}${bindir} install -m 0755 helloworld ${D}${bindir} } As a result of the build process "helloworld" and "helloworld-dbg" packages will be built. 1.2. Autotooled Package Applications which use autotools (autoconf, automake) require a recipe which has a source archive listed in SRC_URI and inherit autotools to instruct BitBake to use the autotools.bbclass which has definitions of all the steps needed to build an autotooled application. The result of the build will be automatically packaged and if the application uses NLS to localise then packages with locale information will be generated (one package per language). DESCRIPTION = "GNU Helloworld application" SECTION = "examples" LICENSE = "GPLv2" SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.bz2" inherit autotools 1.3. Makefile-Based Package Applications which use GNU make require a recipe which has the source archive listed in SRC_URI. Adding a do_compile step is not needed as by default BitBake will start the "make" command to compile the application. If there is a need for additional options to make then they should be stored in the EXTRA_OEMAKE variable - BitBake will pass them into the GNU make invocation. A do_install task is required - otherwise BitBake will run an empty do_install task by default. Some applications may require extra parameters to be passed to the compiler, for example an additional header path. This can be done buy adding to the CFLAGS variable, as in the example below. DESCRIPTION = "Tools for managing memory technology devices." SECTION = "base" DEPENDS = "zlib" HOMEPAGE = "http://www.linux-mtd.infradead.org/" LICENSE = "GPLv2" SRC_URI = "ftp://ftp.infradead.org/pub/mtd-utils/mtd-utils-${PV}.tar.gz" CFLAGS_prepend = "-I ${S}/include " do_install() { oe_runmake install DESTDIR=${D} } 1.4. Controlling packages content The variables PACKAGES and FILES are used to split an application into multiple packages. Below the "libXpm" recipe is used as an example. By default the "libXpm" recipe generates one package which contains the library and also a few binaries. The recipe can be adapted to split the binaries into separate packages. require xorg-lib-common.inc DESCRIPTION = "X11 Pixmap library" LICENSE = "X-BSD" DEPENDS += "libxext" PE = "1" XORG_PN = "libXpm" PACKAGES =+ "sxpm cxpm" FILES_cxpm = "${bindir}/cxpm" FILES_sxpm = "${bindir}/sxpm" In this example we want to ship the "sxpm" and "cxpm" binaries in separate packages. Since "bindir" would be packaged into the main PN package as standard we prepend the PACKAGES variable so additional package names are added to the start of list. The extra FILES_* variables then contain information to specify which files and directories goes into which package. 1.5. Post Install Scripts To add a post-installation script to a package, add a pkg_postinst_PACKAGENAME() function to the .bb file where PACKAGENAME is the name of the package to attach the postinst script to. A post-installation function has the following structure: pkg_postinst_PACKAGENAME () { #!/bin/sh -e # Commands to carry out } The script defined in the post installation function gets called when the rootfs is made. If the script succeeds, the package is marked as installed. If the script fails, the package is marked as unpacked and the script will be executed again on the first boot of the image. Sometimes it is necessary that the execution of a post-installation script is delayed until the first boot, because the script needs to be executed the device itself. To delay script execution until boot time, the post-installation function should have the following structure: pkg_postinst_PACKAGENAME () { #!/bin/sh -e if [ x"$D" = "x" ]; then # Actions to carry out on the device go here else exit 1 fi } The structure above delays execution until first boot because the D variable points to the 'image' directory when the rootfs is being made at build time but is unset when executed on the first boot. 2. Customising Images Poky images can be customised to satisfy particular requirements. Several methods are detailed below along with guidelines of when to use them. 2.1. Customising Images through a custom image .bb files One way to get additional software into an image is by creating a custom image. The recipe will contain two lines: IMAGE_INSTALL = "task-poky-x11-base package1 package2" inherit poky-image By creating a custom image, a developer has total control over the contents of the image. It is important use the correct names of packages in the IMAGE_INSTALL variable. The names must be in the OpenEmbedded notation instead of Debian notation, for example "glibc-dev" instead of "libc6-dev" etc. The other method of creating a new image is by modifying an existing image. For example if a developer wants to add "strace" into "poky-image-sato" the following recipe can be used: require poky-image-sato.bb IMAGE_INSTALL += "strace" 2.2. Customising Images through custom tasks For for complex custom images, the best approach is to create a custom task package which is them used to build the image (or images). A good example of a tasks package is meta/packages/tasks/task- poky.bb . The PACKAGES variable lists the task packages to build (along with the complimentary -dbg and - dev packages). For each package added, RDEPENDS and RRECOMMENDS entries can then be added each containing a list of packages the parent task package should contain. An example would be: DESCRIPTION = "My Custom Tasks" PACKAGES = "\ task-custom-apps \ task-custom-apps-dbg \ task-custom-apps-dev \ task-custom-tools \ task-custom-tools-dbg \ task-custom-tools-dev \ " RDEPENDS_task-custom-apps = "\ dropbear \ portmap \ psplash" RDEPENDS_task-custom-tools = "\ oprofile \ oprofileui-server \ lttng-control \ lttng-viewer" RRECOMMENDS_task-custom-tools = "\ kernel-module-oprofile" In this example, two tasks packages are created, task-custom-apps and task-custom-tools with the dependencies and recommended package dependencies listed. To build an image using these task packages, you would then add "task- custom-apps" and/or "task-custom-tools" to IMAGE_INSTALL or other forms of image dependencies as described in other areas of this section. 2.3. Customising Images through custom IMAGE_FEATURES Ultimately users may want to add extra image "features" as used by Poky with the IMAGE_FEATURES variable. To create these, the best reference is meta/classes/poky-image.bbclass which illustrates how poky achieves this. In summary, the file looks at the contents of the IMAGE_FEATURES variable and based on this generates the IMAGE_INSTALL variable automatically. Extra features can be added by extending the class or creating a custom class for use with specialised image .bb files. 2.4. Customising Images through local.conf It is possible to customise image contents by abusing variables used by distribution maintainers in local.conf. This method only allows the addition of packages and is not recommended. To add an "strace" package into the image the following is added to local.conf: DISTRO_EXTRA_RDEPENDS += "strace" However, since the DISTRO_EXTRA_RDEPENDS variable is for distribution maintainers this method does not make adding packages as simple as a custom .bb file. Using this method, a few packages will need to be recreated and the the image built. bitbake -cclean task-boot task-base task-poky bitbake poky-image-sato Cleaning task-* packages is required because they use the DISTRO_EXTRA_RDEPENDS variable. There is no need to build them by hand as Poky images depend on the packages they contain so dependencies will be built automatically. For this reason we don't use the "rebuild" task in this case since "rebuild" does not care about dependencies - it only rebuilds the specified package. 3. Porting Poky to a new machine Adding a new machine to Poky is a straightforward process and this section gives an idea of the changes that are needed. This guide is meant to cover adding machines similar to those Poky already supports. Adding a totally new architecture might require gcc/glibc changes as well as updates to the site information and, whilst well within Poky's capabilities, is outside the scope of this section. 3.1. Adding the machine configuration file A .conf file needs to be added to conf/machine/ with details of the device being added. The name of the file determines the name Poky will use to reference this machine. The most important variables to set in this file are TARGET_ARCH (e.g. "arm"), PREFERRED_PROVIDER_virtual/kernel (see below) and MACHINE_FEATURES (e.g. "kernel26 apm screen wifi"). Other variables like SERIAL_CONSOLE (e.g. "115200 ttyS0"), KERNEL_IMAGETYPE (e.g. "zImage") and IMAGE_FSTYPES (e.g. "tar.gz jffs2") might also be needed. Full details on what these variables do and the meaning of their contents is available through the links. 3.2. Adding a kernel for the machine Poky needs to be able to build a kernel for the machine. You need to either create a new kernel recipe for this machine or extend an existing recipe. There are plenty of kernel examples in the packages/linux directory which can be used as references. If creating a new recipe the "normal" recipe writing rules apply for setting up a SRC_URI including any patches and setting S to point at the source code. You will need to create a configure task which configures the unpacked kernel with a defconfig be that through a "make defconfig" command or more usually though copying in a suitable defconfig and running "make oldconfig". By making use of "inherit kernel" and also maybe some of the linux-*.inc files, most other functionality is centralised and the the defaults of the class normally work well. If extending an existing kernel it is usually a case of adding a suitable defconfig file in a location similar to that used by other machine's defconfig files in a given kernel, possibly listing it in the SRC_URI and adding the machine to the expression in COMPATIBLE_MACHINES . 3.3. Adding a formfactor configuration file A formfactor configuration file provides information about the target hardware on which Poky is running, and that Poky cannot obtain from other sources such as the kernel. Some examples of information contained in a formfactor configuration file include framebuffer orientation, whether or not the system has a keyboard, the positioning of the keyboard in relation to the screen, and screen resolution. Sane defaults should be used in most cases, but if customisation is necessary you need to create a machconfig file under meta/packages/formfactor/files/MACHINENAME/ where MACHINENAME is the name for which this infomation applies. For information about the settings available and the defaults, please see meta/packages/formfactor/files/config. 4. Making and Maintaining Changes We recognise that people will want to extend/configure/optimise Poky for their specific uses, especially due to the extreme configurability and flexibility Poky offers. To ensure ease of keeping pace with future changes in Poky we recommend making changes to Poky in a controlled way. Poky supports the idea of "collections" which when used properly can massively ease future upgrades and allow segregation between the Poky core and a given developer's changes. Some other advice on managing changes to Poky is also given in the following section. 4.1. Bitbake Collections Often, people want to extend Poky either through adding packages or overriding files contained within Poky to add their own functionality. Bitbake has a powerful mechanism called collections which provide a way to handle this which is fully supported and actively encouraged within Poky. In the standard tree, meta-extras is an example of how you can do this. As standard the data in meta-extras is not used on a Poky build but local.conf.sample shows how to enable it: BBFILES := "${OEROOT}/meta/packages/*/*.bb ${OEROOT}/meta-extras/packages/*/*.bb" BBFILE_COLLECTIONS = "normal extras" BBFILE_PATTERN_normal = "^${OEROOT}/meta/" BBFILE_PATTERN_extras = "^${OEROOT}/meta-extras/" BBFILE_PRIORITY_normal = "5" BBFILE_PRIORITY_extras = "5" As can be seen, the extra recipes are added to BBFILES. The BBFILE_COLLECTIONS variable is then set to contain a list of collection names. The BBFILE_PATTERN variables are regular expressions used to match files from BBFILES into a particular collection in this case by using the base pathname. The BBFILE_PRIORITY variable then assigns the different priorities to the files in different collections. This is useful in situations where the same package might appear in both repositories and allows you to choose which collection should 'win'. This works well for recipes. For bbclasses and configuration files, you can use the BBPATH environment variable. In this case, the first file with the matching name found in BBPATH is the one that is used, just like the PATH variable for binaries. 4.2. Committing Changes Modifications to Poky are often managed under some kind of source revision control system. The policy for committing to such systems is important as some simple policy can significantly improve usability. The tips below are based on the policy that OpenedHand uses for commits to Poky. It helps to use a consistent style for commit messages when committing changes. We've found a style where the first line of a commit message summarises the change and starts with the name of any package affected work well. Not all changes are to specific packages so the prefix could also be a machine name or class name instead. If a change needs a longer description this should follow the summary. Any commit should be self contained in that it should leave the metadata in a consistent state, buildable before and after the commit. This helps ensure the autobuilder test results are valid but is good practice regardless. 4.3. Package Revision Incrementing If a committed change will result in changing the package output then the value of the PR variable needs to be increased (commonly referred to as 'bumped') as part of that commit. Only integer values are used and PR = "r0" should not be added into new recipes as this is default value. When upgrading the version of a package (PV), the PR variable should be removed. The aim is that the package version will only ever increase. If for some reason PV will change and but not increase, the PE (Package Epoch) can be increased (it defaults to '0'). The version numbers aim to follow the Debian Version Field Policy Guidelines which define how versions are compared and hence what "increasing" means. There are two reasons for doing this, the first is to ensure that when a developer updates and rebuilds, they get all the changes to the repository and don't have to remember to rebuild any sections. The second is to ensure that target users are able to upgrade their devices via their package manager such as with the ipkg update;ipkg upgrade commands (or similar for dpkg/apt or rpm based systems). The aim is to ensure Poky has upgradable packages in all cases. 5. Modifying Package Source Code Poky is usually used to build software rather than modifying it. However, there are ways Poky can be used to modify software. During building, the sources are available in WORKDIR directory. Where exactly this is depends on the type of package and the architecture of target device. For a standard recipe not related to MACHINE it will be tmp/work/PACKAGE_ARCH-poky-TARGET_OS/PN-PV-PR/. Target device dependent packages use MACHINE instead of PACKAGE_ARCH in the directory name. Tip Check the package recipe sets the S variable to something other than standard WORKDIR/PN-PV/ value. After building a package, a user can modify the package source code without problem. The easiest way to test changes is by calling the "compile" task: bitbake --cmd compile --force NAME_OF_PACKAGE Other tasks may also be called this way. 5.1. Modifying Package Source Code with quilt By default Poky uses quilt to manage patches in do_patch task. It is a powerful tool which can be used to track all modifications done to package sources. Before modifying source code it is important to notify quilt so it will track changes into new patch file: quilt new NAME-OF-PATCH.patch Then add all files which will be modified into that patch: quilt add file1 file2 file3 Now start editing. At the end quilt needs to be used to generate final patch which will contain all modifications: quilt refresh The resulting patch file can be found in the patches/ subdirectory of the source (S) directory. For future builds it should be copied into Poky metadata and added into SRC_URI of a recipe: SRC_URI += "file://NAME-OF-PATCH.patch;patch=1" This also requires a bump of PR value in the same recipe as we changed resulting packages. Chapter 4. Platform Development with Poky Table of Contents 1. Software development 1.1. Developing externally using the Poky SDK 1.2. Developing externally using the Anjuta plugin 1.3. Developing externally in QEMU 1.4. Developing externally in a chroot 1.5. Developing in Poky directly 1.6. Developing with 'devshell' 1.7. Developing within Poky with an external SCM based package 2. Debugging with GDB Remotely 2.1. Launching GDBSERVER on the target 2.2. Launching GDB on the host computer 3. Profiling with OProfile 3.1. Profiling on the target 3.2. Using OProfileUI 1. Software development Poky supports several methods of software development. These different forms of development are explained below and can be switched between as needed. 1.1. Developing externally using the Poky SDK The meta-toolchain and meta-toolchain-sdk targets (see the images section) build tarballs which contain toolchains and libraries suitable for application development outside Poky. These unpack into the /usr/local/poky directory and contain a setup script, e.g. /usr/local/poky/eabi- glibc/arm/environment-setup which can be sourced to initialise a suitable environment. After sourcing this, the compiler, QEMU scripts, QEMU binary, a special version of pkgconfig and other useful utilities are added to the PATH. Variables to assist pkgconfig and autotools are also set so that, for example, configure can find pre-generated test results for tests which need target hardware to run. Using the toolchain with autotool enabled packages is straightforward, just pass the appropriate host option to configure e.g. "./configure --host=arm-poky-linux-gnueabi". For other projects it is usually a case of ensuring the cross tools are used e.g. CC=arm-poky-linux-gnueabi-gcc and LD=arm-poky-linux-gnueabi-ld. 1.2. Developing externally using the Anjuta plugin An Anjuta IDE plugin exists to make developing software within the Poky framework easier for the application developer. It presents a graphical IDE from which the developer can cross compile an application then deploy and execute the output in a QEMU emulation session. It also supports cross debugging and profiling. To use the plugin, a toolchain and SDK built by Poky is required along with Anjuta and the Anjuta plugin. The Poky Anjuta plugin is available from the OpenedHand SVN repository located at http://svn.o-hand.com/repos/anjuta- poky/trunk/anjuta-plugin-sdk/; a web interface to the repository can be accessed at http://svn.o- hand.com/view/anjuta-poky/. See the README file contained in the project for more information about the dependencies and how to get them along with details of the prebuilt packages. 1.2.1. Setting up the Anjuta plugin Extract the tarball for the toolchain into / as root. The toolchain will be installed into /usr/local/poky. To use the plugin, first open or create an existing project. If creating a new project the "C GTK+" project type will allow itself to be cross-compiled. However you should be aware that this uses glade for the UI. To activate the plugin go to Edit → Preferences, then choose General from the left hand side. Choose the Installed plugins tab, scroll down to Poky SDK and check the box. The plugin is now activated but first it must be configured. 1.2.2. Configuring the Anjuta plugin The configuration options for the SDK can be found by choosing the Poky SDK icon from the left hand side. The following options need to be set: SDK root: this is the root directory of the SDK for an ARM EABI SDK this will be /usr/local/poky/eabi-glibc/arm. This directory will contain directories named like "bin", "include", "var", etc. With the file chooser it is important to enter into the "arm" subdirectory for this example. Toolchain triplet: this is the cross compile triplet, e.g. "arm-poky-linux-gnueabi". Kernel: use the file chooser to select the kernel to use with QEMU Root filesystem: use the file chooser to select the root filesystem image, this should be an image (not a tarball) 1.2.3. Using the Anjuta plugin As an example, cross-compiling a project, deploying it into QEMU and running a debugger against it and then doing a system wide profile. Choose Build → Run Configure or Build → Run Autogenerate to run "configure" (or to run "autogen") for the project. This passes command line arguments to instruct it to cross-compile. Next do Build → Build Project to build and compile the project. If you have previously built the project in the same tree without using the cross-compiler you may find that your project fails to link. Simply do Build → Clean Project to remove the old binaries. You may then try building again. Next start QEMU by using Tools → Start QEMU, this will start QEMU and will show any error messages in the message view. Once Poky has fully booted within QEMU you may now deploy into it. Once built and QEMU is running, choose Tools → Deploy, this will install the package into a temporary directory and then copy using rsync over SSH into the target. Progress and messages will be shown in the message view. To debug a program installed into onto the target choose Tools → Debug remote. This prompts for the local binary to debug and also the command line to run on the target. The command line to run should include the full path to the to binary installed in the target. This will start a gdbserver over SSH on the target and also an instance of a cross-gdb in a local terminal. This will be preloaded to connect to the server and use the SDK root to find symbols. This gdb will connect to the target and load in various libraries and the target program. You should setup any breakpoints or watchpoints now since you might not be able to interrupt the execution later. You may stop the debugger on the target using Tools → Stop debugger. It is also possible to execute a command in the target over SSH, the appropriate environment will be be set for the execution. Choose Tools → Run remote to do this. This will open a terminal with the SSH command inside. To do a system wide profile against the system running in QEMU choose Tools → Profile remote. This will start up OProfileUI with the appropriate parameters to connect to the server running inside QEMU and will also supply the path to the debug information necessary to get a useful profile. 1.3. Developing externally in QEMU Running Poky QEMU images is covered in the Running an Image section. Poky's QEMU images contain a complete native toolchain. This means that applications can be developed within QEMU in the same was as a normal system. Using qemux86 on an x86 machine is fast since the guest and host architectures match, qemuarm is slower but gives faithful emulation of ARM specific issues. To speed things up these images support using distcc to call a cross-compiler outside the emulated system too. If runqemu was used to start QEMU, and distccd is present on the host system, any bitbake cross compiling toolchain available from the build system will automatically be used from within qemu simply by calling distcc (export CC="distcc" can be set in the enviroment). Alterntatively, if a suitable SDK/toolchain is present in /usr/local/poky it will also automatically be used. There are several options for connecting into the emulated system. QEMU provides a framebuffer interface which has standard consoles available. There is also a serial connection available which has a console to the system running on it and IP networking as standard. The images have a dropbear ssh server running with the root password disabled allowing standard ssh and scp commands to work. The images also contain an NFS server exporting the guest's root filesystem allowing that to be made available to the host. 1.4. Developing externally in a chroot If you have a system that matches the architecture of the Poky machine you're using, such as qemux86, you can run binaries directly from the image on the host system using a chroot combined with tools like Xephyr. Poky has some scripts to make using its qemux86 images within a chroot easier. To use these you need to install the poky-scripts package or otherwise obtain the poky-chroot-setup and poky-chroot-run scripts. You also need Xephyr and chrootuid binaries available. To initialize a system use the setup script: # poky-chroot-setup <qemux86-rootfs.tgz> <target-directory> which will unpack the specified qemux86 rootfs tarball into the target-directory. You can then start the system with: # poky-chroot-run <target-directory> <command> where the target-directory is the place the rootfs was unpacked to and command is an optional command to run. If no command is specified, the system will drop you within a bash shell. A Xephyr window will be displayed containing the emulated system and you may be asked for a password since some of the commands used for bind mounting directories need to be run using sudo. There are limits as to how far the the realism of the chroot environment extends. It is useful for simple development work or quick tests but full system emulation with QEMU offers a much more realistic environment for more complex development tasks. Note that chroot support within Poky is still experimental. 1.5. Developing in Poky directly Working directly in Poky is a fast and effective development technique. The idea is that you can directly edit files in WORKDIR or the source directory S and then force specific tasks to rerun in order to test the changes. An example session working on the matchbox-desktop package might look like this: $ bitbake matchbox-desktop $ sh $ cd tmp/work/armv5te-poky-linux-gnueabi/matchbox-desktop-2.0+svnr1708-r0/ $ cd matchbox-desktop-2 $ vi src/main.c $ exit $ bitbake matchbox-desktop -c compile -f $ bitbake matchbox-desktop Here, we build the package, change into the work directory for the package, change a file, then recompile the package. Instead of using sh like this, you can also use two different terminals. The risk with working like this is that a command like unpack could wipe out the changes you've made to the work directory so you need to work carefully. It is useful when making changes directly to the work directory files to do so using quilt as detailed in the modifying packages with quilt section. The resulting patches can be copied into the recipe directory and used directly in the SRC_URI. For a review of the skills used in this section see Sections 2.1.1 and 2.4.2. 1.6. Developing with 'devshell' When debugging certain commands or even to just edit packages, the 'devshell' can be a useful tool. To start it you run a command like: $ bitbake matchbox-desktop -c devshell which will open a terminal with a shell prompt within the Poky environment. This means PATH is setup to include the cross toolchain, the pkgconfig variables are setup to find the right .pc files, configure will be able to find the Poky site files etc. Within this environment, you can run configure or compile command as if they were being run by Poky itself. You are also changed into the source (S) directory automatically. When finished with the shell just exit it or close the terminal window. The default shell used by devshell is the gnome-terminal. Other forms of terminal can also be used by setting the TERMCMD and TERMCMDRUN variables in local.conf. For examples of the other options available, see meta/conf/bitbake.conf. An external shell is launched rather than opening directly into the original terminal window to make interaction with bitbakes multiple threads easier and also allow a client/server split of bitbake in the future (devshell will still work over X11 forwarding or similar). It is worth remembering that inside devshell you need to use the full compiler name such as arm-poky-linux- gnueabi-gcc instead of just gcc and the same applies to other applications from gcc, bintuils, libtool etc. Poky will have setup environmental variables such as CC to assist applications, such as make, find the correct tools. 1.7. Developing within Poky with an external SCM based package If you're working on a recipe which pulls from an external SCM it is possible to have Poky notice new changes added to the SCM and then build the latest version. This only works for SCMs where its possible to get a sensible revision number for changes. Currently it works for svn, git and bzr repositories. To enable this behaviour it is simply a case of adding SRCREV_pn- PN = "${AUTOREV}" to local.conf where PN is the name of the package for which you want to enable automatic source revision updating. 2. Debugging with GDB Remotely GDB (The GNU Project Debugger) allows you to examine running programs to understand and fix problems and also to perform postmortem style analsys of program crashes. It is available as a package within poky and installed by default in sdk images. It works best when -dbg packages for the application being debugged are installed as the extra symbols give more meaningful output from GDB. Sometimes, due to memory or disk space constraints, it is not possible to use GDB directly on the remote target to debug applications. This is due to the fact that GDB needs to load the debugging information and the binaries of the process being debugged. GDB then needs to perform many computations to locate information such as function names, variable names and values, stack traces, etc. even before starting the debugging process. This places load on the target system and can alter the characteristics of the program being debugged. This is where GDBSERVER comes into play as it runs on the remote target and does not load any debugging information from the debugged process. Instead, the debugging information processing is done by a GDB instance running on a distant computer - the host GDB. The host GDB then sends control commands to GDBSERVER to make it stop or start the debugged program, as well as read or write some memory regions of that debugged program. All the debugging information loading and processing as well as the heavy debugging duty is done by the host GDB, giving the GDBSERVER running on the target a chance to remain small and fast. As the host GDB is responsible for loading the debugging information and doing the necessary processing to make actual debugging happen, the user has to make sure it can access the unstripped binaries complete with their debugging information and compiled with no optimisations. The host GDB must also have local access to all the libraries used by the debugged program. On the remote target the binaries can remain stripped as GDBSERVER does not need any debugging information there. However they must also be compiled without optimisation matching the host's binaries. The binary being debugged on the remote target machine is hence referred to as the 'inferior' in keeping with GDB documentation and terminology. Further documentation on GDB, is available on on their site. 2.1. Launching GDBSERVER on the target First, make sure gdbserver is installed on the target. If not, install the gdbserver package (which needs the libthread- db1 package). To launch GDBSERVER on the target and make it ready to "debug" a program located at /path/to/inferior, connect to the target and launch: $ gdbserver localhost:2345 /path/to/inferior After that, gdbserver should be listening on port 2345 for debugging commands coming from a remote GDB process running on the host computer. Communication between the GDBSERVER and the host GDB will be done using TCP. To use other communication protocols please refer to the GDBSERVER documentation. 2.2. Launching GDB on the host computer Running GDB on the host computer takes a number of stages, described in the following sections. 2.2.1. Build the cross GDB package A suitable gdb cross binary is required which runs on your host computer but knows about the the ABI of the remote target. This can be obtained from the the Poky toolchain, e.g. /usr/local/poky/eabi- glibc/arm/bin/arm-poky-linux-gnueabi-gdb which "arm" is the target architecture and "linux-gnueabi" the target ABI. Alternatively this can be built directly by Poky. To do this you would build the gdb-cross package so for example you would run: bitbake gdb-cross Once built, the cross gdb binary can be found at tmp/cross/bin/<target-abi>-gdb 2.2.2. Making the inferior binaries available The inferior binary needs to be available to GDB complete with all debugging symbols in order to get the best possible results along with any libraries the inferior depends on and their debugging symbols. There are a number of ways this can be done. Perhaps the easiest is to have an 'sdk' image corresponding to the plain image installed on the device. In the case of 'pky-image-sato', 'poky-image-sdk' would contain suitable symbols. The sdk images already have the debugging symbols installed so its just a question expanding the archive to some location and telling GDB where this is. Alternatively, poky can build a custom directory of files for a specific debugging purpose by reusing its tmp/rootfs directory, on the host computer in a slightly different way to normal. This directory contains the contents of the last built image. This process assumes the image running on the target was the last image to be built by Poky, the package foo contains the inferior binary to be debugged has been built without without optimisation and has debugging information available. Firstly you want to install the foo package to tmp/rootfs by doing: tmp/staging/i686-linux/usr/bin/ipkg-cl -f \ tmp/work/<target-abi>/poky-image-sato-1.0-r0/temp/ipkg.conf -o \ tmp/rootfs/ update then, tmp/staging/i686-linux/usr/bin/ipkg-cl -f \ tmp/work/<target-abi>/poky-image-sato-1.0-r0/temp/ipkg.conf \ -o tmp/rootfs install foo tmp/staging/i686-linux/usr/bin/ipkg-cl -f \ tmp/work/<target-abi>/poky-image-sato-1.0-r0/temp/ipkg.conf \ -o tmp/rootfs install foo-dbg which installs the debugging information too. 2.2.3. Launch the host GDB To launch the host GDB, run the cross gdb binary identified above with the inferior binary specified on the commandline: <target-abi>-gdb rootfs/usr/bin/foo This loads the binary of program foo as well as its debugging information. Once the gdb prompt appears, you must instruct GDB to load all the libraries of the inferior from tmp/rootfs: set solib-absolute-prefix /path/to/tmp/rootfs where /path/to/tmp/rootfs must be the absolute path to tmp/rootfs or wherever the binaries with debugging information are located. Now, tell GDB to connect to the GDBSERVER running on the remote target: target remote remote-target-ip-address:2345 Where remote-target-ip-address is the IP address of the remote target where the GDBSERVER is running. 2345 is the port on which the GDBSERVER is running. 2.2.4. Using the Debugger Debugging can now proceed as normal, as if the debugging were being done on the local machine, for example to tell GDB to break in the main function, for instance: break main and then to tell GDB to "continue" the inferior execution, continue For more information about using GDB please see the project's online documentation at http://sourceware.org/gdb/download/onlinedocs/. 3. Profiling with OProfile OProfile is a statistical profiler well suited to finding performance bottlenecks in both userspace software and the kernel. It provides answers to questions like "Which functions does my application spend the most time in when doing X?". Poky is well integrated with OProfile to make profiling applications on target hardware straightforward. To use OProfile you need an image with OProfile installed. The easiest way to do this is with "tools-profile" in IMAGE_FEATURES. You also need debugging symbols to be available on the system where the analysis will take place. This can be achieved with "dbg-pkgs" in IMAGE_FEATURES or by installing the appropriate -dbg packages. For successful call graph analysis the binaries must preserve the frame pointer register and hence should be compiled with the "-fno-omit-framepointer" flag. In Poky this can be achieved with SELECTED_OPTIMIZATION = "-fexpensive- optimizations -fno-omit-framepointer -frename-registers -O2" or by setting DEBUG_BUILD = "1" in local.conf (the latter will also add extra debug information making the debug packages large). 3.1. Profiling on the target All the profiling work can be performed on the target device. A simple OProfile session might look like: # opcontrol --reset # opcontrol --start --separate=lib --no-vmlinux -c 5 [do whatever is being profiled] # opcontrol --stop $ opreport -cl Here, the reset command clears any previously profiled data, OProfile is then started. The options used to start OProfile mean dynamic library data is kept separately per application, kernel profiling is disabled and callgraphing is enabled up to 5 levels deep. To profile the kernel, you would specify the --vmlinux=/path/to/vmlinux option (the vmlinux file is usually in /boot/ in Poky and must match the running kernel). The profile is then stopped and the results viewed with opreport with options to see the separate library symbols and callgraph information. Callgraphing means OProfile not only logs infomation about which functions time is being spent in but also which functions called those functions (their parents) and which functions that function calls (its children). The higher the callgraphing depth, the more accurate the results but this also increased the loging overhead so it should be used with caution. On ARM, binaries need to have the frame pointer enabled for callgraphing to work (compile with the gcc option -fno-omit-framepointer). For more information on using OProfile please see the OProfile online documentation at http://oprofile.sourceforge.net/docs/. 3.2. Using OProfileUI A graphical user interface for OProfile is also available. You can either use prebuilt Debian packages from the OpenedHand repository or download and build from svn at http://svn.o-hand.com/repos/oprofileui/trunk/. If the "tools-profile" image feature is selected, all necessary binaries are installed onto the target device for OProfileUI interaction. In order to convert the data in the sample format from the target to the host the opimport program is needed. This is not included in standard Debian OProfile packages but an OProfile package with this addition is also available from the OpenedHand repository. We recommend using OProfile 0.9.3 or greater. Other patches to OProfile may be needed for recent OProfileUI features, but Poky usually includes all needed patches on the target device. Please see the OProfileUI README for up to date information, and the OProfileUI website for more information on the OProfileUI project. 3.2.1. Online mode This assumes a working network connection with the target hardware. In this case you just need to run "oprofile- server" on the device. By default it listens on port 4224. This can be changed with the --port command line option. The client program is called oprofile-viewer. The UI is relatively straightforward, the key functionality is accessed through the buttons on the toolbar (which are duplicated in the menus.) These buttons are: Connect - connect to the remote host, the IP address or hostname for the target can be supplied here. Disconnect - disconnect from the target. Start - start the profiling on the device. Stop - stop the profiling on the device and download the data to the local host. This will generate the profile and show it in the viewer. Download - download the data from the target, generate the profile and show it in the viewer. Reset - reset the sample data on the device. This will remove the sample information that was collected on a previous sampling run. Ensure you do this if you do not want to include old sample information. Save - save the data downloaded from the target to another directory for later examination. Open - load data that was previously saved. The behaviour of the client is to download the complete 'profile archive' from the target to the host for processing. This archive is a directory containing the sample data, the object files and the debug information for said object files. This archive is then converted using a script included in this distribution ('oparchconv') that uses 'opimport' to convert the archive from the target to something that can be processed on the host. Downloaded archives are kept in /tmp and cleared up when they are no longer in use. If you wish to profile into the kernel, this is possible, you just need to ensure a vmlinux file matching the running kernel is available. In Poky this is usually located in /boot/vmlinux-KERNELVERSION, where KERNEL-version is the version of the kernel e.g. 2.6.23. Poky generates separate vmlinux packages for each kernel it builds so it should be a question of just ensuring a matching package is installed ( ipkg install kernel-vmlinux. These are automatically installed into development and profiling images alongside OProfile. There is a configuration option within the OProfileUI settings page where the location of the vmlinux file can be entered. Waiting for debug symbols to transfer from the device can be slow and it's not always necessary to actually have them on device for OProfile use. All that is needed is a copy of the filesystem with the debug symbols present on the viewer system. The GDB remote debug section covers how to create such a directory with Poky and the location of this directory can again be specified in the OProfileUI settings dialog. If specified, it will be used where the file checksums match those on the system being profiled. 3.2.2. Offline mode If no network access to the target is available an archive for processing in 'oprofile-viewer' can be generated with the following set of command. # opcontrol --reset # opcontrol --start --separate=lib --no-vmlinux -c 5 [do whatever is being profiled] # opcontrol --stop # oparchive -o my_archive Where my_archive is the name of the archive directory where you would like the profile archive to be kept. The directory will be created for you. This can then be copied to another host and loaded using 'oprofile-viewer''s open functionality. The archive will be converted if necessary. Appendix 1. Reference: Directory Structure Table of Contents 1. Top level core components 1.1. bitbake/ 1.2. build/ 1.3. meta/ 1.4. meta-extras/ 1.5. scripts/ 1.6. sources/ 1.7. poky-init-build-env 2. build/ - The Build Directory 2.1. build/conf/local.conf 2.2. build/tmp/ 2.3. build/tmp/cache/ 2.4. build/tmp/cross/ 2.5. build/tmp/deploy/ 2.6. build/tmp/deploy/deb/ 2.7. build/tmp/deploy/images/ 2.8. build/tmp/deploy/ipk/ 2.9. build/tmp/rootfs/ 2.10. build/tmp/staging/ 2.11. build/tmp/stamps/ 2.12. build/tmp/work/ 3. meta/ - The Metadata 3.1. meta/classes/ 3.2. meta/conf/ 3.3. meta/conf/machine/ 3.4. meta/conf/distro/ 3.5. meta/packages/ 3.6. meta/site/ Poky consists of several components and understanding what these are and where they're located is one of the keys to using it. This section walks through the Poky directory structure giving information about the various files and directories. 1. Top level core components 1.1. bitbake/ A copy of BitBake is included within Poky for ease of use, and should usually match the current BitBake stable release from the BitBake project. Bitbake, a metadata interpreter, reads the Poky metadata and runs the tasks defined in the Poky metadata. Failures are usually from the metadata, not BitBake itself, so most users don't need to worry about BitBake. The bitbake/bin/ directory is placed into the PATH environment variable by the poky-init-build- env script. For more information on BitBake please see the BitBake project site at http://bitbake.berlios.de/ and the BitBake on- line manual at http://bitbake.berlios.de/manual/. 1.2. build/ This directory contains user configuration files and the output from Poky. 1.3. meta/ This directory contains the core metadata, a key part of Poky. Within this directory there are definitions of the machines, the Poky distribution and the packages that make up a given system. 1.4. meta-extras/ This directory is similar to meta/, and contains some extra metadata not included in standard Poky. These are disabled by default, and are not supported as part of Poky. 1.5. scripts/ This directory contains various integration scripts which implement extra functionality in the Poky environment, such as the QEMU scripts. This directory is appended to the PATH environment variable by the poky-init-build-env script. 1.6. sources/ While not part of a checkout, Poky will create this directory as part of any build. Any downloads are placed in this directory (as specified by the DL_DIR variable). This directory can be shared between Poky builds to save downloading files multiple times. SCM checkouts are also stored here as e.g. sources/svn/ , sources/cvs/ or sources/git/ and the sources directory may contain archives of checkouts for various revisions or dates. It's worth noting that BitBake creates .md5 stamp files for downloads. It uses these to mark downloads as complete as well as for checksum and access accounting purposes. If you add a file manually to the directory, you need to touch the corresponding .md5 file too. This location can be overridden by setting DL_DIR in local.conf . This directory can be shared between builds and even between machines via NFS, so downloads are only made once, speeding up builds. 1.7. poky-init-build-env This script is used to setup the Poky build environment. Sourcing this file in a shell makes changes to PATH and sets other core BitBake variables based on the current working directory. You need to use this before running Poky commands. Internally it uses scripts within the scripts/ directory to do the bulk of the work. 2. build/ - The Build Directory 2.1. build/conf/local.conf This file contains all the local user configuration of Poky. If there is no local.conf present, it is created from local.conf.sample. The local.conf file contains documentation on the various configuration options. Any variable set here overrides any variable set elsewhere within Poky unless that variable is hardcoded within Poky (e.g. by using '=' instead of '?='). Some variables are hardcoded for various reasons but these variables are relatively rare. Edit this file to set the MACHINE for which you want to build, which package types you wish to use (PACKAGE_CLASSES) or where downloaded files should go (DL_DIR). 2.2. build/tmp/ This is created by BitBake if it doesn't exist and is where all the Poky output is placed. To clean Poky and start a build from scratch (other than downloads), you can wipe this directory. The tmp/ directory has some important sub- components detailed below. 2.3. build/tmp/cache/ When BitBake parses the metadata it creates a cache file of the result which can be used when subsequently running commands. These are stored here on a per machine basis. 2.4. build/tmp/cross/ The cross compiler when generated is placed into this directory and those beneath it. 2.5. build/tmp/deploy/ Any 'end result' output from Poky is placed under here. 2.6. build/tmp/deploy/deb/ Any .deb packages emitted by Poky are placed here, sorted into feeds for different architecture types. 2.7. build/tmp/deploy/images/ Complete filesystem images are placed here. If you want to flash the resulting image from a build onto a device, look here for them. 2.8. build/tmp/deploy/ipk/ Any resulting .ipk packages emitted by Poky are placed here. 2.9. build/tmp/rootfs/ This is a temporary scratch area used when creating filesystem images. It is run under fakeroot and is not useful once that fakeroot session has ended as information is lost. It is left around since it is still useful in debugging image creation problems. 2.10. build/tmp/staging/ Any package needing to share output with other packages does so within staging. This means it contains any shared header files and any shared libraries amongst other data. It is subdivided by architecture so multiple builds can run within the one build directory. 2.11. build/tmp/stamps/ This is used by BitBake for accounting purposes to keep track of which tasks have been run and when. It is also subdivided by architecture. The files are empty and the important information is the filenames and timestamps. 2.12. build/tmp/work/ This directory contains various subdirectories for each architecture, and each package built by BitBake has its own work directory under the appropriate architecture subdirectory. All tasks are executed from this work directory. As an example, the source for a particular package will be unpacked, patched, configured and compiled all within its own work directory. It is worth considering the structure of a typical work directory. An example is the linux-rp kernel, version 2.6.20 r7 on the machine spitz built within Poky. For this package a work directory of tmp/work/spitz-poky- linux-gnueabi/linux-rp-2.6.20-r7/ , referred to as WORKDIR , is created. Within this directory, the source is unpacked to linux-2.6.20 and then patched by quilt (see Section 3.5.1). Within the linux-2.6.20 directory, standard Quilt directories linux-2.6.20/patches and linux- 2.6.20/.pc are created, and standard quilt commands can be used. There are other directories generated within WORKDIR. The most important is WORKDIR/temp/ which has log files for each task (log.do_*.pid) and the scripts BitBake runs for each task (run.do_*.pid). The WORKDIR/image/ directory is where make install places its output which is then split into subpackages within WORKDIR/install/. 3. meta/ - The Metadata As mentioned previously, this is the core of Poky. It has several important subdivisions: 3.1. meta/classes/ Contains the *.bbclass files. Class files are used to abstract common code allowing it to be reused by multiple packages. The base.bbclass file is inherited by every package. Examples of other important classes are autotools.bbclass that in theory allows any Autotool-enabled package to work with Poky with minimal effort, or kernel.bbclass that contains common code and functions for working with the linux kernel. Functions like image generation or packaging also have their specific class files (image.bbclass , rootfs_*.bbclass and package*.bbclass). 3.2. meta/conf/ This is the core set of configuration files which start from bitbake.conf and from which all other configuration files are included (see the includes at the end of the file, even local.conf is loaded from there!). While bitbake.conf sets up the defaults, these can often be overridden by user (local.conf), machine or distribution configuration files. 3.3. meta/conf/machine/ Contains all the machine configuration files. If you set MACHINE="spitz", the end result is Poky looking for a spitz.conf file in this directory. The includes directory contains various data common to multiple machines. If you want to add support for a new machine to Poky, this is the directory to look in. 3.4. meta/conf/distro/ Any distribution specific configuration is controlled from here. OpenEmbedded supports multiple distributions of which Poky is one. Poky only contains the Poky distribution so poky.conf is the main file here. This includes the versions and SRCDATES for applications which are configured here. An example of an alternative configuration is poky- bleeding.conf although this mainly inherits its configuration from Poky itself. 3.5. meta/packages/ Each application (package) Poky can build has an associated .bb file which are all stored under this directory. Poky finds them through the BBFILES variable which defaults to packages/*/*.bb. Adding a new piece of software to Poky consists of adding the appropriate .bb file. The .bb files from OpenEmbedded upstream are usually compatible although they are not supported. 3.6. meta/site/ Certain autoconf test results cannot be determined when cross compiling since it can't run tests on a live system. This directory therefore contains a list of cached results for various architectures which is passed to autoconf. Appendix 2. Reference: Bitbake Table of Contents 1. Parsing 2. Preferences and Providers 3. Dependencies 4. The Task List 5. Running a Task 6. Commandline 7. Fetchers Bitbake a program written in Python which interprets the metadata that makes up Poky. At some point, people wonder what actually happens when you type bitbake poky-image-sato. This section aims to give an overview of what happens behind the scenes from a BitBake perspective. It is worth noting that bitbake aims to be a generic "task" executor capable of handling complex dependency relationships. As such it has no real knowledge of what the tasks its executing actually do. It just considers a list of tasks with dependencies and handles metadata consisting of variables in a certain format which get passed to the tasks. 1. Parsing The first thing BitBake does is work out its configuration by looking for a file called bitbake.conf. Bitbake searches through the BBPATH environment variable looking for a conf/ directory containing a bitbake.conf file and adds the first bitbake.conf file found in BBPATH (similar to the PATH environment variable). For Poky, bitbake.conf is found in meta/conf/. In Poky, bitbake.conf lists other configuration files to include from a conf/ directory below the directories listed in BBPATH. In general the most important configuration file from a user's perspective is local.conf, which contains a users customized settings for Poky. Other notable configuration files are the distribution configuration file (set by the DISTRO variable) and the machine configuration file (set by the MACHINE variable). The DISTRO and MACHINE environment variables are both usually set in the local.conf file. Valid distribution configuration files are available in the meta/conf/distro/ directory and valid machine configuration files in the meta/conf/machine/ directory. Within the meta/conf/machine/include/ directory are various tune-*.inc configuration files which provide common "tuning" settings specific to and shared between particular architectures and machines. After the parsing of the configuration files some standard classes are included. In particular, base.bbclass is always included, as will any other classes specified in the configuration using the INHERIT variable. Class files are searched for in a classes subdirectory under the paths in BBPATH in the same way as configuration files. After the parsing of the configuration files is complete, the variable BBFILES is set, usually in local.conf, and defines the list of places to search for .bb files. By default this specifies the meta/packages/ directory within Poky, but other directories such as meta-extras/ can be included too. If multiple directories are specified a system referred to as "collections" is used to determine which files have priority. Bitbake parses each .bb file in BBFILES and stores the values of various variables. In summary, for each .bb file the configuration + base class of variables are set, followed by the data in the .bb file itself, followed by any inherit commands that .bb file might contain. Parsing .bb files is a time consuming process, so a cache is kept to speed up subsequent parsing. This cache is invalid if the timestamp of the .bb file itself has changed, or if the timestamps of any of the include, configuration or class files the .bb file depends on have changed. 2. Preferences and Providers Once all the .bb files have been parsed, BitBake will proceed to build "poky-image-sato" (or whatever was specified on the commandline) and looks for providers of that target. Once a provider is selected, BitBake resolves all the dependencies for the target. In the case of "poky-image-sato", it would lead to task-oh.bb and task- base.bb which in turn would lead to packages like Contacts, Dates, BusyBox and these in turn depend on glibc and the toolchain. Sometimes a target might have multiple providers and a common example is "virtual/kernel" that is provided by each kernel package. Each machine will often elect the best provider of its kernel with a line like the following in the machine configuration file: PREFERRED_PROVIDER_virtual/kernel = "linux-rp" The default PREFERRED_PROVIDER is the provider with the same name as the target. Understanding how providers are chosen is complicated by the fact multiple versions might be present. Bitbake defaults to the highest version of a provider by default. Version comparisons are made using the same method as Debian. The PREFERRED_VERSION variable can be used to specify a particular version (usually in the distro configuration) but the order can also be influenced by the DEFAULT_PREFERENCE variable. By default files have a preference of "0". Setting the DEFAULT_PREFERENCE to "-1" will make a package unlikely to be used unless it was explicitly referenced and "1" makes it likely the package will be used. PREFERRED_VERSION overrides any default preference. DEFAULT_PREFERENCE is often used to mark more experimental new versions of packages until they've undergone sufficient testing to be considered stable. The end result is that internally, BitBake has now built a list of providers for each target it needs in order of priority. 3. Dependencies Each target BitBake builds consists of multiple tasks (e.g. fetch, unpack, patch, configure, compile etc.). For best performance on multi-core systems, BitBake considers each task as an independent entity with a set of dependencies. There are many variables that are used to signify these dependencies and more information can be found found about these in the BitBake manual. At a basic level it is sufficient to know that BitBake uses the DEPENDS and RDEPENDS variables when calculating dependencies and descriptions of these variables are available through the links. 4. The Task List Based on the generated list of providers and the dependency information, BitBake can now calculate exactly which tasks it needs to run and in what order. The build now starts with BitBake forking off threads up to the limit set in the BB_NUMBER_THREADS variable as long there are tasks ready to run, i.e. tasks with all their dependencies met. As each task completes, a timestamp is written to the directory specified by the STAMPS variable (usually build/tmp/stamps/*/). On subsequent runs, BitBake looks at the STAMPS directory and will not rerun tasks its already completed unless a timestamp is found to be invalid. Currently, invalid timestamps are only considered on a per .bb file basis so if for example the configure stamp has a timestamp greater than the compile timestamp for a given target the compile task would rerun but this has no effect on other providers depending on that target. This could change or become configurable in future versions of BitBake. Some tasks are marked as "nostamp" tasks which means no timestamp file will be written and the task will always rerun. Once all the tasks have been completed BitBake exits. 5. Running a Task It's worth noting what BitBake does to run a task. A task can either be a shell task or a python task. For shell tasks, BitBake writes a shell script to ${WORKDIR}/temp/run.do_taskname.pid and then executes the script. The generated shell script contains all the exported variables, and the shell functions with all variables expanded. Output from the shell script is sent to the file ${WORKDIR}/temp/log.do_taskname.pid. Looking at the expanded shell functions in the run file and the output in the log files is a useful debugging technique. Python functions are executed internally to BitBake itself and logging goes to the controlling terminal. Future versions of BitBake will write the functions to files in a similar way to shell functions and logging will also go to the log files in a similar way. 6. Commandline To quote from "bitbake --help": Usage: bitbake [options] [package ...] Executes the specified task (default is 'build') for a given set of BitBake files. It expects that BBFILES is defined, which is a space separated list of files to be executed. BBFILES does support wildcards. Default BBFILES are the .bb files in the current directory. Options: --version show program's version number and exit -h, --help show this help message and exit -b BUILDFILE, --buildfile=BUILDFILE execute the task against this .bb file, rather than a package from BBFILES. -k, --continue continue as much as possible after an error. While the target that failed, and those that depend on it, cannot be remade, the other dependencies of these targets can be processed all the same. -f, --force force run of specified cmd, regardless of stamp status -i, --interactive drop into the interactive mode also called the BitBake shell. -c CMD, --cmd=CMD Specify task to execute. Note that this only executes the specified task for the providee and the packages it depends on, i.e. 'compile' does not implicitly call stage for the dependencies (IOW: use only if you know what you are doing). Depending on the base.bbclass a listtasks tasks is defined and will show available tasks -r FILE, --read=FILE read the specified file before bitbake.conf -v, --verbose output more chit-chat to the terminal -D, --debug Increase the debug level. You can specify this more than once. -n, --dry-run don't execute, just go through the motions -p, --parse-only quit after parsing the BB files (developers only) -d, --disable-psyco disable using the psyco just-in-time compiler (not recommended) -s, --show-versions show current and preferred versions of all packages -e, --environment show the global or per-package environment (this is what used to be bbread) -g, --graphviz emit the dependency trees of the specified packages in the dot syntax -I IGNORED_DOT_DEPS, --ignore-deps=IGNORED_DOT_DEPS Stop processing at the given list of dependencies when generating dependency graphs. This can help to make the graph more appealing -l DEBUG_DOMAINS, --log-domains=DEBUG_DOMAINS Show debug logging for the specified logging domains -P, --profile profile the command and print a report 7. Fetchers As well as the containing the parsing and task/dependency handling code, bitbake also contains a set of "fetcher" modules which allow fetching of source code from various types of sources. Example sources might be from disk with the metadata, from websites, from remote shell accounts or from SCM systems like cvs/subversion/git. The fetchers are usually triggered by entries in SRC_URI. Information about the options and formats of entries for specific fetchers can be found in the BitBake manual. One useful feature for certain SCM fetchers is the ability to "auto-update" when the upstream SCM changes version. Since this requires certain functionality from the SCM only certain systems support it, currently Subversion, Bazaar and to a limited extent, Git. It works using the SRCREV variable. See the developing with an external SCM based project section for more information. Appendix 3. Reference: Classes Table of Contents 1. The base class - base.bbclass 2. Autotooled Packages - autotools.bbclass 3. Alternatives - update-alternatives.bbclass 4. Initscripts - update-rc.d.bbclass 5. Binary config scripts - binconfig.bbclass 6. Debian renaming - debian.bbclass 7. Pkg-config - pkgconfig.bbclass 8. Distribution of sources - src_distribute_local.bbclass 9. Perl modules - cpan.bbclass 10. Python extensions - distutils.bbclass 11. Developer Shell - devshell.bbclass 12. Packaging - package*.bbclass 13. Building kernels - kernel.bbclass 14. Creating images - image.bbclass and rootfs*.bbclass 15. Host System sanity checks - sanity.bbclass 16. Generated output quality assurance checks - insane.bbclass 17. Autotools configuration data cache - siteinfo.bbclass 18. Other Classes Class files are used to abstract common functionality and share it amongst multiple .bb files. Any metadata usually found in a .bb file can also be placed in a class file. Class files are identified by the extension .bbclass and are usually placed in a classes/ directory beneath the meta/ directory or the build/ directory in the same way as .conf files in the conf directory. Class files are searched for in BBPATH in the same was as .conf files too. In most cases inheriting the class is enough to enable its features, although for some classes you may need to set variables and/or override some of the default behaviour. 1. The base class - base.bbclass The base class is special in that every .bb file inherits it automatically. It contains definitions of standard basic tasks such as fetching, unpacking, configuring (empty by default), compiling (runs any Makefile present), installing (empty by default) and packaging (empty by default). These are often overridden or extended by other classes such as autotools.bbclass or package.bbclass. The class contains some commonly some commonly used functions such as oe_libinstall and oe_runmake. The end of the class file has a list of standard mirrors for software projects for use by the fetcher code. 2. Autotooled Packages - autotools.bbclass Autotools (autoconf, automake, libtool) brings standardisation and this class aims to define a set of tasks (configure, compile etc.) that will work for all autotooled packages. It should usualy be enough to define a few standard variables as documented in the simple autotools example section and then simply "inherit autotools". This class can also work with software that emulates autotools. Its useful to have some idea of the tasks this class defines work and what they do behind the scenes. 'do_configure' regenearates the configure script and then launches it with a standard set of arguments used during cross-compilation. Additional parameters can be passed to configure through the EXTRA_OECONF variable. 'do_compile' runs make with arguments specifying the compiler and linker. Additional arguments can be passed through the EXTRA_OEMAKE variable. 'do_install' runs make install passing a DESTDIR option taking its value from the standard DESTDIR variable. By default the class does not stage headers and libraries so the recipe author needs to add their own do_stage() task. For typical recipes the following example code will usually be enough: do_stage() { autotools_stage_all } 3. Alternatives - update-alternatives.bbclass Several programs can fulfill the same or similar function and they can be installed with the same name. For example the ar command is available from the "busybox", "binutils" and "elfutils" packages. This class handles the renaming of the binaries so multiple packages can be installed which would otherwise conflict and yet the ar command still works regardless of which are installed or subsequently removed. It renames the conflicting binary in each package and symlinks the highest priority binary during installation or removal of packages. Four variables control this class: ALTERNATIVE_NAME Name of binary which will be replaced (ar in this example) ALTERNATIVE_LINK Path to resulting binary ("/bin/ar" in this example) ALTERNATIVE_PATH Path to real binary ("/usr/bin/ar.binutils" in this example) ALTERNATIVE_PRIORITY Priority of binary, the version with the most features should have the highest priority 4. Initscripts - update-rc.d.bbclass This class uses update-rc.d to safely install an initscript on behalf of the package. Details such as making sure the initscript is stopped before a package is removed and started when the package is installed are taken care of. Three variables control this class, INITSCRIPT_PACKAGES, INITSCRIPT_NAME and INITSCRIPT_PARAMS. See the links for details. 5. Binary config scripts - binconfig.bbclass Before pkg-config became widespread, libraries shipped shell scripts to give information about the libraries and include paths needed to build software (usually named 'LIBNAME-config'). This class assists any recipe using such scripts. During staging Bitbake installs such scripts into the staging/ directory. It also changes all paths to point into the staging/ directory so all builds which use the script will use the correct directories for the cross compiling layout. 6. Debian renaming - debian.bbclass This class renames packages so that they follow the Debian naming policy, i.e. 'glibc' becomes 'libc6' and 'glibc-devel' becomes 'libc6-dev'. 7. Pkg-config - pkgconfig.bbclass Pkg-config brought standardisation and this class aims to make its integration smooth for all libraries which make use of it. During staging Bitbake installs pkg-config data into the staging/ directory. By making use of sysroot functionality within pkgconfig this class no longer has to manipulate the files. 8. Distribution of sources - src_distribute_local.bbclass Many software licenses require providing the sources for compiled binaries. To simplify this process two classes were created: src_distribute.bbclass and src_distribute_local.bbclass. Result of their work are tmp/deploy/source/ subdirs with sources sorted by LICENSE field. If recipe lists few licenses (or has entries like "Bitstream Vera") source archive is put in each license dir. Src_distribute_local class has three modes of operating: copy - copies the files to the distribute dir symlink - symlinks the files to the distribute dir move+symlink - moves the files into distribute dir, and symlinks them back 9. Perl modules - cpan.bbclass Recipes for Perl modules are simple - usually needs only pointing to source archive and inheriting of proper bbclass. Building is split into two methods dependly on method used by module authors. Modules which use old Makefile.PL based build system require using of cpan.bbclass in their recipes. Modules which use Build.PL based build system require using of cpan_build.bbclass in their recipes. 10. Python extensions - distutils.bbclass Recipes for Python extensions are simple - usually needs only pointing to source archive and inheriting of proper bbclass. Building is split into two methods dependly on method used by module authors. Extensions which use autotools based build system require using of autotools and distutils-base bbclasses in their recipes. Extensions which use distutils build system require using of distutils.bbclass in their recipes. 11. Developer Shell - devshell.bbclass This class adds the devshell task. Its usually up to distribution policy to include this class (Poky does). See the developing with 'devshell' section for more information about using devshell. 12. Packaging - package*.bbclass The packaging classes add support for generating packages from the output from builds. The core generic functionality is in package.bbclass, code specific to particular package types is contained in various sub classes such as package_deb.bbclass and package_ipk.bbclass. Most users will want one or more of these classes and this is controlled by the PACKAGE_CLASSES variable. The first class listed in this variable will be used for image generation. Since images are generated from packages a packaging class is needed to enable image generation. 13. Building kernels - kernel.bbclass This class handle building of Linux kernels and the class contains code to know how to build both 2.4 and 2.6 kernel trees. All needed headers are staged into STAGING_KERNEL_DIR directory to allow building of out-of-tree modules using module.bbclass. The means that each kerel module built is packaged separately and inter-modules dependencies are created by parsing the modinfo output. If all modules are required then installing "kernel-modules" package will install all packages with modules and various other kernel packages such as "kernel-vmlinux" are also generated. Various other classes are used by the kernel and module classes internally including kernel- arch.bbclass, module_strip.bbclass, module-base.bbclass and linux-kernel-base.bbclass. 14. Creating images - image.bbclass and rootfs*.bbclass Those classes add support for creating images in many formats. First the rootfs is created from packages by one of the rootfs_*.bbclass files (depending on package format used) and then image is created. The IMAGE_FSTYPES variable controls which types of image to generate. The list of packages to install into the image is controlled by the IMAGE_INSTALL variable. 15. Host System sanity checks - sanity.bbclass This class checks prerequisite software is present to try and identify and notify the user of problems which will affect their build. It also performs basic checks of the users configuration from local.conf to prevent common mistakes and resulting build failures. Its usually up to distribution policy to include this class (Poky does). 16. Generated output quality assurance checks - insane.bbclass This class adds a step to package generation which sanity checks the packages generated by Poky. There are an ever increasing range of checks this makes, checking for common problems which break builds/packages/images, see the bbclass file for more information. Its usually up to distribution policy to include this class (Poky doesn't at the time of writing but plans to soon). 17. Autotools configuration data cache - siteinfo.bbclass Autotools can require tests which have to execute on the target hardware. Since this isn't possible in general when cross compiling, siteinfo is used to provide cached test results so these tests can be skipped over but the correct values used. The meta/site directory contains test results sorted into different categories like architecture, endianess and the libc used. Siteinfo provides a list of files containing data relevant to the current build in the CONFIG_SITE variable which autotools will automatically pick up. The class also provides variables like SITEINFO_ENDIANESS and SITEINFO_BITS which can be used elsewhere in the metadata. This class is included from base.bbclass and is hence always active. 18. Other Classes Only the most useful/important classes are covered here but there are others, see the meta/classes directory for the rest. Appendix 4. Reference: Images Poky has several standard images covering most people's standard needs. A full list of image targets can be found by looking in the meta/packages/images/ directory. The standard images are listed below along with details of what they contain: poky-image-minimal - A small image, just enough to allow a device to boot poky-image-base - console only image with full support of target device hardware poky-image-core - X11 image with simple apps like terminal, editor and file manager poky-image-sato - X11 image with Sato theme and Pimlico applications. Also contains terminal, editor and file manager. poky-image-sdk - X11 image like poky-image-sato but also include native toolchain and libraries needed to build applications on the device itself. Also includes testing and profiling tools and debug symbols. meta-toolchain - This generates a tarball containing a standalone toolchain which can be used externally to Poky. It is self contained and unpacks to the /usr/local/poky directory. It also contains a copy of QEMU and the scripts neccessary to run poky QEMU images. meta-toolchain-sdk - This includes everything in meta-toolchain but also includes development headers and libraries forming a complete standalone SDK. See the Developing using the Poky SDK and Developing using the Anjuta Plugin sections for more information. Appendix 5. Reference: Features Table of Contents 1. Distro 2. Machine 3. Reference: Images 'Features' provide a mechanism for working out which packages should be included in the generated images. Distributions can select which features they want to support through the DISTRO_FEATURES variable which is set in the distribution configuration file (poky.conf for Poky). Machine features are set in the MACHINE_FEATURES variable which is set in the machine configuration file and specifies which hardware features a given machine has. These two variables are combined to work out which kernel modules, utilities and other packages to include. A given distribution can support a selected subset of features so some machine features might not be included if the distribution itself doesn't support them. 1. Distro The items below are valid options for DISTRO_FEATURES. alsa - ALSA support will be included (OSS compatibility kernel modules will be installed if available) bluetooth - Include bluetooth support (integrated BT only) ext2 - Include tools for supporting for devices with internal HDD/Microdrive for storing files (instead of Flash only devices) irda - Include Irda support keyboard - Include keyboard support (e.g. keymaps will be loaded during boot). pci - Include PCI bus support pcmcia - Include PCMCIA/CompactFlash support usbgadget - USB Gadget Device support (for USB networking/serial/storage) usbhost - USB Host support (allows to connect external keyboard, mouse, storage, network etc) wifi - WiFi support (integrated only) cramfs - CramFS support ipsec - IPSec support ipv6 - IPv6 support nfs - NFS client support (for mounting NFS exports on device) ppp - PPP dialup support smbfs - SMB networks client support (for mounting Samba/Microsoft Windows shares on device) 2. Machine The items below are valid options for MACHINE_FEATURES. acpi - Hardware has ACPI (x86/x86_64 only) alsa - Hardware has ALSA audio drivers apm - Hardware uses APM (or APM emulation) bluetooth - Hardware has integrated BT ext2 - Hardware HDD or Microdrive irda - Hardware has Irda support keyboard - Hardware has a keyboard pci - Hardware has a PCI bus pcmcia - Hardware has PCMCIA or CompactFlash sockets screen - Hardware has a screen serial - Hardware has serial support (usually RS232) touchscreen - Hardware has a touchscreen usbgadget - Hardware is USB gadget device capable usbhost - Hardware is USB Host capable wifi - Hardware has integrated WiFi 3. Reference: Images The contents of images generated by Poky can be controlled by the IMAGE_FEATURES variable in local.conf. Through this you can add several different predefined packages such as development utilities or packages with debug information needed to investigate application problems or profile applications. Current list of IMAGE_FEATURES contains: apps-console-core - Core console applications such as ssh daemon, avahi daemon, portmap (for mounting NFS shares) x11-base - X11 server + minimal desktop x11-sato - OpenedHand Sato environment apps-x11-core - Core X11 applications such as an X Terminal, file manager, file editor apps-x11-games - A set of X11 games apps-x11-pimlico - OpenedHand Pimlico application suite tools-sdk - A full SDK which runs on device tools-debug - Debugging tools such as strace and gdb tools-profile - Profiling tools such as oprofile, exmap and LTTng tools-testapps - Device testing tools (e.g. touchscreen debugging) nfs-server - NFS server (exports / over NFS to everybody) dev-pkgs - Development packages (headers and extra library links) for all packages installed in a given image dbg-pkgs - Debug packages for all packages installed in a given image Appendix 6. Reference: Variables Glossary Table of Contents Glossary This section lists common variables used in Poky and gives an overview of their function and contents. Glossary A B C D E F H I K L M P R S T W A AUTHOR E-mail address to contact original author(s) - to send patches, forward bugs... AUTOREV Use current (newest) source revision - used with SRCREV variable. B BB_NUMBER_THREADS Number of BitBake threads BBFILES List of recipes used by BitBake to build software BBINCLUDELOGS Variable which controls how BitBake displays logs on build failure. C CFLAGS Flags passed to C compiler for the target system. Evaluates to the same as TARGET_CFLAGS. COMPATIBLE_MACHINES A regular expression which evalutates to match the machines the recipe works with. It stops recipes being run on machines they're incompatible with which is partciuarly useful with kernels. It also helps to to increase parsing speed as if its found the current machine is not compatible, further parsing of the recipe is skipped. CONFIG_SITE Contains a list of files which containing autoconf test results relevant to the current build. This variable is used by the autotools utilities when running configure. CVS_TARBALL_STASH Location to search for pre-generated tarballs when fetching from remote SCM repositories (CVS/SVN/GIT) D D Destination directory DEBUG_BUILD Build packages with debugging information. This influences the value SELECTED_OPTIMIZATION takes. DEBUG_OPTIMIZATION The options to pass in TARGET_CFLAGS and CFLAGS when compiling a system for debugging. This defaults to "-O -fno-omit- frame-pointer -g". DEFAULT_PREFERENCE Priority of recipe DEPENDS A list of build time dependencies for a given recipe. These indicate recipes that must have staged before this recipe can configure. DESCRIPTION Package description used by package managers DESTDIR Destination directory DISTRO Short name of distribution DISTRO_EXTRA_RDEPENDS List of packages required by distribution. DISTRO_EXTRA_RRECOMMENDS List of packages which extend usability of image. Those packages will be automatically installed but can be removed by user. DISTRO_FEATURES Features of the distribution. DISTRO_NAME Long name of distribution DISTRO_VERSION Version of distribution DL_DIR Directory where all fetched sources will be stored E ENABLE_BINARY_LOCALE_GENERATION Variable which control which locales for glibc are to be generated during build (useful if target device has 64M RAM or less) EXTRA_OECONF Additional 'configure' script options EXTRA_OEMAKE Additional GNU make options F FILES list of directories/files which will be placed in packages FULL_OPTIMIZATION The options to pass in TARGET_CFLAGS and CFLAGS when compiling an optimised system. This defaults to "-fexpensive- optimizations -fomit-frame-pointer -frename-registers -O2". H HOMEPAGE Website where more info about package can be found I IMAGE_FEATURES List of features present in resulting images IMAGE_FSTYPES Formats of rootfs images which we want to have created IMAGE_INSTALL List of packages used to build image INHIBIT_PACKAGE_STRIP This variable causes the build to not strip binaries in resulting packages. INHERIT This variable causes the named class to be inherited at this point during parsing. Its only valid in configuration files. INITSCRIPT_PACKAGES Scope: Used in recipes when using update-rc.d.bbclass. Optional, defaults to PN. A list of the packages which contain initscripts. If multiple packages are specified you need to append the package name to the other INITSCRIPT_* as an override. INITSCRIPT_NAME Scope: Used in recipes when using update-rc.d.bbclass. Mandatory. The filename of the initscript (as installed to ${etcdir}/init.d). INITSCRIPT_PARAMS Scope: Used in recipes when using update-rc.d.bbclass. Mandatory. Specifies the options to pass to update-rc.d. An example is "start 99 5 2 . stop 20 0 1 6 ." which gives the script a runlevel of 99, starts the script in initlevels 2 and 5 and stops it in levels 0, 1 and 6. K KERNEL_IMAGETYPE The type of kernel to build for a device, usually set by the machine configuration files and defaults to "zImage". This is used when building the kernel and is passed to "make" as the target to build. L LICENSE List of package source licenses. M MACHINE Target device MACHINE_ESSENTIAL_RDEPENDS List of packages required to boot device MACHINE_ESSENTIAL_RRECOOMENDS List of packages required to boot device (usually additional kernel modules) MACHINE_EXTRA_RDEPENDS List of packages required to use device MACHINE_EXTRA_RRECOMMNEDS List of packages useful to use device (for example additional kernel modules) MACHINE_FEATURES List of device features - defined in machine features section MAINTAINER E-mail of distribution maintainer P PACKAGE_ARCH Architecture of resulting package PACKAGE_CLASSES List of resulting packages formats PACKAGE_EXTRA_ARCHS List of architectures compatible with device CPU. Usable when build is done for few different devices with misc processors (like XScale and ARM926-EJS) PACKAGES List of packages to be created from recipe. The default value is "${PN}-dbg ${PN} ${PN}-doc ${PN}-dev" PN Name of package. PR Revision of package. PV Version of package. The default value is "1.0" PE Epoch of the package. The default value is "1". The field is used to make upgrades possible when the versioning scheme changes in some backwards incompatible way. PREFERRED_PROVIDER If multiple recipes provide an item, this variable determines which one should be given preference. It should be set to the "$PN" of the recipe to be preferred. PREFERRED_VERSION If there are multiple versions of recipe available, this variable determines which one should be given preference. It should be set to the "$PV" of the recipe to be preferred. POKYLIBC Libc implementation selector - glibc or uclibc can be selected. POKYMODE Toolchain selector. It can be external toolchain built from Poky or few supported combinations of upstream GCC or CodeSourcery Labs toolchain. R RCONFLICTS List of packages which which conflict with this one. Package will not be installed if they will not be removed first. RDEPENDS A list of run-time dependencies for a package. These packages need to be installed alongside the package it applies to so the package will run correctly, an example is a perl script which would rdepend on perl. Since this variable applies to output packages there would usually be an override attached to this variable like RDEPENDS_${PN}-dev. Names in this field should be as they are in PACKAGES namespave before any renaming of the output package by classes like debian.bbclass. ROOT_FLASH_SIZE Size of rootfs in megabytes RRECOMMENDS List of packages which extend usability of package. Those packages will be automatically installed but can be removed by user. RREPLACES List of packages which are replaced with this one. S S Path to unpacked sources (by default: "${WORKDIR}/${PN}- ${PV}") SECTION Section where package should be put - used by package managers SELECTED_OPTIMIZATION The variable takes the value of FULL_OPTIMIZATION unless DEBUG_BUILD = "1" in which case DEBUG_OPTIMIZATION is used. SERIAL_CONSOLE Speed and device for serial port used to attach serial console. This is given to kernel as "console" param and after boot getty is started on that port so remote login is possible. SHELLCMDS A list of commands to run within the a shell, used by TERMCMDRUN. It defaults to SHELLRCCMD. SHELLRCCMD How to launch a shell, defaults to bash. SITEINFO_ENDIANESS Contains "le" for little-endian or "be" for big-endian depending on the endian byte order of the target system. SITEINFO_BITS Contains "32" or "64" depending on the number of bits for the CPU of the target system. SRC_URI List of source files (local or remote ones) SRC_URI_OVERRIDES_PACKAGE_ARCH By default there is code which automatically detects whether SRC_URI contains files which are machine specific and if this is the case it automatically changes PACKAGE_ARCH. Setting this variable to "0" disables that behaviour. SRCDATE Date of source code used to build package (if it was fetched from SCM). SRCREV Revision of source code used to build package (Subversion, GIT, Bazaar only). STAGING_KERNEL_DIR Directory with kernel headers required to build out-of-tree modules. STAMPS Directory (usually TMPDIR/stamps) with timestamps of executed tasks. T TARGET_ARCH The architecture of the device we're building for. A number of values are possible but Poky primarily supports "arm" and "i586". TARGET_CFLAGS Flags passed to C compiler for the target system. Evaluates to the same as CFLAGS. TARGET_FPU Method of handling FPU code. For FPU-less targets (most of ARM cpus) it has to be set to "soft" otherwise kernel emulation will get used which will result in performance penalty. TARGET_OS Type of target operating system. Can be "linux" for glibc based system, "linux-uclibc" for uClibc. For ARM/EABI targets there are also "linux-gnueabi" and "linux-uclibc-gnueabi" values possible. TERMCMD This command is used by bitbake to lauch a terminal window with a shell. The shell is unspecified so the user's default shell is used. By default it is set to gnome-terminal but it can be any X11 terminal application or terminal multiplexers like screen. TERMCMDRUN This command is similar to TERMCMD however instead of the users shell it runs the command specified by the SHELLCMDS variable. W WORKDIR Path to directory in tmp/work/ where package will be built. Appendix 7. Reference: Variable Locality (Distro, Machine, Recipe etc.) Table of Contents 1. Distro Configuration 2. Machine Configuration 3. Local Configuration (local.conf) 4. Recipe Variables - Required 5. Recipe Variables - Dependencies 6. Recipe Variables - Paths 7. Recipe Variables - Extra Build Information Whilst most variables can be used in almost any context (.conf, .bbclass, .inc or .bb file), variables are often associated with a particular locality/context. This section describes some common associations. 1. Distro Configuration DISTRO DISTRO_NAME DISTRO_VERSION MAINTAINER PACKAGE_CLASSES TARGET_OS TARGET_FPU POKYMODE POKYLIBC 2. Machine Configuration TARGET_ARCH SERIAL_CONSOLE PACKAGE_EXTRA_ARCHS IMAGE_FSTYPES ROOT_FLASH_SIZE MACHINE_FEATURES MACHINE_EXTRA_RDEPENDS MACHINE_EXTRA_RRECOMMENDS MACHINE_ESSENTIAL_RDEPENDS MACHINE_ESSENTIAL_RRECOMMENDS 3. Local Configuration (local.conf) DISTRO MACHINE DL_DIR BBFILES IMAGE_FEATURES PACKAGE_CLASSES BB_NUMBER_THREADS BBINCLUDELOGS CVS_TARBALL_STASH ENABLE_BINARY_LOCALE_GENERATION 4. Recipe Variables - Required DESCRIPTION LICENSE SECTION HOMEPAGE AUTHOR SRC_URI 5. Recipe Variables - Dependencies DEPENDS RDEPENDS RRECOMMENDS RCONFLICTS RREPLACES 6. Recipe Variables - Paths WORKDIR S FILES 7. Recipe Variables - Extra Build Information EXTRA_OECONF EXTRA_OEMAKE PACKAGES DEFAULT_PREFERENCE Appendix 8. FAQ 8.1. How does Poky differ from OpenEmbedded? 8.2. How can you claim Poky is stable? 8.3. How do I get support for my board added to Poky? 8.4. Are there any products running poky ? 8.5. What is the Poky output ? 8.6. How do I add my package to Poky? 8.7. Do I have to reflash my entire board with a new poky image when recompiling a package? 8.8. What is GNOME Mobile? What's the difference between GNOME Mobile and GNOME? 8.9. How do I make Poky work in RHEL/CentOS? 8.10. I see lots of 404 responses for files on http://folks.o-hand.com/~richard/poky/sources/*. Is something wrong? 8.11. I have a machine specific data in a package for one machine only but the package is being marked as machine specific in all cases, how do I stop it? 8.1. How does Poky differ from OpenEmbedded? Poky is a derivative of OpenEmbedded, a stable, smaller subset focused on the GNOME Mobile environment. Development in Poky is closely tied to OpenEmbedded with features being merged regularly between the two for mutual benefit. 8.2. How can you claim Poky is stable? There are three areas that help with stability; We keep Poky small and focused - around 650 packages compared to over 5000 for full OE We only support hardware that we have access to for testing We have a Buildbot which provides continuous build and integration tests 8.3. How do I get support for my board added to Poky? There are two main ways to get a board supported in Poky; Send us the board if we don't have it yet Send us bitbake recipes if you have them (see the Poky handbook to find out how to create recipes) Usually if it's not a completely exotic board then adding support in Poky should be fairly straightforward. 8.4. Are there any products running poky ? The Vernier Labquest is using Poky (for more about the Labquest see the case study at OpenedHand). There are a number of pre- production devices using Poky and we will announce those as soon as they are released. 8.5. What is the Poky output ? The output of a Poky build will depend on how it was started, as the same set of recipes can be used to output various formats. Usually the output is a flashable image ready for the target device. 8.6. How do I add my package to Poky? To add a package you need to create a bitbake recipe - see the Poky handbook to find out how to create a recipe. 8.7. Do I have to reflash my entire board with a new poky image when recompiling a package? Poky can build packages in various formats, ipkg, Debian package, or RPM. The package can then be upgraded using the package tools on the device, much like on a desktop distribution like Ubuntu or Fedora. 8.8. What is GNOME Mobile? What's the difference between GNOME Mobile and GNOME? GNOME Mobile is a subset of the GNOME platform targeted at mobile and embedded devices. The the main difference between GNOME Mobile and standard GNOME is that desktop-orientated libraries have been removed, along with deprecated libraries, creating a much smaller footprint. 8.9. How do I make Poky work in RHEL/CentOS? To get Poky working under RHEL/CentOS 5.1 you need to first install some required packages. The standard CentOS packages needed are: "Development tools" (selected during installation) texi2html compat-gcc-34 On top of those the following external packages are needed: python-sqlite2 from DAG repository help2man from Karan repository Once these packages are installed Poky will be able to build standard images however there may be a problem with QEMU segfaulting. You can either disable the generation of binary locales by setting ENABLE_BINARY_LOCALE_GENERATION to "0" or remove the linux- 2.6-execshield.patch from the kernel and rebuild it since its that patch which causes the problems with QEMU. 8.10. I see lots of 404 responses for files on http://folks.o- hand.com/~richard/poky/sources/*. Is something wrong? Appendix 9. Contributing to Poky Table of Contents 1. Introduction 2. Bugtracker 3. Mailing list 4. IRC 5. Links 1. Introduction We're happy for people to experiment with Poky and there are a number of places to find help if you run into difficulties or find bugs. To find out how to download source code see the Obtaining Poky section of the Introduction. 2. Bugtracker Problems with Poky should be reported in the bug tracker. 3. Mailing list To subscribe to the mailing list send mail to: poky+subscribe <at> openedhand <dot> com Then follow the simple instructions in subsequent reply. Archives are available here. 4. IRC Nothing is wrong, Poky will check any configured source mirrors before downloading from the upstream sources. It does this searching for both source archives and pre-checked out versions of SCM managed software. This is so in large installations, it can reduce load on the SCM servers themselves. The address above is one of the default mirrors configured into standard Poky so if an upstream source disappears, we can place sources there so builds continue to work. 8.11. I have a machine specific data in a package for one machine only but the package is being marked as machine specific in all cases, how do I stop it? Set SRC_URI_OVERRIDES_PACKAGE_ARCH = "0" in the .bb file but make sure the package is manually marked as machine specific in the case that needs it. The code which handles SRC_URI_OVERRIDES_PACKAGE_ARCH is in base.bbclass. Join #poky on freenode. 5. Links The Poky website OpenedHand - The company behind Poky. OpenEmbedded - The upstream generic embedded distribution Poky derives from (and contributes to). Bitbake - The tool used to process Poky metadata. Bitbake User Manual Pimlico - A suite of lightweight Personal Information Management (PIM) applications designed primarily for handheld and mobile devices. QEMU - An open source machine emulator and virtualizer. Appendix 10. OpenedHand Contact Information OpenedHand Ltd Unit R, Homesdale Business Center 216-218 Homesdale Rd Bromley, BR1 2QZ England +44 (0) 208 819 6559
[email protected] Index