«« sommaire »»

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

Christophe BLAESS - novembre 2022

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, cartes Beaglebone Black et Raspberry Pi.

Variable d'environnement MACHINE

Comment Yocto Project 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 précédemment, 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 PowerPC
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 x86 32 bits
genericx86-64PC standard à processeur x86 64 bits
mpc8315e-rdbCarte pour processeur PowerQuicc II (PowerPC)
edgerouterRouteur à 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 machines 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-64 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"

On peut se demander ce que signifie le symbole «??=».

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
Loading cache: 100% |                                                                                                                                                         | ETA:  --:--:--
Loaded 0 entries from dependency cache.
Parsing recipes: 100% |########################################################################################################################################################| Time: 0:00:43
Parsing of 882 .bb files complete (0 cached, 814 parsed). 1438 targets, 59 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION           = "2.0.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "arm-poky-linux-gnueabi"
MACHINE              = "qemuarm"
DISTRO               = "poky"
DISTRO_VERSION       = "4.0.11"
TUNE_FEATURES        = "arm vfp cortexa15 neon thumb callconvention-hard"
TARGET_FPU           = "hard"
meta                 
meta-poky            
meta-yocto-bsp       = "HEAD:fc697fe87412b9b179ae3a68d266ace85bb1fcc6"

[...]
Sstate summary: Wanted 736 Local 18 Mirrors 0 Missed 718 Current 459 (2% match, 39% complete)
NOTE: Executing Tasks
NOTE: Tasks Summary: Attempted 3152 tasks of which 1568 didn't need to be rerun and all succeeded.

Lorsque bitbake s'arrête de travailler, nous pouvons voir la nouvelle image :

[build-qemu]$ ls tmp/deploy/images/
qemuarm  qemux86-64

[build-qemu]$ ls tmp/deploy/images/qemuarm/
core-image-minimal-qemuarm-20230722080734.qemuboot.conf
core-image-minimal-qemuarm-20230722080734.rootfs.ext4
core-image-minimal-qemuarm-20230722080734.rootfs.manifest
core-image-minimal-qemuarm-20230722080734.rootfs.tar.bz2
core-image-minimal-qemuarm-20230722080734.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.15.113+git0+957ddf5f9d_8f55d1b405-r0-qemuarm-20230722080734.tgz
modules-qemuarm.tgz
zImage
zImage--5.15.113+git0+957ddf5f9d_8f55d1b405-r0-qemuarm-20230722080734.bin
zImage-qemuarm.bin

[build-qemu]$

Nous pouvons lancer le script «runqemu» avec le nom de l’architecture «qemuarm» en paramètre.

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 BeagleBones. 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.

Lors des compilations précédentes nous étions dans le même répertoire pour réaliser les deux builds. Dans ce répertoire, deux sous-dossiers intéressants avaient été créés :

[build-qemu]$ ls
bitbake-cookerdaemon.log  cache  conf  downloads  sstate-cache  tmp

[build-qemu]$ 

Ces deux répertoires gagnent nettement à être partagés entre les différents builds. Cela permet d'améliorer nettement le temps de compilation et l'espace occupé sur le disque de travail.

Personnellement, j'ai l'habitude de placer ces deux dossiers à côté des répertoires `layers` et `builds` que nous avons créés plus tôt. Je vais donc commencer par les déplacer.

[build-qemu]$ mv  downloads/  ../../

[build-qemu]$ mv  sstate-cache/  ../../

[build-qemu]$ cd  ../../

[Yocto-lab]$ ls
builds  downloads  layers  sstate-cache

[Yocto-lab]$

Bien entendu, il va falloir indiquer à Yocto l'emplacement de ces deux dossiers. Commençons par préparer un nouveau répertoire de compilation :

[Yocto-lab]$ source  layers/poky/oe-init-build-env  builds/build-bbb

Pour indiquer à Yocto où se trouvent les deux répertoires ci-dessus, nous allons éditer le fichier conf/local.conf.

Le fichier conf/local.conf regroupe les paramètres de configuration concernant le build que nous nous préparons à lancer depuis le répertoire de travail. Tout le contenu de conf/local.conf (et plus globalement le contenu essentiel des recettes utilisées par Yocto) se présente sous la forme :

VARIABLE = "<value>"

