Réalisé Par:
*AYOUB ROUZI
*ABDELHAKIM SALAMA
*FADILI MUSTAFA
*ELMALKAOUI YASSINE
Encadré Par:
Mr.Abdelhakim Anouar
MINIMISER LE SYSTÈME
D'EXPLOITATION EN UTILISANT
OPENEMBEDDED

 Introduction
 OpenEmbedded en quelques mots
 Historique et rappels
 OpenEmbedded
 OpenEmbedded en détail
 Cas d’utilisation
 OpenEmbedded Meta data
 Bitbake
 OpenEmbedded en pratique
 Comment tester ?
 Conclusion
PLAN:

 OpenEmbedded est un Framework de compilation de composants
logiciels libres destines a être déployés sur des systèmes embarques
 production d’un simple binaire jusqu’à une distribution complété
 support de nombreuses architectures et configurations flexible
 autosuffisant et déterministe
OPENEMBEDDED EN QUELQUES MOTS

HISTORIQUE ET RAPPELS

 Les briques logiciels de base pour construire un système Linux
glibc: GNU C library.
gcc: GNU C compiler.
binutils: outils manipulant les fichiers objet et binaire
Ces éléments constituent une toolchain, avec laquelle peut ensuite
être compile tout autre composant (make, le kernel, X, KDE, ...)
HISTORIQUE ET RAPPELS

 Une toolchain permet de compiler sur une machine hôte (’build’, ’native’)
d’architecture A du code exécutable sur une machine cible (’Target’) d’architecture B.
 si A == B: on parle de toolchain et de compilation
 si A != B: on parle de cross-toolchain et de cross-compilation
HISTORIQUE ET RAPPELS

 Pour compiler du code pour une machine cible, il y a plusieurs
possibilités
 récupérer une standalone/prebuilt toochain/SDK s’exécutant
sur la machine cible. Rarement viable par manque de mémoire
et puissance de la machine embarquée
 compiler une toochain/SDK exécutable sur la machine cible
 récupérer une cross-toochain s’exécutant sur une machine
hôte générant du code spécifique a la machine cible
(ex: ARM)
 compiler une cross-toolchain
HISTORIQUE ET RAPPELS
« COMPILATION POUR L’EMBARQUE»

OPENEMBEDDED

 Les systèmes de build existants ne gèrent pas les dépendances ou montrent vite leurs
limites d’utilisation grande échelle par:
 manque de flexibilité
 lourdeur de maintenance (ex: des makefiles)
 OpenEmbedded a ete crée en 2003 par Chris Larson:
 pour fédérer les efforts de développement des différentes distro embarquées qui sont/étaient
trop souvent spécifiques à une seule architecture cible.
 pour fournir un systéme de build flexible et puissant, utilisant une syntaxe et sémantique plus
adaptée que des makefiles
OPENEMBEDDED
« POURQUOI AVOIR CRÉER OPENEMBEDDED ?»

 compilation de binaires/paquets/distributions complètes exnihilo (from scratch)
 possibilité d’utiliser une toolchain préexistante
 génération d’une même distribution déployable sur différente architecture cible
 plusieurs milliers de paquets disponibles: vim, python, qt4, etc.
 plusieurs images disponibles: console(2Mo), gpe-image, etc.
 customisation: toolchain (glibc/uClibc/eglibc), scripts d’init,découpage des paquets.
 kernel très récents supportes (2.6.24)syntaxe simple et puissante des .bb
 pleins d’autres encore ...
 parce que c’est fun de créer sa propre mini distribution
OPENEMBEDDED
« LES ATOUTS D’OPENEMBEDDED»

 Des laboratoires de recherches
 Des sociétés spécialisées dans l’électronique embarque
 Des sociétés de de télécom (t´téléphonie mobile / PDA)
 Des projets libres de distributions Linux embarquée
(ex: nslu2,OpenMoko)
OPENEMBEDDED
« QUI UTILISE OPENEMBEDDED ?»

OPENEMBEDDED EN DETAIL

