Linux embarqué avec Yocto (étape I.3)


Christophe BLAESS – [WIP] Novembre 2019

I.3 – Production d’images pour des cibles spécifiques

Dans la séquence précédente nous avons créé une image standard pour une émulation de processeur x86. Nous allons à présent tester quelques autres cibles possibles : émulateur Arm, carte Beaglebone Black et Raspberry Pi.

Variable d’environnment MACHINE

Comment Yocto connaît-il la cible pour laquelle nous souhaitons préparer une image ?

Il s’appuie sur la variable d’environnement MACHINE. Celle-ci doit contenir le nom d’une cible connue par Yocto. Lorsqu’on utilise simplement les layers de Poky, comme nous l’avons fait, la liste est limitée.

NomCible
qemuarmÉmulation de système à processeur ARM 32 bits
qemuarm64Émulation de système à processeur ARM 64 bits
qemumipsÉmulation de système à processeur MIPS 32 bits
qemumips64Émulation de système à processeur MIPS 64 bits
qemuppcÉmulation de système à processeur PoxerPC
qemux86Émulation de système à processeur x86 32 bits
qemux86-64Émulation de système à processeur x86 64 bits
beaglebone-yoctoFamille de Single Board Computers ARM 32 bits
genericx86PC standard à processeur 32 bits
genericx86-64PC standard à processeur 64 bits
mpc8315e-rdbCarte pour processeur PowerQuicc II (PowerPC)
edegerouterRouteur à processeur MIPS 64 bits

Nous trouvons la liste de ces cibles dans les sous-répertoires poky/meta/conf/machine/ et poky/meta-yocto-bsp/conf/machine/.

Nous pouvons également les trouver au début du fichier conf/local.conf qui a été automatiquement créé lorsque nous avons appelé le script poky/oe-init-build-env pour la première fois.

 [build-qemu]$ head  -40  conf/local.conf
 [...]
#
# Machine Selection
#
# You need to select a specific machine to target the build with. There are a selection
# of emulated machines available which can boot and run in the QEMU emulator:
#
#MACHINE ?= "qemuarm"
#MACHINE ?= "qemuarm64"
#MACHINE ?= "qemumips"
#MACHINE ?= "qemumips64"
#MACHINE ?= "qemuppc"
#MACHINE ?= "qemux86"
#MACHINE ?= "qemux86-64"
#
# There are also the following hardware board target machine included for 
# demonstration purposes:
#
#MACHINE ?= "beaglebone-yocto"
#MACHINE ?= "genericx86"
#MACHINE ?= "genericx86-64"
#MACHINE ?= "mpc8315e-rdb"
#MACHINE ?= "edgerouter"
#
# This sets the default machine to be qemux86 if no other machine is selected:
MACHINE ??= "qemux86-64"
[...]

Dans ce fichier les lignes commençant par un caractère # sont considérées comme des commentaires. La seule qui configure la variable MACHINE est donc la dernière de cet extrait. C’est ainsi que Yocto a su qu’il devait nous préparer une image pouvant être prise en charge par l’émulateur Qemu-x86.

Mais nous voyons également que l’affectation de la variable est curieuse :

MACHINE ??= "qemux86"

Que signifie donc “??=” ?
Nous étudierons la syntaxe des fichiers de Yocto ultérieurement, mais précisons simplement pour le moment que cela signifie que la variable n’est affectée que si elle n’a pas de valeur préalable.

Autrement dit, nous pouvons remplir la variable avant de lancer bitbake et notre affectation aura précédence sur celle par défaut indiqué dans conf/local.conf.

Dans les prochaines étapes nous inscrirons le nom de la machine cible désirée dans ce fichier, mais pour le moment, contentons-nous d’interagir uniquement depuis la ligne de commande.

Image pour émulateur ARM

La syntaxe du shell nous permet de précéder une commande (comme bitbake) d’une affectation de variable d’environnement. Essayons cela tout de suite (prévoyez encore un petit moment de compilation)…

