Développement avec Openembedded

user_icon admin | icon2 Openembedded | icon4 26/11/2006 16h31| Type doc: article| Type File: txt| icon3 29 Comments

Développement avec Openembedded


1. Environnement de développement pour Zaurus

Ce chapitre présente le processus permettant la compilation d’applications/images pour Zaurus (C1000) avec openembedded Il est largement inspiré de http://www.openembedded.org/wiki/GettingStarted Cet environnement nous permettra aussi la construction des fameux fichiers ‘zImage.bin’, ‘initrd.bin’ et ‘updater.sh’ (OPIE et/ou GPE) et même d’un feed.

1.1. Prérequis:

  • Prévoir au minimum 5Go pour la compilation d’un système comme GPE ou OPIE.

apt-get install python2.4 python2.4-dev python2.4-psyco ccache patch quilt m4 sed docbook \
                bison make subversion libc6-dev libboost* texi2html

1.2. Installation de l'environnement de développement:

1.2.1. Installation de bitbake:

Bitbake est un outil de gestion de packages qui permet :

  • la cross-compilation

  • Les dépendances interpackages

  • la construction de packages et ensemble de packages (téléchargement des sources, configuration,compilation et packaging)

  • 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’info sur bitbake : cd /stuff/tools/bitbake/doc/manual && make ( ou BitBake User Manual http://bitbake.berlios.de/manual/ )

1.2.2. Installation des utilitaires ipkg (optionnel):


cd /stuff/tools
wget http://handhelds.org/download/packages/ipkg-utils/ipkg-utils-050831.tar.gz
tar xvjf ipkg-utils-050831.tar.gz
mv ipkg-utils-050831 ipkg-utils

1.2.3. Installation de monotone

Monotone est un outil de versioning qui va nous permettre d’extraire une branche de la base Openembedded.

apt-get install monotone

Pour une autre distribution voir http://www.venge.net/monotone/

1.2.4. Installation d'Openembedded

Dans cet exemple nous utiliserons la branche .org.openembedded.oz354X (voir hwr à http://www.oesf.org/forums/index.php?showtopic=20111)


cd /stuff
wget http://openembedded.org/snapshots/OE.mtn.bz2
bunzip2 OE.mtn.bz2
# Pour lister les branches de la base
mtn --db=/stuff/OE.mtn list branches
org.openembedded.dev
org.openembedded.documentation
org.openembedded.dreambox
org.openembedded.oz354fam083
org.openembedded.oz354x
org.openembedded.packaged-staging

# Extraction de la branche org.openembedded.oz354x
mtn co --db=/stuff/OE.mtn --branch org.openembedded.oz354x ( ou org.openembedded.dev)

Mise à jour de la base Oe.db:

mtn --db=/stuff/OE.mtn pull monotone.openembedded.org org.openembedded.oz354x

Mise à jour de la branche:

cd /stuff/org.openembedded.oz354x && mtn update

Configuration:


cd /stuff
cp org.openembedded.oz354x/conf/local.conf.openzaurus-3.5.4 build/conf/local.conf

Modifier le fichier build/conf/local.conf de manière à avoir:

MACHINE = "akita"
TARGET_ARCH = "arm"
TARGET_OS = "linux"

#adapt these to match your directory layout
DL_DIR   = "/stuff/sources/"
BBFILES := "/stuff/org.openembedded.oz354x/packages/*/*.bb"

#set distro and version
DISTRO = "openzaurus-3.5.4"

#what kind of images do we want?
IMAGE_FSTYPE="jffs2 tar"

#Make use of my SMP box
PARALLEL_MAKE="-j2"

#multimachine build stuff
KERNEL_STAGING = "${STAGING_DIR}/${PACKAGE_ARCH}-${HOST_OS}/kernel"
STAGING_KERNEL_DIR = "${STAGING_DIR}/${PACKAGE_ARCH}-${HOST_OS}/kernel"
STAMP = "${TMPDIR}/stamps/${PACKAGE_ARCH}-${HOST_OS}/${PF}"
WORKDIR = "${TMPDIR}/work/${PACKAGE_ARCH}-${HOST_OS}/${PF}"

#Add verbosity to make fixing easier
BBINCLUDELOGS = "yes"

#The name says it all
CVS_TARBALL_STASH = "http://www.oesources.org/source/current/"

1.2.5. Initialisation de l’environement:

export LANG=C
export BBPATH=/stuff/build:/stuff/org.openembedded.oz354x

export PATH=/stuff/tools/bitbake/bin:/stuff/tools/ipkg-utils:$PATH

1.3. Création de packages et/ou d’images (bootstrap, OPIE ou GPE)

Créer un simple package:

bitbake nano
...
Packaged contents of nano into /stuff/tmp/deploy/ipk/nano_1.3.9-r0_armv5te.ipk
Packaged contents of nano-doc into /stuff/tmp/deploy/ipk/nano-doc_1.3.9-r0_armv5te.ipk
...
Packaged contents of nano-locale-fr into /stuff/tmp/deploy/ipk/nano-locale-fr_1.3.9-r0_armv5te.ipk

Bitbake lors de sa première utilisation créeera un cache dans /stuff/tmp/cache/bb_cache.dat. Par la suite ce sera ce cache qui sera utilisé.

Il faut noter que la commande bitbake nano est un ensemble de commande paramétré par le fichier nano….bb qui peut être décomposé comme ceci:

fecth : Telecharge les sources

unpack : décompression des sources

patch : application du / des patch(s)

configure : configuration des sources

compile : compilation

populate_staging : intégration des fichiers compilés

package : création du fichier ipk

donc bitbake nano est en fait la suite de commandes:


bitbake -b /stuff/org.openembedded.oz354x/packages/nano/nano_1.3.9.bb -c fectch
bitbake -b /stuff/org.openembedded.oz354x/packages/nano/nano_1.3.9.bb -c unpack 
bitbake -b /stuff/org.openembedded.oz354x/packages/nano/nano_1.3.9.bb -c patch
bitbake -b /stuff/org.openembedded.oz354x/packages/nano/nano_1.3.9.bb -c configure
bitbake -b /stuff/org.openembedded.oz354x/packages/nano/nano_1.3.9.bb -c compile
bitbake -b /stuff/org.openembedded.oz354x/packages/nano/nano_1.3.9.bb -c populate_staging
bitbake -b /stuff/org.openembedded.oz354x/packages/nano/nano_1.3.9.bb -c package

Pratique pour dépolluer certains pb, notamment en utilisant l’option -D (DEBUG)

Quelques commandes ‘ bitbake’:

La commande suivante pertmet de lister toutes les taches lors de la création d’un package:

bitbake -b <path to bb file> -c listtasks

Pour consulter toutes les variables utilisées lors de la compilation (ex: nano) :

bitbake -e /stuff/org.openembedded.oz354x/packages/nano/nano_1.3.9.bb |more

Pour voir la valeur d’une variable OE d’un package:


bitbake -b ../openembedded/packages/meta/bootstrap-image.bb -c showdata

Important

Special note for task-bootstrap: you may need additional setup for building this very one task.

bitbake task-bootstrap

Créer un ensemble de packages:

cd /stuff
bitbake bootstrap-image
  ...
ls -l tmp/deploy/images/3.5.4.1-rc4/akita/
-rw-r--r-- 1 root root 7110672 2006-05-11 00:47 bootstrap-image-akita-20060510224546.rootfs.img
-rw-r--r-- 1 root root 4846056 2006-05-11 00:47 bootstrap-image-akita-20060510224546.rootfs.tar.bz2
-rw-r--r-- 1 root root 2784412 2006-05-11 00:03 modules-2.6.16-akita.tgz
-rwxr-xr-x 1 root root    5903 2006-05-11 00:35 updater.sh.akita
-rw-r--r-- 1 root root 1141124 2006-05-11 00:03 zImage-2.6.16-akita-20060510191839.bin

Créer un groupe de packages:


bitbake gpe-image

Pour la compilation prévoir au moins 300Mo disponibles pour le téléchargement des sources (DL_DIR) et 4.5Go pour l’espace de travail (/stuff). Après quelques heures de compilation … ( et divers petits problèmes avec la version de developpement )…

# ls /stuff/tmp/deploy/images/3.5.4.1-rc4/akita/
gpe-image-akita-20060515185250.rootfs.img
gpe-image-akita-20060515185250.rootfs.tar.bz2
modules-2.6.16-akita.tgz
updater.sh.akita
zImage-2.6.16-akita-20060514140125.bin

Yes :) De la même manière il est possible de créer une image Opie

bitbake opie-image

ls /stuff/tmp/deploy/images/3.5.4.1-rc4/akita/opie*
opie-image-akita-20060518143804.rootfs.img
opie-image-akita-20060518143804.rootfs.tar.bz2

Re yes :) Créer la totalité des packages (déconseillé)

