Ingénierie et formations sur les systèmes libres
Nous avons vu dans le premier article de cette série comment construire une image de Zephyr OS pour Raspberry Pi Pico en utilisant un exemple basique (« blinky« ).
Nous allons à présent voir comment développer une application personnelle très simple, toujours sur le microcontrôleur pour Raspberry Pico.
Lire la suite de cette entrée »Zephyr 0S est un système d’exploitation temps réel que l’on peut utiliser sur de petits microcontrôleurs pour réaliser des tâches relativement simples avec un comportement temporel précis.
Nous allons l’étudier pendant quelques articles en nous appuyant sur des modèles de microcontrôleurs répandus, peu coûteux et faciles à se procurer comme le Raspberry Pi Pico.
Attention : il s’agit bien du « Raspberry Pi Pico » et pas du « Raspberry Pi Pico 2 » sorti il y a quelques semaines. Ce dernier est architecturé autour d’un microcontrôleur différent et n’est pas encore supporté par Zephyr Os au moment de la rédaction de cet article.
Lire la suite de cette entrée »
La future branche 6.12 du noyau Linux, qui sera publiée à la fin du mois de novembre, contiendra plusieurs nouveautés par rapport au noyau actuel. La plus commentée depuis deux semaines concerne l’intégration complète du patch PREEMPT_RT dans le noyau. Annoncée lors du Maintainer Summit du 17 septembre dernier, cette intégration se manifeste par un patch sur la fonction printk() qui représentait le dernier point de blocage.
Il n’y aura donc plus besoin de patch pour bénéficier de la préemptibilité totale du noyau sur les trois architectures principales pour le temps réel : x86, riscv et aarch64 (ARM 64 bits). Il faudra néanmoins toujours appliquer un patch (du moins pendant quelques temps) pour l’architecture ARM 32 bits par exemple.
Comment tester cette nouveauté ? C’est très simple : je vous propose de faire un build rapide pour une machine virtuelle Risc-V 64 bits en utilisant Buildroot et la version release candidate 6.12-rc2 du kernel, disponible depuis quelques heures.
Lire la suite de cette entrée »
Nous avons vu dans l’article précédent qu’il existe de nombreuses variables pour configurer le comportement de Bitbake lors d’un build de Yocto Project. Nous avons examiné précédemment les variables globales, qui sont valables durant tout le build.
Nous allons étudier à présent les principales variables contextuelles (on parle aussi de variables « scopées ») qui ne sont valides que dans certains contextes.
Les contextes qui nous intéresseront ici sont ceux des recettes (.bb) et des amendements de recettes (.bbappend).
Lorsqu’on effectue un build pour Yocto Project, l’outil bitbake parcourt des fichiers de configuration que nous avons pu examiner dans l’article précédent. Pendant ce parcours, un nombre important de variables sont remplies.
Il est facile de retrouver dans la documentation de Yocto Project la signification d’une variable, mais l’opération inverse n’est pas toujours facile : trouver quelle variable remplir pour répondre à un problème donné.
C’est la question à laquelle j’ai essayé de répondre dans cette série d’articles, en commençant par les variables globales, dont le contenu est disponible durant tout le build. Le prochain article traitera des variables définies dans les contextes de recette.
Lire la suite de cette entrée »
Lorsqu’on réalise un build pour un système Linux embarqué avec Yocto Project, de nombreux fichiers sont parcourus par l’outil Bitbake. Il n’est pas toujours simple de savoir dans quel ordre ces fichiers de configuration sont examinés, mais c’est pourtant une clé pour la bonne compréhension des opérations réalisées.
Nous allons nous intéresser ici aux fichiers de configuration et de données (distro, machine, image, recettes, etc.) pas aux fichiers python internes de Bitbake, ni aux fichiers sources, objets ou exécutables obtenus lors de la compilation des packages.
Bien sûr nous regarderons certains fichiers directement livrés avec Yocto, mais ce qui m’intéresse avant tout, c’est la connaissance des fichiers sur lesquels nous avons la possibilité d’agir, ceux que nous pouvons personnaliser avant de lancer le build.
Lire la suite de cette entrée »J’ai mis à jour mon cours en ligne « Linux embarqué avec Yocto » (gratuit, sous licence Creative Commons CC-BY-NC) avec la dernière version long terme de Yocto Project : « Poky Scarthgap »
La première édition de ce cours datait de janvier 2020 (Poky « Zeus » ), la deuxième de 2021 (Poky « Hardknott » ) et la troisième de 2023 (Poky « Kirkstone » ).
Ce cours est destiné aux personnes souhaitant découvrir l’utilisation de Yocto pour produire des systèmes Linux embarqués robustes et fiables.
Le texte est accompagné de beaucoup de manipulations que je vous encourage à refaire vous-même pour bien prendre en main cet environnement de build (la plupart des expérimentations ne nécessite qu’un PC sous Linux).
Le cours est accessible ici : https://www.blaess.fr/christophe/yocto-lab/.
Illustration : Lake District, England (fond de carte OpenStreetMap) les versions récentes de Yocto Project sont nommées à partir de lieux de ce parc national.
J’aime bien de temps en temps essayer des implémentations improbables, exécuter une tâche sur une plateforme inattendue ou l’écrire dans un langage peu approprié, juste pour l’exercice.
Par exemple, il y a quelques temps, je m’étais amusé à imbriquer des émulateurs Qemu les uns dans les autres, en compilant l’émulateur central sur une machine cible tournant avec Qemu. Une autre fois nous avions réussi, avec mon fils, à implémenter un jeu de la vie de Conway en utilisant uniquement le langage LaTeX.
Avec l’engouement actuel pour l’IA et plus particulièrement les LLM (Large Language Model), j’ai été séduit par l’idée de faire fonctionner un de ces modèles sur une plateforme non prévue pour cela : un Raspberry Pi.
Lire la suite de cette entrée »
Pour des applications où l’aspect sécurité est particulièrement important, on souhaite souvent s’assurer de l’intégrité de l’espace mémoire et des activités du noyau Linux. Pour cela on vérifie que les modules chargés dynamiquement dans le noyau (les fichiers avec l’extension .ko) sont bien conformes à ceux prévus à la production du système en les signant cryptographiquement.
Si cette étape est souvent réalisée automatiquement pour les distributions Linux courantes (voir par exemple https://www.kernel.org/doc/html/latest/admin-guide/module-signing.html), elle est un peu moins simple à mettre en oeuvre pour les systèmes embarqués produits avec Yocto.
Lors d’une récente session de formation « Écriture de drivers pour Linux » que j’animais pour Logilin, un participant m’a interrogé sur les méthodes à employer pour signer les modules dans un contexte de système embarqué. Nous n’avons pas eu le temps de développer ce sujet durant cette session, mais j’ai voulu détailler ce thème dans ce petit article.
Lire la suite de cette entrée »La fonctionnalité LFS (Large File Support) permet de superviser avec git des fichiers volumineux en évitant les téléchargements longs. Lors d’une opération git clone, le fichier original est remplacé par un fichier de référence beaucoup plus petit. Le remplacement inverse par le contenu initial n’a lieu que sur demande explicite.
Les anciennes versions de Yocto Project étaient capable d’extraire automatiquement les contenus LFS, mais il semble que cette fonctionnalité ait disparue depuis la branche Kirkstone de Poky. Nous pouvons y remédier assez simple en appelant explicitement git lfs pull dans une recette. Toutefois, l’écriture de la fonction nécessaire n’est pas intuitive et s’avère plutôt intéressante.
