Le projet Yocto est une solution pour les industriels qui veulent concevoir un périphérique embarqué basé sur Linux. CIO Systèmes Embarqués a animé pour le compte du programme Cap'tronic un atelier dédié à Yocto au mois de mars 2015 à Gardanne (Bouches du Rhône). Suite au succès de ce premier atelier, et à l'intérêt autour de Yocto, un nouvel atelier est organisé les 7 et 8 octobre 2015 à Montpellier.
Une participation au frais de 100 € pour les adhérents Cap'tronic, plus de 600 € pour les autres, est demandée. Ce n'est pas ouvert aux particuliers.
Programme
L'atelier est articulé autour d'une journée de présentation théorique et d'une journée de travaux pratiques qui permettront diverses adaptations d'une distribution de base proposée par Yocto :
- ajouter de nouveaux composants logiciels ;
- créer une layer spécifique ;
- paramétrer la langue du clavier et la timezone ;
- ajouter et configurer un client NTP ;
- ajouter et configurer un serveur FTP ;
- créer une recette pour composant logiciel upstream non supportés nativement ;
- créer une recette pour logiciel développé en interne.
Rappels sur Yocto
Hébergé par la Linux Foundation et soutenu par de très nombreux fondeurs tels Intel, AMD, Broadcom, Texas Instruments et Freescale, il sert de base à des solutions Linux commerciales, mais peut également être utilisé par tout développeur qui souhaite bénéficier d'une solution Linux embarqué à fort contenu applicatif, avec une grande qualité de production de la distribution tant du point de vue de la richesse que de la fiabilité ou de la reproductibilité.
Aller plus loin
- Programme et inscription (190 clics)
- CIO Systèmes Embarqués - Yocto (263 clics)
- Cap'tronic (140 clics)
- Yocto Project (399 clics)
# 3615 MaLife
Posté par TheBreton . Évalué à 2.
Je travaille avec Yocto en se moment sur un projet et je dois dire que les débuts ont été laborieux, voir plus. Actuellement sur une équipe de 5 personne, je suis le seul qui continu à l'utiliser (et intégré le boulot des autres sur le projets), les autres développeurs ont jeté l'éponge.
Je pense que l'organisation matriciel de Yocto à tendance à rebuter certain.
Car si il y a une chose à retenir de Yocto, c'est qu'il est très bien dans sont rôle de constructeur d'image (versioning des packets etc), mais dans la phase de dev. et la mise au points de logiciel, il est plus du genre à mettre des bâtons dans les roues que d'aider.
Mais une fois que l'on y à pris gouts c'est un outils que j'aimerais bien utiliser plus souvent (et qui ce répand de plus en plus chez les fondeurs/fournisseur de puce).
Bref, jetez y un coup d'oeil ca vaut le coup, et par rapport à buildroot vous trouverez une grosse améliorations. Au début on se bat beaucoup avec Yocto, mais une fois domptez c'est sympa.
Question : dans les pré-requis de formation des participants, je ne comprend pas pourquoi il y a java ?
[^] # Re: 3615 MaLife
Posté par DL . Évalué à 2.
Yocto a vocation d'être orienté vers des process reproductibles: un ensemble de construction d'images, outils utilisables en production. Du coup la mise en place peut vite être lourde si l'on souhaite modifier les réglages de base, particulièrement les recettes. Passé ce cap, c'est juste un plaisir car tout est fait dans l'esprit industriel, on choisit son système (OS, compilateur, packet, formats de sortie, etc) et l'on sait que ce sera généré avec les mises à jour du système global.
SI c'est pour un système perso et léger/Rapide : je conseillerai plutôt Buildroot qui donne de ses nouvelles parfois ici voire Linulink qui est gratuit avec un compte tant que l'on ne veut pas customiser (démarrage noyau, Qt) mais on peut créer aussi son système avec la nouvelle interface très bien faite. Rien que par curiosité je conseillerais de faire un essais de build car il y à des templates prédéfinis pour les cartes comme i.MX.., BeagleBone…, etc .
[^] # Re: 3615 MaLife
Posté par Cch . Évalué à 1.
Tout à fait d'accord avec ton diagnostic. Une précision par rapport au coté industriel : le but du jeu est d'intégrer tous les réglages (logins, réseau, timezone etc…) dans l'image afin d'avoir un processus d'installation sur cible sans action manuelle (et donc sans aléa), ce qui suppose de modifier les recettes (typiquement par des append sur la recette).
Donc tirer pleinement partie de Yocto, c'est créer ses propres recettes et modifier les recettes existantes, mais ceci demande un peu d'apprentissage.
[^] # Re: 3615 MaLife
Posté par DL . Évalué à 2. Dernière modification le 14 septembre 2015 à 13:21.
je trouve vraiment bien pensé qu'à la sortie d'un build il soit possible d'utiliser directement le tout sur des machines utilisateurs, impliquant effectivement les réglages ad-hoc. Mais c'est à ce prix là que l'on arrive à des résultats reproductibles avec un rootfs, des outils (si l'on veut) et l'application utilisateur. Yocto pousse le détail jusque là, du coup il faut accepter la contrepartie : mettre en place une recette et comprendre le fonctionnement. Mais Intel à tellement bien fait la doc et puis je rappelle que le livre (ou les articles dans linux mag) de P. Ficheux voire de Packtpub abordent ce sujet.
[^] # Re: 3615 MaLife
Posté par Cch . Évalué à 1.
En effet, Yocto doit être utilisé par un rôle spécifique dans l'équipe de développement : celui du responsable de la distribution et du packaging.
Les développeurs n'ont pas besoin de se frotter directement à Yocto. Il "suffit" de générer un SDK et de leur fournir, afin qu'ils configurent et compilent leurs développements avec le même environnement que celui qu'ils trouveront sur la cible.
Après installation du SDK, le développeur source un fichier de définition de l'environnement, puis effectue son cycle ./configure, make dans l'environnement Yocto, mais sans avoir à toucher des recettes ou utiliser bitbake.
Si le développement cible une architecture Intel, il est possible de se passer de Yocto : développer en natif en s'assurant que l'on n'a pas de lien dur avec le PC de dév. (autotools bienvenus), puis lorsque c'est au point livrer le code source au packager qui l'intègre dans Yocto. Personnellement j'accompagne des clients qui bossent comme cela.
Encore faut il s'assurer que les différences de version entre le PC de développement et l'image finale générée par Yocto n'induisent pas de problème lors de l'intégration sur la cible.
Si par contre on cible une architecture non Intel, se replier sur le PC de développement n'est pas possible puisqu'il faut tester en croisé. Le SDK devient alors la solution.
Concernant les prérequis, c'est une erreur lors de la mise en ligne du programme. Merci de l'avoir signalé, je fais rectifier.
# Terminologie
Posté par Alexandre Belloni (site web personnel) . Évalué à 2.
Le terme Yocto est souvent mal utilisé et ne doit pas être utilisé seul.
Yocto Project est une organisation qui s'occupe de la maintenance d'une multitude de projets open source.
Dire "j'utilise Yocto", c'est comme dire "j'utilise Airbus".
Parmi les projets, il y a notamment bitbake, OpenEmbedded et Poky et leur relation est la suivante:
- bitbake est un ordonnanceur de tâches, un peu comme Make mais avec son propre langage
- OpenEmbedded est le système de build, il utilise bitbake. C'est l'équivalent de buildroot (qui utilise Make)
- Poky est une distribution de référence, c'est à dire que c'est une configuration particulière des paquets qui permet de générer une distribution. Poky n'a pas vocation à être utilisée telle quelle et ne devrait jamais se retrouver dans un produit final. C'est une distribution qui permet de réaliser les tests d'intégration et qui de fait active un maximum de fonctionnalités ce qui ne convient pas pour un système embarqué.
La confusion la plus courante est donc d'utiliser Yocto à la place de Poky.
[^] # Re: Terminologie
Posté par Cch . Évalué à 2.
Tout à fait d'accord sur les précisions de terminologie. D'ailleurs dans l'atelier j'indique que le terme consacré est Yocto Project, et que c'est par commodité (voire par abus) qu'on le raccourcit en Yocto.
Effectivement Yocto est le projet, qui offre des outils divers, mais également un très gros effort de documentation. Par contre dans les échanges force est de constater que c'est Yocto qui est utilisé et non Poky. Mes clients viennent me voir pour du support Yocto, et non du support Poky. Du coup c'est rapidement que le vocable impropre se banalise.
Concernant le fait de savoir si Poky est utilisé pour des tests ou un projet final, je pense que la distinction est plus fine. Ce qui fait le contenu logiciel du projet final, c'est la recette image qui est buildée puis installée. Donc ce n'est pas Poky qui est l'ensemble des possibles, mais l'image bâtie à partir des choix de Poky en terme de réglages, versionning etc…; et de la sélection des composants embarqués dans l'image.
Donc on a le choix entre choisir l'une des images de référence proposées par Poky, qui ne seront pas utilisables telles quelles effectivement (sauf à fin de test), ou bien créer sa propre recette d'image en sélectionnant les paquets ou groupes de paquets adaptés, et bien souvent en les customisant au passage.
A noter que dans tout les cas il manquera dans les recettes l'applicatif (ou les applicatifs) métier. Pour ma part j'encourage vivement à considérer l'applicatif métier comme le reste et à créer une ou des recettes pour lui, afin de le packager dès le build de l'image.
[^] # Re: Terminologie
Posté par Cch . Évalué à 1.
Petite précision supplémentaire par rapport au commentaire d'Alexandre : dans ma réponse précédente, il faut entendre distribution Poky comme l'ensemble des recettes disponibles à travers les recettes fournies.
Si par contre on prend poky comme les réglages de type distro (fichier conf/distro/poky.conf), alors Alexandre a raison : pour quelqu'un de suffisamment expérimenté, il peut être intéressant de créer sa propre distribution afin d'affiner/modifier les réglages spécifiés par le fichier poky.conf, et éventuellement de modifier les DISTRO_FEATURES pour adapter le contenu de l'image de base à ses pré-requis.
Par contre à ce niveau là on est dans de l'utilisation avancée, et de l'optimisation fine de l'image finale.
# Retour d'expérience
Posté par mathle . Évalué à 1.
Il y a quelques mois, j'étais très motivé quand j'ai appris que Yocto allait faire partie de mon environnement de travail. C'est la référence et ce genre d'outil est indispensable pour contrôler le build d'un environnement complet.
Le problème, c'est que c'est ardu ! Il y a la complexité inhérente à la tâche à effectuer bien sûr, mais … pas que ! Yocto souffre un héritage et d'une évolution comme on voit trop souvent … Il y a de bonnes idées (ou plutôt, si ça n'était pas là, ça serait grave) mais également pas mal de difficultés liées au design, à la syntaxe, au nommage pas explicite, … ça mène à pas mal d'effets de bord et d'avancées à tâtons plutôt usantes. Il y a de trop nombreuses possibilités de se faire avoir (ce qui, bien sûr, ne manque pas d'arriver). C'est dommage.
Il semble accepté que Yocto n'est pas fait pour développer mais quand on travaille avec, ce n'est pas toujours pour un build final. Travailler sur U-Boot de manière indépendante de Yocto, soit. Mais pour Linux, ça se complique. On a forcément vite des réglages à effectuer, des modifications à tester, … et pour ça, travailler avec Yocto permet d'avoir sous la main et de générer le noyau et le filesystem. Mais ce n'est pas tout à fait adapté pour ça.
[^] # Re: Retour d'expérience
Posté par Cch . Évalué à 2.
Globalement d'accord avec le fait que ce n'est pas simple (sinon proposer un atelier n'aurait pas de sens …).
Néanmoins est ce le fait de l'outil, ou bien est ce intrinsèque? J'ai l'habitude de dire aux gens que je forme que ce n'est pas parce qu'ils commencent à maîtriser l'outil que tout est gagné. En effet encore faut il savoir comment bâtir une distribution embarquée, et même comment arriver à un objectif fonctionnel à base de composants Linux.
Ceci se retrouve amplifié dans le cas assez fréquent d'un développement croisé, du fait de la dualité PC de développement / cible.
En l'absence des outils proposés par Yocto Project, on peut s'appuyer sur buildroot qui rendra un service similaire mais en étant plus léger (et donc moins ambitieux, il n'y a pas de miracle), ou bien travailler à la main (en mode Do It Yourself).
Pour avoir bâti pendant de nombreuses années des distributions Linux embarquées, il est clair que le mode Do It Yourself trouve vite ses limites dès lors que l'on veut ajouter du contenu logiciel riche dans la distribution, ce qui est de plus en plus fréquent.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.