[build-qemu]$ MACHINE=qemuarm  bitbake  core-image-minimal
Parsing of 772 .bb files complete (0 cached, 772 parsed). 1298 targets, 63 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
Build Configuration:
BB_VERSION           = "1.44.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "arm-poky-linux-gnueabi"
MACHINE              = "qemuarm"
DISTRO               = "poky"
DISTRO_VERSION       = "3.0"
TUNE_FEATURES        = "arm armv7ve vfp thumb neon callconvention-hard"
TARGET_FPU           = "hard"
meta
meta-poky
meta-yocto-bsp       = "HEAD:94f6b31befda5c496f65e863a6f8152b42d7ebf0"
Initialising tasks: 100% |#############################################################################################| Time: 0:00:01
Sstate summary: Wanted 557 Found 15 Missed 542 Current 255 (2% match, 33% complete)
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks

NOTE: Tasks Summary: Attempted 2640 tasks of which 35 didn't need to be rerun and all succeeded.
Summary: There was 1 WARNING message shown

Après quelques temps, bitbake s’arrête, et nous pouvons voir la nouvelle image :

[build-quemu]$ ls  tmp/deploy/images/
qemuarm  qemux86-64
[build-quemu]$ ls  tmp/deploy/images/qemuarm/
core-image-minimal-qemuarm-20191030082847.qemuboot.conf
core-image-minimal-qemuarm-20191030082847.rootfs.ext4
core-image-minimal-qemuarm-20191030082847.rootfs.manifest
core-image-minimal-qemuarm-20191030082847.rootfs.tar.bz2
core-image-minimal-qemuarm-20191030082847.testdata.json
core-image-minimal-qemuarm.ext4
core-image-minimal-qemuarm.manifest
core-image-minimal-qemuarm.qemuboot.conf
core-image-minimal-qemuarm.tar.bz2
core-image-minimal-qemuarm.testdata.json
modules--5.2.17+git0+b867b78b50_47b80ef7bd-r0-qemuarm-20191030082847.tgz
modules-qemuarm.tgz
zImage
zImage--5.2.17+git0+b867b78b50_47b80ef7bd-r0-qemuarm-20191030082847.bin
zImage-qemuarm.bin
[build-quemu]$

Il nous faut à nouveau installer une version adaptée de Qemu pour processeur Arm.

[buid-quemu]$ sudo  apt  install  qemu-system-arm

Ensuite nous pouvons lancer le script runqemu avec le nom de l’architecture qemuarm en paramètre.

Figure I.3-1 – Exécution de commandes sur un émulateur ARM

La figure I.3-1 nous montre la fenêtre de l’émulateur et la commande uname -a nous indiquant que l’architecture est bien de type ARM.

Et sur une vraie cible embarquée ?

L’utilisation d’un émulateur comme Qemu présente de nombreux avantages pour la mise au point d’un système embarqué. Toutefois, cela a tendance à dissimuler les problèmes que l’on rencontre lorsque l’on passe à des cibles réelles (configuration du bootloader, flashage de la mémoire, connexion au système, etc.)

Dans les architectures connues par Yocto, il y a la famille des BeagleBone. Nous pouvons relancer un build pour cette architecture. Comme notre cible ne sera plus l’émulateur Qemu pour le moment, je préfère recréer un nouveau répertoire de compilation à côté de build-quemu.

Disons build-bbb comme abréviation de Beagle Bone Black, la carte que je vais utiliser.

[build-qemu]$ cd  ..
[Yocto-lab]$ source poky/oe-init-build-env build-bbb

Je relance une compilation avec une nouvelle architecture cible.

[build-bbb]$ MACHINE=beaglebone-yocto  bitbake  core-image-minimal
Parsing recipes: 100% |##########################################| Time: 0:00:40
Parsing of 772 .bb files complete (0 cached, 772 parsed). 1298 targets, 60 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
Build Configuration:
BB_VERSION           = "1.44.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "ubuntu-18.04
TARGET_SYS           = "arm-poky-linux-gnueabi"
MACHINE              = "beaglebone-yocto"
DISTRO               = "poky"
DISTRO_VERSION       = "3.0"
TUNE_FEATURES        = "arm vfp cortexa8 neon callconvention-hard"
TARGET_FPU           = "hard"
meta
meta-poky
meta-yocto-bsp       = "HEAD:94f6b31befda5c496f65e863a6f8152b42d7ebf0"
Initialising tasks: 100% |#######################################| Time: 0:00:01
Sstate summary: Wanted 519 Found 5 Missed 514 Current 236 (0% match, 31% complete)
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks

