{"id":5897,"date":"2022-01-13T09:00:00","date_gmt":"2022-01-13T08:00:00","guid":{"rendered":"https:\/\/www.blaess.fr\/christophe\/?p=5897"},"modified":"2022-01-24T17:45:11","modified_gmt":"2022-01-24T16:45:11","slug":"yocto-cooker-1-3","status":"publish","type":"post","link":"https:\/\/www.blaess.fr\/christophe\/2022\/01\/13\/yocto-cooker-1-3\/","title":{"rendered":"Yocto Cooker (1\/3)"},"content":{"rendered":"\n
\"\"<\/a><\/figure><\/div>\n\n\n\n

Cette petite s\u00e9rie de trois articles pr\u00e9sente un outil (Yocto Cooker<\/strong>) qui permet d’organiser tous les fichiers n\u00e9cessaires \u00e0 la compilation d’un syst\u00e8me Linux embarqu\u00e9 avec Yocto Project. Cet outil permet \u00e9galement de lancer automatiquement un ou plusieurs builds<\/em> (compilation d’images compl\u00e8tes pr\u00eates \u00e0 installer).<\/p>\n\n\n\n

Attention: cet article ne pr\u00e9sente pas les concepts propres \u00e0 Yocto Project, on pr\u00e9-suppose une certaine familiarit\u00e9 avec cet environnement. Pour trouver une introduction \u00e0 Yocto, et un tutorial complet sur son utilisation, on se reportera \u00e0 l’article Linux embarqu\u00e9 avec Yocto Project<\/a>.<\/p>\n\n\n\n\n\n\n\n

Probl\u00e9matique<\/h2>\n\n\n\n

L’outil Yocto Project repr\u00e9sente aujourd’hui l’une des deux principales solutions pour mettre au point et produire un syst\u00e8me embarqu\u00e9 bas\u00e9 sur Linux.<\/p>\n\n\n\n

\u00c0 mon sens, le meilleur avantage de Yocto sur son principal concurrent (Buildroot<\/em>) est la possibilit\u00e9 de g\u00e9rer la configuration du syst\u00e8me \u00e0 diff\u00e9rents niveaux (param\u00e9trage des packages, contenu de l’image, d\u00e9finition de la plateforme cible, etc.) et de partager ces \u00e9l\u00e9ments de configuration entre diff\u00e9rents builds<\/em>. On peut ainsi g\u00e9rer ais\u00e9ment une gamme compl\u00e8te de produits que ce soit au niveau mat\u00e9riel (lorsque la m\u00eame application m\u00e9tier doit tourner sur diff\u00e9rente plateformes, avec diff\u00e9rentes options en terme de p\u00e9riph\u00e9riques) ou au niveau applicatif (lorsqu’on propose plusieurs versions du m\u00eame code m\u00e9tier : \u00ab\u00a0lite<\/em>\u00a0\u00bb , normal, \u00ab\u00a0full-featured<\/em>\u00a0\u00bb etc.).<\/p>\n\n\n\n

La contrepartie de cette versatilit\u00e9 est la complexit\u00e9 de la configuration (qui repr\u00e9sente donc le point faible de Yocto Project par rapport \u00e0 Buildroot).<\/p>\n\n\n\n

On peut se retrouver rapidement avec plusieurs dizaines de layers<\/em>, une douzaine de configurations pour les machines<\/em>, les images<\/em>, voire les distros<\/em>. Pour chaque build<\/em> on peut avoir \u00e0 g\u00e9rer des fichiers local.conf<\/code> et bblayers.conf<\/code> sp\u00e9cifiques. Bref, la maintenance d’un environnement destin\u00e9 \u00e0 produire des images pour plusieurs projets, plusieurs plateformes ou plusieurs versions logicielles peut vite devenir un enfer.<\/p>\n\n\n\n

Confront\u00e9s \u00e0 ce probl\u00e8me pour le projet d’un client, nous avons d\u00e9cid\u00e9, avec mon coll\u00e8gue Patrick Boettcher de d\u00e9velopper un outil permettant d’organiser le plus simplement possible les diff\u00e9rents builds<\/em>. Notre objectif \u00e9tait de centraliser dans un seul fichier tous les \u00e9l\u00e9ments n\u00e9cessaires pour r\u00e9aliser un voire plusieurs builds<\/em> : notamment les noms et origines des layers<\/em> \u00e0 utiliser et les param\u00e8tres sp\u00e9cifiques \u00e0 ajouter dans le fichier local.conf<\/code>.<\/p>\n\n\n\n

L’environnement Yocto Project utilise un vocabulaire issu de la cuisine (recipes<\/em>, bitbake<\/code>, etc.). Nous avons souhait\u00e9 nous inscrire dans cette coutume, et comme notre logiciel est destin\u00e9 \u00e0 encadrer le travail du cuisinier bitbake<\/code>, nous avons d\u00e9cid\u00e9 de l’appeler chef<\/code>. Malheureusement, \u00e0 peine celui-ci publi\u00e9 nous avons re\u00e7u des menaces de proc\u00e8s car un logiciel commercial de gestion de configuration utilise d\u00e9j\u00e0 ce nom.<\/p>\n\n\n\n

Nous avons choisi de le re-baptiser (un peu dans l’urgence) Yocto Cooker<\/strong>. Ce nom, choisi rapidement, n’est pas non plus parfait, car il existe au sein m\u00eame de bitbake<\/code> un fichier cooker.py<\/code>. Attention donc \u00e0 ne pas faire de confusion, notre projet est compl\u00e8tement ext\u00e9rieur \u00e0 bitbake<\/code>.<\/p>\n\n\n\n

Principe<\/h2>\n\n\n\n

Yocto Cooker<\/a> – ou plus simplement cooker<\/code> – est un script Python qui, apr\u00e8s analyse d’un fichier de configuration au format JSON, pr\u00e9pare les r\u00e9pertoires de travail n\u00e9cessaires, t\u00e9l\u00e9charge les layers<\/em> choisis et d\u00e9marre bitbake<\/code> pour r\u00e9aliser le build<\/em> d\u00e9sir\u00e9.<\/p>\n\n\n\n

Comme cooker<\/code> est l\u00e0 pour organiser le travail du cuisinier bitbake<\/code>, son fichier de configuration en JSON s’appelle un menu<\/strong>.<\/p>\n\n\n\n

Partant d’un simple fichier menu, cooker<\/code> va pr\u00e9parer les r\u00e9pertoires et les fichiers selon l’arborescence suivante.<\/p>\n\n\n\n

+- layers\/ +- poky\/\n|          +- meta-openembedded\/\n|          +- meta-custom-layer\/\n|          +- ...\n|\n+- downloads\/ ...\n|\n+- sstate-cache\/ ...\n|\n+- builds\/ +- build-custom-1\/ conf\/ +- local.conf\n           |                        +- bblayers.conf\n           |                        +- templateconf.cfg\n           |\n           +- build-custom-2\/ conf\/ +- local.conf\n           |                        +- bblayers.conf\n           |                        +- templateconf.cfg\n           |\n           +- ...<\/code><\/pre>\n\n\n\n
Tous les layers<\/em> t\u00e9l\u00e9charg\u00e9s sont proprement rang\u00e9s dans le sous-r\u00e9pertoire layers\/<\/code>. Durant la phase de mise au point, il est possible de travailler dans certains d’entre-eux, nous en reparlerons. Notons que parfois les layers<\/em> se trouvent en r\u00e9alit\u00e9 \u00e0 un degr\u00e9 d’imbrication plus loin. C’est le cas par exemple de la dizaine de layers se trouvant dans l’arborescence meta-openembedded<\/code>.<\/p>\n\n\n\n
Le r\u00e9pertoire downloads\/<\/code> est utilis\u00e9 par bitbake<\/code> comme point de stockage lorsqu’il t\u00e9l\u00e9charge les sources des packages. Ceci afin d’\u00e9viter un t\u00e9l\u00e9chargement inutile si le package est d\u00e9j\u00e0 pr\u00e9sent. \u00c0 cet emplacement de l’arborescence, ce r\u00e9pertoire est mutualis\u00e9 entre tous les builds<\/em>.<\/p>\n\n\n\n
De m\u00eame le r\u00e9pertoire sstate-cache\/<\/code> contient des \u00e9l\u00e9ments produits lors d’un build<\/em>, qui sont susceptibles d’\u00eatre r\u00e9utilis\u00e9s lors des builds<\/em> suivants. Donc cooker<\/code> le place \u00e0 c\u00f4t\u00e9 de download<\/code> pour le partager entre tous les builds<\/em>.<\/p>\n\n\n\n
Le r\u00e9pertoire builds\/<\/code> enfin contient un sous-dossier pour chaque build<\/em> d\u00e9sir\u00e9. Dans chaque sous-dossier, cooker<\/code> pr\u00e9pare les fichiers conf\/local.conf<\/code> et conf\/bblayers.conf<\/code> en fonction du contenu du menu fourni. Le fichier conf\/templateconf.cfg<\/code> est toujours identique.<\/p>\n\n\n\n
Apr\u00e8s avoir rempli cette arborescence, cooker<\/code> va ex\u00e9cuter bitbake<\/code> successivement dans chaque r\u00e9pertoire de build<\/em> (sauf s\u00e9lection explicite sur la ligne de commande) en ayant correctement initialis\u00e9 ses variables d’environnement.<\/p>\n\n\n\n
Bien s\u00fbr cooker<\/code> propose diff\u00e9rentes options de fonctionnement et permet de lancer directement une sous-t\u00e2che pr\u00e9cise. Nous verrons cela dans les prochains articles.<\/p>\n\n\n\n
Installation<\/h2>\n\n\n\n
Yocto Cooker \u00e9tant un script Python, son installation se fait facilement \u00e0 l’aide de pip<\/code>. Vous pouvez t\u00e9l\u00e9charger les sources, les examiner, et les installer avec<\/p>\n\n\n\n
$ git clone https:\/\/github.com\/cpb-\/yocto-cooker<\/a><\/strong>\n\n$ cd yocto-cooker<\/strong>\n\n$ sudo pip3 install .<\/strong>\n<\/code><\/pre>\n\n\n\n
Il est aussi possible de faire l’installation directe avec :<\/p>\n\n\n\n
$ sudo python3 -m pip install --upgrade git+https:\/\/github.com\/cpb-\/yocto-cooker.git<\/strong><\/code><\/pre>\n\n\n\n
Notez que vous pouvez \u00e9galement utiliser l’option -e<\/code> de pip3 install<\/code> pour que le script soit \u00e9ditable, dans le cas o\u00f9 vous souhaiteriez contribuer \u00e0 notre projet (et je vous y encourage fortement !).<\/p>\n\n\n\n
Une fois le script cooker<\/code> install\u00e9, vous pouvez le lancer avec l’option --help<\/code> pour voir ses sous-commandes disponibles ou l’option --version<\/code> pour vous assurer de la version install\u00e9e :<\/p>\n\n\n\n
$ cooker --version<\/strong>\n# 1.1.0\n\n$ cooker --help<\/strong>\nusage: Cooker [-h] [--debug] [--version] [-v] [-n] {cook,init,update,generate,show,build,shell,clean} ...\n\npositional arguments:\n  {cook,init,update,generate,show,build,shell,clean}\n               subcommands of Cooker\n  cook         prepare the directories and cook the menu\n  init         initialize the project-dir\n  update       update source layers\n  generate     generate build-configuration\n  show         show builds and targets information\n  build        build one or more configurations\n  shell        run an interactive shell ($SHELL) for the given build\n  clean        clean a previously build recipe\n\noptional arguments:\n -h, --help    show this help message and exit\n --debug       activate debug printing\n --version     cooker version\n -v, --verbose activate verbose printing (of called subcommands)\n -n, --dry-run print what would have been done (without doing anything)\n<\/code><\/pre>\n\n\n\n
Pour pouvoir r\u00e9aliser un build<\/em> complet \u00e0 partir d’une distribution Ubuntu-2020.04 fra\u00eechement install\u00e9e, il faut ajouter les packages suivants chrpath<\/code>, cpio<\/code>, diffstat<\/code>, gawk<\/code>, git<\/code>, locales<\/code>, locales-all<\/code>, python3-pip<\/code>, wget<\/code>.  Si besoin on d\u00e9finira la variable d’environnement LC_ALL<\/code> ainsi avant de lancer la compilation :<\/p>\n\n\n\n
$ export LC_ALL=en_US.UTF-8<\/strong>\n<\/code><\/pre>\n\n\n\n
Menu<\/h2>\n\n\n\n
Pour le premier test de cooker<\/code>, nous allons lui demander de compiler une image de base pour une seule cible. Le menu sera donc tr\u00e8s simple. En voici une version que je vais d\u00e9tailler plus bas.<\/p>\n\n\n\n
On peut le t\u00e9l\u00e9charger ici : menu-001.json<\/a><\/p>\n\n\n\n
$ cat menu-001.json<\/strong>\n{\n  \"sources\" : [\n    { \"url\": \"git:\/\/git.yoctoproject.org\/poky\", \"branch\": \"dunfell\", \"rev\": \"yocto-3.1.13\" }\n  ],\n\n  \"layers\" : [\n    \"poky\/meta\",\n    \"poky\/meta-poky\",\n    \"poky\/meta-yocto-bsp\"\n  ],\n\n  \"builds\" : {\n\n    \"qemuarm\": {\n\n      \"target\" : \"core-image-base\",\n      \"local.conf\": [\n        \"MACHINE = 'qemuarm' \",\n        \"IMAGE_FEATURES += 'empty-root-password' \"\n      ]\n    }\n  }\n}<\/code><\/pre>\n\n\n\n
Comme indiqu\u00e9 plus haut le fichier est au format JSON. Il d\u00e9crit un objet menu
poss\u00e9dant trois attributs (\"sources\"<\/code>, \"layers\"<\/code> et \"builds\"<\/code>). C’est le
cas le plus fr\u00e9quent, m\u00eame si nous verrons dans le prochain article deux
autres attributs possibles.<\/p>\n\n\n\n
sources<\/code><\/h3>\n\n\n\n
Le premier attribut (\"sources\"<\/code>) est un ensemble d’objets indiquant comment t\u00e9l\u00e9charger les layers utilis\u00e9s pendant le build<\/em>. Pour ce premier exemple nous n’utiliserons que Poky, mais on ajoute souvent le d\u00e9p\u00f4t \u00ab\u00a0meta-openembedded<\/code>\u00a0\u00bb ainsi que les layers permettant de supporter la cible mat\u00e9rielle et des layers d\u00e9velopp\u00e9s sp\u00e9cifiquement.<\/p>\n\n\n\n
Un objet source<\/code> peut \u00eatre d\u00e9fini gr\u00e2ce quelques attributs :<\/p>\n\n\n\n