Copyright © 2010 Sébastien Bocahu
Permission vous est donnée de copier, distribuer et/ou modifier ce document selon les termes de la Licence GNU Free Documentation License, Version 1.1 ou ultérieure publiée par la Free Software Foundation.
Une copie de cette Licence est incluse dans la section appelée GNU Free Documentation License de ce document et peut être consultée à l'adresse www.gnu.org/copyleft/fdl.html.
Définir rapidement ce qu'est l'embarqué, quelles sont les principales différences entre la plateforme x86 que nous connaissons bien et les plateformes embarquées.
Présentation d'outils libres dédiés ou utilisable pour l'embarqué. Bootloader, création de chaine de crosscompilation, création de rootfs, buildsystems, distributions
Un smartphone pas comme les autres: il est libre !
Les distributions Debian et Emdebian pour l'embarqué, la distribution/le buildsystem d'hackable:1 basé sur la distribution Debian
Un système embarqué peut être défini comme un système électronique et informatique autonome, qui est dédié à une tâche bien précise. Ses ressources disponibles sont généralement limitées. Cette limitation est généralement d'ordre spatial (taille limitée) et énergétique (consommation restreinte). ()
Notre système d'exploitation doit convenir à ces limitations. On retrouve généralement ces contraintes:
principalement dans le but de réduire les coûts et la consommation énergétique
Auquelles s'ajoutent d'autres éventuelles contraintes selon le produit:
Architecture processeur différente
Pas de “BIOS�?, initialisation du matériel par le bootloader, par exemple uboot
“L'embarqué�? est partout: toutes tailles, différents usages. quelques exemples facile à se procurer et/ou intéressants:
Bien que n'ayant pas été conçu pour l'embarqué, le couple GNU/Linux, et de nombreux projets libres qui gravitent autour s'adaptent aux limitations des plateforme embarqués.
Les avantages sont nombreux: (avantages “classiques�? du logiciel libre)
Compilation d'un logiciel pour une architecture cible différente de l'architecture actuelle (hôte)
Utilisation d'une chaine de compilation croisée (crosscompilation toolchain) qui contient:
Avantages de la crosscompilation:
Regardons à quoi ressemble U-boot !
Das U-Boot (Universal Bootloader) est un chargeur de démarrage pour différentes architectures, telles que PPC, ARM, AVR32, MIPS, x86, 68k, Nios, et MicroBlaze.
Permet de charger kernel/rootfs via tftp, nfs, serial
uboot> printenv bootargs
bootargs=console=ttyS0,115200 ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs'
uboot> tftpboot 0x6400000 uImage-2.6.30-sheevaplug
uboot> bootm 0x6400000
C'est plus pratique via serial, où est mon OpenRD-base ?!
Il nous faut un kernel !
Quelles sources ?
Quelle configuration ?
Exit les kernel GENERIC !
$ make ARCH=arm ${MACHINE}_defconfig
Initrd ou non ?
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
Uboot peut charger des images au format ELF (Executable and Linkable Format), ou son propre format: Uboot Image format, qui ajoute des informations sur le type du système d'exploitation, le point d'entrée… et est souvent préféré.
mkimage -A arm -O linux -T kernel -C none -a 30008000 -e 30008000 -n "Kernel" -d linux.bin uImage
Par exemple, debootstrap avec le repository Emdebian/grip (Ou en compilant busybox, comme dans la présentation de Pierre Ficheux :))
$ sudo debootstrap lenny grip/ http://www.emdebian.org/grip/
$ cd grip/dev; /dev/MAKEDEV -v generic console
... boot init=/bin/sh
/debootstrap/debootstrap --second-stage
Nous évoquerons par la suite quelques outils pour la création de rootfs
Utilisation d'une toolchain précedement installée/compilée
Appel du compilateur:
$ arm-linux-gnueabi-gcc -o hello hello.c
Autotools/autoconf:
$ ./configure --host=arm-linux-gnueabi
$ make
Makefile sans autoconf:
$ make CC=arm-linux-gnueabi-gcc
Variables d'environement de pkgconfig (souvent utilisé dans les Makefile)
$ export PKG_CONFIG_LIBDIR="/usr/arm-linux-gnueabi/usr/lib/pkgconfig"
$ export PKG_CONFIG_LIBDIR="$PKG_CONFIG_LIBDIR:/usr/arm-linux-gnueabi/usr/share/pkgconfig"
$ export PKG_CONFIG_SYSROOT_DIR="/usr/arm-linux-gnueabi"
Problèmes au moment de l'édition de liens
Si ld tente d'utiliser les librairies de l'hôte, ça ne fonctionnera evidemment pas…
Indiquez à ld où se trouvent les librairies:
LDFLAGS="-L/usr/arm-linux-gnueabi/lib -L/usr/arm-linux-gnueabi/usr/lib"
LDFLAGS="$LDFLAGS -Wl,-rpath-link /usr/arm-linux-gnueabi/lib"
LDFLAGS="$LDFLAGS -Wl,-rpath-link /usr/arm-linux-gnueabi/usr/lib"
-L: emplacement des librairies
-rpath-link: emplacement des librairies, nécessaire dans certains cas lors d'utilisation d'ELF ou sur Sun OS (voir la page de man)
-inst-prefix-dir permet d'installer les binaires dans un DESTDIR différent de l'emplacement réservé au logiciel dans le futur (stagging area). Libtool assure également que les binaires sont bien liés avec les librairies présentes dans ce répetoire. Il nous faut donc utiliser cet argument, avec comme parametre l'emplacement de notre toolchain.
Problème: il peut être nécessaire de patcher libtool pour la prise en compte de notre répertoire pour que l'édition de lien se passe correctement !
~2784 ltmain.sh
+ test -f "$inst_prefix_dir$add" && add="$inst_prefix_dir$add"
Nous évoquerons par la suite quelques outils pour la création de packages
Qemu est un logiciel d'émulation qui supporte de nombreuses architectures, dont ARM, MIPS, PPC… C'est un excellent outil pour tester, mais aussi debugguer grâce à son excelente intégration avec gdb
User mode emulation:
$ qemu-arm -L /usr/arm-linux-gnueabi ~/work/bin/mysoft
System emulation:
$ qemu-system-arm -kernel vmlinuz-arm -hda rootfs.img -append "root=/dev/sda1"
Debugging:
arm$ gdbserver 0.0.0.0:9999 mysoft
work$ arm-linux-gnueabi-gdb target/bin/mysoft
(gdb) target remote 127.0.0.1:9999
Un nom de projet
Comme Debian, Fedora, PostgreSQL, …
Une société
Openmoko Inc. basée à Taïwan
Un ensemble de suites logicielles
Om 2008, FSO, SHR, …
Un téléphone
Abus de langage bien pratique
Specs techniques
Neo Freerunner – Le premier vendu au public Début des ventes en juin 2008, encore réservé aux développeurs et bidouilleurs
Suite à des problèmes financiers importants, de très nombreux licenciements et l'abandon du projet GTA03, le troisième smartphone prévu, qui devait être doté de charactéristiques alléchantes:
Remplacé par un autre projet, moins couteu et mené à bien:
Le :
WIP: HTC Dream, Palm Pre, HTC Magician, HTC Kaiser, Raphael, Diamond, Blackstone, etc.
En concurence avec par Nokia et Intel…
.
Le projet Emdebian vise à “dégrossir�? Debian pour la rendre plus adaptée à l'embarqué:
Emdebian Crush: rendre Debian la plus petite possible, entraine des changements fonctionnels:
Outils pour la création de rootfs, toolchain, ajouts de nouveaux packages à Emdebian…
Hackable:1 est une distribution basée sur Debian et Gnome mobile, pour les “hackable devices�?: machines bidouillables, où l'on peut modifier le système d'exploitation…
Strap:1 est un outil de création de rootfs à partir de packages debian, en utilisant des “profils�? de packages nécessaires. En ce sens c'est une alternative aux outils de Debian debootstrap et cdebootstrap (ou emsandbox pour Emdebian).
Différents repositories peuvent être configurés (externes à Debian, personnel par exemple) et dpkg n'est jamais utilisé: seul le contenu est extrait, et lorsque celà est nécessaire des scripts peuvent être éxécutés lors de l'extraction d'un certain package (pour palier au manque des postinst par exemple)
├── build.sh
├── packages
│ ├── adduser
│ ├── alsa-utils
│ ├── apmd
│ ├── apt
│ ├── automake1.9
... ...
└── profiles
├── common.include
├── cross.include
├── developer.include
├── generic-bluetooth.include
├── generic-cross.include
├── generic-gps.include
├── generic-phone.include
├── generic-touchscreen.include
├── generic-wifi.include
├── Openmoko-Freerunner-cross.profile
├── Openmoko-Freerunner-developer.profile
├── Openmoko-Freerunner.include
... ...
$ ./build.sh VENDOR=Openmoko MODEL=Freerunner PURPOSE=developer archive
Pour Hackable:1, des logiciels doivent être crosscompilés, et packagés au format Debian.
Après avoir assimilé les différents problèmes basiques liés à la croscompilation (voir les “étapes typiques�? vu précedement), il suffit de les incorporer au packaging system.
En utilisant debhelper, quelques modifications sont à effectuer sur le Makefile debian/rules:
ifneq (\$(DEB_HOST_GNU_TYPE),\$(DEB_BUILD_GNU_TYPE))
CROSS= --build \$(DEB_BUILD_GNU_TYPE) --host \$(DEB_HOST_GNU_TYPE)
CROSS_CFLAGS=-I/usr/\$(DEB_HOST_GNU_TYPE)/include -I/usr/\$(DEB_HOST_GNU_TYPE)/usr/include
LDFLAGS=-L/usr/\$(DEB_HOST_GNU_TYPE)/lib -L/usr/\$(DEB_HOST_GNU_TYPE)/usr/lib
MAKE_LDFLAGS=-inst-prefix-dir /usr/\$(DEB_HOST_GNU_TYPE) -Wl,-rpath-link /usr/\$(DEB_HOST_GNU_TYPE)/lib
MAKE_LDFLAGS=$(MAKE_LDFLAGS) -Wl,-rpath-link /usr/\$(DEB_HOST_GNU_TYPE)/usr/lib
...
Jetons un oeil à mkdebpackaging.sh et au Makefile final
, des présentations sur l'embarqué ou le développement kernel
: trouvez d'autres geeks/hackers, des idées de projets, les prochains évênements, du matériel libre et/ou bidouillable !