Les lignes blanches sont ignorées et celles commençant par un «#» représentent des commentaires.

Nous allons renseigner dans ce fichier la variable «MACHINE», pour cela il nous suffit de dé-commenter la ligne :

#MACHINE ?= "beaglebone-yocto"

Inutile de s'inquiéter de la ligne «MACHINE ??= "qemux86-64"» plus bas. L'opérateur «??=» est moins prioritaire que «?=» et sera ignoré.

Deux autres modifications vont être nécessaires. Nous allons dé-commenter et modifier les deux lignes :

#DL_DIR ?= "${TOPDIR}/downloads"

et

#SSTATE_DIR ?= "${TOPDIR}/sstate-cache"

Elles indiquent l'emplacement des répertoires que nous avons déplacés précédemment. Il faut donc les modifier pour indiquer que ces deux dossiers se trouvent finalement deux niveaux plus haut. Elles deviennent donc :

DL_DIR ?= "${TOPDIR}/../../downloads"
SSTATE_DIR ?= "${TOPDIR}/../../sstate-cache"

Ces modifications faites, nous pouvons lancer un nouveau build qui sera un peu plus court puisqu'il pourra bénéficier en partie du travail réalisé lors de la compilation pour qemuarm.

[build-bbb]$ bitbake  core-image-minimal
Loading cache: 100% |                                                                                                                                                                                                        | ETA:  --:--:--
Loaded 0 entries from dependency cache.
Parsing recipes: 100% |#######################################################################################################################################################################################################| Time: 0:00:17
Parsing of 883 .bb files complete (0 cached, 883 parsed). 1644 targets, 63 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION           = "2.0.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "ubuntu-22.04"
TARGET_SYS           = "arm-poky-linux-gnueabi"
MACHINE              = "beaglebone-yocto"
DISTRO               = "poky"
DISTRO_VERSION       = "4.0.11"
TUNE_FEATURES        = "arm vfp cortexa8 neon callconvention-hard"
TARGET_FPU           = "hard"
meta                 
meta-poky            
meta-yocto-bsp       = "HEAD:fc697fe87412b9b179ae3a68d266ace85bb1fcc6"

Initialising tasks: 100% |####################################################################################################################################################################################################| Time: 0:00:02
Sstate summary: Wanted 1241 Local 484 Mirrors 0 Missed 757 Current 0 (39% match, 0% complete)
NOTE: Executing Tasks
NOTE: Tasks Summary: Attempted 3307 tasks of which 1582 didn't need to be rerun and all succeeded.

Sur la dernière ligne de ce compte-rendu, nous pouvons voir que 1582 tâches n'ont pas eu besoin d'être relancées, bénéfice des deux répertoires partagés ci-dessus.

[build-bbb]$ ls  tmp/deploy/images/beaglebone-yocto/
  [...]
 core-image-minimal-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 que je suis sûr que les deux partitions sont bien démontées, je viens écrire le fichier d'extension «.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-minimal-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 (suivant les versions de BeagleBone 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, rouge et noir de la figure I.3-3).

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

U-Boot SPL 2022.01 (Jan 10 2022 - 18:46:34 +0000)
Trying to boot from MMC1


U-Boot 2022.01 (Jan 10 2022 - 18:46:34 +0000)

CPU  : AM335X-GP rev 2.1
Model: TI AM335x BeagleBone Black
DRAM:  512 MiB
WDT:   Started wdt@44e35000 with servicing (60s timeout)
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... <ethaddr> not set. Validating first E-fuse MAC
Net:   eth2: ethernet@4a100000, eth3: usb_ether
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
1:      Yocto
Retrieving file: /zImage
append: root=PARTUUID=ce1e71a2-02 rootwait console=ttyS0,115200
Retrieving file: /am335x-boneblack.dtb
Kernel image @ 0x82000000 [ 0x000000 - 0x77b6e8 ]
## Flattened Device Tree blob at 88000000
   Booting using the fdt blob at 0x88000000
   Loading Device Tree to 8ffec000, end 8ffff64e ... OK

Starting kernel ...

Le bootloader U-boot 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.