Techniquement, le projet OpenEmbedded se compose de
bitbake: la commande utilisée pour construire d’un simple
paquet jusqu’à une distribution complète avec OpenEmbedded
les metadata d’OpenEmbedded: l’ensemble des fichiers que
bitbake exploite pour pouvoir faire cela
OPENEMBEDDED EN DÉTAIL
« OPENEMBEDDED = BITBAKE + METADATA»

Le dépôt des Meta data contient l’ensemble des données
nécessaires et suffisantes pour (cross)-compiler des composants
logiciels open sources
 On distingue trois principaux types de Meta data
 recipe (*.bb): caractérise un composant logiciel (executable, bibliothéques, kernel.)
 class (*.bbclass): contient des taches communes aux recipes,
 conf (*.conf): fichier de configuration,
OPENEMBEDDED EN DÉTAIL
« OPENEMBEDDED METADATA REPOSITORY»

 Un recipe contient l’ensemble des données permettant de compiler
 un composant depuis son code source.
 description et licence
 liens vers les sources et patchs `a appliquer
 dépendances (build dépendances, runtime dépendances)
 options de configuration
 customisation du découpage et contenu des paquets générées
(-dev, -doc, etc.)
OPENEMBEDDED EN DÉTAIL
« OPENEMBEDDED METADATA: RECIPE (*.BB) »

 Les fichiers de configuration
 local.conf: contient votre conf personnelle de build (TARGET ARCH, DISTRO, ...)
 machine configurations: common architectures, routers, PDA,GSM phones, ...
 distribution policies: packaging, naming, preferred version ofsoftware,
OPENEMBEDDED EN DÉTAIL
« OPENEMBEDDED METADATA: CONF (*.CONF) »

 un exécuteur de taches et un gestionnaire de metadata
 un peu le ’make’ d’OpenEmbedded
 inspire de Portage, le gestionnaire de paquet de la distribution Gentoo
 écrit en python
OPENEMBEDDED EN DÉTAIL
« BITBAKE »

 Gérer la cross-compilation
 Gérer les dépendances inter-paquets
 build time on target architectures
 build time on native architectures
 Runtime
 Linux distribution agnostic
 Architecture agnostic
 Gérer les metadata conditionnellement (target, OS, distro,machine)
 Multiple target operating system (Linux, BSDs, etc.)
OPENEMBEDDED EN DÉTAIL
« BUTS DE BITBAKE »

OPENEMBEDDED EN PRATIQUE

 Pour faire c’est premiers pas avec OpenEmbedded et bitbake:
http://www.openembedded.org/wiki/GettingStarted
Un seul fichier à configurer: /build/conf/local.conf
OPENEMBEDDED EN PRATIQUE
« OPENEMBEDDED CONFIGURATION »

OPENEMBEDDED EN PRATIQUE
« UTILISATION DE BITBAKE »
Les paquets et images résultantes sont dans tmp/deploy/

L'ENVIRONNEMENT DE DÉVELOPPEMENT

 Une personnalisation simple
mkdir -p /stuff/build/conf /stuff/tools/
cd /stuff/tools
svn co svn://svn.berlios.de/bitbake/branches/bitbake -1.4 bitbake
cd bitbake
./setup.py build
 Pour plus d’informations sur bitbake :
cd /stuff/tools/bitbake/doc/manual && make
 pour add bitbake a linux PATH :
export PATH=$HOME/oe/bitbake/bin:$PATH
L'ENVIRONNEMENT DE DÉVELOPPEMENT
« INSTALLATION DE L'ENVIRONNEMENT DE DÉVELOPPEMENT »

 aptget install wget curl
L'ENVIRONNEMENT DE DÉVELOPPEMENT
« INSTALLATION DES OUTILLES POUR LE CODE »

L'ENVIRONNEMENT DE DÉVELOPPEMENT
« INSTALLATION DE COMPILATEUR POUR PYTHON »
 aptget install python-psycop2

 Dans cet exemple nous utiliserons la branche
(git.openembedded.org/openembedded)
L'ENVIRONNEMENT DE DÉVELOPPEMENT
« INSTALLATION D'OPENEMBEDDED »

mtn –db=OE.mtn pull monotone.openembedded.org org.openembedded.stable
L'ENVIRONNEMENT DE DÉVELOPPEMENT
« MISE À JOUR DE LA BASE OPENOMBEDDED »

BBFILES = "${HOME}/openombedde/recipes/bb/bb_1.2.bb"
Choisir une machine depuis :
org.openembedded.stable/conf/machine/
L'ENVIRONNEMENT DE DÉVELOPPEMENT
« MODIFIER LE FICHIER BUILD/CONF/LOCAL.CONF »

Org.openembedded.stable/conf/distro/
L'ENVIRONNEMENT DE DÉVELOPPEMENT
« CHOISIR UNE DISTRIBUTION »

 PARALLEL_MAKE = "j 4"
 BB_NUMBER_THREADS = "4“
 Spécifier le système de fichier
 IMAGE_FSTYPES = "ext2 tar"
L'ENVIRONNEMENT DE DÉVELOPPEMENT
« SPÉCIFIER LE NOMBRE DE PROCESSUS À UTILISER »

 Crée un environnement de configuration des scripts
 export PATH=$HOME/openembedded/bitbake/bin:$PATH
 export BBPATH=$HOME/oe/build:$HOME/openembedded
 Configuration de fichier système de Ubuntu
 echo 0 > /proc/sys/vm/mmap_min_addr
L'ENVIRONNEMENT DE DÉVELOPPEMENT
« INSTALLATION DE L'ENVIRONNEMENT DE DÉVELOPPEMENT »

ÉTAPES DE CONFIGURATION
BITBAKE

On a téléchargé bitbake et après on a décompresser le fichier, et ça nous donne les
fichiers suivants :
ÉTAPES DE CONFIGURATION
« SPÉCIFIER LE NOMBRE DE PROCESSUS À UTILISER »

 Il nous est aussi possible d’ajouter un package à une image.
 Imaginons que nous souhaitions que l’éditeur ‘nano’ soit intégré à notre image OPIE.
 Nous ajoutons simplement ce package au fichier à la variable INSTALL_PACKAGES du
fichier
/stuff/org.openembedded.dev/packages/meta/opie-image.bb
ÉTAPES DE CONFIGURATION
« AJOUTER UN PACKAGE À UNE IMAGE »

Puisque nous venons de modifier le fichier meta-bzImage.bb
il nous faut donc purger le package pour permettre sa reconstruction.
 bitbake -c clean meta-bzImage bitbake bzImage-fr-image
Il est possible de construire un patch
 diff -aburN org.openembedded.oz354x.orig/ org.openembedded.oz354x_fr >
org.openemb
ÉTAPES DE CONFIGURATION
« RECONSTRUCTION DE L’IMAGE BZIMAGE »

ÉMULATION AVEC QEMU

Qemu émule diverses architectures dont une qui nous intéresse,
Il nous est donc possible d’émuler notre image
Pour pouvoir réaliser cela plusieurs prérequis sont nécessaires.
ÉMULATION AVEC QEMU
« L’INSTALLATION DE QEMU »

Qemu émule diverses architectures dont une qui nous intéresse,
Il nous est donc possible d’émuler notre image
Pour pouvoir réaliser cela plusieurs prérequis sont nécessaires.
ÉMULATION AVEC QEMU
« OPENEMBEDDED & QEMU »

Au passage il faut noter que nous utiliserons l’émulateur qemu-system-arm fourni pas
le package qemu- native:
« qemu-system-arm -kernel zImage-2.6.17-qemuarm-20061008161924.bin -append "root=/de »
ÉMULATION AVEC QEMU
« OPENEMBEDDED & QEMU »

Des patchs sont ajouter pour
la prise en compte de l’écran
tactile:
ÉMULATION AVEC QEMU
« OPENEMBEDDED & QEMU »

ÉMULATION AVEC QEMU
« OPENEMBEDDED & QEMU »

Durant la réalisation de ce projet on a pu acquérir une petite expérience dans le
domaine des noyaux(Kernels) et on a réalisé une configuration d’un nouveau noyau
conçu complétement pour l’utilisation qui s’adapte avec nos besoins, et comment
l’installer avec openembedded.
CONCLUSION