Après un “petit” moment de compilation, nous pouvons observer les images produites :

[build-bbb]$ ls tmp/deploy/images/beaglebone-yocto/
[...]
core-image-base-beaglebone-yocto.wic
[...]
[build-bbb]$

Je n’ai laissé apparaître que le fichier qui va nous servir directement, mais il y en a une trentaine dans ce répertoire (notamment des liens symboliques pointant vers des versions horodatées).

L’installation de l’image sur une Beaglebone Black est simple car Yocto a l’amabilité de nous fournir un gros fichier doté de l’extension .wic qui contient toutes les données à inscrire sur la carte micro-SD, y compris la table des partitions nécessaire. Le script wic qui crée ces fichiers est fourni par Poky comme bitbake ou runqemu.

J’insère sur mon PC de travail une carte micro-SD par l’intermédiaire d’un adaptateur USB. J’examine les périphériques blocs disponibles.

[build-bbb]$ lsblk 
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 465,8G 0 disk
├─sda1 8:1 0 400G 0 part /home/testing
└─sda2 8:2 0 8G 0 part [SWAP]
sdb 8:16 1 14,4G 0 disk
├─sdb1 8:17 1 64M 0 part /media/cpb/BOOT
└─sdb2 8:18 1 1G 0 part /media/cpb/ROOT

nvme0n1 259:0 0 232,9G 0 disk
├─nvme0n1p1 259:1 0 512M 0 part /boot/efi
├─nvme0n1p2 259:2 0 224,6G 0 part /
└─nvme0n1p3 259:3 0 7,8G 0 part
└─cryptswap1 253:0 0 7,8G 0 crypt

La carte micro-SD est accessible ici en tant que /dev/sdb. Comme elle contenait déjà des partitions elle a été auto-montée. Je la démonte pour la détacher du système de fichiers.

[build-bbb]$ umount /dev/sdb?

Une fois sûr que les deux partitions sont bien démontées, je viens écrire le fichier .wic directement sur l’ensemble du périphérique représentant toute la carte micro-SD (/dev/sdb dans mon cas)

[build-bbb]$ sudo  cp  tmp/deploy/images/beaglebone-yocto/core-image-base-beaglebone-yocto.wic  /dev/sdb
[build-bbb]$

Je peux à présent extraire la carte micro-SD de mon PC, l’insérer dans la Beaglebone Black et démarrer celle-ci (il peut être nécessaire de presser un bouton spécifique pour indiquer que l’on souhaite démarrer sur la carte micro-SD et non sur la mémoire eMMC interne).

Je me connecte sur la Beaglebone par l’intermédiaire d’un adaptateur USB-Série (les trois fils jaune, route et noir de la figure I.3-2)

Figure I.3-2 – Branchement de la Beaglebone Black

Nous pouvons examiner les traces de boot dans la console d’un émulateur de terminal (minicom) sur le poste de développement.

U-Boot 2019.07 (Oct 30 2019 - 12:41:34 +0000)
 CPU  : AM335X-GP rev 2.1
 Model: TI AM335x BeagleBone Black
 DRAM:  512 MiB
 NAND:  0 MiB
 MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
 Loading Environment from FAT… *** Warning - bad CRC, using default environment
  not set. Validating first E-fuse MAC
 Net:   eth0: ethernet@4a100000
 Warning: usb_ether MAC addresses don't match:
 Address in ROM is          de:ad:be:ef:00:01
 Address in environment is  d0:39:72:3b:d4:a6
 , eth1: usb_ether
 Hit any key to stop autoboot:  0 
 switch to partitions #0, OK
 mmc0 is current device
 SD/MMC found on device 0
 switch to partitions #0, OK
 mmc0 is current device
 Scanning mmc 0:1…
 Found /extlinux/extlinux.conf
 Retrieving file: /extlinux/extlinux.conf
 119 bytes read in 3 ms (38.1 KiB/s)
 1:      Yocto
 Retrieving file: /zImage
 6785528 bytes read in 435 ms (14.9 MiB/s)
 append: root=PARTUUID=36fb2077-02 rootwait console=ttyS0,115200
 Retrieving file: /am335x-boneblack.dtb
 58296 bytes read in 6 ms (9.3 MiB/s)
 Flattened Device Tree blob at 88000000
 Booting using the fdt blob at 0x88000000
    Loading Device Tree to 8ffee000, end 8ffff3b7 … OK

