MACHINEDans 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.
MACHINEComment 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.
| Nom | Cible |
|---|---|
qemuarm | Émulation de système à processeur ARMv7 32 bits |
qemuarm64 | Émulation de système à processeur ARMv8 64 bits |
qemuarmv5 | Émulation de système à processeur ARMv5 |
qemuloongarch64 | Émulation de système à processeur loongarch 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 32 bits |
qemuppc64 | Émulation de système à processeur PowerPC 64 bits |
qemuriscv32 | Émulation de système à processeur Risc-V 32 bits |
qemuriscv64 | Émulation de système à processeur Risc-V 64 bits |
qemux86 | Émulation de système à processeur x86 32 bits |
qemux86-64 | Émulation de système à processeur x86 64 bits |
beaglebone-yocto | Famille de Single Board Computers ARM 32 bits |
genericarm64 | Machine générique à processeur ARM 64 bits |
genericx86 | PC standard à processeur x86 32 bits |
genericx86-64 | PC standard à processeur x86 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 ?= "genericarm64" #MACHINE ?= "genericx86" #MACHINE ?= "genericx86-64" # # 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.
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.8.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "arm-poky-linux-gnueabi" MACHINE = "qemuarm" DISTRO = "poky" DISTRO_VERSION = "5.0.2" TUNE_FEATURES = "arm vfp cortexa15 neon thumb callconvention-hard" TARGET_FPU = "hard" meta meta-poky meta-yocto-bsp = "HEAD:f7def85be9f99dcb4ba488bead201f670304379b" Sstate summary: Wanted 929 Local 25 Mirrors 0 Missed 904 Current 929 (2% match, 51% complete)############################################################################################################# | ETA: 0:00:00 Initialising tasks: 100% |#####################################################################################################################################################################################################| Time: 0:00:01 NOTE: Executing Tasks [...] NOTE: Tasks Summary: Attempted 4082 tasks of which 2328 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.rootfs-20240723160541.ext4 core-image-minimal-qemuarm.rootfs-20240723160541.manifest core-image-minimal-qemuarm.rootfs-20240723160541.qemuboot.conf core-image-minimal-qemuarm.rootfs-20240723160541.spdx.tar.zst core-image-minimal-qemuarm.rootfs-20240723160541.tar.bz2 core-image-minimal-qemuarm.rootfs-20240723160541.testdata.json core-image-minimal-qemuarm.rootfs.ext4 core-image-minimal-qemuarm.rootfs.manifest core-image-minimal-qemuarm.rootfs.qemuboot.conf core-image-minimal-qemuarm.rootfs.spdx.tar.zst core-image-minimal-qemuarm.rootfs.tar.bz2 core-image-minimal-qemuarm.rootfs.testdata.json modules--6.6.23+git0+f7f00b22ef_ceb94a8529-r0-qemuarm-20240723160541.tgz modules-qemuarm.tgz zImage zImage--6.6.23+git0+f7f00b22ef_ceb94a8529-r0-qemuarm-20240723160541.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.
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]$
downloads/ contient tous les fichiers sources qui ont été téléchargés (près de 5 Gb),sstate-cache qui contient des fichiers intermédiaires que Bitbake peut réutiliser (un peu plus de 5 Gb)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.8.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "arm-poky-linux-gnueabi" MACHINE = "beaglebone-yocto" DISTRO = "poky" DISTRO_VERSION = "5.0.2" TUNE_FEATURES = "arm vfp cortexa8 neon callconvention-hard" TARGET_FPU = "hard" meta meta-poky meta-yocto-bsp = "HEAD:f7def85be9f99dcb4ba488bead201f670304379b" Sstate summary: Wanted 1955 Local 0 Mirrors 0 Missed 1955 Current 0 (0% match, 0% complete)### | ETA: 0:00:00 Initialising tasks: 100% |############################################################################| Time: 0:00:00 NOTE: Executing Tasks NOTE: Tasks Summary: Attempted 4322 tasks of which 2482 didn't need to be rerun and all succeeded.
La dernière ligne nous indique que sur les 4322 tâches à réaliser pour produire l'image,
2482 n'ont pas été nécessaires, bénéfice du partage des dossiers downloads
et sstate-cache avec le build précédent.
[build-bbb]$ ls tmp/deploy/images/beaglebone-yocto/ [...] core-image-minimal-beaglebone-yocto.rootfs.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 [...] sdd 8:48 1 29,5G 0 disk ├─sdd1 8:49 1 50,4M 0 part /media/cpb/boot └─sdd2 8:50 1 228,8M 0 part /media/cpb/root [...]
La carte micro-SD est accessible ici en tant que «/dev/sdd». 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/sdd?
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/sdd» dans mon cas).
[build-bbb]$ sudo cp tmp/deploy/images/beaglebone-yocto/core-image-minimal-beaglebone-yocto.rootfs.wic /dev/sdd [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. La capture a été réalisée sur une installation de
la version corrective précédente de Poky (5.0.1 et non 5.0.2).
U-Boot SPL 2024.01 (Jan 08 2024 - 15:37:48 +0000) Trying to boot from MMC1 U-Boot 2024.01 (Jan 08 2024 - 15:37:48 +0000) CPU : AM335X-GP rev 2.1 Model: TI AM335x BeagleBone Black DRAM: 512 MiB Core: 160 devices, 18 uclasses, devicetree: separate WDT: Started wdt@44e35000 with servicing every 1000ms (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@4a100000using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in MAC de:ad:be:ef:00:01 HOST MAC de:ad:be:ef:00:00 RNDIS ready , 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=076c4a2a-02 rootwait console=ttyS0,115200 Retrieving file: /am335x-boneblack.dtb Kernel image @ 0x82000000 [ 0x000000 - 0x83a0e0 ] ## Flattened Device Tree blob at 88000000 Booting using the fdt blob at 0x88000000 Working FDT set to 88000000 Loading Device Tree to 8ffeb000, end 8ffff1df ... OK Working FDT set to 8ffeb000 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 6.6.21-yocto-standard (oe-user@oe-host) (arm-poky-linux-gnueabi-gcc (GCC) 13.3.0, GNU ld (GNU Binutils) 2.42.0.20240216) #1 PREEMPT Tue Mar 19 16:42:51 UTC 2024 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 on node -1 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. CPU: All CPU(s) started in SVC mode. [...] mmc0: new high speed SDHC card at address b368 mmcblk0: mmc0:b368 LX32G 29.5 GiB mmcblk0: p1 p2 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): orphan cleanup on readonly fs EXT4-fs (mmcblk0p2): mounted filesystem 6fe4f78e-91a6-434e-9875-6664635bc72e ro with ordered data mode. 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.04 booting Starting udev udevd[97]: starting version 3.2.14 udevd[98]: starting eudev-3.2.14 EXT4-fs (mmcblk0p2): re-mounted 6fe4f78e-91a6-434e-9875-6664635bc72e r/w. Quota mode: disabled. Fri Mar 9 12:34:56 UTC 2018 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.36.1 udhcpc: broadcasting discover udhcpc: broadcasting discover udhcpc: broadcasting discover udhcpc: no lease, forking to background ip: SIOCGIFFLAGS: No such device Starting syslogd/klogd: done
Il n’y a plus qu’à se connecter et tester quelques commandes.
Poky (Yocto Project Reference Distro) 5.0.2 beaglebone-yocto /dev/ttyS0 beaglebone-yocto login: root WARNING: Poky is a reference Yocto Project distribution that should be used for testing and development purposes only. It is recommended that you create your own distribution for production use. root@beaglebone-yocto:~# uname -a Linux beaglebone-yocto 6.6.21-yocto-standard #1 PREEMPT Tue Mar 19 16:42:51 UTC 2024 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 : 2014BBBK0007 root@beaglebone-yocto:~# root@beaglebone-yocto:~# cat /sys/firmware/devicetree/base/model TI AM335x BeagleBone Black
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-». C'est une convention, pas une obligation, mais il
est préférable de la respecter quand on crée son propre layer.
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 scarthgap loning into 'meta-raspberrypi'... remote: Enumerating objects: 11263, done. remote: Total 11260 (delta 8), reused 0 (delta 0), pack-reused 11223 Receiving objects: 100% (11260/11260), 3.49 MiB | 23.36 MiB/s, done. Resolving deltas: 100% (6519/6519), 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.conf» 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 variable 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 raspberrypi-cm3.conf raspberrypi0-wifi.conf raspberrypi3.conf raspberrypi-armv7.conf raspberrypi.conf raspberrypi0.conf raspberrypi4-64.conf raspberrypi-armv8.conf raspberrypi0-2w-64.conf raspberrypi2.conf raspberrypi4.conf raspberrypi-cm.conf raspberrypi0-2w.conf raspberrypi3-64.conf raspberrypi5.conf
| Nom | Cible |
|---|---|
raspberrypi | Les premiers modèles de Raspberry Pi B et B+ |
raspberrypi2 | Le Raspberry Pi modèle 2 |
raspberrypi3 | Les Raspberry Pi 3 et 3B+, compilation 32 bits |
raspberrypi3-64 | Les Raspberry Pi 3 et 3B+, compilation 64 bits |
raspberrypi4 | Le Raspberry Pi 4, compilation 32 bits |
raspberrypi4-64 | Le Raspberry Pi 4, compilation 64 bits |
raspberrypi5 | Le Raspberry Pi 5, compilation 64 bits |
raspberrypi-cm | Le premier Raspberry Pi Compute Module |
raspberrypi-cm3 | Le Raspberry Pi Compute Module 3 |
raspberrypi-armv7 | Support générique pour les Raspberry Pi 32 bits |
raspberrypi-armv8 | Support générique pour les Raspberry Pi 64 bits |
raspberrypi0 | Le Raspberry Pi Zéro initial |
raspberrypi0-wifi | Le second Raspberry Pi Zéro avec wifi |
raspberrypi0-2w | Carte de développement pour Pi Zéro W |
raspberrypi0-2w-64 | Carte de développement pour Pi Zéro W en 64 bits. |
La carte la plus puissante est à ce jour le Raspberry Pi 5. Toutefois, je préfère utiliser un
Raspberry Pi 4, car l'utilisation du port série du Raspberry Pi 5 (que j'emploierai par la suite)
est un peu plus complexe que ses prédecesseurs. Je dois éditer le
fichier conf/local.conf et ajouter les quatre lignes suivantes (ou modifier
les lignes existantes qui font la configuration par défaut :
MACHINE = "raspberrypi4"
ENABLE_UART = "1"
DL_DIR = "${TOPDIR}/../../downloads"
SSTATE_DIR = "${TOPDIR}/../../sstate-cache"
La variable ENABLE_UART est mise à 1 pour demander d'activer
une console sur le port série du Raspberry Pi, sur laquelle nous allons nous connecter.
Nous devons également ajouter une ligne qui accepte une licence spécifique pour le Bluetooth du Raspberry Pi 4 :
LICENSE_FLAGS_ACCEPTED += 'synaptics-killswitch'
Je lance la compilation avec une image un peu plus complète que la précédente :
core-image-base.
[build-rpi]$ bitbake core-image-base Loading cache: 100% | | ETA: --:--:-- Loaded 0 entries from dependency cache. Parsing recipes: 100% |###############################################################################| Time: 0:00:36 Parsing of 958 .bb files complete (0 cached, 958 parsed). 1914 targets, 71 skipped, 0 masked, 0 errors. NOTE: Resolving any missing task queue dependencies Build Configuration: BB_VERSION = "2.8.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "ubuntu-22.04" TARGET_SYS = "aarch64-poky-linux" MACHINE = "raspberrypi5" DISTRO = "poky" DISTRO_VERSION = "5.0.2" TUNE_FEATURES = "aarch64 crypto cortexa76" TARGET_FPU = "" meta meta-poky meta-yocto-bsp = "HEAD:f7def85be9f99dcb4ba488bead201f670304379b" meta-raspberrypi = "scarthgap:1918a27419dcd5e79954c0dc0edddcde91057a7e" Sstate summary: Wanted 2535 Local 2528 Mirrors 0 Missed 7 Current 0 (99% match, 0% complete)## | ETA: 0:00:00 Initialising tasks: 100% |############################################################################| Time: 0:00:03 NOTE: Executing Tasks NOTE: Tasks Summary: Attempted 5249 tasks of which 1906 didn't need to be rerun and all succeeded. [build-rpi]$ ls tmp/deploy/images/raspberrypi4/core-image-base-raspberrypi4.rootfs.* tmp/deploy/images/raspberrypi4/core-image-base-raspberrypi4.rootfs.ext3 tmp/deploy/images/raspberrypi4/core-image-base-raspberrypi4.rootfs.manifest tmp/deploy/images/raspberrypi4/core-image-base-raspberrypi4.rootfs.spdx.tar.zst tmp/deploy/images/raspberrypi4/core-image-base-raspberrypi4.rootfs.tar.bz2 tmp/deploy/images/raspberrypi4/core-image-base-raspberrypi4.rootfs.testdata.json tmp/deploy/images/raspberrypi4/core-image-base-raspberrypi4.rootfs.wic.bmap tmp/deploy/images/raspberrypi4/core-image-base-raspberrypi4.rootfs.wic.bz2
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».
Il existe également un fichier «.wic.bmap» qui
permet d'utiliser l'outil bmaptool pour copier le fichier
.wic.bz2 de manière optimisée :
[build-rpi]$ sudo bmaptool copy tmp/deploy/images/raspberrypi4/core-image-base-raspberrypi4.rootfs.wic.bz2 /dev/sdd bmaptool: info: discovered bmap file 'tmp/deploy/images/raspberrypi4/core-image-base-raspberrypi4.rootfs.wic.bmap' bmaptool: info: block map format version 2.0 bmaptool: info: 76083 blocks of size 4096 (297.2 MiB), mapped 30848 blocks (120.5 MiB or 40.5%) bmaptool: info: copying image 'core-image-base-raspberrypi4.rootfs.wic.bz2' to block device '/dev/sdd' using bmap file 'core-image-base-raspberrypi4.rootfs.wic.bmap' bmaptool: info: 100% copied bmaptool: info: synchronizing '/dev/sdd' bmaptool: info: copying time: 15.4s, copying speed 7.8 MiB/sec
On peut assister au boot classique du Raspberry Pi sur l’une des sorties micro-HDMI. L'écran photographié ci-dessous est très petit, la qualité de l'image est médiocre.
On peut également se connecter sur son port série en utilisant
minicom sur la machine hôte.
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 6.6.22-v7l (oe-user@oe-host) (arm-poky-linux-gnueabi-gcc (GCC) 13.3.0, GNU ld (GNU Binutils) 2.42.0.20240216)>
[ 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.5
[ 0.000000] random: crng init done
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] Reserved memory: created CMA memory pool at 0x000000000ec00000, size 512 MiB
[...]
[ 21.702522] cryptd: max_cpu_qlen set to 1000
Starting Linux NFC daemon
[ 21.790424] nfc: nfc_init: NFC Core ver 0.1
[ 21.794752] NET: Registered PF_NFC protocol family
[ 21.800739] Bluetooth: RFCOMM TTY layer initialized
[ 21.805702] Bluetooth: RFCOMM socket layer initialized
[ 21.810988] Bluetooth: RFCOMM ver 1.11
Poky (Yocto Project Reference Distro) 5.0.2 raspberrypi4 /dev/ttyS0
raspberrypi4 login: root
WARNING: Poky is a reference Yocto Project distribution that should be used for
testing and development purposes only. It is recommended that you create your
own distribution for production use.
root@raspberrypi4:~# uname -a
Linux raspberrypi4 6.6.22-v7l #1 SMP Tue Mar 19 17:41:59 UTC 2024 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 : 10000000c8cd6acf
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
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…
Si vous préférez une session de cours interactif, en mode présentiel ou distanciel, n'hésitez pas à vous inscrire à mes formations "Développeur Linux embarqué avec Yocto Project" ou "Yocto Project avancé" .
Ce document est placé sous licence Creative Commons 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.
