La version 3.0, Zeus, de Yocto et sa distribution de référence poky (version 24) sont sorties le 23 octobre 2019.
Il s’agit d’un environnement et une collection d’outils qui vous permettront de créer des distributions GNU/Linux sur mesure, principalement orientées vers le monde de l’embarqué. Cette version amène son lot de nouvelles recettes et de sauts de versions pour les composants qui serviront de base par défaut à vos distributions.
Il n’y a pas de grands changements dans la structure et les règles d’écriture des recettes et des configurations. Vous devriez pouvoir migrer facilement. Vérifiez que les meta‑layers tierces que vous utilisez soient déclarées compatibles avec cette version. Ajustez la variable LAYERSERIES_COMPAT_XXXX du fichier conf/layer.conf. Normalement, celles qui sont hébergées par le projet Yocto le sont automatiquement.
Sommaire
Mécanique
Yocto repose sur un ensemble de scripts qui vont analyser une liste de jeux de recettes organisés en meta, chaque recette configurant une suite de tâches à réaliser. De cette analyse sort un arbre de tâches que bitbake, le constructeur va lancer.
Dans cette version, le standard d’identification de licences SPDX a été adopté. La construction en une seule commande d’images pour différentes cibles, multiconfig, est considérée mature.
Bitbake
Les commandes --runall et --runonly, qui ne demandent la réalisation que d’un seul type de tâche, respectent désormais --force.
Précisez mc:prefix à bitbake -e pour afficher les configurations multiples. Notez que mc: est le raccourci pour multiconfig:.
Les tâches SetScene ont fusionnées avec les tâches RunQueue, ce qui permet de les exécuter en parallèle. En effet, il y a deux grandes catégories de tâches : SetScene permet de restaurer un état précédemment calculé et mis en cache, et RunQueue, lui, concerne l’exécution des tâches restantes. La variable BB_SETSCENE_VERIFY_FUNCTION2 est aussi ignorée. Les paramètres passés à la fonction définie dans BB_HASHCHECK_FUNCTION, appelée durant SetScene, ont changé.
Les définitions des tâches listées dans la variable BB_TASKDEPDATA doivent utiliser uniquement la signature <func>:<task>, les implémentations qui utilisaient encore un . comme délimiteur ont été modifiées.
compilation
Par défaut, ce sont gcc 9.2 et la glibc 2.30 qui s’en chargent.
Recettes
Les paramètres minver et maxver sont intégrés en option de SRC_URI pour les correctifs, afin de proposer une plus grande souplesse. De même, il est déconseillé d’utiliser la variable ${PN} (Package Name) dans SRC_URI, vous en serez averti lors des phases de contrôle d’intégrité (Sanity check).
Dans la même idée, il est désormais interdit d’utiliser ${PN} avec DEPENDS_, qui entretenait la confusion avec RDEPENDS_ qui, lui, est bien lié au paquetage.
Les variables TARGET_CFLAGS, TARGET_CPPFLAGS, TARGET_CXXFLAGS et TARGET_LDFLAGS ne sont plus exportées dans l’environnement.
La recette cve-update-db, basée sur la classe cve-check annule et remplace l’outil cve-check-tool. Ce nouvel outil utilise un flux NVD JSON en entrée plutôt que des données XML, obsolètes. En autre amélioration, il comprend la notation CVSSv37. De plus, la variable CVE_CHECK_CVE_WHITELIST est remplacée par CVE_CHECK_WHITELIST.
fonctions et scripts
La fonction bb.build.exec_func() ne prend plus en compte le paramètre pythonexception. Dans la même idée, l’exception bb.build.FuncFailed est supprimée, les exceptions sous‑jacentes seront levées à la place.
Architectures
De base, Yocto propose une liste d’architectures cibles, dont des cibles QEMU, que vous pouvez compléter par des meta maintenues par les fondeurs.
Cette version ajoute l’émulation de RISC‑V 64 (qemuriscv64) et ajoute ppc64 dans la liste des cibles pour QEMU (QEMU_TARGETS).
qemuarm64 prend en charge les accélérateurs KVM (QB_CPU_KVM).
De nouveaux fichiers de réglage, tun*, sont présents pour Cortex-A53, Cortex-A57 et ARM1176JZ-S.
Cette nouvelle version de Yocto prend en charge ARM32 (armel) par ICU et RISC-V par libffi.
L’outil de création de fichiers images wic comprend le nouveau plugin bootimg-biosplusefi qui crée une partition d’amorçage compatible à la fois BIOS et EFI.
Composants
Pour construire une image, il vous faut assembler divers composants, dont la version par défaut est figée à chaque mise à jour. La liste est longue et se trouve dans les notes de publications.
Noyau
Yocto propose d’utiliser les versions 4.19 et 5.2 du noyau Linux.
Parmi les améliorations, on peut retrouver :
- la classe
kernel-fitimagecomprend la variableFIT_HASH_ALGqui définit l’algorithme de contrôle d’une fitimage, image pour le gestionnaire d’amorçage capable d’adresser plusieurs éléments (noyau, ramfs, dtb) ; - la prise en charge de la compression des modules via l’option de configuration noyau
CONFIG_MODULE_COMPRESS=y; - importation des fragments de configuration depuis la meta‑security.
Pilotes
Le pilote graphique drm-bochs est maintenant pris en charge. Comme son nom l’indique, ce pilote permet de gérer l’adaptateur graphique virtuel de l’émulateur Bochs.
La recette libdrm intègre le fichier amdgpu.ids dans le paquet libdrm-amdgpu.
Distributions
La sélection du gestionnaire d’initialisation du système a été simplifiée, grâce à la variable INIT_MANAGER qui comprend les valeurs suivantes :
-
none; -
sysvinit; -
systemd; -
mdev-busybox.
Si none est sélectionné, votre configuration actuelle est utilisée. C’est‐à‐dire que cette variable est ignorée.
La distribution poky-lsb et la majorité des recettes associées sont retirées de poky. La version destinée aux configurations de tests est renommée poky-altcfg.
Base
busybox active Unicode par défaut.
Développement
L’outil de parallélisation de compilation distcc est séparé en deux paquets distcc‑client et distcc‑server.
Bibliothèques
GTK+ 2 est déplacé vers la meta-oe.
Les dépendances à Python 2 sont réduites au maximum.
Le paquet libcap-ng ne prend plus Python en charge, ajoutez le paquet libcap-ng-python en cas de besoin.
Autour de Yocto
Les branches précédentes de Yocto sont toujours vivantes et ont connu de récentes mises à jour :
- Warrior est passée en 2.7.2 le 26 novembre 2019 ;
- Thud est en 2.6.4 depuis le 31 octobre.
La prochaine branche, dunfell, sortira en avril 2020. La nouvelle meta‑intel, version 12.0, a été publiée le 27 novembre. Il est possible de suivre l’état de maintenance des branches via la page wiki dédiée sur le site du projet.
LuneOS, une distribution GNU/Linux pour appareils mobiles qui utilise Yocto, a présenté sa dernière version, eggnog‑latte, le 24 octobre. Celle‑ci suit la branche warrior de Yocto.
Aller plus loin
- L’annonce (47 clics)
- Notes de version (33 clics)
- Yocto project (118 clics)
# correctif version sur branche thud
Posté par goeb . Évalué à 2.
En fait c'est "2.6.4" je crois.
[^] # Re: correctif version sur branche thud
Posté par David Marec . Évalué à 2.
En effet, il n'y a pas de version
2.8.*.On est passé directement de
2.7à3.0.[^] # Re: correctif version sur branche thud
Posté par ZeroHeure . Évalué à 3.
Corrigé, merci.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# Vraiment utilisé ? find et grep only ? Buildroot n'est-il pas mieux ?
Posté par AncalagonTotof . Évalué à 4.
C'est une vraie question : est-ce que vous avez connaissance de cas d'utilisation concret, ayant abouti à la réalisation, voire la commercialisation d'un produit, avec un OS construit avec Yocto ?
Pourquoi je demande ?
Je vais essayer de faire bref, ce qui indique généralement que ça va être confus ! Ou même pas vraiment bref … Bref …
J'ai utilisé Yocto dans plusieurs cas de figure, sans jamais concrétiser, ou en obtenant un résultat bancal, fragile. C'étaient des projets de R&D, ils n'ont pas aboutis pour diverses raisons, ça n'est pas grave (un peu quand même, pour l'amour propre, mais on s'en remet …).
Mais j'ai souffert avec ce truc, la vache !
En gros, de ce que j'en retire, c'est qu'il y a beaucoup de moyen d'arriver à un résultat bon, mauvais ou acceptable …
La doc officielle explique plein de choses, mais il est difficile de trouver la bonne méthode, ne serait-ce que pour ajouter un paquet au build. Qui peut me dire où je dois taper pour ajouter le package
mpg123par exemple ? Rien que pour ça, j'ai déjà trouvé plusieurs méthodes …Et les outils qui m'ont été les plus utile sont
findetgrep, souvent combinés enfind . -type f -exec grep -Hn <truc> "{}" \;C'est d'un lourdingue, naudidju ! Au bout de 100 ou 200 find/grep, ça fatigue … Et Yocto, c'est gros, non, gigantesque. Un build peut faire grimper une arborescence à facilement plus de 50 ou 100 Go. Un find/grep là-dedans … Brrrr …
J'ai pratiqué en ciblant du ATmel SAMA5D2, du i.MX6 et du 7, mais je vais décrire un cas sur Raspberry Pi. Peu importe le projet, l'objectif était d'avoir un OS avec affichage graphique (Qt), écran tactile et quelques communications série et I2C avec le monde extérieur.
étape 1 : Raspbian. Bien au début, un peu pénible pour Qt (une tentative en direct, une autre avec QTRPI), bizarre quant à la config du tactile et de son orientation portrait (2 R-Pi, 2 Rasbian identiques, orientation OK sur l'une, NOK sur l'autre). On laisse tomber Raspbian.
étape 2 : Yocto. Cool, c'est du R-Pi, c'est méga répandu, ils en ont vendu des myiards, ça va rouler tout seul. Eh beh nan. Grosse galère pour Qt et d'autres bricoles. Vite abandonné.
étape 3 : Buildroot. Magnifique ! Approche directe, ça se configure quasiment comme un kernel (
make menuconfig; recherches faciles avec/) la plupart du temps, la seule et unique doc ne fait que 130 pages. J'ai très vite obtenu mon premier OS fonctionnel. Mais surtout, les retouches successives pour ajouter tel ou tel package manquant se sont faite naturellement, sans chercher pendant des heures (ou des jours; si, si, c'est possible avec Yocto !). J'ai besoin d'un truc, ça me paraîtrait logique que ça marche comme-ci ou comme-ça, et effectivement, ça se passe comme prévu. La chaîne de cross-compilation s'est faite toute seule, et a fonctionné nickel sur la bécane du collègue. Au final, un OS qui affiche une image quasi instantanément, une petite animation au démarrage des services et notre application qui arrivait très vite avec quasiment rien pour encombrer le boot. Et nos devices gérés correctement, jusqu'à l'écran en portrait (sur les deux exemplaires de R-Pi à l'identique, hein !).Au passage, pour Yocto, selon le fabricant du SoC, selon le fabricant du SoM, et selon l'âge du capitaine, on récupère des choses, avec la commande repo initiale, rarement organisées de la même manière, quand ça n'est pas carrément un conteneur Docker !
Alors, il se dit que les deux ont leur intérêt. Par exemple, Yocto est plus indiqué pour faire une gamme de produits ou pour pouvoir réutiliser les layers d'un projet sur l'autre. OK, probablement, mais avant de passer à un nouveau projet, il faudrait terminer le premier ! Plus sérieusement, je commence à sérieusement douter : ça fait des dizaines d'années qu'on me parle de ré-utilisabilité, mais j'en ai jamais vraiment vu …
Tandis qu'avec Buildroot, tout est direct au but, logique et sans détour.
D'où ma question initiale : vraiment utilisé, Yocto ?
Oh, je sais qu'on est pas vendredi, mais je précise quand même : Buildroot, c'est avec un bon vieil
/etc/inittabdes familles, et c'est sanssystemd!!![^] # Re: Vraiment utilisé ? find et grep only ? Buildroot n'est-il pas mieux ?
Posté par Thomas Petazzoni (site web personnel) . Évalué à 8.
Oh, je sais qu'on est pas vendredi, mais je précise quand même : Buildroot, c'est avec un bon vieil /etc/inittab des familles, et c'est sans systemd !!!
Juste pour précider: Buildroot supporte effectivement l'init de Busybox (choix par défault), l'init SysV classique, mais aussi systemd.
[^] # Re: Vraiment utilisé ? find et grep only ? Buildroot n'est-il pas mieux ?
Posté par Renault (site web personnel) . Évalué à 5.
J'en suis à je crois mon 3e projet en 3 ans qui utilise Yocto et qui réutilise des couches. J'ai utilisé aussi buildroot et OpenWrt par le passé. Le gain sur buildroot ici est redoutable.
Exemple typique, je travaille sur un écosystème de produits qui a 4 cartes différentes basées sur deux modules différents, seulement les composants additionnels et quelques logiciels changent. Ils utilisent le même Yocto et le gain est puissant.
Les paquets qui diffèrent entre les plateformes sont de l'ordre de la vingtaine (globalement le noyau, le chargeur de démarrage et quelques paquets spécifiques à la fonction du produit) à mettre en comparaison les quelques centaines nécessaires pour produire le système complet pour chacun. La compilation du système complet et l'espace disque nécessaire pour l'ensemble est donc bien plus faible que ce que buildroot fournirait en équivalent. Sans compter que buildroot demanderait plus d'efforts de maintenance probablement dans ce contexte.
Il faut vraiment voir Yocto comme un système pour créer une (ou plusieurs) distribution, c'est puissant, très flexible mais aussi très complexe. Buildroot c'est plutôt dédié à faire un firmware, donc dédié à une cible unique. C'est plus simple mais peu adapté dans certains cas comme le mien actuellement (mais sur d'anciens projets que j'ai fait, buildroot était tout indiqué).
La courbe d'apprentissage est par conséquent assez raide et la doc officielle est selon moi taillée pour quelqu'un qui connaît et comprend le fonctionnement de Yocto, pas vraiment pour quelqu'un qui débute.
[^] # Re: Vraiment utilisé ? find et grep only ? Buildroot n'est-il pas mieux ?
Posté par Tangi Colin . Évalué à 4.
Yocto est aujourd'hui le standard dans le milieu industrielle (si la cible est un BSP linux bien entendu).
Je l'ai mis en oeuvre sur de nombreux projets, sur des cibles TI OMAP 3/4 ou IMX.6 principalement avec ou sans intégration QT (opengl).
Il est très puissant dans une stratégie de "plateforming" (c'est à dire une équipe BSP qui supporte un ensemble de carte HW/BSP réduit) et X dizaines de projets au dessus qui rajoute les partie applicatives pour faire leurs produits.
Pour une raison de coût (augmenter les volumes et réduire les coût de mise à jour/cybersécurité BSP) l'industrie ce rapproche de plus en plus de ce mode de fonctionnement, c'est fini le temps où chaques équipes au sein d'une grosse boite avait dans son coin son équipe de Hard, BSP, Soft sur sa carte custom et où tu te retrouver avec 50 carte différents sur X OS différents à la fin…
Et dans ces cas là, le débat Builroot vs Yocto est plié depuis longtemps, Yocto gagne haut la main.
Après des distributions Yocto y en a des tonnes sur le marché. Par exemple eux : https://www.balena.io/os/ .
Bref Yocto est une belle boite à outil, très complète mais aussi très complexe, il n'y a pas un seul workflow possible avec, ça demande effectivement une courbe d'apprentissage longue. Y a pas mal de société qui propose des formations dessus.
[^] # Re: Vraiment utilisé ? find et grep only ? Buildroot n'est-il pas mieux ?
Posté par gUI (Mastodon) . Évalué à 3. Dernière modification le 03 décembre 2019 à 14:21.
En complément du commentaire de Renault
Je suis sur mon premier vrai projet où j'ai besoin de builder un système embarqué de A à Z (le fabriquant te file une Debian de 2Go, rien que le temps de flash en usine est hors de question). J'ai donc essayé de comparer Buildroot (facilement préhensible, j'avais déjà fait mumuse) et Yocto (l'usine à gaz dans toute sa splendeur).
C'est un peu le jour et la nuit.
Quand NXP fournit un Yocto, que le fabriquant du SoM (System On Module) te fournit une couche, et que toi tu "n'as plus qu'à" écrire la tienne, sans toucher aux autres, chacune restant dans son GIT respectif, c'est très élégant, c'est réellement maintenable. Ensuite oui, Yocto est compliqué, très compliqué. Il t'oblige à comprendre les couches sur lesquelles tu te bases pour pouvoir les modifier le moins possible. C'est un gros effort à faire qui n'a de sens que sur des projets assez long je pense (typiquement un produit industriel sur lequel tu prévois à moyen terme des évolution importanttes comme le changement de SoC, sans toucher aux périphériques).
Au passage, j'ai discuté avec Thomas Petazzoni qui est un mainteneur Buildroot,
il m'a clairement ditj'avais cru comprendre que c'est bien gentil Buildroot, mais dès que tu veux bosser sérieusement, c'est Yocto (il m'avait sorti un truc style "Yocto c'est Buildroot dopé aux emphétamines" je crois) et qu'en pro, il utilise quasi exclusivement Yocto.EDIT : ne gardons pas cette citation erronée en début de conversation, le commentaire de Thomas a gardé la version originale de mon texte et permet de comprendre l'historique.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Vraiment utilisé ? find et grep only ? Buildroot n'est-il pas mieux ?
Posté par Thomas Petazzoni (site web personnel) . Évalué à 6.
Au passage, j'ai discuté avec Thomas Petazzoni qui est un mainteneur Buildroot, il m'a clairement dit que c'est bien gentil Buildroot, mais dès que tu veux bosser sérieusement, c'est Yocto (il m'avait sorti un truc style "Yocto c'est Buildroot dopé aux emphétamines" je crois). En pro, il utilise quasi exclusivement Yocto.
Oula oula. Je suis cité ici, pourtant je ne pense pas avoir jamais dit ça. Nous utilisons Buildroot professionnellement à Bootlin pour de nombreux projets clients, un certain nombre de nos clients demandent explicitement Buildroot car ils n'ont pas besoin de la puissance de Yocto, et n'ont pas l'envie, l'intérêt ou l'expertise pour aller gravir la raide courbe d'apprentissage que Yocto nécessite. Bref, à Bootlin, nous faisons à la fois du Yocto et du Buildroot, selon les demandes de nos clients et le type des projets.
Et c'est tout à fait possible de bosser sérieusement avec Buildroot. Des petites entreprises comme Google, Tesla, Rockwell Collins utilisent Buildroot pour des produits.
[^] # Re: Vraiment utilisé ? find et grep only ? Buildroot n'est-il pas mieux ?
Posté par gUI (Mastodon) . Évalué à 3. Dernière modification le 03 décembre 2019 à 14:24.
Salut,
J'avais mal compris, vraiment désolé pour la méprise.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Vraiment utilisé ? find et grep only ? Buildroot n'est-il pas mieux ?
Posté par Christophe . Évalué à 3.
Je vais apporter ma petite expérience personnelle… J'utilise Yocto tous les jours pour le projet LuneOS auquel je participe.
Pour LuneOS, nous réutilisons plusieurs couches: meta-qt5, meta-smartphone, meta-raspberrypi… Et de plus en plus, nous réutilisons des briques de webOS OSE (OpenSource Edition), qui lui aussi utilise Yocto.
Ce qui m'amène à répondre à la question principale: webOS (qui est utilisé sur les TVs de LG) est construit en utilisant Yocto. Et ça marche. LuneOS également, à sa petite échelle.
Je suis assez d'accord avec plusieurs remarques:
* Yocto devient réellement puissant lorsqu'il s'agit de réutiliser la même base pour plusieurs cibles
* Yocto est très (trop ?) personnalisable. Il y a une infinité de possibilités pour tout faire. Il est très facile de s'y perdre !
* Yocto est vaste, trop vaste.
AMHA, utiliser Yocto pour refaire une distrib "classique" (genre Gnome/KDE) ne me semble pas être la voie la plus simple. Yocto est vraiment puissant pour des projets embarqués sous contraintes, avec une interface dédiée, et un besoin de cibler plusieurs architectures. Car vu le coût de la mise en place initiale, il vaut mieux pouvoir réutiliser ce travail pour plusieurs projets !
[^] # Re: Vraiment utilisé ? find et grep only ? Buildroot n'est-il pas mieux ?
Posté par amdg . Évalué à 1.
Tu as par exemple STMicroelectronics qui publie sur Github le BSP pour son microprocesseur: https://github.com/STMicroelectronics/STM32MPU_EmbSW_Overall_Offer#stm32mpu-embedded-software-packages
C'est basé sur Yocto (et développé principalement en France au passage)
[^] # Re: Vraiment utilisé ? find et grep only ? Buildroot n'est-il pas mieux ?
Posté par Tarnyko (site web personnel) . Évalué à 1.
Tizen.
Tu peux te passer de systemd avec Yocto aussi.
Après, je ne prétends pas que cela soit facile.
La manière dont je vois les choses est : Yocto est plus configurable, plus connu (=vendable) dans l'industrie. Buildroot est plus léger, plus simple d'usage pour des petits projets.
[^] # Re: Vraiment utilisé ? find et grep only ? Buildroot n'est-il pas mieux ?
Posté par AncalagonTotof . Évalué à 1.
Merci pour toutes ces réponses ! Je ne pourrai pas répondre à toutes individuellement malheureusement, j'ai procrastination …
Bon, si je résume correctement :
1) pour maîtriser Yocto, il faut maîtriser Yocto. OK, c'est clair !
findetgrepcomme seuls outils, c'est anecdotique …2) le problème, c'est ma boite. Elle n'a aucune vision à long terme, ne sait même pas ce que c'est qu'un soft, et encore moins son dév, etc. Je vais pas vous faire la liste de tous les problèmes et des mauvais choix stratégiques, sauf à dire que justement, ils disent souvent "stratégie", mais ils confondent avec "objectif". Entre maintenant, et l'objectif, on va faire des réunions, et on changera d'avis en cours de route, et … Désolé, je crois que j'ai de plus en plus besoin d'un divan …
3) la prochaine fois qu'un Yocto me tombe dessus, je réponds merde, en principe, ça colle avec tout … Mais surtout parce qu'un "temps Yocto" ne peut pas être compris/envisagé par nos "décideurs"
4) merci spécial à M. Petazzoni. Free Electrons, pardon, Bootlin ;-) semble faire autorité. J'ai failli vous contacter pour un projet avant son abandon. Oui, je ressasse encore …
Ah, si, un dernier truc, on est vendredi, donc, sus à systemd !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.