Booting Linux on physical CPU 0x0
Linux version 5.15.54-yocto-standard (oe-user@oe-host) (arm-poky-linux-gnueabi-gcc (GCC) 11.3.0, GNU ld (GNU Binutils) 2.38.20220708) #1 PREEMPT Thu Jul 14 18:52:26 UTC 2022
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
Zone ranges:
  Normal   [mem 0x0000000080000000-0x000000009fefffff]
  HighMem  empty
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x0000000080000000-0x000000009fefffff]
Initmem setup node 0 [mem 0x0000000080000000-0x000000009fefffff]
CPU: All CPU(s) started in SVC mode.
   [...]
mmc0: new high speed SDHC card at address 1234
mmcblk0: mmc0:1234 SA16G 14.5 GiB 
 mmcblk0: p1 p2
EXT4-fs (mmcblk0p2): INFO: recovery required on readonly filesystem
EXT4-fs (mmcblk0p2): write access will be enabled during recovery
mmc1: new high speed MMC card at address 0001
mmcblk1: mmc1:0001 MMC04G 3.60 GiB 
mmcblk1boot0: mmc1:0001 MMC04G 2.00 MiB 
mmcblk1boot1: mmc1:0001 MMC04G 2.00 MiB 
mmcblk1rpmb: mmc1:0001 MMC04G 128 KiB, chardev (247:0)
EXT4-fs (mmcblk0p2): recovery complete
EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null). Quota mode: disabled.
VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
devtmpfs: mounted
Freeing unused kernel image (initmem) memory: 1024K
Run /sbin/init as init process

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 3.01 booting
Starting udev
udevd[128]: starting version 3.2.10
udevd[129]: starting eudev-3.2.10
EXT4-fs (mmcblk0p2): re-mounted. Opts: (null). Quota mode: disabled.
Fri Mar  9 12:34:56 UTC 2018
Configuring packages on first boot....
 (This may take several minutes. Please do not power off the machine.)
Running postinst /etc/rpm-postinsts/100-sysvinit-inittab...
update-rc.d: /etc/init.d/run-postinsts exists during rc.d purge (continuing)
 Removing any system startup links for run-postinsts ...
  /etc/rcS.d/S99run-postinsts
INIT: Entering runlevel: 5
Configuring network interfaces... cpsw-switch 4a100000.switch: starting ndev. mode: dual_mac
SMSC LAN8710/LAN8720 4a101000.mdio:00: attached PHY driver (mii_bus:phy_addr=4a101000.mdio:00, irq=POLL)
udhcpc: started, v1.35.0
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: no lease, forking to background
done.
Starting syslogd/klogd: done

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

Poky (Yocto Project Reference Distro) 4.0.11 beaglebone-yocto /dev/ttyS0

beaglebone-yocto login: root
root@beaglebone-yocto:~# uname -a
Linux beaglebone-yocto 5.15.54-yocto-standard #1 PREEMPT Thu Jul 14 18:52:26 UTC 2022 armv7l GNU/Linux
root@beaglebone-yocto:~#
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:~#
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-».

Tous les layers que nous téléchargerons seront placés dans le répertoire global «layers/» de notre projet. C'est une habitude qui permet de conserver un certain ordre dans l'organisation de nos dossiers de travail.

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]$ cd layers/

[layers]$ git  clone  git://git.yoctoproject.org/meta-raspberrypi  -b kirkstone
Cloning into 'meta-raspberrypi'...
remote: Enumerating objects: 10626, done.
remote: Counting objects: 100% (81/81), done.
remote: Compressing objects: 100% (80/80), done.
remote: Total 10626 (delta 20), reused 0 (delta 0), pack-reused 10545
Receiving objects: 100% (10626/10626), 3.31 MiB | 24.73 MiB/s, done.
Resolving deltas: 100% (6049/6049), done.

[layers]$ ls
meta-raspberrypi  poky

[layers]$ cd ..

[Yocto-lab]$ 

Nous voyons qu’un répertoire «meta-raspberrypi/» est bien présent dans «layers/». Préparons un nouveau répertoire de travail.