Le bootloader a fini de démarrer, de charger le noyau Linux en mémoire (fichier /zImage) ainsi que le device tree (fichier /am335x-boneblack.dtb) qui décrit le matériel présent. Le boot du noyau est à présent possible.


Starting kernel ...
 Booting Linux on physical CPU 0x0
 Linux version 5.2.17-yocto-standard (oe-user@oe-host) (gcc version 9.2.0 (GCC)) #1 PREEMPT Wed Oct 30 11:09:57 UTC 2019
 CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
 CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
 OF: fdt: Machine model: TI AM335x BeagleBone Black
 Memory policy: Data cache writeback
 cma: Reserved 16 MiB at 0x9e800000
 CPU: All CPU(s) started in SVC mode.
 AM335X ES2.1 (sgx neon)
[...]
Freeing unused kernel memory: 1024K

Cette dernière ligne indique que l’essentiel du démarrage du noyau est terminé, et qu’il passe le contrôle à l’espace utilisateur.

INIT: version 2.88 booting
Starting udev
udevd[124]: starting version 3.2.8
udevd[125]: starting eudev-3.2.8
 EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
 Wed Oct 30 12:39:54 UTC 2019
 INIT: Entering runlevel: 5
[...]
udhcpc: started, v1.31.0
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: no lease, forking to background
done.
Starting syslogd/klogd: done

Poky (Yocto Project Reference Distro) 3.0 beaglebone-yocto /dev/ttyS0
[...]
 beaglebone-yocto login:

Il n’y a plus qu’à se connecter et tester quelques commandes.

beaglebone-yocto login: root
root@beaglebone-yocto:~# uname -a
Linux beaglebone-yocto 5.2.17-yocto-standard #1 PREEMPT Wed Oct 30 11:09:57 UTC 2019 armv7l GNU/Linux
root@beaglebone-yocto:~# ls /
bin         etc         lost+found  proc        sys         var
boot        home        media       run         tmp
dev         lib         mnt         sbin        usr
root@beaglebone-yocto:~# cat /proc/cpuinfo 
processor       : 0
model name      : ARMv7 Processor rev 2 (v7l)
BogoMIPS        : 996.14
Features        : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x3
CPU part        : 0xc08
CPU revision    : 2
Hardware        : Generic AM33XX (Flattened Device Tree)
Revision        : 0000
Serial          : 6000BBBK7210
root@beaglebone-yocto:~# cat /sys/firmware/devicetree/base/model 
TI AM335x BeagleBone Black

Un Raspberry Pi sinon rien !

La carte fétiche des bidouilleurs Linux de nos jours est l’inévitable Raspberry Pi. Bien entendu Yocto permet de générer une image pour cette cible.
Toutefois, il nous faut télécharger un layer supplémentaire, un répertoire contenant les recettes et éléments de configuration propres à cette carte. Les layers de Yocto sont faciles à identifier, car leurs noms commencent par le préfixe meta-.

J’ai pour habitude de télécharger les layers que j’ajoute “à côté” du répertoire poky. Rien ne nous y oblige, il est possible de les regrouper dans un sous-dossier spécifique si on le préfère

Nous verrons dans les prochaines étapes comment rechercher un layer adapté à l’architecture ou à la fonctionnalité souhaitées. Dans un premier temps, acceptons simplement l’URL fournie ci-dessous.

[Yocto-lab]$ git  clone git://git.yoctoproject.org/meta-raspberrypi
[Yocto-lab]$ ls
build-bbb build-quemu meta-raspberrypi poky
[Yocto-lab]$

