J’ai eu récemment l’occasion de mettre en œuvre Yocto. J’avais déjà pas mal pratiqué OpenEmbedded auparavant. On peut voir Yocto comme un projet dérivé d’OpenEmbedded même si c’est un peu plus que cela.
En effet Yocto c’est Poky (un système de build qui s’appuie sur OpenEmbedded), quelques outils de build recréés pour l’occasion (swabber, pseudo, etc..) ainsi qu’un ensemble de méta données permettant de créer des distributions embarquées pour un certain nombre de cibles.
La force mais aussi la faiblesse d’OpenEmbedded c’est que c’est un système de build qui peut tout faire: des images finales de rootfs, mais aussi une distribution complète avec son dépôt de paquets prêt à l’emploi, et cela sur plusieurs plateformes matérielles. Cela en fait un système complexe à mettre en œuvre et à prendre en main. Il y a encore 2 ans, la documentation d’OpenEmbedded participait à cette difficulté de prise en main. En effet OpenEmbedded fournissait bien une documentation mais qui ne prenait vraiment tout son sens seulement une fois que l’on avait commencé à maîtriser le sujet. Ce qui est assez paradoxal pour une documentation. Il manquait les éléments qui permettent aux développeurs de rentrer dans ce système de build.
Avec Yocto j’ai pu constater qu’il y a eu un réel progrès de ce côté
là. Le projet vient avec une documentation beaucoup plus complète et surtout beaucoup plus accessible. La prise en main n’est tout de même pas immédiate mais cette fois cela est plutôt dû à la complexité et à la richesse de l’outil.
En quelques heures je suis quand même parvenu à développer un BSP (Board Support Package) minimaliste pour une carte donnée (en l’occurrence une AT91SAM9G20-EK). Le concept de layer permet d’avoir une couche de configuration spécifique pour un matériel donné. On peut en fait même supporter plusieurs matériels différents et on peut aussi ajouter des paquets spécifiques. En fait un layer n’est rien de plus qu’un ensemble de paquets et de configurations ou de surcharges de configurations. Le BSP n’est qu’un layer spécifique à un matériel (ou à un ensemble de matériel). Comme on le voit même pour le support d’une simple carte électronique, il y a déjà beaucoup de concepts qui entrent en jeu. Il y a aussi déjà de nombreuses façon de faire qui arriveront à la même fin mais qui seront plus ou moins faciles à maintenir. Le concept de BSP se rapproche surtout d’un « guideline » pour permettre à la « communauté Yocto » d’avoir un référentiel commun. Je tâcherai d’illustrer la mise en œuvre d’un BSP sur la carte AT91SAMG20-EK dans mes prochains articles ici même et/ou sur ma page Google+.
Une autre avancée notable de Yocto est son optimisation pour le temps de la première compilation d’une cible « minimale », je suis passé de plus de 3 heures à une légèrement plus d’heure maintenant. Cela reste quand même très long notamment pour une cible qui se veut minimale.
Pour faire une image d’un système avec quelques composants seulement, Buildroot reste largement plus approprié. Pour des systèmes requérant un grand nombre de composants, alors il vient souvent le besoin de fonctions plus avancées comme la gestion d’un dépôt de paquet ou la prise en charge de plusieurs plateformes matérielles par exemple. Dans ce cas-là, Yocto reste la meilleure (la seule?) option d’autant plus que ce projet tend à améliorer les points faibles historiquse d’OpenEmbedded.
Depuis de nombreuses années, Bootlin a proposé deux sessions de formation pour les développeurs Linux embarqué : une session 
Après 
Intitulé du stage: Participation à des projets Linux embarqué