Vous êtes sur la page 1sur 118

Conception dun systme

embarqu pour la
supervision des ateliers
Projet de Fin dEtude
Raliser par :
YOUSSEF FARES
Encadrer par :
Mr. Laurent Laffont La socit TEMIS
Mr. Hamdi Abdelaziz Lcole national des ingnieurs de
Sousse
2008
Youssef Fares
Lecole national des ingnieurs de Sousse
07/06/2008
ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES
Table de matire 2
ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES
Table de matire 3
Remerciement
Avant dentamer ce rapport de projet de fin dtudes, je tenais exprimer mon
sincre gratitude envers tous ceux qui mont aid ou ont particip au bon
droulement de ce projet. Je tenais remercier :
- Toute ma famille qui ma t toujours la garante dune existence paisible et
dun avenir radieux, mon pre, ma mre, mon frre Idris mes surs Marieme
et Samia.
- Tous ceux qui sont toujours dans mes penses.
- 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 socit TEMIS qui ma accueilli. Je devais remercier Mr. Laurent
Laffont pour sa gnrosit, sa comprhension et son aide inestimable et Mr.
Laurent Terrier le directeur de lentreprise. Je suis reconnaissant galement
M. Hamdi Abdelaziz, mon encadreur sans oublier tout mes professeurs,
dont Jexprimons mes sentiments de gratitude tous mes professeurs et
tous ceux qui mont aid ou encadr pour mavoir transmis leur savoir et leur
savoir faire dans les meilleures conditions possibles.
ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES
Table de matire 4
Table de matire
Table de matire................................................................................................................................................ 4
Table de figures ................................................................................................................................................. 7
Table des Images ............................................................................................................................................... 8
Table de tableaux .............................................................................................................................................. 8
Introduction ...................................................................................................................................................... 9
Section 1 Prsentation..................................................................................................................................... 10
Chapitre 1 Prsentation de TEMIS et son produit IGM50..................................................................................... 10
1 Prsentation de TEMIS................................................................................................................................. 10
2 Le produit IGM50......................................................................................................................................... 10
Chapitre 2 Le systme IGM50 ............................................................................................................................. 11
1 Principe de fonctionnement ......................................................................................................................... 11
2 Le terminale IGM50..................................................................................................................................... 13
Section 2 Prsentation et dfinition des besoins............................................................................................... 15
chapitre 1. Le concept IGM2.O : Ide et Objectifs .......................................................................................... 15
1 Lide de projet IGM2.0................................................................................................................................ 15
2 Lobjectifs de IGM2.0 ................................................................................................................................... 15
2.1 Objectifs............................................................................................................................................ 15
2.2 Description de concept IGM2.0.......................................................................................................... 16
chapitre 2. Prsentation de terminale IGM2.0............................................................................................... 18
1 Prsentation ................................................................................................................................................ 18
2 IGM2.0 est un systme embarqu................................................................................................................ 19
2.1. Caractristiques de systmes embarqus..................................................................................... 19
Faible cot........................................................................................................................................... 19
Faible consommation .......................................................................................................................... 19
Faible encombrement et faible poids................................................................................................... 19
Fonctionnement en Temps Rel (Rponse de temps) .......................................................................... 19
Environnement.................................................................................................................................... 20
2.2. Architecture gnrale de IGM2.0................................................................................................. 20
Section 3 Outils de dveloppement.................................................................................................................. 22
1 Introduction................................................................................................................................................. 22
Chapitre 1 Les environnements de dveloppement ............................................................................................ 22
1 Dfinitions ................................................................................................................................................... 22
ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES
Table de matire 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 Lenvironnement dmulation............................................................................... 27
2.2 SVN un logiciel de gestion de versions.............................................................................................. 28
2.3 NFS.................................................................................................................................................... 28
Section 4 Solutions techniques......................................................................................................................... 29
chapitre 1. Linux notre systme dexploitation embarqu............................................................................. 29
1 Pour quoi un systme dexploitation............................................................................................................ 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 dveloppement disponibles ........................................................ 30
2.4 Plein d'applications............................................................................................................................ 30
2.5 Support de rseau ............................................................................................................................. 30
2.6 La multitude des architecture support ............................................................................................. 30
2.7 Le march.......................................................................................................................................... 31
Chapitre 2 Linux un systme dexploitation pour lembarqu, comment ? .......................................................... 32
1 Introduction................................................................................................................................................. 32
2 Architecture de linux.................................................................................................................................... 32
2.1 Chargeur de dmarrage ou le bootloader .......................................................................................... 33
2.2 Noyau................................................................................................................................................ 33
2.3 Pilotes de priphrique...................................................................................................................... 34
2.4 Systme de fichiers............................................................................................................................ 34
2.5 Bibliothques (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 matire 6
3.1 Loptimisation de systme de fichier.................................................................................................. 35
3.2 Suppression du swapping .................................................................................................................. 36
3.3 Optimisation de noyau ...................................................................................................................... 36
chapitre 2. Les applications et les paquets ncessaires .................................................................................. 38
1 Introduction................................................................................................................................................. 38
2 Les applications............................................................................................................................................ 38
2.1 BusyBox............................................................................................................................................. 38
2.2 TinyLogin........................................................................................................................................... 38
2.3 Temix webkit ................................................................................................................................... 39
Dfinitions........................................................................................................................................... 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 libration-fonts.................................................................................................................................. 40
3.6 Xinit................................................................................................................................................... 40
3.7 Netbase............................................................................................................................................. 40
3.8 Udev.................................................................................................................................................. 40
Section 5 Dveloppement ................................................................................................................................ 41
1 Introduction................................................................................................................................................. 41
Chapitre 1 Construction de linux et les applications embarqus.......................................................................... 41
1 Poky, Comment utiliser ?.............................................................................................................................. 41
1.1 Installation des paquets ncessaires .................................................................................................. 41
1.2 Tlchargement de Poky ................................................................................................................... 42
1.3 Compiler et excuter 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 rseaux........................................................................................................ 46
1 Programmation web .................................................................................................................................... 46
1.1 Le Dmo web- igm2.0........................................................................................................................ 46
1.2 JavaScript et les raccourcis des boutons............................................................................................. 47
1.3 Ajax, rcuprer les valeurs des capteurs ............................................................................................ 47
2 Programmation rseaux............................................................................................................................... 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 tlcharger le fichier de systme 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 dfini.0
Table de figures
Figure 1-1 principe de fonctionnement dIGM5O........................................................................................................................................................ 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 Systme Embarqu............................................................................................................................................................. 20
Figure 3-1 la compilation crois..................................................................................................................................................................................... 23
Figure 3-2 Sato Desktop - Une capture d'cran partir d'un ordinateur excutant Poky built image .................................................................... 25
Figure 4-1 Le dveloppement des OSs Embarqus, 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 dmarrage 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 dvaluation AT91SAM9260EK ........................................................................................................................................................ 26
Image 5-1l'image de bureau de poky sato.................................................................................................................................................................... 43
Image 5-4 un dsigne imagin dIGM2.0....................................................................................................................................................................... 46
Image 5-2 menu Arrts dIGM2.0 .................................................................................................................................................................................. 46
Image 5-3 menu principale dIGM2.0............................................................................................................................................................................ 46
Image 5-5 La position de jumper 7 sur la carte ............................................................................................................................................................ 48
Image 5-7 La fentre de SAM-BA................................................................................................................................................................................... 49
Image 5-6 Excution de SAM-BA ................................................................................................................................................................................... 49
Image 5-8 le Flash Memory map ................................................................................................................................................................................... 50
Image 5-9 temix-webkit excuter 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 systme 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
Lobjet de ce rapport est le stage de fin dtude ralis en troisime anne lcole national des
ingnieurs de Sousse. Le stage tait au sein de la socit TEMIS. Dans l'objectif de satisfaire les nouveaux
besoins clients et de s'intgrer dans les nouvelles technologies, la socit TEMIUS dmarre un projet de ralisation
d'un nouveau terminal, dont le sujet de mon projet de fin dtude.
Dans ce cadre je suis appel, sur une carte avec microcontrleur ARM9, de mettre en uvre :
- Un systme dexploitation linux
- un cran TFT avec dalle tactile
- un lecteur RFID
- le pilotage d'entres/sorties logiques et d'entres analogiques
- Raliser 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
Prsentation 10
Section 1 Prsentation
Chapitre 1 Prsentation de TEMIS et son produit IGM50
1 Prsentation de TEMIS
La socit TEMIS est un bureau dtude cre en 1997 et situ la Roche sur Forn (haute Savoie), elle
comptabilise au total un effectif de 7 personnes, dont le capital est denviron 50 000.
TEMIS est un bureau dtude spcialis dans linformatique 50% et llectronique 35% mais galement
dans la mcanique 15%. Ils imaginent, conoivent et crent tout types de produits ayant un lien avec lun des
trois domaines cits. Ils programment des logiciels, pratiquent le hardware et le software, conoivent des
circuits imprims, utilisent la CAO en 3D et peuvent fournir des prototypes du projet aux clients le souhaitant.
Bien entendu ceci nest quun aperu de leurs comptences mais rsume bien les principales. Ses clients sont
des entreprises de la Valle de lArve tel que FCMP, Perrotton, Meister France ou encore Sopil, mais on peut
galement compter dans ses clients de grandes socits comme Somfy, SEB, ou encore Tefal mais aussi des
socits trangres tel que Swissvoice, ou ALSTOM.
Bien que travaillant pour de nombreux clients, lactivit principale de la socit est lIGM50. Cest un
produit de supervision datelier entirement fourni par TEMIS. Le design mais surtout la programmation de cet
appareil a totalement t cre par cette socit. Il quipe de nombreuses socits de la Valle de lArve
travaillant dans les domaines du dcolletage, de limprimerie ou encore de la dcoupe laser. Actuellement ce
produit se rpand de plus en plus partout en France mais galement ltranger (Suisse, Espagne).
2 Le produit IGM50
Le systme IGM50 est un systme dinterface de gestion de machines qui a pour but de visualiser en
temps rel ltat dun parc de production et de mmoriser un historique de ltat des machines. Cet
historique peut tre ensuite analys pour dterminer les causes darrt les plus frquentes et calculer les
indicateurs relatifs la qualit de production de chaque machine ou dun ensemble.
Le systme IGM50 permet de faire le lien entre le GPAO
1
latelier de production les ordre de
fabrication (OF) sont transmis de la GPAO vers lIGM50 qui les transmet lui-mme aux operateurs. Le systme
IGM50 rend compte de ltat davancement des OF. Toutes les saisies de renseignements sur les OF (nombre
de pices produites, rebuts,) sont automatises
Depuis sa conception, IGM50 a permis :
- La mise en place dune gestion des contrles de qualit.
- La possibilit de suivre une production partir dun dbit ou dune vitesse au lieu dun
comptage dunits produites.
- La gestion dun planning des OF mis jour en temps rel en fonction de ltat davancement
des produits en cours.
- La possibilit de visualiser en temps rel lvolution dindicateurs statistiques de production
grce au tableau de bord.

1
Gestion de production assiste par ordinateur
ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES
Prsentation 11
Chapitre 2 Le systme IGM50
1 Principe de fonctionnement
Concentrateur
Le concentrateur IGM50 scrute tous les terminaux connects au bus et
envoie les informations au PC de supervision.
Il renvoie toutes les informations avec un horodatage prcis.
Il permet galement d'enregistrer les cartes puce pour les
oprateurs.
Logiciel de Supervision
Le PC d'atelier supervise en temps rel toutes les machines connectes.
Il enregistre dans la base de donnes toutes les informations
recueillies dans l'atelier.
Ceci permet de visualiser en temps rel l'tat de chaque machine: les
quantits produites, les arrts et leurs causes, les performances.
Toutes les donnes enregistres servent raliser les analyses de
production, calculer les indicateurs de production.
Logiciel d'Analyse
Le logiciel d'analyse traite les informations de la base de donnes issues de
l'atelier en temps rel et les filtre selon vos critres de choix.
Il vous permet de connatre et d'optimiser l'utilisation de vos
machines.
Il analyse les temps d'arrt et de production.
Il suit et mesure la productivit des machines, ateliers, ilts,...
Il calcule les indicateurs de production normaliss: TRS, TRG, TRE,
Taux de charge, Disponibilit oprationnelle, SMED,...
Logiciel de Planning
Equivalent d'un planning mural, il visualise l'tat d'avancement des
OF et se met jour en temps rel.
Il vous permet de prvoir votre production et optimiser
l'occupation de vos machines.
Il rcupre les informations des OF et les ordonne sur les
machines, et permet de dplacer des productions d'une machine
l'autre d'un coup de clic.
Il permet de simuler des productions venir.
Il indique les retards prvoir en fonction des alas dans
l'atelier.
Logiciel Gestion Automatique des OF
Mini base article pour les systmes non relis une GPAO.
Crez votre base article trs simplement. Gnrez vos OF vers les machines.
Permet un lancement ordonnancement trs efficace.
Gnre 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 pices fabriques, mesure les temps de cycle
machine.
Il mesure les temps de fonctionnement, les temps d'arrt.
Il permet la saisie des causes d'arrts.
Il permet de slectionner l'OF raliser.
Il enregistre les oprateurs par leur carte puce.
Logiciel Tableau de Bord
Slectionnez les indicateurs de votre choix.
Visualisez leur volution en temps rel.
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'arrt,
bilans de production,...
Comparez : machine par machine, par quipe, par jour, par
semaine, par mois,...
Montrez leurs performances vos oprateurs.
Figure 1-1 principe de fonctionnement dIGM5O
ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES
Prsentation 12
Visualisation instantane de l'tat des machines par groupes suivant la configuration de l'atelier.
Information en temps rel sur l'avancement de la production :
- rfrence OF et pice,
- avancement de la production visualise graphiquement,
- dure estime de l'OF en cours par rapport la cadence relle de la machine,
- contrle du temps de cycle instantan, TRS, cadence,
- causes d'arrts renseignes.
L'tat de la machine et de la production
Saffiche instantanment :
Visualisation des
groupes de
machines
Accs au dtail
dune machine
Contrle de
l'avancement de la
production
Etat des machines
en temps rel
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
Prsentation 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 grer les prises et fin de poste, contrle,
Nature des entres (exemples)
Comptage des pices produites
Marche machine
Dtection dfaut
Rebuts
Nature des sorties (exemples)
Alarme lumineuse sur contrles,
Pilotage (arrt machine)
Voyants dalarme
Carte mmoire :
Changement O.F. avec
visualisation des O.F. suivants.
Indicateurs lumineux :
- fin dO.F.
Choix du fonctionnement :
- production
5 groupes de 15
causes darrt
paramtrables
Visualisation :
- rfrences de O.F. en cours
- quantit de pices produites
- identit de loprateur,
- temps de cycle instantan
- rfrence pice
Rebuts
- 4 entres
(Informations machines)
- 2 sorties
(Signalisations ou commandes)
Carte mmoire :
Changement O.F. avec
visualisation des O.F. suivants.
Indicateurs lumineux :
- fin dO.F.
Clavier de saisie des
quantits produites, des
rebuts
Choix du poste de travail ;
Choix de lopration en cours ;
Visualisation :
- rfrences de O.F. en cours
- quantit de pices produites
- identit de loprateur
- rfrence pice
Rebut
- 3 entres
- 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
Prsentation 14
Ce terminal gre 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 dun OF et dune opration sur lOF (charg depuis la supervision avec les quantits produire)
Entre des pices produites et des rebuts au clavier ou sur entre
Comptage automatique du temps pass sur chaque opration et suivi par quipes la supervision
Boutons de causes darrt et causes dabsences (programmables).
ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES
Prsentation et dfinition des besoins 15
Section 2 Prsentation et dfinition des besoins
chapitre 1. Le concept IGM2.O : Ide et Objectifs
1 Lide de projet IGM2.0
L e projet IGM2.0 ou plutt le concept IGM2.0 est bas sur lide de migrer vers le web ou prcisment
vers les applications web (la source de lide t le projet WEB2.0
2
, pour cela la notation 2.0). La question que
se pose alors :
Cest quoi les applications web ?
On dit que ces sont ; comme il les dfinit le site Bitpipe.com
3
; des logiciels stocks sur un serveur et
achemins 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 intgrer les Navigateurs de
cot client, et de bash, C, PHP, Access ou Bases de donnes SQL Server, de cot serveur.
Et wikipedia
4
les dfinit comme des applications livres aux utilisateurs partir d'un serveur web par un
rseau tel que lInternet ou lIntranet.
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 cration de PDF,
agenda ..., offerts par des sites sont aussi des applications web.
Mais pour quoi les applications web ?
2 Lobjectifs 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 dplacent sur terrain. L'entreprise doit pouvoir
communiquer aisment 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 rpondre aux besoins de
communications ncessaires la comptitivit de l'entreprise. Quelles sont aujourd'hui les solutions offertes
pour bnficier d'une application permettant un travail collaboratif ?
Il est toujours possible de faire raliser un logiciel sur mesure. Mais ce dveloppement est important (il
devra notamment implmenter 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 ncessaires, il faudra diffuser
disquettes,CD-ROM.
Pour remdier ces inconvnients, tout en conservant la mme base, il est aujourd'hui possible d'utiliser
une nouvelle technologie : la fdration d'applications. Dans une architecture de ce type, l'application
fonctionne sur un serveur centralis. Les utilisateurs accdent l'application sur le serveur comme des clients.

2
http://fr.wikipedia.org/wiki/Web2.0
3
www.Bitpipe.com
4
www.wikipdia.org
ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES
Prsentation et dfinition des besoins 16
Les mises jour s'en trouvent simplifies puisque l'application est centralise sur un serveur. Pour l'utilisateur,
c'est compltement transparent.
Un double clic sur l'icne et l'application est lance. Cette technologie reste nanmoins coteuse puisque
en plus du dveloppement de l'application il faut mettre en place l'architecture fdre qui repose sur des
applicatifs propritaires onreux. Ces solutions ne fonctionnent qu'avec certaines versions de Windows. Autre
inconvnient, les protocoles de fdrations sont gourmands en bande passante. Attention votre rseau !
Quant utiliser cette technologie via Internet, mieux vaut prvoir de gros tuyaux.
Un autre choix est de raliser un logiciel suivant une architecture web. Dans une architecture web,
l'application s'excute sur un serveur et les utilisateurs se connectent au serveur en utilisant leur navigateur
internet. Cette architecture prsente de nombreux avantages :
Les pages web sont lgres, ne satureront pas le rseau et permettent une utilisation nomade de
l'application. Les mises jour sont toujours simples puisque centralises 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 ncessaire de dvelopper une interface de communication et on bnficie de la
plateforme du navigateur web qui gre l'affichage des pages.
L'application peut alors tre utilise de n'importe quelle ordinateur (PC Windows, mac, linux),
Pocket PC ou mme tlphone. Il suffit que l'appareil possde un navigateur internet, ce qui
constitue une solution universelle d'utilisation.
Pas dinstallation juste un navigateur web
C'est donc naturellement que les entreprises se sont tournes vers les applications web. Aujourd'hui la
majorit des nouveaux projets de Systme 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
Prsentation et dfinition des besoins 17
Serveur IGM:
Le serveur IGM (matriel et logiciel) va jouer les rles :
Dun serveur web normale pour grer les communications et partager les donnes et les bases de
donnes.
Un serveur dapplication ; tous les applications sont centralises et installes sur ce serveur, et
tous les autres terminaux et postes accdent ces applications par rseaux.
Machine : cest la machine dans lusine
Pc industriel (Pc industriel) : Cest un ordinateur qui va contrler et muler les terminaux.
Terminal IGM2.0 : cest le nouveau terminal qui va remplacer IGM50
Les mthodes de communications :
Http : est un protocole de communication client-serveur dvelopp pour le World Wide Web.
RS232 : est une norme standardisant un port de communication de type srie.
RS485 : est une norme qui dfinit les caractristiques lectriques de la couche physique d'une interface
numrique srielle. La transmission se fait sur une ligne lectrique, pratiquement une paire torsade, par
des variations de tension en mode diffrentiel.
TCP/IP : est un ensemble de logiciels dvelopps au fil des annes (depuis les annes 70) qui
constituent un "langage universel" de communication informatique travers le monde.

chapitre 2. Prsentation de terminale IGM2.0
1 Prsentation
Cette dcision de migrer vers les applications web va exiger des modifications de base au niveau des
architectures matrielles et logicielles
nouvelle stratgie de communication et lintgration de nouveaux mthodes et solutions de communication.
Toute entreprise cherche maintenir son position dan
poursuivre les volutions technologies et les intgrer 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
Prsentation et dfinition des besoins
Prsentation de terminale IGM2.0
Cette dcision de migrer vers les applications web va exiger des modifications de base au niveau des
matrielles et logicielles des terminaux et au niveau de communication par linstallation dune
nouvelle stratgie de communication et lintgration de nouveaux mthodes et solutions de communication.
Toute entreprise cherche maintenir son position dans le march et battre ses concourants, doit
poursuivre les volutions technologies et les intgrer 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
Prsentation et dfinition des besoins 18
Cette dcision de migrer vers les applications web va exiger des modifications de base au niveau des
et au niveau de communication par linstallation dune
nouvelle stratgie de communication et lintgration de nouveaux mthodes et solutions de communication.
s le march et battre ses concourants, doit
ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES
Prsentation et dfinition des besoins 19
Alors, ma tache consiste prcisment intgrer un os embarque sur un microcontrleur avec un serveur
web et un navigateur embarque et la gestion des entres/sorties de microcontrleur tout en respectant les
contraintes de cout, de consommation, de taille, et des ressources limits (mmoire.), or la conception et
le dveloppement des modules de communication dpendra de lvolution et lavancement de projet.
2 IGM2.0 est un systme embarqu
Il est clairement remarquable que notre terminal IGM2.0 rpond pratiquement la dfinition de Patrice
Kadionik
5
pour le systme embarqu : Un Systme Embarqu, c'est une combinaison de matriels et logiciels
permettant de remplir une ou plusieurs fonctions spcifiques avec des contraintes plus ou moins svres tel
que la consommation, la temprature, la taille, les performances... et. [Patrice Kadionik, 2004].
2.1. Caractristiques de systmes embarqus
Alors, notre terminal est un systme embarqu, il se caractrise par suit par :
Faible cot
Un assez grand nombre de produits dembarqu sont sur les marchs o l'utilisateur ne veut pas payer le
supplmentaire pour la performance ou fonctionnalit de plus, Les concepteurs ont donc d concevoir avec
des rapports optimaux entre le prix et la performance Le rsultat de ceci est que les ressources disponibles
sont minimaux possibles. Cest pour quoi un systme embarqu a rarement plus de quelques Mga octets de
mmoire disponible.
Faible consommation
La minimisation de la consommation est essentielle pour les systmes autonomes afin de maximiser
l'autonomie des batteries. Une consommation excessive augmente le prix de revient du systme embarqu
car il faut alors des batteries de forte capacit. Or pour IGM2.0 la consommation ne prsente pas critre trs
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 numrique.
Fonctionnement en Temps Rel (Rponse de temps)
Les applications embarques, comme des applications de systme de contrle, sont vnement conduit et
doivent rpondre rapidement ces vnements.
Peut tre, Un systme embarque a besoin des oprations de calcul doivent tre faites en rponse un
vnement extrieur. Cest une caractristique pour quelques domaines spciaux.

5
Ingnieur 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
Prsentation et dfinition des besoins 20
Environnement
Ils sont soumis de nombreuses contraintes dictes par l'environnement telles que la temprature,
lhumidit, les vibrations, les chocs, les variations dalimentation, les interfrences RF, la corrosion, l'eau, le
feu, les radiationsetc. Cette caractristique est importante pour IGM2.0 car il va fonctionner dans un
environnement industriel.
2.2. Architecture gnrale de IGM2.0
Comme vous savez l'architecture de systme normal, un ordinateur se compose de trois couches:
Application, Systme d'exploitation, et Matriel. De mme, un systme embarque dispose de 3 couches.
Chaque couche a la mme fonctionnalit qu'un systme normal. Mais, Il y a des diffrences de sous
composants du systme. Les deux premires couches, Il s'agit du logiciel. Il est possible de modifier ces
composants logiciels, et aussi ajouter ou supprimer ses modules au besoin dpendant du but de systme.
Cependant, Ce n'est pas un systme qui contient tous les composants comme le systme complet. Car le but
de conception est de servir quelques tches spcifiques, et de concentrer un unique travail. Le systme
d'exploitation est une couche logicielle sur laquelle on va se placer l'ensemble des applications lances par les
utilisateurs. Il comprend les librairies pour le dveloppement, des drivers permettant aux applications
d'accder des priphriques volus, peut-tre les interfaces pour contrler les lments. La conception de
lOS se base forcment sur le matriel visant optimiser la performance etc.
La dernire couche, Il s'agit du matriel. C'est--dire qu'un ensemble des lments physiques employs
pour le traitement de donnes. Les composants matriels sont limits et peut-tre il y aurait un composant
ddi aux tches spcifiques.
Figure 2-3 Topologie d'un Systme Embarqu
Entres:
- 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
Prsentation et dfinition des besoins 21
Sorties:
- crans LCD tactile.
- les LED tmoins.
- les sorties des commandes.
Mmoire de mass : (La dtaille 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.
Cest lcran avec les dispositifs TouchScreen et les boutons.
ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES
Outils de dveloppement 22
Section 3 Outils de dveloppement
1 Introduction
Aprs avoir spcifi les diffrents besoin de notre projet, nous prsenterons dans cette section les
diffrents outils matriels et logiciels utiliss dans le dveloppement.
Je vais prsenter en premier lieux les outils logiciel tel que les environnements de dveloppement (ELDK,
Buildroot, Poky) et en deuxime lieu les matriels (carte) et dans une dernire partie les autres outils que
sont indpendant de projet.
Chapitre 1 Les environnements de dveloppement
1 Dfinitions
La plupart des dveloppeurs utilisent un PC x86 (Linux ou Windows) comme poste de travail et il est donc
ncessaire de mettre en place des outils permettant de dvelopper du code non-x86 sur un PC, mais avant de
discuter a, on parlera de la terminologie qui concerne le dveloppement .Il sagit dun environnement de
dveloppement crois avec deux entits distinguer :
La cible (Target-System) est la plate-forme matrielle qui va accueillir l'OS et le ou les applicatifs
embarques. En fait, La cible est un systme cible sur lequel On veut mis en place lOS, ou bien l'application. Elle
est caractrise par l'architecture des processeurs que peut tre IntelX86, MIPS, ARM, SuperHitachi-SHetc.
L'hte de dveloppement (Host-Development) est la plate-forme de dveloppement sur la quelle sont mis
au point les diffrentes parties logicielles de la cible. En fait, C'est une machine hte (host) pour le
dveloppement et la mise au point. Simplement, lors de la cration d'un OS Embarqu ou d'une application
embarque, On crit "code source" et compile directement les sources sur ce host de dveloppement.
Comme le dveloppement de logiciel ordinaire, les dveloppeurs de systme embarqu ont besoin des
compilateurs, des interprteurs, les linkers, les IDE, et d'autres outils de dveloppement. Les outils pour les
dveloppeurs de systme embarqus sont diffrents. Car ils fonctionnent sur une architecture diffrente lors
de la construction des applications pour le systme cible. C'est pourquoi ces outils s'appellent souvent des
chanes de compilation croise en anglais "cross-platform development tools" ou "cross-development tools".
La compilation croise ( cross-compile ) est un processus de cration des logiciels pour le systme
(microprocesseurs) cible en utilisant un machine hte avec les outils tel que compilateur, bibliothque C, etc
La chane de compilation croise est trs importants pour dvelopper 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 dbogueur GDB
3. bibliothque C : Glibc, Dietlibc, uClibc
ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES
Outils de dveloppement 23

Figure 3-1 la compilation croise
Dans le cas de la compilation croise, ces diffrents outils, ainsi que le compilateur, seront excut sous
linux dans un environnement x86 mais le code gnr sera d'un type diffrent (ARM). Il est donc ncessaire
de compiler le paquetage partir des sources en spcifiant de nouvelles options de gnration.
La gnration de la chane de compilation croise est peut tre possible la main mais les applications
pour les systmes cibles est souvent fastidieuse car elle peut que l'application a beaucoup des dpendances et
de mme ces dpendances ont des dpendances, etc.., exemple :
Exemple fichiers dpendances 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
croise
les outils de
compilations
de hote
ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES
Outils de dveloppement 24
Et aussi elle peut quelle ncessite des patchs en fonction des architectures. De ce fait, l'utilisateur non
averti risque de disposer d'une chane errone et il est donc conseill d'utiliser des outils spcialiss.
Dans cette partie, nous allons prsenter 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 ncessaire pour dvelopper
en linux embarqu:
- outils de compilation (le compilateur, l'assembler, le linker etc..), sont des outils pour gnrer le code
pour l'architecture vis.
- native-tools et native-libraries sont des outils utiliss pour compiler des programmes excuter sur des
systmes embaqus.
- Des codes sources et des fichiers binaire pour linux.
ELDK est dvelopp par DENX Software, socit de consulting Linux situe 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
tlcharger l'image ISO du CDROM contenant les binaires ou les sources
7
.
ELDK permet de mettre en place une chane 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
ncessaire de mettre jour systmatiquement la cible. La version de noyau fournie par ELDK est la 2.4.25
amliore par DENX principalement pour la plate-forme PowerPC.
Vous trouvez titre de formation une mthode de mettre en uvre un Linux sous ARM avec ELDK dans
lannexe B.
3 Buildroot
Buildroot est un ensemble de Makefile et patches qui permettent de gnrer facilement une chane de
compilation croise et un systme de fichiers racine de votre cible.
Buildroot automatise la mise en place d'un systme de fichiers racine avec tous les outils ncessaires
comme busybox. Il rend beaucoup plus facile que de le faire la main.
Buildroot automatise la gnration de la chaine de compilation grce 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 tlcharger Buildroot utilisant SVN, il vous suffit de suivre les rgles dcrites 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 dveloppement 25
Buildroot se caractrise 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 ncessaire d'tre root pour configurer et l'utilisation de Buildroot.
4 OpenEmbedded
OpenEmbedded est un outil qui permet aux dveloppeurs de crer un Linux pleinement utilisable pour
divers systmes embarqus. Il a t conu pour tre en mesure de traiter diffrentes architectures matrielles
et d'utiliser des outils pour acclrer 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 dveloppe une collection de recettes BitBake. Les bitbakes
constitus des sources URL du paquet, les dpendances et les options de compilation ou d'installation.
Pendant le processus de constructions, les recettes sont utiliss pour suivre les dpendances, le cross-compiler
et le paquetage de paquets susceptible d'tre install sur le priphrique cible. Il est galement possible de
crer des images compltes, compos de systme de fichiers racine et du noyau.

5 Poky Linux
Poky est une plateforme open source. Il est un environnement de dveloppement logiciel ddi pour
linux. Il aide la conception, le dveloppement, la construction, le dbogage, la simulation complte de
logiciels modernes utilisant Linux, il est fond sur lenvironnement OpenEmbedded.
Poky a t configur pour:
Fournir des programmes open-source pour Linux.
Crer des paquets stable, en se basant sur de OpenEmbedded et qui peuvent tre facilement et de
manire fiable intgrer sur des systmes embarqu.
Soutenir une large gamme des architectures x86 et ARM.
Poky est avant tout une plate-forme qui gnre des images de fichier-system (filesystem images) base
sur des logiciels open source tels que le serveur X Kdrive, le gestionnaire de fentres Matchbox, la bote
outils GTK + et le bus de system D-Bus message. Des nombreux types des images peuvent tre gnrs par
poky, et de plus il est compltement adapt avec lmulateur QEMU pour les architectures x86 et ARM.
Figure 3-2 : Sato Desktop - Une capture d'cran partir d'un ordinateur excutant Poky built image
ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES
Outils de dveloppement 26
Poky a de plus en plus une communaut open-source soutenu par un support commercial assur par le
principe dveloppeur et mainteneur de Poky, OpenedHand Ltd.
Pourquoi poky ?
Le choix de lenvironnement ce nest pas facile. Avec une petite recherche sur internet on trouve que Buildroot,
OpenEmbedded et Poky sont le plus populaire mais les dveloppeurs conseillent dutiliser OpenEmbedded avec sa
commande magique bitbake, par contre on choisis poky tout dabord car il se base sur OpenEmbedded et de plus
je lai trouvais plus structur et simple manipuler.
Chapitre 2 La carte et les autres outils
1 La carte AT91SAM9260-EK
AT91SAM9260EK est un kit dvaluation dAtmel qui est conue pour lvaluation des programmes tournant
sur le microcontrleur AT91SAM9260 de Atmel cur ARM9.
LAT91SAM9260EK est quip d'un AT91SAM9260 (217-ball LFBGA paquet) ainsi que les lments suivants:
64 Mo de mmoire SDRAM
256 Mo de mmoire NANDFlash
Mmoire Data flash dAtmel
EEPROM srie DHT
un port USB type A
deux ports USB hte interfaces type B
un port de communication srie pour
le debug
un port MODEM srie de
communication
un autre port de communication srie
avec RTS / CTS
JTAG / CIE interface de dbogage
un port Ethernet 100 Base TX avec trois LEDs
d'tat
un audio dac AT73C213 dAtmel
une puissance LED usage gnral
deux boutons poussoirs configurable
une entre bouton-poussoir pour le Wake up
un bouton-poussoir de rinitialisation
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 dvaluation AT91SAM9260EK
ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES
Outils de dveloppement 27
2 Les autres outils
2.1 QEMU Emulateur Lenvironnement dmulation
Qemu est un mulateur de matriel, 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 systme hte. Cependant, la virtualisation vous permet de rentabiliser le temps
processeur libre en multipliant les OS.
QEMU a deux modes de fonctionnement:
- Emulation complte du systme .Dans ce mode, QEMU mule un systme complet (par exemple un
PC), y compris le processeur (un ou plusieurs processeurs) et les divers priphriques. Cest une bonne
manire pour lancer diffrents systmes d'exploitation sans formater, partitionner ou redmarrer le PC ou
pour dboguer le code systme.
- 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 complte 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 dveloppement 28
Pour le mode utilisateur Qemu mule x86, PowerPC, ARM, 32-bit MIPS, Sparc32/64 et ColdFire
(m68k).
Cet outil me permet dmuler le systme dexploitation 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 diffrences entre les fichiers.
Ce systme permet par exemple de mutualiser un dveloppement. Un groupe de dveloppeurs autour
d'un mme dveloppement se servira de l'outil pour stocker toute volution du code source. Le systme gre
les mises jour des sources par chaque dveloppeur, conserve une trace de chaque changement. Ceux-ci sont,
en bonne utilisation, chaque fois accompagns d'un commentaire. Le systme travaille par fusion de copies
locale et distante, et non par crasement de la version distante par la version locale. Ainsi, deux dveloppeurs
travaillant de concert sur une mme source, les changements du premier soumettre son travail ne seront
pas perdus lorsque le second, qui a donc travaill sur une version non encore modifie par le premier, renvoie
ses modifications.
Cet outil ma normment aid aux cours de mon dveloppement par le visionnement de mes
modifications et il permet aussi de prsenter le changement entre les versions.
2.3 NFS
Network File System (NFS) est un moyen de partager des fichiers entre plusieurs machines sur un mme
rseau comme si les fichiers se trouvaient sur votre disque dur local.L'ide de base de NFS est de permettre
un ensemble quelconque de clients et de serveurs de partager un mme systme de fichiers. Ce partage de
fichiers s'effectue d'une faon aussi transparente que possible. D'une manire gnrale, les clients et les
serveurs sont sur le mme rseau local mais il est possible d'excuter nfs travers un rseau 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 rle
d'un serveur cause de sa structure mono-tche.
Cet outils ma permet de partager le systme 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 systme 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 systme dexploitation embarqu
1 Pour quoi un systme dexploitation
Pourquoi intgrer tout un systme dexploitation sur le terminal et pas des programmes en dur qui
rpond directement nous besoins ?
Le systme dexploitation, est multitche. Il est possible dy excuter plusieurs processus qui se partagent
les ressources de la machine. Il peut, en effet, stopper, tout moment, nimporte quelle application pour
passer la main la suivante. Le plus intressant dans un systme dexploitation est quil va nous faciliter la
communication et la gestion de matriel, imaginer qui on va faire la gestion des mmoires et les interruptions
dune application; comme un navigateur web; manuellement, cest fastidieuse !
On trouve une multitude des systmes dexploitation pour lembarque, les uns sont gratuits et open
source et les autres non,.
Quelques OS Embarqu trs connu :
Palm OS pour le handheld
Ses applications comprennent
- Gestion de la mmoire simplifie,
- Gestion de bases de donnes et de l'cran,
- Fournissement de la bibliothque mathmatique
- Fournissement des applications minimalistes.
Symbian OS pour la tlphonie,
- Gestion des contacts,
- gestion de rseaux divers (SMS, Bluetooth, GSM,TCP/IP),
- gestion multimdia
- Supporte la technologie Java (Java Phone)
Windows Embarqu :
- Les applications drives du Windows
Alors Pourquoi intgrer Linux dans notre systme embarqu quant il existe cette multitude dautres
systmes dexploitation ?
2 Pourquoi Linux ?
Cette partie apporte les lments de rponse 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 systmes destins tre fabriqus en grande srie, et o chaque cot supplmentaire doit tre vit.
Toutes les distributions Linux sont disponibles gratuitement au tlchargement par Internet, D'ailleurs, les
outils de dveloppement d'un Linux comme les compilateurs, le IDE, la bibliothqueetc sont disponibles
faible cot ou gratuits parce que fonctionner en terme de GNU. Donc les cots de mise en uvre de Linux sont
rduits. 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 trs bien pour la
construction d'un Linux embarqu.
2.3 Beaucoup de pilotages et outils de dveloppement 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 systmes d'exploitation existants.
Maintenant, Linux offre l'avantage nombreux pilotes existent souvent en modle "Open Source", et sont donc
facilement modifiables ou adaptables, si le besoin s'en faisait sentir. Pour dvelopper une application, Il est
ncessaire d'avoir les outils comme les compilateurs, IDE, et le dboguer. Linux supporte le GCC, GDB four
dboguer et beaucoup de IDE. Pour le dveloppement de OS Embarqu, la chane de dveloppement qui
s'appelle "cross-compilation" en anglais (compilation pour une machine cible diffrente de la machine qui sert
gnrer un programme) est trs importante. La communaut de Linux Embarqu fournit suffisamment les
outils de dveloppement ncessaires.
2.4 Plein d'applications
Lapplication tant support par LINUX est beaucoup diverse, On peut chercher une application adapte
pour votre domaine. Dailler, lutilisation est aussi gratuite.
2.5 Support de rseau
La capacit de rseau sera indispensable pour la connectivit IP dans l'embarqu. Linux le trs bon
support en rseaux. Il supporte le plus nombreux de protocoles possibles de rseau tests t prouvs depuis
des annes comme suit. Cela permet votre systme dtre interoprabilit.
TCP/IP rseau.
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 utilises 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 dveloppement des OSs Embarqus, En 2004
9
Selon VDC (www.vdc.com), qui a tudi sur des plateformes de matriel, des logiciels, Linux, Java, et
logiciel ouvert de source, et des outils de dveloppement. Il conclut que Linux Embraqu se dveloppe trs
rapidement. On utilise de plus en plus linux pour la stratgie de dveloppement de ses produits. Et Linux
embarqu, aujourdhui, 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 systme dexploitation pour lembarqu, comment ?
1 Introduction
La construction dun linux pour lembarqu se base sur linux normale mais avec des modifications qui les
exigent le matriel et lobjectif de systme embarqu. Alors cest quoi ces modifications et pourquoi ?
2 Architecture de linux
A partir les caractristiques et l'architecture du LINUX en gnral, on peut donner un exemple sur
l'architecture logicielle d'un Linux Embarqu car elle va tre notre base pour le dveloppement.
Figure 4-2 l'architecture de linux
Chargeur de dmarrage
Noyau
Systme de fichiers
Bibliothques (librairies)
Utilitaires de base
Pilotes
Applications
Ces composants Peut-tre sont prsents ou non dans les diffrents systmes. Cela dpend de
larchitecture cible et lobjectif de systme.
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 rutiliser les logiciels existence pour Linux embarqu.
Le noyau doit pouvoir charger et/ou accder un file-system en mmoire local ou en rseau par NFS
10
ou
FTP
11
. Un Systme de Fichiers doit tre prsent dans Linux embarqu.

10
NFS ou Network File System est un Protocole de communication dvelopp par Sun Microsystems qui permet un
Ordinateur d'accder un systme de fichier via un Rseau.
11
FTP est un Protocole de communication destin l'change de fichiers sur un Rseau TCP/IP
ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES
Solutions techniques 33
Pourtant, les services exports par le noyau sont souvent incapables pour tre employs directement par
des applications. Au lieu de cela, les applications se basent sur des bibliothques qui fournir les APIs familiers
et services abstraits qui communique avec le noyau pour obtenir la fonctionnalit dsire.
La bibliothque principale employe par la plupart des applications de Linux est la bibliothque de GNU C.
Pour les systmes embarqus de Linux, La librairie GNU peut tre remplace en autre bibliothque.
2.1 Chargeur de dmarrage ou le bootloader
Le bootloader est un petit programme ncessaire pour tout systme embarqu baser sur des OSs et qui
est charg de :
Initialisation matrielle
CPU, mmoire, (mmoire flash)
Commandes de monitoring ou tests
(optionnels)
Accs mmoire
Accs flash
Chargement de fichiers
Mise jour du systme
Chargement du noyau
Dcompression
Chargement (optionnel) de systme ``root''
initial provisoire (initrd)
Et on trouve plusieurs types de bootloader ces qui sont gnrale tel que syslinux, blob, u-boot qui jai le
utilis pour le dveloppement, et grup et ces qui sont spcifique au matriel et qui ncessite de
configurations particuliers et parfois ils exigent mme les adresses des mmoires.
Logiciel Architecture de
processeurs
Types
damorage
Description
LILO x86 - Disque Dur
- Mmoire de
Flash
Le bootloader principal pour le Disque
commun sous Linux
GRUB x86 - Disque Dur
- Mmoire de
Flash
- DOC
- TFTP, NFS
Une version avance de LILO
U-BOOT Tous Tous les types le bootloader universel bas sur ARM-Boot,
pour presque tous les processeurs embarqus :
REDBOOT Tous Tous Dvelopp par RedHat
Tableau 4-2 comparaison bootloaders
Jai travaill avec u-boot car le plus adapter pour lembarqu et on plus pour lARM et aussi car il offre la
possibilit de charger le noyau et le systme de fichier par rseau avec NFS ou FTP qui ma trop facilit le
dveloppement.
2.2 Noyau
Le noyau est le composant le plus important du systme d'exploitation. Son but est de contrler le
matriel d'une faon logique et il fournit les services de bas niveau aux utilisateurs de haut niveau. Comme
avec autre Unix, Linux conduit des dispositifs, contrle des accs d'I/O, gestion de processus, gestion de la
ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES
Solutions techniques 34
mmoire, manipule la distribution des signaux (ils ncessitent peut tre des patchs) chargement de systme
de fichier, et on trouve souvent des noyaux avec des pilotes compiler en dur.
2.3 Pilotes de priphrique
Vous n'avez pas besoin d'crire vos pilotes de zro. Vous pouvez rutiliser le code de pilotes libres
similaires. Les pilotes peuvent tre compils statiquement dans le noyau ou comme des modules charger par
lutilisateur aprs le dmarrage de noyau, et le choix entre le deux dpond de systme embarqu et ces
ressources.
Les pilotes sont chargs la gestion de ressource matrielle (E/S mmoire, E/S ports, les interruptions )
en assurant les communications entre les matriels et la couche suprieur.
2.4 Systme de fichiers
Un systme de fichiers est un format de stockage des fichiers sur des supports tels que le disque dur, la
disquette, le cd-rom et autres mmoires de masses. Les systmes 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 reconnat que son propre systme de fichier, en plus du systme des cd-
rom, Linux a la possibilit de lire et crire sur un grand nombre de systme de fichiers provenant dOs
multiples.
Lorsque lon travaille avec un systme dexploitation de type Unix comme Linux, on ne peut pas supprimer son
systme de fichier. Celui-ci fait intgralement parti du processus de fonctionnement de lensemble de lOs.
2.5 Bibliothques (Librairies)
Ces sont les bibliothques ncessaires pour le bon fonctionnement de systme tel que glibc2, libc5 et
aussi on peut trouver des bibliothques additionnels pour le rseau 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 .
Daprs la dfinition de systme embarqu ; que est un systme aves des ressources matriel rduit et
qui va remplir une tache bien dtermin ; on peut penser optimiser notre linux pour rpondre aux
contrainte matriel (mmoire), mais comment ? On liminant tout qui nest pas ncessaire pour excuter
notre tache.
3 Optimisation
La construction dun systme Linux embarqu passe par lanalyse du systme Linux standard. Cette
analyse permet de dterminer les parties modifiables afin doptimiser le systme dexploitation. Loptimisation
nira pas dans le sens des performances (vitesse dexcution), mais dans celui de la taille occupe en mmoire
vive et en mmoire de masse. En effet, lheure actuelle bien des systmes embarqus sont quip des
mmoires (vive RAM et de masse FLASH) de capacit importante (pour notre systme est quip de 64M pour
le RAM et 256M pour le FLASH). Mais, encore le cot prohibitif de la mmoire (RAM et de masse) impose de
trouver des solutions quant la diminution de la taille de stockage de lOs.
Loptimisation du systme passe par la rduction des diffrents blocs qui constituent le systme
dexploitation Linux. Il sagit doprer, une transformation au nivaux du noyau que peut subir une optimisation
en vue dtre dbarrass des pilotes de priphriques inutiles, mme 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 Loptimisation de systme de fichier
Discuter du choix dun systme de fichier et du logiciel permettant au systme dexploitation de le grer
peut paratre inutile lors dune configuration standard dun Pc de bureau. Et Lorsquon parle dun systme
embarqu, il faut avoir lesprit, quil volue dans des conditions trs rudes que nous faire pens bien choisir
le type de systme et ladapter sans perdre le standard et la philosophie du systme de fichier de linux
(Unix).Linux supportant un nombre impressionnant de systmes de fichiers, or je vais juste prsenter trois que
parais bien adapter pour lembarqu.
Ext2 : Il sagit du systme de fichier le plus utilis actuellement sous Linux. Son utilisation sur des
stations de travail ou des serveurs ne pose aucun problme. En utilisant un systme de redondance des
structures vitales, il permet souvent de retrouver un systme cohrent aprs un arrt forc, grce un
utilitaire semi-automatique du nomm e2fsck.
Initrd : Lune des options prcieuses de Linux consiste dans la possibilit de crer de petite image de
boot en utilisant le systme de fichiers initrd. Initialement destin simplifier la procdure dinstallation, le
systme de fichier initrd permet de charger un petit systme de fichiers en mmoire vive depuis son lieu de
stockage. Ce systme de fichier est compress au format gzip. Le noyau le dcompresse en RAMDisk12 au
moment du dmarrage. Avant la cration du systme initrd il tait impossible de dmarrer Linux dun support
quelconque sans que le driver pour ce support nait t pralablement compil avec le noyau. Avec initrd un
petit systme de fichiers contenant les drivers essentiels et les scripts de dmarrage est charg avec le noyau.
Ce dernier dcompresse le systme de fichiers et excute un fichier nomm linuxrc. Ce script met en place les
drivers manquants pour complter la procdure de dmarrage. Lorsque le script se termine le systme de
fichiers initrd est dmont, la mmoire occupe est libre et la procdure dinitialisation du systme se
poursuit dune faon normale.
Il est alors concevable de dtourner le systme initrd afin quils deviennent le systme de fichier dune
machine embarque :
Comme le noyau, le systme de fichier initrd est compress et donc ne prend pas beaucoup de place en
stockage.

12
Le RAMDisk permet dobtenir une partition similaire celle rencontre sur une mmoire de masse en mmoire vive.
ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES
Solutions techniques 36
Le systme de fichier et le noyau peuvent tre fusionns pour ne former plus quun seul gros fichier.
La mmoire de masse, par exemple une mmoire Flash, peut tre rduite 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 dvelopp lorigine pour les mmoires Flash qui,
imposent quelques contraintes de gestion. Pour saccommoder au mieux de la limite du nombre de
modifications dune zone de donnes, ce systme de fichiers ne rcrit jamais les donnes au mme
emplacement, et garde toujours les versions antrieures cohrentes des donnes en cours de modification. Ce
systme de fichier fut dvelopp pour des systmes embarqus aux ressources limites.
Il parait que le systme de fichiers le mieux adapt aux machines embarques est le JFFS2. Il na
cependant pas tait possible de le tester. En effet, il parait quil est mal adapt avec qemu. En prsence de ce
problme, lemploi du systme 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 dveloppement et test.
===> Alors lemploi du systme de fichier Ext2 est solution avantageuse dans mon cas.
3.2 Suppression du swapping
On alloue sous Linux un espace mmoire nomm zone de swap. Cet espace est rserv en mmoire de
masse, le disque dur dans le cas dun systme de bureau.
Le swapping sacquitte de deux fonctions majeures :
Augmenter ladressage rellement utilisable par un processus ;
Augmenter la quantit de mmoire vive dynamique (ce qui reste de mmoire vive une fois que le code du
noyau et les structures de donnes statiques ont t initialises) pour charger les processus
Le swap est utile lorsque le noyau manque dangereusement de mmoire. Le noyau garde toujours une
petite rserve de pages mmoire libres qui ne peuvent tre utilises que par les fonctions les plus critiques.
Ceci savre essentiel pour viter les pannes systme qui pourrait se produire lorsquune routine du noyau
appele en vue de librer des ressources nest pas en mesure dobtenir la zone de mmoire dont elle a besoin
pour raliser sa tche.
Lors de la conception dun systme embarqu, les fonctionnalits exactes sont dfinies dans la premire
phase dun projet. Connaissant avec prcision les applications qui sexcutent sur le systme, le concepteur
peut prvoir une quantit de mmoire suffisante sans devoir recourir aux services du swapping.
Loptimisation de la taille du systme dexploitation soulve la question de lutilit de la zone de swap. La
suppression de celle-ci entranerait un gain de place apprciable Lutilisation de la mmoire vive sans
swapping augmente galement les performances du systme en termes de rapidit.
===> La suppression de la zone de swapping est automatiquement par dfaut par poky.
3.3 Optimisation de noyau
Loptimisation du noyau se fait par deux nivaux, le premier et de bien configurer le fichier de
configuration du noyau pour se dbarrasser de tout que est inutile comme les pilotes intitules, et le deuxime
est la compression du noyau.
Pour la compression du noyau il faut prciser le type de compression soit zImage ou bzImage au moment
de compilation, or le deuxime type ne donne pas un intrt para port le premier.
ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES
Solutions techniques 37
Traditionnellement, les pilotes de priphriques intgrent le noyau, ce pour plusieurs raisons. En premier
lieu, la plupart ont besoin dinteragir de faon spcifique avec le matriel, ce que seul le noyau permet. Ce
systme pose videmment certains problmes. Tout dabord, chaque ajout de nouveau matriel
ladministrateur doit reconstruire le noyau pour y inclure les nouveaux priphriques. Pour y remdier, Linux
reconnat les pilotes chargeables, ajouts ou supprims de la mmoire lors du fonctionnement du systme.
Ces pilotes, qui constituent toujours une partie du noyau, sont compils sparment et valider quau moment
de leur utilisation. Pour que le noyau soit mme dutiliser les modules, une option de compilation spcifique
doit tre slectionne. Si cela est possible, il est prfrable dans le cadre dun systme embarqu de compiler
les pilotes comme des modules. Ceci nest malheureusement pas toujours possible, il faut savoir que certains
drivers ne peuvent pas tre utiliss sous forme de module. Il sagit plus particulirement des pilotes de
priphriques utiles au dmarrage du systme (Le pilote du contrleur IDE dans le cas dun systme x86.).
Dans tout le cas la taille du noyau dpend de lutilit du systme final. Cest en compilant le noyau avec les
options dsires que le volume prcis peut tre dfini.
ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES
Solutions techniques 38
chapitre 2. Les applications et les paquets ncessaires
1 Introduction
Dans le mme cadre davoir un linux fonctionnelle avec le minimum de taille, il faut bien choisir les
applications et les paquets que respectent cette contrainte et rpondre au bien fonctionnement de systme.
Les applications sont les programmes accessibles par lutilisateur directe or les paquets sont les
programme ncessaires pour le noyau et le bon fonctionnement de notre systme.
Les applications et les paquets sont bien choisir suivant les objectifs de notre systme.
2 Les applications
2.1 BusyBox
BusyBox combine des versions "allges" de nombreux utilitaires Unix en un excutable unique et de
petite taille. En effet, chaque fichier excutable individuel contient un en-tte de chargement, dont la taille est
loin dtre ngligeable 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 reprsente un environnement POSIX assez complet pour petits systmes ou
systmes embarqus. BusyBox a t crit avec pour objectif une optimisation de taille et une utilisation de
ressources limites.
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 incorpore ne possde pas toutes les options des commandes
externes quivalentes. Cependant, elles savrent plus que suffisantes. L'outil est aussi extrmement
modulaire, ainsi il est facile dinclure ou dexclure des commandes la compilation. Cela permet de l'adapter
facilement chaque type de systme embarqu. Sa taille est dapproximativement 200 [ko].
2.2 TinyLogin
TinyLogin fonctionne selon le mme principe que BusyBox. Il complte gnralement ce dernier, en
fournissant des commandes Shell complmentaires pour la gestion des connexions utilisateurs. Il sagit 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
quon soit claire il vaut mieux dfinir quelques notions. Et ensuite je vais expliquer le choix de webkit.
Dfinitions
Navigateur : Un navigateur web est un logiciel conu 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 appeles plugins.
Un moteur de rendu : Un moteur de rendu HTML est un composant logiciel de base qui permet aux
logiciels d'afficher les lments d'une page web. Ils sont de ce fait le cur des navigateurs web.
Les standards du Web est une expression dsignant diffrentes technologies et protocoles utiliss sur le
Web et en particulier ceux dfinis par le W3C sous forme de recommandations.
Webkit
13
est une bibliothque de fonctions permettant aux dveloppeurs d'intgrer facilement un moteur
de rendu de pages web dans leurs logiciels. Originellement rserve au systme d'exploitation Mac OS X (
partir de la version 10.3 Panther), elle a t porte vers Linux et Windows.
Webkit est un fork du moteur de rendu KHTML du projet KDE utilis notamment dans le navigateur
Konqueror. Elle intgre deux sous-bibliothques : WebCore et JavaScriptCore correspondant respectivement
KHTML et KJS.
Il passe avec succs le test Acid2
14
et il a obtient 100% au test Acid3 depuis le 27 mars 2008.
Pour quoi webkit ?
Dans notre recherche dun navigateur embarqu on a dfinit quelque critres quil doit les respecter, il
doit tre on open source, intgre le CGI, JavaScript, XML et CSS, et test sur lembarqu.
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 placs et intgre le CGI, le JavaScript et . Et encore webkit est trs
rpondue dans lembarqu 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 quil nous offre busybox on activant
loption 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 systme 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 ncessaire pour construire le systme de fichier de notre OS linux.

13
http://en.wikipedia.org/wiki/WebKit
14
Les testes Acid2/3 ceux-ci sont destins la vrification 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 spcifiques pour la configuration de la bibliothque de rsolution de
noms.
17
"motd" signifie "message of the day", et il contient gnralement des messages destins aux utilisateurs concernant
l'administration du systme (ajout de priphriques, arrts prvus du systme, nouvelles versions de logiciels, etc...).
18
Fichier de configuration des bases de donnes systmes et des services de noms.
ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES
Solutions techniques 40
Tableau 4-4 le systme de fichier respectant le standard
3.2 Initscripts
Ces scripts de ce paquet initialisent un systme standard GNU/Linux Debian au moment du dmarrage et
le stoppent au moment de l'arrt ou du redmarrage.
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 dafficher 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 bibliothques ncessaires pour lutilisation du service NFS (Network File Service).
3.5 libration-fonts
Ce paquet contient bibliothques 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 dmarrage d'un serveur
X, et le chargement dune session X
3.7 Netbase
Ce paquet fournit l'infrastructure ncessaire pour les bases d'une mise en rseau TCP/IP.
3.8 Udev
Ce paquet contient le gestionnaire de priphriques udev. Sa fonction principale est de grer les
priphriques dans le rpertoire /dev.

19
General Graphics Interface libraries
ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES
Dveloppement 41
Section 5 Dveloppement
1 Introduction
Maintenant nous somme prt aborder la partie pratique aprs toutes ces dfinitions. Dans une premire
partie on va parler du dveloppement (construction) de linux et les applications embarqus et en deuxime
partie de le dveloppement web et rseaux et pour la dernire pour la partie de la configuration de hardware
et test.
Chapitre 1 Construction de linux et les applications embarqus
Comme on va utiliser lenvironnement poky il est indispensable de savoir comment lutiliser, 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 rpond pratiquement nous besoin (si on veut ne pas dire compltements) comme un
environnement de dveloppement ddi linux embarqu, et avec ses outils avancs, sa structuration, sa
flexibilit il va nous permettre de configurer et personnaliser aux moindres dtails nous applications.
1.1 Installation des paquets ncessaires
==> 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
Dveloppement 42
1.2 Tlchargement de Poky
==> Vous pouvez le tlcharger:
Soit en ligne de commande :

Soit partir de cet lien http://pokylinux.org/releases/
1.3 Compiler et excuter une image
Apres le tlchargement de Poky, dcompressez le dossier :

Pour lancez la compilation une limage poky-image-sato par exemple il suffit de tapez ces commandes :
==> Il est de prfrence de compiler poky-image-minimal (bitbake poky-image-minimal) pour que ne
prendre pas beaucoup de temps.
==> Les images / noyaux construites par Poky sont placs dans le /tmp/deploy/images.
On peut galement tlcharger des images et des noyaux :
Le Poky QEMU noyau (zImage * * qemu *. bin) et le systme de fichier image compress (poky-image-*-
qemu *. ext2.bz2) que vous aurez besoin de le dcompresser avec 'bzip2-d'. Celles-ci sont disponibles partir
de la dernire publication sur http://pokylinux.org/releases/blinky-3.0/ ou de l'autobuilder sur
http://pokylinux.org/autobuild/poky/.
Pour l'excution (simulation) il faut :
Tlcharger 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 accs Internet, et d'environ 9 Go
d'espace disque disponible, et vous devriez vous attendre d'environ 4 - 5
heures suivant le dbit de connexion (pour tlchargement) et
caractristique de lordinateur (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
Dveloppement 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 systme (machine) sous Poky il faut passer par trois tapes :
Etape 1 : ajout et la configuration de la nouvelle machine ; la machine ici reprsente la carte de
dveloppement.
Etape 2 : configuration de noyau.
Etape 3 : configuration de poky
2.1 Etape 1
Ajouter un fichier at91sam9260ek.conf sous le rpertoire meta/conf/machine/ avec
tous les dtails de la carte vous trouvez le fichier dans lannexe 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 limage de noyau KERNEL_IMAGETYPE = "zImage"
- Le fichier de configuration de linux pour la carte PREFERRED_PROVIDER_virtual/kernel = "linux-
at91sam9260ek"

20
Voir les dfinitions des variables dans lannexe C
poky-qemu zImage-qemuarm.bin poky-image-sato-qemuarm.ext2
ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES
Dveloppement 44
- La console de dbogage SERIAL_CONSOLE = "115200 ttyS0"
- Les fichiers de configuration gnral 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 rpertoire meta/packages/linux/ sous la variable COMPATIBLE_MACHINE
Crer le fichier linux-at91sam9260ek.bb dans le repertoire meta/packages/ dont voila
son contenue :
Les fichiers *.bb sont gnralement appels les recettes. En
gnral, une recette contient des informations sur un paquet ou une
application tels que, les sources de tlchargement (SRC_URI
21
), tous les
correctifs qui s'imposent, les options de configuration spciale, la
mthode de compilation si il ncessite 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
Dveloppement 45
Les variables quil faut les voir sont :
- IMAGE_FSTYPES dfinit le type de systme fichier
- ROOT_FLASH_SIZE la taille de flash
- IMAGE_ROOTFS_SIZE_ext2 et la taille de systme de fichier dans cette cas
pour ext2 car on a utilis le EXT2
23
2.3 Etape 3
Apres lajout de notre machine Il faut indique Poky quel est le nom de la machine cible, et quil faut le
mentionner dans le fichier local.conf sous le rpertoire build/conf/ avec la variable MACHINE.
3 Ajout des applications et des paquets
3.1 Construction de temix-webkit
Comme on a dfendit au dessus temix-webkit se base sur webkit et on cherche crer un navigateur :
- lger qui prend pas beaucoup de mmoire
- Il naffiche que les pages web (pas de barre de menu)
Et pour dvelopper a je utiliser les langages GTK2+ et C et vous trouvez le code sources de la page temix-
webkit.c dans lannexe A.
3.2 Configuration de busybox
Nous avons besoin dun serveur web de base et on a dit que busybox intgre un serveur lger 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 slection et la configuration des paquets compiler et aussi la configuration de linux on va lancer
la construction de notre systme (compilation). Et pour faire a sous avec poky il faut crer une recette (fichier
.bb) sous le dossier meta/packages/image et que en va lappeler 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 deffacer 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 Dmo web- igm2.0
La dmo web-igm2.0 est la version 0 de linterface graphique (menu) de notre terminale, cest un ensemble des
pages web (XML et Html) affich par notre navigateur web embarqu.
Il sagit 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 dIGM2.0
ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES
web et rseaux
igm2.0 est la version 0 de linterface graphique (menu) de notre terminale, cest un ensemble des
pages web (XML et Html) affich par notre navigateur web embarqu.
Image 5-4 un dsigne imagin dIGM2.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 Arrts dIGM2.0
ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES
Dveloppement 46
igm2.0 est la version 0 de linterface graphique (menu) de notre terminale, cest un ensemble des
web pur avec XML, HTML et xslt (XSL), dont vous trouvez dans lannexe A
sont de mme modle que
ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES
Dveloppement 47
1.2 JavaScript et les raccourcis des boutons
Comme on na 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 rcuprer les codes de touches
et suivant cette ide on a cr une fonction que se lance louverture de chaque page web et qui :
Dtecte tout les liens dans la page
Dtecte le bouton enfonc
Faire le lien entre les liens et les boutons (les boutons (code) sont choisis paravent).
Elle ouvre ce lien sil existe
Vous trouvez le code de la fonction dans le fichier terminal.xsl dans lannexe A
1.3 Ajax, rcuprer les valeurs des capteurs
Pour la rcupration de la valeur dun capteur (vitesse ou compteur de pices) on a utilis Ajax pour
mettre jour le champ de compteur.
On va rcuprer la valeur de deux capteur ; u n pour le nombre de pices fabriques et lautre pour
ltat de la machine.
Lide consiste crer une fonction qui envoi une requte http au serveur fonctionnant sur la carte par la
mthode XMLHttpRequest. Le serveur quand il dtecte cette demande il excute un script bash
(ou un programme) dans le dossier cgi-bin, cette script va renvoyer une page XML comme rponse.
Ensuite il suffit danalyser cette page par un code JavaScript pour rcuprer la valeur de capteur.
Et avec la mthode setTimeout on va contrler lexcution de cette fonction chaque les n
millisecondes suivant la frquence de capteur le dbit de connexion rseaux.
RQ : Pour simuler les deux capteurs on a utilis le deux boutons ; une pour le capteur de comptage et
lautre pour ltat de la machine.
Etant donn qui la page XML est cr par un programme LISTEN qui tourne sur la carte en arrire plans et
qui coute les boutons et chaque appuis sur un bouton on incrmente le compteur correspondant.
Vous trouvez dans lannexe A, le code source de programme LISTEN et dans la page terminal.xsl le code de
la fonction de la mise jour.
2 Programmation rseaux
Pour cette parte est en cours de dveloppement au moment de taper ces lignes, mais on a arriv
envoyer la valeur de compteur et ltat de la machine var la base de donn de serveur IGM (serveur rails) avec
la commande curl PUT :
Et rcuprer le numro dOF par la commande curl
La rponse de serveur est une page XML et pour recperez la valeur il faut analyser cette page.
===> Vous trouvez galement les codes de scripts bash qui automatise tous la synchronisation dans
lannexe A.

24
Voir les caractristiques de la carte dans la section outils de dveloppements
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
Dveloppement 48
Chapitre 3 Configuration de la carte et test
1 Configuration de la carte
Comme on a dcrit au dessus que u-boot est notre chargeur (bootloader) et par suit il faut linstaller sur
la carte. Mais on besoin sur la carte dun autre programme qui va lui-mme charger u-boot, ce programme
est nomm AT91Bootstrap.
AT91Bootstrap est une premire tape d'amorage qui fournissent un ensemble d'algorithmes pour grer
linitialisation de matriels (GPIO, Horloge, SDRAM, etc) et pour tlcharger votre application principale
de certaines mmoire flash (Data Flash, FlashNand,) la mmoire principale et la dmarrer.
AT91Bootstarp est utilis ici pour configurer le matriel et charger et excuter le chargeur U-Boot
ncessaire pour le dmarrage de systme dexploitation (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 srie. Vous pouvez utiliser le programme
minicom
25
, et si vous ne lavez pas vous pouvez le tlcharger : sudo aptitude Install minicom.
Tlcharger lAT91Bootstarp pour la carte AT91sam9200ek
- Les sources de AT91Bootstrap est tlchargeable partir de site de ATMEL :
Et vous trouvez galement de documentation sur la mthode de la compilation et la configuration.
- Dans le cas dutilisation standard (configuration standard pour le chargement de u-boot
de la DataFlash) dAT91Bootstarp ; comme notre cas ; on peut tlcharger le fichier .bin
compil configur pour des diffrentes cartes partir :
Chargement
Avant de commencer les tapes de chargement il faut vrifier :
J7 doit tre ouvert (BMS = 1) pour dmarrer partir Boot ROM

Image 5-5 La position de jumper 7 sur la carte

25
est un programme de contrle 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
Dveloppement 49
la mise sous tension de la carte
vrifier la connexion USB
Les tapes de chargement :
Tlcharger SAM-BA : http://www.atmel.com/dyn/products/ faq_card.asp?faq_id=1981
Lancer SAM-BA
Dans les menus droulent slectionner la
connexion USB et la carte AT91SAM9260EK
Connecter
Une fentre saffiche
Image 5-7 La fentre de SAM-BA
1. Choisir ou AT91Bootstrap va tre charg dans notre cas cest le DataFlash
2. Initialiser le DataFlash on choisir Enable Dataflash on CSO dans le menu Scripts puis
excuter.
Image 5-6 Excution de SAM-BA
ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES
Dveloppement 50
3. Puis choisir Send boot file, pour envoyer les fichiers de dmarrage, puis appuyez sur
Excuter
4. Il faut indiquer ladresse 0x0 et la taille du fichier 0x1000.
5. Slectionnez le fichier binaire at91bootstrap et appuyez sur Send File.
6. Fermer SAM-BA et dbranchez le cble USB
1.2 Chargement de u-boot
Pour u-boot cest pratiquement les mmes tapes quAT91Bootstrap
Tlcharger lU-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 mmes tapes justes il faut choisir le fichier u-boot.bin charger et changer ladresse de chargement
0x08400.
Image 5-8 le Flash Memory map
Et voila un trs bon site que dcrivent 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
Dveloppement 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 dmarche :
Figure 5-1 dmarrage du-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 dveloppement (serveur) avec le cble ethernet
Configurer le Pc en serveur
Dfinir l'adresse MAC de la carte rseau (attention, on ne peut pas la rcrire la suite de la commande
saveenv. Attention, le saveenv est ncessaire .
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
Dveloppement 52
Configurer u-boot pour tlcharger l'image noyau via tftp
26
et la booter:
Pour lancer:
2.1.2 Pour flasher linux
Dfinir les scripts de flash (ici uImage est le kernel)
pour flasher :
2.1.3 Pour tlcharger le fichier de systme par nfs
dfinir la variable bootargs
Rq : il faut ajouter le rpertoire /home/yf/image dans le fichier dexport de nfs /etc/exports
copier le noyau flasher dans ladresse 20000000
pour booter

26
Cest 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
Dveloppement 53
2.2 Lancer les applications
Lancer le serveur web
o Il faut copier le pages web cre (voir le dmo web-igm2.0) dans le systme de fichier.
o Crer le dossier cgi-bin sous la racine et copier dans ce dossier le script bash qui va renvoyer la
page XML (voir Ajax, rcuprer les valeurs des capteurs).
o Lancer le serveur (busybox httpd) sous la racine.
Lancer du programme LISTEN (voir Ajax, rcuprer les valeurs des variables)
Le programme LISTEN doit tre compil avec poky (compilateur de poky) puis le copier dans le systme de
fichier sous /usr/bin.
Lancer le programme temix-webkit
Comme on na pas dcran (pour le moment) on va exporter laffichage sur le PC
de dveloppement :
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 excuter 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
Dveloppement 54
webkit excuter 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
prcdemment cela a ncessit la mettre en uvre sur une carte devaluation, un systme dexploitation
linux, un cran TFT avec dalle tactile, un lecteur RFID, le pilotage d'entres/sorties logiques et d'entres ,
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 acheves:
- Intgration un systme dexploitation linux.
- le pilotage d'entres/sorties logiques et dentres, analogiques
- serveur web
- communication TCP/IP avec la supervision,
- interface graphique via un navigateur Web embarqu.
Pendant la dure de ce stage, j'ai bien pu mettre en pratique les connaissances acquises durant
mes tudes lENISO. D'un point de vue plus personnel, ce stage m'a permis d'tre confront aux
ralits du monde du travail et galement appris l'importance du travail en quipe et l'intrt de la
communication.

ETUDE, CONSEIL ET REALISATION DE SYSTEMES ELECTRONIQUES ET MECANIQUES
Bibliographie 56
Bibliographie
Livre :
Linux systme programming Robert Love
Embedded linux primer Christopher Hallinan
Linux Device Driver Corbet, Rubini & Kroah-Hartman
Embedded linux systme Designe and Developement Raghavan & Lad & Neelakandan
Articles :
EMBEDDED LINUX Gaspoz Frdric en 2002.
Linux embarqu : le projet uClinux - Patrice Kadionik, 2003
Embarquez Linux! ou Linux Everywhere - Pierre Ficheux, 2004
Les Systmes Embarqus Linux pour lembarqu - 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 pice(s)</info>
<info name="Oprateur">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 paramtre (id1:id2) et le fichier xml en 2eme paramtre
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
Procdure 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 quil est indispensable davoir une connexion internet pour tlcharger les outils ncessaire.
Prparation : crer un rpertoire de travail (ex: /home/user/embedded-linux)
Installer ELDK pour armet les outils ncessaires
Voir http://www.denx.de/wiki/view/DULG/ELDKInitialInstallation
Monter l'iso du CD tlcharg sur le site de ELDK et excuter le script d'installation.
Exemple pour installer eldk dans ~/embedded-linux :

Il faut ensuite changer les droits des programmes qui doivent tre installs SETUID avec le script
ELDK_FIXOWNER:
Il faut enfin crer les devices:

On peut alors dmonter l'iso

Installer qemu :
Tester la compilation croise pour ARM:
La compilation croise ncessite de dfinir les variables d'environnements
ARCH qui indique l'architecture pour laquelle compiler, ici arm
CROSS_COMPILE qui indique le prfixe des outils de compilation croise 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 rpertoires ou se trouvent les outils de compilation croise, 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:
Aprs 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'interprteur 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
lentreprise). 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
installs. 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 nest applicable que si vous tes connect au serveur de lentreprise,
cependant vous pouvez tlcharger la configuration partir dinternet et lancer les lignes ; 1, 3 (cp le-chemin-
de-fichier-config .config), 4.
Limage du noyau sera dans ~/embedded-linux/eldk/arm/usr/src/linux/arch/arm/boot/zImage.
Prparer l'environnement de simulation
Installer et configurer un serveur NFS :
Installer
diter le fichier de configuration /etc/exports:
On ajoutant cette ligne :
Puis redmarrer le serveur Nfs:
On peut tester le bon fonctionnement de Nfs comme ceci:
Vrifier si le montage local a bien fonctionn (voir si le rpertoire test_nfs contient le rpertoire arm) puis
dmonter le rpertoire:
Installer et configurer un rseau virtuel
Note: Il est ncessaire que le noyau hte 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 rseau virtuelle tap0 dans /etc/network/interfaces
Et ajouter ces lignes :
Pour activer l'interface (pour activer l'interface au dmarrage, 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 redmarrer 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 srie sur laquelle est redirige 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.
Chapter2.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).
Chapter3.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.
Chapter4.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.
Appendix1.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.
Appendix2.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.
Appendix3.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.
Appendix4.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.
Appendix5.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
Appendix6.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.
Appendix7.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
Appendix8.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?
Appendix9.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.
Appendix10.OpenedHand Contact Information
OpenedHandLtd
UnitR,HomesdaleBusinessCenter
216-218HomesdaleRd
Bromley,BR12QZ
England
+44(0)2088196559
info@openedhand.com
Index

Vous aimerez peut-être aussi