Nous voyons qu’un répertoire meta-raspberrypi est bien apparu.

Préparons à nouveau un répertoire de travail.

[Yocto-lab]$ source  poky/oe-init-build-env  build-rpi
You had no conf/local.conf file. This configuration file has therefore been
[...]
[build-rpi]$

Nous devons commencer par ajouter le layer téléchargé plus haut dans la configuration actuelle. Regardons d’abord la liste des layers déjà pris en compte par le build.

La commande bitbake-layers et son option show-layers vont nous servir.

[build-rpi]$ bitbake-layers show-layers
 NOTE: Starting bitbake server...
layer                 path                                      priority
meta                  /home/cpb/Yocto-lab/poky/meta  5
meta-poky             /home/cpb/Yocto-lab/poky/meta-poky  5
meta-yocto-bsp        /home/cpb/Yocto-lab/poky/meta-yocto-bsp  5

Trois layers sont déjà préconfigurés dans notre image. Ils se trouvent tous les trois dans le dossier poky téléchargés initialement. Nous pouvons également observer une valeur de priorité, qui indique l’ordre de prise en charge des layers (nous examinerons ça en détail cela dans une étape ultérieure).

Ajoutons le layer spécifique pour Raspberry Pi en utilisant l’option add-layer de l’outil bitbake-layers.

[build-rpi]$ bitbake-layers add-layer ../meta-raspberrypi/
NOTE: Starting bitbake server…
[build-rpi]$ bitbake-layers show-layers
NOTE: Starting bitbake server…
layer path priority
meta /home/cpb/Yocto-lab/poky/meta 5
meta-poky /home/cpb/Yocto-lab/poky/meta-poky 5
meta-yocto-bsp /home/cpb/Yocto-lab/poky/meta-yocto-bsp 5
meta-raspberrypi /home/cpb/Yocto-lab/meta-raspberrypi 9
[build-rpi]$

Nous voyons bien que le nouveau layer a été ajouté à la liste. Sa priorité est plus élevée que celles des autres. Son contenu sera donc analysé après celui des autres layers. Les fichiers de recette qu’il contient pourront donc surcharger les précédents et ajuster la configuration avant la compilation proprement dite.

Où cette liste de layers est-elle stockée ? Nous avons vu que le répertoire de compilation ne contient pas beaucoup de fichiers de configuration. Pourtant l’un d’eux peut attirer notre attention :

[build-rpi]$ ls conf/
bblayers.conf local.conf templateconf.cfg

Le fichier bblayers (bb représentant bitbake) contient ceci :

# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
  /home/cpb/Yocto-lab/poky/meta \
  /home/cpb/Yocto-lab/poky/meta-poky \
  /home/cpb/Yocto-lab/poky/meta-yocto-bsp \
  /home/cpb/Yocto-lab/meta-raspberrypi \
  "

Les premières lignes configurent une variable (POKY_BBLAYERS_CONV_VERSION) à usage interne de Poky, qui ne nous concerne pas. Nous voyons que la variables BBLAYERS, est renseignée (si ce n’est fait auparavant) avec les chemins vers les répertoires des layers.

Nous aurions très bien pu rajouter manuellement la dernière ligne plutôt qu’appeler bitbake-layers, mais l’avantage d’utiliser ce dernier est qu’il vérifie la cohérence de la configuration.

Voyons les versions de Raspberry Pi connues par le layer que nous avons téléchargé :

[build-rpi]$ ls  ../meta-raspberrypi/conf/machine/
include                 raspberrypi3-64.conf  raspberrypi-cm3.conf
 raspberrypi0.conf       raspberrypi3.conf     raspberrypi-cm.conf
 raspberrypi0-wifi.conf  raspberrypi4-64.conf  raspberrypi.conf
 raspberrypi2.conf       raspberrypi4.conf