[Yocto-lab]$ source  layers/poky/oe-init-build-env  builds/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 liste de ceux parcourus par bitbake lors du build. Commençons par voir la liste des layers déjà pris en compte.

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/Builds/Lab/Yocto-lab/layers/poky/meta  5
meta-poky             /home/Builds/Lab/Yocto-lab/layers/poky/meta-poky  5
meta-yocto-bsp        /home/Builds/Lab/Yocto-lab/layers/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é initialement. Nous pouvons également observer une valeur de priorité, qui indique l’ordre de prise en charge des layers (nous examinerons cela plus en détail ultérieurement).

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  ../../layers/meta-raspberrypi/
NOTE: Starting bitbake server...

[build-rpi]$ bitbake-layers  show-layers
NOTE: Starting bitbake server...
layer                 path                                      priority
==========================================================================
meta                  /home/Builds/Lab/Yocto-lab/layers/poky/meta  5
meta-poky             /home/Builds/Lab/Yocto-lab/layers/poky/meta-poky  5
meta-yocto-bsp        /home/Builds/Lab/Yocto-lab/layers/poky/meta-yocto-bsp  5
meta-raspberrypi      /home/Builds/Lab/Yocto-lab/layers/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 recettes 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» 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/Builds/Lab/Yocto-lab/layers/poky/meta \
  /home/Builds/Lab/Yocto-lab/layers/poky/meta-poky \
  /home/Builds/Lab/Yocto-lab/layers/poky/meta-yocto-bsp \
  /home/Builds/Lab/Yocto-lab/layers/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é. Il s'agit des fichiers avec l'extension .conf que l'on trouve dans le sous-dossier conf/machine du layer :

[build-rpi]$ls  ../../layers/meta-raspberrypi/conf/machine/
include                  raspberrypi2.conf     raspberrypi-cm3.conf
raspberrypi0-2w-64.conf  raspberrypi3-64.conf  raspberrypi-cm.conf
raspberrypi0-2w.conf     raspberrypi3.conf     raspberrypi.conf
raspberrypi0.conf        raspberrypi4-64.conf
raspberrypi0-wifi.conf   raspberrypi4.conf
NomCible
raspberrypiLes premiers modèles de 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 32 bits
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 Zéro initial
raspberrypi0-wifiLe second Raspberry Pi Zéro avec wifi
raspberrypi0-2wCarte de développement pour Pi Zéro W
raspberrypi0-2w-64Carte de développement pour Pi Zéro W en 64 bits.

Je vais lancer une compilation pour le Raspberry Pi 4, à ce jour la carte la plus puissante. Pour cela, je dois éditer le fichier conf/local.conf et ajouter les trois lignes suivantes (ou modifier les lignes existantes qui font la configuration par défaut :

MACHINE = "raspberrypi4"
DL_DIR ?= "${TOPDIR}/../../downloads"
SSTATE_DIR ?= "${TOPDIR}/../../sstate-cache"

Démarrons donc la compilation :

[build-rpi]$ bitbake  core-image-minimal

Loading cache: 100%
Loaded 0 entries from dependency cache.
Parsing recipes: 100% |#########################################| Time: 0:00:18
Parsing of 915 .bb files complete (0 cached, 915 parsed). 1676 targets, 70 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION           = "2.0.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "ubuntu-22.04"
TARGET_SYS           = "arm-poky-linux-gnueabi"
MACHINE              = "raspberrypi4"
DISTRO               = "poky"
DISTRO_VERSION       = "4.0.11"
TUNE_FEATURES        = "arm vfp cortexa7 neon vfpv4 thumb callconvention-hard"
TARGET_FPU           = "hard"
meta                 
meta-poky            
meta-yocto-bsp       = "HEAD:fc697fe87412b9b179ae3a68d266ace85bb1fcc6"
meta-raspberrypi     = "kirkstone:43683cb14b6afc144619335b3a2353b70762ff3e"

Initialising tasks: 100% |######################################| Time: 0:00:02
Sstate summary: Wanted 1161 Local 427 Mirrors 0 Missed 734 Current 0 (36% match, 0% complete)
NOTE: Executing Tasks
NOTE: Tasks Summary: Attempted 3011 tasks of which 1383 didn't need to be rerun and all succeeded.

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 «.wic.bz2», on peut le décompresser au préalable puis le copier sur la carte SD, ou utiliser bzcat pour le décompresser à la volée :

[build-rpi]$ ls tmp/deploy/images/raspberrypi4/core-image-minimal-raspberrypi4.*
tmp/deploy/images/raspberrypi4/core-image-minimal-raspberrypi4.ext3
tmp/deploy/images/raspberrypi4/core-image-minimal-raspberrypi4.manifest
tmp/deploy/images/raspberrypi4/core-image-minimal-raspberrypi4.tar.bz2
tmp/deploy/images/raspberrypi4/core-image-minimal-raspberrypi4.testdata.json
tmp/deploy/images/raspberrypi4/core-image-minimal-raspberrypi4.wic.bmap
tmp/deploy/images/raspberrypi4/core-image-minimal-raspberrypi4.wic.bz2

[build-rpi]$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0 931,5G  0 disk 
└─sda1        8:1    0 931,5G  0 part /home/Builds
sdb           8:16   1     0B  0 disk 
sdc           8:32   1  14,5G  0 disk 
├─sdc1        8:33   1    32M  0 part /media/cpb/boot
└─sdc2        8:34   1  31,4M  0 part /media/cpb/root
nvme0n1     259:0    0 931,5G  0 disk 
├─nvme0n1p1 259:1    0   512M  0 part /boot/efi
└─nvme0n1p2 259:2    0   931G  0 part /

[build-rpi]$ sudo umount  /dev/sdc?

[build-rpi]$ sudo  bash

# bzcat tmp/deploy/images/raspberrypi4/core-image-minimal-raspberrypi4.wic.bz2 > /dev/sdc

# exit

[build-rpi]$ 

On peut assister au boot classique du Raspberry Pi sur l’une des sorties micro-HDMI. L'image ci-dessous a été prise sur une version ultérieure, sa qualité est médiocre car l'écran était très petit.

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 pour cela d’éditer le fichier conf/local/conf et d'ajouter la ligne suivante (où l'on veut dans le fichier) :

	ENABLE_UART="1"

