Cet article va vous présenter les étapes pour générer vous-même une image pour Raspberry Pi 4 avec Yocto et kas.
Cet article va vous présenter les étapes pour générer vous-même une image pour Raspberry Pi 4 avec Yocto et kas.
L’image générée pourra être écrite sur une carte SD et fera fonctionner un système minimal.
Le choix de la Raspberry Pi 4 a été fait car il s’agit d’une carte commune, représentant bien le monde de l’embarqué et de l’IoT.
Si vous possédez une autre Raspberry Pi, ne vous inquiétez pas, il sera possible pour vous de générer votre image, nous verrons ça un peu plus loin 😉.
Pour éviter d’installer une distribution spécifique et supporté par notre version de Yocto (Kirkstone pendant l’écriture de cet article), ainsi que tous les paquets nécessaires à la génération d’image, nous allons utiliser un container docker, dans lequel sera généré notre image.
Il est donc nécessaire d’avoir docker d’installé. Vous pouvez vous reporter à la page d’installation officielle de docker sur votre machine.
Pour simplifier la mise en place de ce container docker, nous allons utiliser un utilitaire utilisant kas, kas-container.
Cet utilitaire permettra de simplifier l’utilisation de docker pour générer nos images.
Dans un dossier de travail (nommé dev-rpi dans cet exemple), nous allons récupérer l’utilitaire kas-container.
wget https://github.com/siemens/kas/raw/3.3/kas-container
chmod +x kas-containerLa version taggué 3.3, car elle doit fournir le docker compatible avec Yocto en version kirkstone.
💡 La version 3.3 est la dernière version compatible officiellement avec la version kirkstone de Yocto. Il est possible d’utiliser la dernière version, mais il y aura un warning spécifiant que la version de la distribution n’a pas été testée avec kirkstone.
WARNING: Host distribution "debian-12" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.
Dans un dossier de travail (nommé dev-rpi dans cet exemple), nous allons initialiser le fichier projet pour que kas fonctionne correctement.
Voici le fichier projet nécessaire pour générer une image pour Raspberry Pi 4, basé sur poky en version kirkstone (project.yml):
header:
version: 14
machine: raspberrypi4-64
distro: poky
target: core-image-minimal
repos:
poky:
url: https://git.yoctoproject.org/git/poky
commit: e51bf557f596c4da38789a948a3228ba11455e3c
branch: kirkstone
path: layers/poky
layers:
meta:
meta-poky:
meta-openembedded:
url: http://git.openembedded.org/meta-openembedded
commit: 79a6f60dabad9e5b0e041efa91379447ef030482
branch: kirkstone
path: layers/meta-openembedded
layers:
meta-oe:
meta-python:
meta-raspberrypi:
url: https://github.com/agherzan/meta-raspberrypi/
path: layers/meta-raspberrypi
commit: 59a6a1b5dd1e21189adec49c61eae04ed3e70338
branch: kirkstone
local_conf_header:
debug-tweaks: |
EXTRA_IMAGE_FEATURES += "debug-tweaks"
ssh: |
EXTRA_IMAGE_FEATURES += "ssh-server-openssh"
💡 À ce niveau, vous avez donc seulement deux fichiers dans votre répertoire de travail: kas-container et project.yml, et c’est suffisant pour générer votre image !
Le fichier projet en YAML décrit les points important pour la génération de l’image.
header:
version: 14
La partie header (obligatoire) est utile à kas, elle permet de définir la version du format du fichier actuel (voir https://kas.readthedocs.io/en/latest/format-changelog.html pour le numéro de version du fichier YAML. Changer la version de la doc pour voir les versions supportés en fonction de la version de kas).
machine: raspberrypi4-64
La partie machine (obligatoire) définit la machine à supporter. On peut ici changer raspberrypi4-64 en d’autres machine si l’on ne possède pas de Raspberry Pi 4. (Voir meta-raspberrypi/conf/machine).
distro: poky
La partie distro (obligatoire) définit la distribution à utiliser, nous allons ici utiliser celle par défaut fournit par Yocto: poky.
target: core-image-minimal
La target (optionnelle) permet de définir une (ou plusieurs) image(s) à générer. Les images répondent à des besoins, elles contiennent des paquets et des fonctionnalités pour y répondre (audio, vidéo, réseau…). On utilise une image basique ici, core-image-minimal.
💡 core-image-minimal contient le minimum pour que le périphérique boot. Une liste des images disponible de base dans Yocto est disponible sur leur documentation.
repos:
poky:
url: https://git.yoctoproject.org/git/poky
commit: e51bf557f596c4da38789a948a3228ba11455e3c
branch: kirkstone
path: layers/poky
layers:
meta:
meta-poky:
meta-openembedded:
url: http://git.openembedded.org/meta-openembedded
commit: 79a6f60dabad9e5b0e041efa91379447ef030482
branch: kirkstone
path: layers/meta-openembedded
layers:
meta-oe:
meta-python:
meta-raspberrypi:
url: https://github.com/agherzan/meta-raspberrypi/
path: layers/meta-raspberrypi
commit: 59a6a1b5dd1e21189adec49c61eae04ed3e70338
branch: kirkstoneLa partie repo (obligatoire) permet de lister les différentes méta utilisées dans notre projet. Chaque méta est décrite par sont url, sont SHA de commit, sont path et aussi par les layers utilisés.
💡 Les commit id utilisés correspondent à des commits sur des tags de versions officielles.
Par exemple, pour poky le commit e8e3555cb977353df50b2e32a495c71f72494ce0 correspond à kirkstone-4.0.13.
Avec une version plus récente de kas (4.1 minimum) il est possible de spécifier des tags directement. Cela permet d’être plus explicite qu’un commit id.
local_conf_header:
debug-tweaks: |
EXTRA_IMAGE_FEATURES += "debug-tweaks"
ssh: |
EXTRA_IMAGE_FEATURES += "ssh-server-openssh"Une dernière configuration a été ajoutée : local_conf_header. Elle permet de définir des variables de configuration supplémentaires dans le fichier local.conf. Ici, deux configurations sont ajoutées: debug-tweak permettant de se passer de mot de passe root, et ssh-server-openssh pour avoir un serveur SSH sur la cible.
💡 Ces configurations ne sont pas obligatoires, mais elles nous permettent de facilement accéder à notre système. De plus debug-tweaksn’est pas du tout recommandé pour une image de production.
Pour générer l’image, il suffit simplement d’exécuter kas-container
./kas-container build project.ymlLa génération peut prendre du temps selon la puissance de calcul de votre machine hôte (10 min à plusieurs heures).
L’image générée se situe dans le dossier build, de façon générique, on peut la retrouver avec la machine et la target (aussi appelée image):
dev-rpi/build/tmp/deploy/images//-.wic.bz2
Dans notre cas (attention il s’agit d’un lien symbolique):
dev-rpi/build/tmp/deploy/images/raspberrypi4-64/core-image-minimal-raspberrypi4-64.wic.bz2
Il y a plusieurs moyens pour la copier sur la SDCard:
wic.bz2directement.nmap, on va pouvoir trouver notre carte sur le réseau, lancer la commande suivante avec le bon sous-réseau (correspondant au votre) avant et après avoir démarré votre Raspberry. Vous en déduirez son adresse IP.nmap -sn 192.168.1.0/24
...
Nmap scan report for raspberrypi4-64 (192.168.1.203)
Host is up (0.0048s latency).
...
Ensuite, connectez vous en SSH à votre Raspberry Pi:
ssh root@
root@raspberrypi4-64:~#
root@raspberrypi4-64:~# cat /etc/issue
Poky (Yocto Project Reference Distro) 4.0.13
L’image généré est basé sur core-image-minimal. Comme expliqué précédemment, cette image permet simplement de booter sur notre périphérique.
Avec la configuration local_conf_header dans le project.yaml, un server OpenSSH est ajouté, permettant les connexions SSH au périphérique.
Quelques fonctionnalités de base sont présentes:
rootCes caractéristiques sont celles par défaut de l’image, mais il est possible de modifier cela, ce que nous verrons dans un autre article 🙂.
Avec kas et Yocto, il est donc très simple de générer une image pour Raspberry. La configuration reste modifiable avec le fichier YAML, seul ce fichier peut être versionné (sous git par exemple). Avec kas il n’est plus nécessaire d’avoir un script shell, un fichier markdown ou tout autre document pour faire le setup d’un projet Yocto. De plus, le container kas-container permet d’avoir rapidement un build system compatible et reproductible.
Avec ce setup simple, il n’est pas possible (pour l’instant) de modifier la configuration d’une application, ou d’ajouter une application ne possédant pas de recette.
L’étape suivante va donc consister à créer notre meta custom, afin d’ajouter ou de modifier des recettes Yocto. Cette étape permettra de customiser finement notre image.
Si vous avez besoin d’assistance ou souhaitez des conseils pour personnaliser vos images, n’hésitez pas à nous contacter !
Nous contacter
Pour aller plus loin dans votre exploration des technologies embarquées, découvrez notre podcast dédié au Linux embarqué dans l’IoT. Nous y abordons les sujets essentiels comme l’utilisation de Yocto, Buildroot, les mises à jour OTA, et bien d’autres aspects de la sécurité et de la gestion des systèmes embarqués. Ce podcast, animé par nos experts, est une ressource incontournable pour mieux comprendre les enjeux du développement embarqué et comment Linux peut répondre aux besoins spécifiques des projets IoT.
Cet article est rédigé par Pierre-Olivier Huard, expert en Linux embarqué
Un peu de lecture
Des articles, des podcasts, des webinars… et surtout des conseils pratiques ! En bref, une collection de ressources pour mener à bien votre projet.