NomCible
raspberrypiLes premiers modèles Raspberry Pi B et B+
raspberrypi2Le Raspberry Pi modèle 2
raspberrypi3Les Raspberry Pi 3 et 3b+, compilation 32 bits
raspberrypi3-64Les Raspberry Pi 3 et 3b+, compilation 64 bits
raspberrypi4Le Raspberry Pi 4, compilation 32bits.
raspberrypi4-64Le Raspberry Pi 4, compilation 64 bits.
raspberrypi-cmLe premier Raspberry Pi Compute Module
raspberrypi-cm3Le Raspberry Pi Compute Module 3
raspberrypi0Le Raspberry Pi Zero initial
raspberrypi0-wifiLe second Raspberry Pi Zero, avec Wifi

Je lance une compilation pour le Raspberry Pi 4, à ce jour le petit dernier de la gamme (et le plus puissant !) :

[build-rpi]$ MACHINE=raspberrypi4  bitbake  core-image-minimal
Parsing recipes: 100% |########################################################| Time: 0:00:46
Parsing of 801 .bb files complete (0 cached, 810 parsed). 1327 targets, 67 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
Build Configuration:
BB_VERSION           = "1.44.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "ubuntu-18.04"
TARGET_SYS           = "arm-poky-linux-gnueabi"
MACHINE              = "raspberrypi3"
DISTRO               = "poky"
DISTRO_VERSION       = "3.0"
TUNE_FEATURES        = "arm vfp cortexa7 neon vfpv4 thumb callconvention-hard"
TARGET_FPU           = "hard"
meta
meta-poky
meta-yocto-bsp       = "HEAD:94f6b31befda5c496f65e863a6f8152b42d7ebf0"
meta-raspberrypi     = "master:254c9366b9c3309db6dc07beb80aba55e0c87f94"
NOTE: Fetching uninative binary shim from http://downloads.yoctoproject.org/releases/uninative/2.7/x86_64-nativesdk-libc.tar.bz2;sha256sum=9498d8bba047499999a7310ac2576d0796461184965351a56f6d32c888a1f216
Initialising tasks: 100% |#####################################################| Time: 0:00:02
Sstate summary: Wanted 814 Found 0 Missed 814 Current 0 (0% match, 0% complete)
NOTE: Executing SetScene Tasks
[...]

Tout comme nous l’avons fait avec la carte BeagleBone Black précédemment, l’image produite est copiée sur une carte micro-SD que l’on prend soin de démonter auparavant. Le fichier à copier a une extension “rpi-sdimg” (et non pas “wic” comme c’est souvent le cas pour d’autres machines).

[build-rpi]$ ls  tmp/deploy/images/raspberrypi4/
  [...]
core-image-minimal-raspberrypi4.rpi-sdimg
  [...]
[build-rpi]$ umount  /dev/sdb?
[build-rpi]$ sudo  cp  tmp/deploy/images/raspberrypi4/core-image-minimal-raspberrypi4.rpi-sdimg   /dev/sdb
[build-rpi]$ 

On peut assister au boot classique du Raspberry Pi sur l’une des sorties micro-HDMI.

Figure I.3-3 – Boot du Raspberry Pi avec Yocto 2.7

On peut également se connecter sur son port série en utilisant minicom sur la machine hôte (dans le cas des Raspberry Pi 3 ou 4, il est nécessaire toutefois pour cela d’éditer le fichier config.txt se trouvant sur la première partition de la carte SD pour y ajouter la ligne “enable_uart=1“)

Poky (Yocto Project Reference Distro) 3.0 raspberrypi4 /dev/ttyS0
 raspberrypi4 login: root
 root@raspberrypi4:~# uname -a
 Linux raspberrypi4 4.19.80 #1 SMP Wed Oct 30 15:23:11 UTC 2019 armv7l GNU/Linux
 root@raspberrypi4:~# 

Conclusion

Cette séquence nous a permis de créer des images standards de Yocto pour différentes cibles et de les tester. Le passage de l’émulateur à une carte réelle est important. Cela permet de s’assurer de la disponibilité des outils nécessaires (notamment lorsqu’il faut employer un utilitaire spécifique pour placer le code en mémoire Flash Nand) et de la maîtrise des techniques employées.

Pour le moment nous n’avons pas du tout personnalisé notre image. Les temps de compilation que nous avons observés sont vraiment très longs (pas loin de dix heures de compilation entre cette séquence et la précédente). Nous allons devoir améliorer cela dans les séquences suivantes…