Il faut également relance «MACHINE=raspberrypi4 bitbake core-image-minimal» (pas d'inquiétude, cela ne dure que quelques secondes).

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.15.34-v7l (oe-user@oe-host) (arm-poky-linux-gnueabi-gcc (GCC) 11.3.0, GNU ld (GNU Binutils) 2.38.20220708) #1 SMP Tue Apr 19 19:21:26 UTC 2022
[    0.000000] CPU: ARMv7 Processor [410fd083] revision 3 (ARMv7), cr=30c5383d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[    0.000000] OF: fdt: Machine model: Raspberry Pi 4 Model B Rev 1.1
[    0.000000] random: fast init done
[    0.000000] Memory policy: Data cache writealloc
    [...]
udhcpc: started, v1.35.0
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: no lease, forking to background
done.
Starting syslogd/klogd: done

Poky (Yocto Project Reference Distro) 4.0.11 raspberrypi4 /dev/ttyS0

raspberrypi4 login: root

root@raspberrypi4:~# uname -a
Linux raspberrypi4 5.15.34-v7l #1 SMP Tue Apr 19 19:21:26 UTC 2022 armv7l GNU/Linux

root@raspberrypi4:~# cat /proc/cpuinfo
processor       : 0
model name      : ARMv7 Processor rev 3 (v7l)
BogoMIPS        : 108.00
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xd08
CPU revision    : 3

processor       : 1
model name      : ARMv7 Processor rev 3 (v7l)
BogoMIPS        : 108.00
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xd08
CPU revision    : 3
   [...]

Hardware        : BCM2711
Revision        : b03111
Serial          : 1000000079d9d08b
Model           : Raspberry Pi 4 Model B Rev 1.1

root@raspberrypi4:~# cat /sys/firmware/devicetree/base/model
Raspberry Pi 4 Model B Rev 1.1

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.

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). Ceci ne concerne que la première compilation pour une plateforme donnée. À partir de maintenant, nous observerons des temps de compilation beaucoup plus raisonnables !

Pour le moment nous n’avons pas du tout personnalisé notre image. Nous allons y remédier dans les séquences suivantes…

Ce document est placé sous licence Creative Common CC-by-nc. Vous pouvez copier son contenu et le réemployer à votre gré pour une utilisation non-commerciale. Vous devez en outre mentionner sa provenance.

Le nom Yocto Project est une marque déposée par la Linux Foundation. Le présent document n'est en aucune façon approuvé par Yocto Project ou la Linux Foundation.

«« sommaire »»