bitbake world

Pour nettoyer/supprimer un package:


bitbake -c clean  LePackage

1.4. Ajouter un package à une image

Il nous est aussi possible d’ajouter un package à une image.

Imaginons que nous souhaitions que l’editeur ‘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 qui devient:

INSTALL_PACKAGES = "task-bootstrap task-opie-base task-opie-base-applets \
                    task-opie-base-inputmethods task-opie-base-apps \
                    task-opie-base-settings task-opie-base-decorations \
                    task-opie-base-styles task-opie-base-pim \
                    task-opie-extra-settings \
                    task-opie-bluetooth task-opie-irda \
                    nano \
                    ${extra_stuff}"

Et on relance


bitbake opie-image

Peut pas faire plus simple :)

Cette méthode nous permet de personnaliser très facilement une image openzaurus. Nota:

Les fichiers BB permettent la construction des packages, on y trouve divers dépendances:

DEPENDS : sont les packages dont nous auront besoin pour la compilation

RDEPENDS : sont ceux dont nous auront besoin pour l’exécution.

1.5. Montage et modification de l’image

Voyons voir ce que contient notre image.

Pour modifier manuellement notre image (par ex gpe-image.img) il nous faut la ‘monter’. (voir le site d’Ulhume qui explique très bien cela : http://artisan.karma-lab.net/node/59 )

Pré requis: mtd-tools

apt-get install mtd-tools

cp /stuff/tmp/deploy/images/.../gpe-image-akita-......rootfs.img /tmp/gpe.img
modprobe mtdblock
mknod /dev/openzaurus b 31 0
modprobe mtdram total_size=65535
dd if=/tmp/gpe.img of=/dev/openzaurus bs=16 skip=1
mkdir /tmp/openzaurus
mount -t jffs2 /dev/openzaurus /tmp/openzaurus
ls /tmp/openzaurus

On peut maintenant personnaliser notre image. Et enfin construire une nouvelle image y incluant nos modifications.

( voir /stuff/org.openembedded.dev/conf/bitbake.conf )


mkfs.jffs2 --root=/tmp/openzaurus/ --faketime --little-endian --eraseblock=0x4000 -n --pad --output=/tmp/my-gpe.jffs2
cat /stuff/tmp/staging/arm-linux/lib/sharp-flash-header/header-c700.bin /tmp/my-gpe.jffs2 > /tmp/my-gpe.img

flashage de /tmp/my-gpe.img (en initrd.bin) Et pour finir un peu de nettoyage.

umount /tmp/openzaurus &amp;&amp; rmdir /tmp/openzaurus
rmmod jffs2 mtdram mtdblock
rm -f /dev/openzaurus

2. Personnalisation du noyau

Ce document décrit une méthodologie permettant la compilation et l’installation d’un nouveau noyau Zaurus C1000. Dans le cas précis j’ajoute les modules permettant le firewalling et la gestion de la Qos.

2.1. Pourquoi recompiler notre noyau ?

Le noyau de base installé sur notre Zaurus supporte diverses fonctionnalités qui sont directement intégrées dans le noyau ou sous forme de module. Dans la majorité des cas ce noyau est suffisant pour une exploitation normal de l’appareil et à la reconnaissance de la plupart des matériels.

Mais imaginons que nous ayons reçu un nouveau matériel qui ne serait pas reconnu ou que nous souhaitions intégrer une fonction qui ne serait pas implémentée. C’est alors qui nous faudrai recompiler le noyau pour cette prise en charge.

En fait j’ai fais cette doc, car les modules relatifs à la gestion d’un firewall n’était pas intégrés dans le noyau fourni en standard. Bon dacoord cela n’est pas vital à l’exploitaion d’un Zaurus mais pourquoi s’en priver. La machine pour laquelle je recompile le noyau est une SLC-1000 (akita), la méthode reste la même pour un autre type de machine (voir /stuff/org.openembedded.oz354x/conf/machine/ )

2.2. Compilation du noyau

Pour permettre la compilation d’un noyau Zaurus sous X86, il est necessaire d’installer l’environnement de cross-compilation comme indiqué dans ce document: Environnement de développement pour Zaurus Cette première étape ayant été franchie, nous allons maintenant tester notre environnement. Commencons simplement par la compilation d’une image zImge.bin et initrd.bin minimum (bootstrap). Nous commencons par charger le module jffs2 pour la création de l’image initrd.bin

(modprobe jffs2)
bitbake task-bootstrap
bitbake bootstrap-image

Des dépendances sont tout dabord compilées (ipkg-utils-native, file-native, flex-native, bison-native, binutils-cross, gcc-cross-initial, linux-libc-headers, glibc, gmp-native, mpfr-native, gcc-cross) puis débute la création des packages ipk.

Nota: Les sources du noyau sont décompressées dans / stuff/tmp/work/akita-linux/linux-openzaurus-2.6.16-r??/linux-2.6.16/, une série de patchs est appliquée, le fichier de config est copié à la racine des sources et la compilation débute … La configuration du noyau standard est présente dans le fichier (selon la machine utilisée): /stuff/org.openembedded.dev/packages/linux/linux-openzaurus-2.6.16/defconfig-akita A l’issue de la compilation le noyau zImage… est présent dans /stuff/tmp/deploy/images/ , des packages ont été crées dans /stuff/deploy/ipkg

2.3. Configuration d’un nouveau noyau

Pour éviter de modifier manuellement le fichier de configuration nous utiliserons le script make des sources du noyau. Tout dabord sauvegarde de la config de base


cp /stuff/org.openembedded.oz354x/packages/linux/linux-openzaurus-2.6.16/defconfig-akita \
   /stuff/org.openembedded.oz354x/packages/linux/linux-openzaurus-2.6.16/defconfig-akita.orig

Les divers menus nous permettent de customiser notre noyau.

J’ajoute la gestion iptables pour la prise en charge du firewalling (Dans Networking/Networking options/Network packet filtering/Core Netfilter Configuration et Netfilter Configuration). Pour les courageux il est aussi possible d’ajouter la gestion de la QoS.

Ensuite je sauvegarde et sors de l’utilitaire de configuration.

Le fichier .config est présent avec toutes nos modifications, c’est donc celui-ci qui sera utilisé lors de la compilation du noyau. Pour cela on remplace la config du package linux-openzaurus.

cp .config /stuff/org.openembedded.oz354x/packages/linux/linux-openzaurus-2.6.16/defconfig-akita

La config de notre noyau étant terminée, comment pouvons nous indiqué à bitbake qu’il lui faut intégrer les nouveaux modules ?

Voyons voir le fichier qui permet cette compilation de l’image minimal. Et comme les choses sont bien faites, il se nomme bootstrap-image.bb

vi /stuff/org.openembedded.oz354x/packages/meta/bootstrap-image.bb

Pas bavard :( par contre on apprend qu’il depend de task-bootstrap

Lecture de celui-ci et la encore des dépendances.

vi /stuff/org.openembedded.oz354x/packages/meta/task-bootstrap.bb
...
RDEPENDS = 'base-files base-passwd busybox \
        initscripts \
        netbase sysvinit sysvinit-pidof tinylogin \
        modutils-initscripts fuser setserial\
        ${HOTPLUG} \
        ${BOOTSTRAP_EXTRA_RDEPENDS} \
        ${@bootstrap_modutils_rdepends(d)}'

L’une d’elle nous intéresse plus particulièrement : BOOTSTRAP_EXTRA_RDEPENDS

Bon très bien mais comment je fais pour savoir d’ou elle est héritée ? On cherche :)

find /stuff/org.openembedded.oz354x | xargs grep BOOTSTRAP_EXTRA_RDEPENDS

oh oh apparement ces dépendances sont fournies par dans les fichiers de config relatifs au type de machines c’est à dire /stuff/org.openembedded.oz354x/conf/machine/*

et moi j’ai un akita

J’ouvre donc le fichier /stuff/org.openembedded.oz354x/conf/machine/akita.conf

Aie pas de BOOTSTRAP_EXTRA_RDEPENDS par contre ce fichier hérite aussi de conf/machine/zaurus-clamshell-2.6.conf Dans celui-ci on y trouve enfin notre, ou plus exactement nos BOOTSTRAP_EXTRA_RDEPENDS

C’est donc dans celui-ci que nous pourrons ajouter nos nouveau modules.

Mais avant de les ajouter et nous faut en encore leurs noms exact.

Il y a peut être plus simple mais moi je compile un linux-openzaurus qui me générera les kernel-modules-* Puisque j’ai déjà fais une compilation du noyau je nettoie les sources pour la prise en compte de nos nouvelles options du kernel.


cd /stuff
ls /stuff/tmp/deploy/ipk/kernel* > avant.txt
rm /stuff/tmp/deploy/ipk/kernel* 
bitbake -c clean linux-openzaurus
bitbake linux-openzaurus
ls /stuff/tmp/deploy/ipk/kernel* > apres.txt
diff avant.txt apres.txt 

Voilà nous avons maintenant la liste des modules qui devront être intégrés à notre image.

Je les ajoute au fichier /stuff/org.openembedded.oz354x/conf/machine/zaurus-clamshell-2.6.conf

Bon certes j’ai été un peu gourmand :) Création de notre image bootstrap:

cd /stuff
rm tmp/deploy/images/*
bitbake -c clean bootstrap-image
bitbake -c clean linux-openzaurus
bitbake -c clean zaurus-updater
bitbake bootstrap-image

Nous pouvons maintenant de tester notre noyau en bootant directement sur l’image bootstrap que nous venons de créer.

Nota: faire un ‘Fn’ + ‘flechedroite’ pour avoir un prompt

Et un modprobe ip_tables nous confirme l’installation des nouveaux modules :) Et maintenant notre image GPE avec un kernel supportant Netfilter

3. Personnalisation de GPE

L’objectif de ce tutoriel étant donner un mode d’emploi permettant le personnalisation et la construction d’une image GPE française.

Notre image devra:

1 - Noyau - source 2.6.17

  • inclure les modules iptables de Netfilter et gestion de la Qos

  • inclure le module Frame Bruffer pour w100

  • modification du logo

2 - Audio/Video: + mplayer + vlc-gpe

3 - Bureautique + Abiword + vim

4 - Réseaux + tcpdump + nmap + kismet

5 - Localisation + française

6 - Personnalisation de matchbox

7 - Divers + firefox 1.5 + gpe-filemanager

8 - Suppression de programmes -gpe-edit

3.1. Préparation:

L’environnement de développement devra être mis en place (voir Environnement de développement pour Zaurus )

Au cours de cette doc je travaillerai dans l’arborescence de /stuff/org.openembedded.oz354x_fr qui sera une copie de /stuff/org.openembedded.oz354x. Je pourrai ainsi créer un fichier .diff


cp /stuff/org.openembedded.oz354x /stuff/org.openembedded.oz354x_fr
mv /stuff/org.openembedded.oz354x /stuff/org.openembedded.oz354x.orig

3.2. Noyau

Pour la personnalisation du noyau : voir Personnalisation du noyau

Modification du logo:

Le fichier linux-openzaurus_2.6.17.bb nous apprend que 3 patchs appliqués sont relatifs au logo.

${RPSRC}/logo_rotate_fix-r1.patch

${RPSRC}/logo_oh-r0.patch.bz2

${RPSRC}/logo_oz-r2.patch.bz2

$RPSRC est défini dans linux-openzaurus.inc et est égale a “ http://www.rpsys.net/openzaurus/patches/archive” En regardant le contenu de ces fichiers on peut constater que le patch logo_oz-r2.patch.bz2 contient les fichiers ppm des logos et que le patch s’applique aux 3 fichiers drivers/video/logo/logo_oz240_clut224.ppm / logo_oz480_clut224.ppm / logo_oz640_clut224.ppm dans les sources du noyau linux. Il nous suffit donc de modifier ces fichiers et de relancer la compilation du noyau. Tout dabord un peu de nettoyage


bitbake -c clean linux-openzaurus
rm /stuff/tmp/deploy/ipk/kernel*

On debute la compilation et la stopppe apres l’application des patchs

Ensuite nous modifierons les 3 fichiers logos … En fait pour un akita seul le fichier logo_oz640_clut224.ppm devra être remplacé.

Creation d’un logo PPM partir d’un image JPEG

#! /bin/bash
# Transformer le .jpg en paramètre du script en .pnm
jpegtopnm $1 > tmp.pnm
# Quantifier à 224 couleurs
pnmquant 224 tmp.pnm > tmp2.pnm

# Transformer au format PPM no raw
pnmnoraw tmp2.pnm > logo_oz640_clut224.ppm
rm tmp.pnm tmp2.pnm 

On relance à nouveau la compilation

bitbake linux-openzaurus

Et voilà notre nouveau noyau est prêt :)

Nous aurions pu pour le tester créer une image bootstrap.

bitbake bootstrap-image

Passons maintenant à la personnalisation de GPE.

Une copie du fichier gpe-image.bb nous permettra de personnaliser le contenu de notre image.


cp /stuff/org.openembedded.oz354x/packages/meta/gpe-image.bb/stuff/org.openembedded.oz354x/packages/meta/gpe-fr-image.bb

Nous modifierons le fichier /stuff/org.openembedded.oz354x/packages/meta/gpe-fr-image.bb en y ajoutantjuste avant ‘ export IPKG_INSTALL’ les divers GPE_EXTRA_INSTALL

3.3. Audio/Video

Ajout de mplayer

bitbake mplayer
bitbake mplayer-common

.. compilation et création de toutes les dépendances qui vont bien ...

GPE_EXTRA_INSTALL += mplayer

3.4. Bureautique

bitbake abiword
bitbake vim

GPE_EXTRA_INSTALL += abiword vim

J’ai aussi ajouté le fichier packages/base-files/base-files/share/dot.vimrc et modifié packages/base-files_3.0.14.bb pour avoir la colorisation sous vim.

3.5. Réseau

bitbake tcpdump
bitbake kismet
bitbake nmap

GPE_EXTRA_INSTALL += tcpdump kismet nmap

3.6. Localisation

Le fichier glibc_2.3.5+cvs20050627.bb sera modifié de manière a appliquer un patch qui modifiera libc/localedata/SUPPORTED. Inutile de compiler les langues qui ne nous intéresse pas. J’ai simplement ajouté la ligne suivante au fichier bb :

file://SUPPORTED_fr.patch;patch=1"

Le patch SUPPORTED_fr.patch sera à copier dans packages/glibc/glibc-cvs-2.3.5/ Pour l’instant j’ajoute simplement les paquets localisés.

GPE_EXTRA_INSTALL += gpe-aerial-locale-fr gpe-beam-locale-fr gpe-calendar-locale-fr gpe-clock-locale-fr gpe-contacts-locale-fr gpe-go-locale-fr gpe-login-locale-fr gpe-ownerinfo-locale-fr gpe-su-locale-fr gpe-taskmanager-locale-fr gpe-timesheet-locale-fr gpe-today-locale-fr gpe-todo-locale-fr gtk+-1.2-locale-fr gtk+-locale-fr libatk-1.0-locale-fr libglib-2.0-locale-fr libgpewidget-locale-fr libmimedir-0.3-locale-fr sylpheed-locale-fr

3.7. Modification de matchbox-common

cp /stuff/sources/matchbox-common-*.tar.gz .
tar xvzf matchbox-common-*.tar.gz

# modifications des fichiers situés dans matchbow-common*data/vfolders-pda/
# ...

tar cvzf matchbox-common-0.9.1.tar.gz matchbox-common-0.9.1/
cp matchbox-common-0.9.1.tar.gz /stuff/sources
bitbake -c clean matchbox-common 

3.8. Divers

bitbake firefox
bitbake gpe-filemanager

GPE_EXTRA_INSTALL += mplayer abiword vim gpe-filemanager gpe-aerial-locale-fr gpe-beam-locale-fr gpe-calendar-locale-fr gpe-clock-locale-fr gpe-contacts-locale-fr gpe-edit-locale-fr gpe-go-locale-fr gpe-login-locale-fr gpe-ownerinfo-locale-fr gpe-su-locale-fr gpe-taskmanager-locale-fr gpe-timesheet-locale-fr gpe-today-locale-fr gpe-todo-locale-fr gtk+-1.2-locale-fr gtk+-locale-fr libatk-1.0-locale-fr libglib-2.0-locale-fr libgpewidget-locale-fr libmimedir-0.3-locale-fr sylpheed-locale-fr

3.9. gpe-fr-image.bb

Au final notre fichier gpe-fr-image.bb ressemblera à:

...
DEPENDS = "task-bootstrap \
           meta-fr-gpe \
           ${GPE_EXTRA_DEPENDS}"


# Audio/Video
GPE_EXTRA_INSTALL += mplayer xmms

# Texte
GPE_EXTRA_INSTALL +=  abiword gnumeric vim gpdf

# Reseau
GPE_EXTRA_INSTALL += tcpdump kismet nmap

# Localisation francaise
GPE_EXTRA_INSTALL += gpe-aerial-locale-fr gpe-beam-locale-fr gpe-calendar-locale-fr gpe-clock-locale-fr gpe-contacts-locale-fr gpe-edit-locale-fr gpe-go-locale-fr gpe-login-locale-fr gpe-ownerinfo-locale-fr gpe-su-locale-fr gpe-taskmanager-locale-fr gpe-timesheet-locale-fr gpe-today-locale-fr gpe-todo-locale-fr gtk+-1.2-locale-fr gtk+-locale-fr libatk-1.0-locale-fr libglib-2.0-locale-fr libgpewidget-locale-fr libmimedir-0.3-locale-fr sylpheed-locale-fr

# Divers
GPE_EXTRA_INSTALL += firefox gpe-filemanager

export IPKG_INSTALL = "task-bootstrap gpe-task-base \
...

3.10. Reconstruction de l’image GPE

Puisque nous venons de modifier le fichier meta-gpe.bb il nous faut donc purger le package pour permettre sa reconstruction.

bitbake -c clean meta-gpe
bitbake gpe-fr-image

3.11. Toutes les modifications

Il est possible de construire un patch

diff -aburN org.openembedded.oz354x.orig/ org.openembedded.oz354x_fr > org.openembedded.oz354x_fr.diff

C'est ce que j'ai fais (voir le chapitre suivant :)

3.12. Annexe: Démarrage de GPE

http://www.oesf.org/forums/index.php?showtopic=18353&st=45

Ok, here’s breakdown how OZ launches its X11 system:

1. /etc/init.d/gpe-dm launches /etx/X11/Xserver

Xserver is a shellscript which sets mutliple paramters for the real X server, like rotation, DPI and input device and the selects the correct xserver binary as well. For OZ that would be kdrive-fbdev.

2. After the xserver is running, all scripts in /etc/X11/Xinit.d are sourced and executed.

Various things are configured at this stage: correct xmodmap (x11 keymapping), TS calibration if required and the mouse pointer is made invisible.

The last script launches gpe-login, the GPE login manager

3. After gpe-login is used to login as a user, a new xserver running with the permissions of $USER is launched and all scripts in /etc/init.d/Xsession.d are executed

At this stage all user-space stuff required for GPE operation is launched under the UID of $USER

(ipaq-sleep, gconfd, keylaunch etc)

The very last script in Xsession.d launches the GUI:

QUOTE

# cat 99xWindowManager

#!/bin/sh

exec x-window-manager

#

x-window-manager is a symlink handled by update-alternatives and points to the session file used to bring up the GUI.

Reroute that script to something else to launch another WM.

The typical GPE session consists of:

matchbox-panel

matchbox-desktop

matchbox-wm

4. buildoz.sh & oz

Créez et personnalisez simplement vos images, packages et feed

Les commandes suiavntes permettent de créer un environnement Debian, indépendant de la distribution utilisée.


wget http://dab.free.fr/buildoz/buildoz.sh
chmod +x buildoz.sh
./buildoz.sh

Un 'chroot' vers notre environnement fraichememt construit ...

chroot DebianOE /root/oechroot

Et voilà nous pouvons maintenant construire nos images.

oz build oz354X

:))

5. Openembedded & qemu

Qemu émule diverses actitectures dont une qui nous intéresse plus particulièrement : ARM :)

Il nous est donc possible d’émuler un Zaurus ? OUI :)

Pour écrire cet article je me suis inspiré des scripts fournis par la branche ‘Poky’ : http://projects.o-hand.com/poky

Pour pouvoir réaliser cela plusieurs prérequis sont nécessaires.

  • Diposer de la branche ‘Poky’ : se chrooter dans l’environnement DebianOE et construire la branche poky

chroot /mnt/DebianOE /root/oechroot
oz build poky

A l’issue de la compilation une image et un noyau sont créés.

ls /mnt/DebianOE/stuff/poky/build/tmp/deploy/images/

modules-2.6.17-qemuarm.tgz
oh-image-pda-qemuarm-20061008213718.rootfs.ext2
oh-image-pda-qemuarm-20061008213718.rootfs.tar.bz2
updater.sh.akita
zImage-2.6.17-qemuarm-20061008161924.bin

Nous avons maintenant tous les ingrédiants pour admirer le résultat

Au passage il faut noter que nous utiliserons l’emulateur qemu-system-arm fourni pas le package qemu-native. (Des patchs sont ajouter pour la prise en compte de l’ecran tactile)

qemu-system-arm -kernel zImage-2.6.17-qemuarm-20061008161924.bin -append "root=/dev/sda mem=64M" -M versatilepb -hda oh-image-pda-qemuarm-20061008213718.rootfs.ext2  -usb -usbdevice wacom-tablet

Il nous manque tout de même l’essentiel : le réseau :( Qemu accéde à la couche réseau par un tunnel créé entre la machine réelle et celle émulée. tout dabord nous allons créer l’interface ‘tun0’ sur la machine physique. chargeons pour cela le module adéquat.


modprobe tun

La configuration de l’interface tun0 se fait simplement # ifconfig tun0 10.1.1.1 Bon jusque là tout va bien on va faire la même manip sur la machine virtuelle. (en changeant simplement d’adresse ip )

modprobe tun

FATAL: Module tun not found. Aie le module n’est pas fourni :(:( … En effet aucun modules n’est présent dans /lib/modules/2.6.17/

hmmm ... :(((

Commentaires:

user_iconGuyou icon4 4/10/2006 - 13h45
Super article. Par contre, j'ai une question de béotien : existe-t'il un équivalent à Pose de Palm ? En fait, mon besoin serait de tester le soft avant de le déployer sur une vrai machine.
user_icondab icon4 6/10/2006 - 0h2
Apparement avec qemu c'est possible, mais jusqu'a maintenant je n'ai pas vraiment eu succès :(
Plus d'infos ici http://www.rpsys.net/openzaurus/qemu/
Voir aussi http://blog.hentges.net/?page_id=50 pour booter le zaurus sur NFS
user_iconUlhume icon4 12/10/2006 - 23h5
Excellent, je vais tester cela ce we :) En revanche, j'imagine que l'émulation s'arrête à l'ARM et que le reste du hardware Zaurus n'est pas pris en charge ?
user_icondab icon4 12/10/2006 - 23h29
En effet l'écran tactile n'est pas émulé :) Et dailleurs le boot et/ou le noyau ont dûs être modifiés pour cela car la souris fonctionne et il n'y a plus de calibrage écran.
Je pense y jeter un oeil (démarrage distrib poky) voir m'en inspirer pour tenter la même chose avec une simple OZ de base.
user_iconGuyou icon4 13/10/2006 - 23h22
Enorme.
Voila une semaine que j'ai décidé de partir à la recherche d'info sur le net, ne voyant aucune solution "clé en main". Et pan, voila que Dab réussi un grand pas.

Bravo.

As-tu regardé du coté de skyeye ? J'ai encore pas testé, mais ils semblent supporter l'émulation d'écran tactile et LCD. Je débute, mais je pense que c'est bon.
user_icondab icon4 14/10/2006 - 0h6
merci :)
Il me semble que qemu supporte aussi les touchscreens via l'emulation usb. ( -usb -usbdevice wacom-tablet ), mais franchement ce n'est pas si agréable qu'à la souris.
Skyeye c'est vrai je l'ai vu apparaitre dans temps à autres sur les forums mais je ne m'y suis jamais intéressé. Pour l'instant j'utilise plutot Openembedded :)
user_iconulhume icon4 7/8/2007 - 15h41
erratum:tar xvjf ipkg-utils-050831.tar.gzpartar xvzf ipkg-utils-050831.tar.gz  
user_icontheClimber icon4 12/11/2007 - 9h59
Bonjour, D'abord merci beaucoup pour ce tutorial très bien fait !! Même si je n'utilise pas OE pour Zaurus, c'était bien pratique pour l'installation. Si je rédige un commentaire ici c'est parce que je suis vraiment vraiment coincé pour faire fonctionner OE chez moi. En effet, ça fait maintenant plusieurs jours que je tourne en rond sans trouver de solution à mon problème. Alors si vous pouvez m'aider ... ça serait hyper cool. Alors voilà, j'ai installé OE et tout. Jusque là, tout va bien. J'ai configuré mon fichier local.conf. Ca me semble bon aussi, mais j'ai toujours pas réussi à compiler quoique ce soit pour la simple raison que glibc ne veut pas compiler. Et comme glibc est une dépendance de presque tout ...je suis un peu bloqué pour compiler des paquages. Alors l'erreur plus précisément à laquelle je suis confronté c'est que lorsque je lancer la compiltation de glibc (bitbate glibc) il me fait l'erreur dans le do_compile en me disant : /home/greg/OE/tmp/cross/lib/gcc-lib/mipsel-linux/3.3.4/../../../../mipsel-linux/bin/ld: cannot find -lgcc_eh Je vous épargne tous les détails. Mais donc c'est comme s'il ne comprennait pas l'argument -lgcc_eh qui est passé en paramètre de la dernière commande gcc initialisée. Bref, je suis bien embêté, et si vous avez une suggestion à me faire pour résoudre le problème je suis ouvert à toutes les propositions. Merci d'avance
user_icondab icon4 12/11/2007 - 10h52
Merci ça fait toujours plaisir :) Il semble qu'il lui manque la libgcc_eh dont je ne connais pas exactement l'utilité (exception handling). Si j'ai bien compris, tu as utilisé 'buildoz' pour la mise en place de l'environnement ? Et la machine est autre qu'un zaurus ? As tu modifié la variable MACHINE pour l'adapter à ta machine dans ton build/conf/locale.conf.
user_icontheClimber icon4 12/11/2007 - 11h36
Oui oui, la configuration du fichier local.conf a été adapté à ma situation : TARGET_OS = "linux" DISTRO = "nylon" MACHINE = "mtx-1" Alors supposons qu'il me manque cette librairie libgcc_eh qui est ce qui me semble le plus logique. As-tu une idée comment je peux installer des librairies dans l'environnement OE? Ou bien, comme spécifier dans les arguments de compilation de compiler éventuellement sans cette option? Peut-être aussi que c'est un bug au niveau de OE car la distribution "nylon" n'est plus très suivie ... pour peu qu'il y ait un conflit, je suis vu :-s J'ai aussi posé des question sur le chan IRC d'OE ...mais y'a pas bcp de réponses. Malheureusement, étant en Asie actuellement je suis en décalage par rapport aux heures de fréquentation des chan ;-)
user_icontheClimber icon4 12/11/2007 - 11h59
J'ai peut-être trouvé une explication à mon problème (en effet lié à libgcc_eh) ... mais toujours pas de solution. Si on jette un oeil sur la page suivante : http://www.diy-linux.org/pipermail/diy-linux-dev/2005-June/000556.html On propose de régler le problème en ajouter des arguments de compilation... cependant, j'ai pas la moindre idée de comment je peux faire ça dans OE? Sinon il dit aussi que la solution serait de recompiler gcc avec l'argument "--disable-shared" car sinon la libraire libgcc_eh n'est pas compilée. Alors je pense que ça peut aussi être une solution, mais penses-tu que je devrais recompiler le gcc de mon tout mon système pour régler le problème de cette façon? Ca fait beaucoup de travail... Bref, je suis encore toujours un peu perplexe face à mon problème. Merci d'avance pour les éventuels conseils :-)
user_icondab icon4 12/11/2007 - 12h12
Je te conseille d'utiliser 'buildoz' qui va te créer un envirionnement de développement indépendant de ton système. Ainsi tu peux y modifier et/ou recompiler ce que tu souhaites sans que cela ai d'incidence sur ton OS de base. Pour ce qui concerne l'utilisation de tes propres options de compilation vois du coté de la variable EXTRA_OECONF Sinon une excellente source pour la personnalisatikon des packages/images de OE: http://www.angstrom-distribution.org/openembedded-user-manual-available-pdf bon courage ;)
user_icontheClimber icon4 12/11/2007 - 12h47
Merci, je vais un peu me reneigner là dessus pour voir si ça peut me servir ;-)
user_icondendene icon4 10/1/2008 - 1h51
Bonjour, j'ai trouvé cette page et elle est vraiement interressante, j'ai rencontré le même probleme de theCliber et je suis totalemnt bloqué, j'ai essayé d'inclure la directive -disable-shared mais j'ai pas trouvé le bon endroit, je suis totalement bloqué, vous avez une idée???
user_icondendene icon4 10/1/2008 - 1h56
mon probleme c que lorsque je compile n'importe quel package, il es tsur qu'il va utiliser glibc alors lors de la phase de compilation il m' affiche glibc (bitbate glibc) /home/greg/OE/tmp/cross/lib/gcc-lib/mipsel-linux/3.3.4/../../../../mipsel-linux/bin/ld: cannot find -lgcc_eh
user_icondab icon4 10/1/2008 - 10h49
Bonjour et merci Si tu regarde les fichiers gcc...bb d'openembedded dans org.openembedded.dev/packages/gcc et que tu y recherche -disable-shared grep disable-shared * gcc-cross-initial.inc: --disable-shared \ gcc-native.inc: --disable-shared \ Tu peux constaté que l'option est utilisé dans la construction de gcc-native et de: grep gcc-cross-initial.inc * gcc-cross-initial* gcc-cross-kernel-3.3.3_3.3.3 gcc-cross-kernel-3.3.4_3.3.4 ... Tu peux tenter la recompilation de gcc de l'un de ces packages avec la commande bitbake -b org.openembedded.dev/packages/gcc/gcc-cross-initial_3.4.4.bb par exemple Sinon de quelle machine s'agit-il ?
user_icondendene icon4 10/1/2008 - 11h35
Bonjour merci pour votre réponse, en faite j'utilise la meme architecture de theCliber, mtx-1, nylon as tu une proposition? merci d'avance
user_icondendene icon4 10/1/2008 - 11h42
en faite bitbake utilise glibc2.3.3 et il arrive pas à trouve libgcc_eh j'ai fait une recherche de cette library dans l'arborescence, j'ai trouvé que le fichier existe mais je peux pas le copie ou faire aucune opération parcequ'il n'etais pas créer correctement ou une autre chose sa taille est seulement 8 octets, meme sous linux il m'indique son icon avec un petit fleche, je ne sais pas quoi dire un raccourcis ou il est supprimé A+
user_iconelhadi.dendene icon4 10/1/2008 - 12h47
Solution au probleme home/skikda/OE/tmp/cross/lib/gcc-lib/mipsel-linux/3.3.4/../../../../mipsel-linux/bin/ld: cannot find -lgcc_eh dû de l'intéret que apporte cette page je dépose la solution ici: 1. chercher la library libgcc.a (find | grep libgcc.a ) vous la trouvez dans un chemin comme ça: ./build/tmp/cross/lib/gcc-lib/mipsel-linux/3.3.4/libgcc.a telque mipsel-linux correspond à mon architecture moi j'utilise TARGET_OS = “linux” DISTRO = “nylon” MACHINE = “mtx-1″ 2. vous recopiez la library libgcc en libgcc_eh dans le meme endroit: cp ./build/tmp/cross/lib/gcc-lib/mipsel-linux/3.3.4/libgcc.a ./build/tmp/cross/lib/gcc-lib/mipsel-linux/3.3.4/libgcc_eh.a 3. relancez la compilation ça va marcher trés bien ;) note: ce probleme peut se répete dans plusisuers configuration et ça marche toujours comme ça je pense
user_icondab icon4 10/1/2008 - 14h2
ok merci ça aidera peut être d'autres personnes ;) Pour ce qui est du fichier de 8 octets j'imagine qu'il s'agit d'un lien symbolique non ?
user_iconelhadi.dendene icon4 10/1/2008 - 15h32
effectivement c'est un lien
user_iconelhadi.dendene icon4 4/3/2008 - 17h59
Bonjour, c moi encore je souhaite savoir quoi à faire, j'ai changé l'architecture de mtx-1 à ixp4xxbe malheureusement, j'obtiens trops d'erreurs, comme c'etait il est entrain d'utiliser l'ancienne architecture, sachant que j'ai modifié le repertoire TMPDIR pour éliminer se probleme mais rien n'est changé merci d'avance.
user_icondab icon4 4/3/2008 - 19h2
J'ai aussi rencontré des problèmes lorsque je changeais de type de machine (akita vers spitz), je te conseille de reprendre en totalité la construction de l'imageL. Conserve uniquement les fichiers bb éventuellement modifiés.
user_iconlamine icon4 24/6/2008 - 16h27
Salut les gars, j’ai une question un peut outline de ce que vous parlé, /*-Est-ce que avec Openembedded nous pouvons compiler des distributions Temps-réel comme xenomai /*- Et est-ce que la distribution ‘Nylon’ est temps-réel merci
user_icondab icon4 24/6/2008 - 19h49
salut Lamine, Il existe dans openembedded un noyau Linux appelé linux-rt, j'imagine que l'on doit pouvoir l'inégrer aux distributions existantes (non testé). Les distributions présentes dans le conf/distrib: amsdelta-oe.conf gmustix.conf openprotium.conf angstrom-2008.1.conf include openwrt-sdk.conf angstrom-2008.1-legacy.conf jlime-donkey.conf oplinux.conf asusoe.conf jlime-henchman.conf oplinux-uclibc.conf celinux-test.conf jlime-mongo.conf sharprom-compatible.conf chinook-compat.conf jlime-shrek.conf slugos.conf colinuxoe.conf mamona.conf slugos-native.conf ezx.conf mokoslug.conf ucslugc.conf foonas.conf nylon.conf unslung.conf generic.conf openmn.conf wrt54oe.conf generic-uclibc.conf openmoko.conf Et donc non xenomai n'est pas distribuée :( Sinon je ne pense pas que Nylon soit temps-reel mais peyt être me trompe-je ?
user_iconarnaud icon4 4/3/2010 - 10h55

Bonjour,

Je me lance actuellement dans la distribution linux pour l'embarqué.

Je suis tombé par hasard sur ton tuto. Très bon tuto, celà m'a beaucoup aidé pour mes manipulations, j'ai toujours des erreurs mais ça avance :).

J'en profite pour te donner les nouveaux liens que j'ai trouvé.

voici les nouveaux liens que j'ai réussis à chopper.

ipkg-utils : wget http://handhelds.org/download/packages/ipkg-utils/ipkg-utils-050831.tar.gz

oe : wget http://wiki.openembedded.net/snapshots/historical/OE.mtn.bz2

PS : existe il quelque part sur le net, un tuto fr assez récent sur openEmbedded et Bitbake?

J'ai l'impression que l'embarqué est le coté obscur de linux en france.


user_iconDab icon4 4/3/2010 - 11h17

Bonjour et merci pour les liens.

En effet peu de documentation française sur le sujet et la mienne n'est pas vraiment récente, je comprend que tu ai pu avoir quelques erreurs lors de la compilation. Un conseil si tu as une version d'openembedded qui fonctionne, garde la bien au chaud. Par curiosité, peux tu me dire sur quel type de machine tu envisage d'installer une image générée à la sauce Openembedded ?

Sinon as tu jeté un oeil du coté d'openwrt ?


user_iconarnaud icon4 4/3/2010 - 15h30

Pour l'instant je vais tester mon sytème sur QEmu x86, (Après avoir réparé toutes les erreurs). Ensuite le système sera embarqué sur une carte de développpement ARM possédant toute la bagatelle de périphériques utiles.

pour openwrt, je ne connaissais pas. Je vais regarder ça de plus près.


user_iconDab icon4 4/3/2010 - 23h30

Bon courage ... devenu trop chronophage pour moi ;)



Add a comment

Validator_logo
Catapulse v0.06
( 0.113925 s)