{"id":5948,"date":"2022-01-20T09:00:00","date_gmt":"2022-01-20T08:00:00","guid":{"rendered":"https:\/\/www.blaess.fr\/christophe\/?p=5948"},"modified":"2022-01-27T14:43:56","modified_gmt":"2022-01-27T13:43:56","slug":"yocto-cooker-2-3","status":"publish","type":"post","link":"https:\/\/www.blaess.fr\/christophe\/2022\/01\/20\/yocto-cooker-2-3\/","title":{"rendered":"Yocto Cooker (2\/3)"},"content":{"rendered":"\n
\"\"<\/a><\/figure><\/div>\n\n\n\n

Dans le premier article<\/a> de cette s\u00e9rie nous avons vu comment utiliser cooker<\/code> pour produire une image avec Yocto Project en ne renseignant qu’un seul fichier : le menu.<\/p>\n\n\n\n

Dans cet article nous allons voir comment compl\u00e9ter ce menu pour produire plusieurs builds<\/em> en une seule commande, certains d’entre-eux pouvant partager divers \u00e9l\u00e9ments de configuration.<\/p>\n\n\n\n\n\n\n\n

Pour m\u00e9moire le fichier que nous avions utilis\u00e9 \u00e9tait le suivant : menu-001.json<\/a><\/p>\n\n\n\n

$ cat menu-001.json<\/strong>\n\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\n      \"local.conf\": [\n        \"MACHINE = 'qemuarm' \",\n        \"IMAGE_FEATURES += 'empty-root-password' \"\n      ]\n    }\n  }\n}<\/code><\/pre>\n\n\n\n
Ajout d’un build<\/em><\/h2>\n\n\n\n
Commen\u00e7ons par ajouter un autre build<\/em> dans notre menu. Par exemple la production d’une image pour une autre cible \u00e9mul\u00e9e par Qemu : qemux86<\/code>. Pour cela nous ajoutons un deuxi\u00e8me couple cl\u00e9\/valeur dans l’attribut builds<\/code> du menu.<\/p>\n\n\n\n
Voici le nouveau menu :<\/p>\n\n\n\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\n      \"local.conf\": [\n        \"MACHINE = 'qemuarm' \",\n        \"IMAGE_FEATURES += 'empty-root-password' \"\n      ]\n    },\n\n    \"qemux86<\/strong>\": {\n\n      \"target\" : \"core-image-base\",\n\n      \"local.conf\": [\n        \"MACHINE = 'qemux86' \",\n        \"IMAGE_FEATURES += 'empty-root-password' \"\n      ]\n    }\n  }\n}<\/code><\/pre>\n\n\n\n
\u00c0 pr\u00e9sent, si nous lan\u00e7ons cooker<\/code> ainsi :<\/p>\n\n\n\n
$ cooker  cook  menu-002.json<\/strong>\n<\/code><\/pre>\n\n\n\n
il va compiler successivement les deux images pour les deux machines voulues. Sauf si nous pr\u00e9cisons explicitement quelle image produire en indiquant le nom du build<\/em> sur la ligne de commande, par exemple :<\/p>\n\n\n\n
$ cooker  cook  menu-002.json  qemux86<\/strong><\/code><\/pre>\n\n\n\n
Avant de produire v\u00e9ritablement l’image, nous pouvons encore am\u00e9liorer et enrichir un peu notre menu.<\/p>\n\n\n\n
Attribut local.conf<\/code> global<\/h2>\n\n\n\n
Nous observons que la ligne<\/p>\n\n\n\n
\" IMAGE_FEATURES += 'empty-root-password' \"<\/code><\/pre>\n\n\n\n
est commune \u00e0 nos deux builds<\/em>. Nous pouvons la factoriser en l’extrayant de leurs propri\u00e9t\u00e9s local.conf<\/code> et en la  pla\u00e7ant dans un attribut local.conf<\/code> global \u00e0 tout le menu. Bien s\u00fbr il faut s’assurer auparavant que cette ligne soit souhaitable pour tous les builds<\/em> envisag\u00e9s. Voici le menu modifi\u00e9.<\/p>\n\n\n\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  \"local.conf\": [\n    \"IMAGE_FEATURES += 'empty-root-password' \"\n  ],<\/strong>\n\n  \"builds\" : {\n\n    \"qemuarm\": {\n\n      \"target\" : \"core-image-base\",\n\n      \"local.conf\": [\n        \"MACHINE = 'qemuarm' \"\n      ]\n    },\n\n    \"qemux86\": {\n\n      \"target\" : \"core-image-base\",\n\n      \"local.conf\": [\n        \"MACHINE = 'qemux86' \"\n      ]\n    }\n  }\n}<\/code><\/pre>\n\n\n\n
Dans les projets de mes clients, j’utilise surtout l’attribut local.conf<\/code> au niveau du menu pour d\u00e9finir des variables de configuration qui sont employ\u00e9es ensuite dans des recettes pour le code m\u00e9tier. Une autre variable que j’indique souvent ici est \"OE_TERMINAL = 'screen' \"<\/code> pour faciliter la configuration du kernel<\/em> lorsque je me connecte \u00e0 distance sur la machine de compilation.<\/p>\n\n\n\n
Pour l’instant nous n’utilisons que le d\u00e9p\u00f4t Poky comme source, avec ses trois layers<\/em> incontournables. Mais nous pouvons en ajouter d’autres.<\/p>\n\n\n\n
Layer suppl\u00e9mentaire<\/h2>\n\n\n\n
Supposons que dans l’image pour qemux86<\/code> nous souhaitions installer l’utilitaire nano<\/code> (\u00e9diteur de texte). Pour cela nous devons inclure un layer<\/em> suppl\u00e9mentaire (meta-oe<\/code>) pr\u00e9sent dans le d\u00e9p\u00f4t meta-openembedded<\/code>.<\/p>\n\n\n\n
Cela implique plusieurs choses pour notre menu. Tout d’abord nous devons ajouter le d\u00e9p\u00f4t meta-openembedded<\/code> \u00e0 la liste des sources<\/code> \u00e0 t\u00e9l\u00e9charger. Contrairement \u00e0 Poky, meta-openembedded<\/code> ne g\u00e8re pas les tags<\/em>, aussi devrons-nous indiquer un num\u00e9ro de commit<\/em> pour garantir la reproductibilit\u00e9 de la compilation.<\/p>\n\n\n\n
  \"sources\" : [\n    { \"url\": \"git:\/\/git.yoctoproject.org\/poky\", \"branch\": \"dunfell\", \"rev\": \"yocto-3.1.13\" },\n    { \"url\": \"git:\/\/git.openembedded.org\/meta-openembedded\", \"branch\": \"dunfell\", \"rev\": \"ab9fca48\" }\n  ],<\/code><\/pre>\n\n\n\n
Ensuite, il faut indiquer que le layer<\/em> meta-oe<\/code> est n\u00e9cessaire pour le build<\/em> qemux86<\/code>. Mais uniquement pour lui. Pas pour qemuarm<\/code>. <\/p>\n\n\n\n
Pour cela, nous allons ajouter un attribut layers<\/code> \u00e0 l’objet build<\/code> concern\u00e9. Cet attribut indiquera les layers<\/em>  suppl\u00e9mentaires \u00e0 prendre en compte en plus de ceux de la propri\u00e9t\u00e9 layers<\/code> du menu.<\/p>\n\n\n\n
  \"qemux86\": {\n\n    \"target\" : \"core-image-base\",\n\n    \"layers\" : [\n      \"meta-openembedded\/meta-oe\"\n    ],<\/strong>\n    [...]\n  }<\/code><\/pre>\n\n\n\n
Enfin, il faut indiquer que l’on veut inclure la recette nano<\/code> lors de la g\u00e9n\u00e9ration de l’image pour qemux86<\/code>, ce que nous pouvons faire directement dans son attribut local.conf<\/code>. Dans un projet r\u00e9el on d\u00e9finirait plut\u00f4t une recette d’image sp\u00e9cifique dans un layer<\/em> personnalis\u00e9 <\/p>\n\n\n\n
Voici donc le contenu du  menu-002.json<\/a> complet.<\/p>\n\n\n\n
{\n  \"sources\" : [\n    { \"url\": \"git:\/\/git.yoctoproject.org\/poky\", \"branch\": \"dunfell\", \"rev\": \"yocto-3.1.13\" },\n    { \"url\": \"git:\/\/git.openembedded.org\/meta-openembedded\", \"branch\": \"dunfell\", \"rev\": \"ab9fca48\" }\n  ],\n\n  \"layers\" : [\n    \"poky\/meta\",\n    \"poky\/meta-poky\",\n    \"poky\/meta-yocto-bsp\"\n  ],\n\n  \"local.conf\": [\n    \"IMAGE_FEATURES += 'empty-root-password' \"\n  ],\n\n  \"builds\" : {\n\n    \"qemuarm\": {\n\n      \"target\" : \"core-image-base\",\n\n      \"local.conf\": [\n        \"MACHINE = 'qemuarm' \"\n      ]\n    },\n\n    \"qemux86\": {\n\n      \"target\" : \"core-image-base\",\n\n      \"layers\" : [\n        \"meta-openembedded\/meta-oe\"\n      ],\n\n      \"local.conf\": [\n        \"MACHINE = 'qemux86' \",\n        \"IMAGE_INSTALL:append = ' nano' \"<\/strong>\n      ]\n    }\n  }\n}\n\n<\/code><\/pre>\n\n\n\n
Note : l’ajout de la recette nano<\/code> dans la variable IMAGE_INSTALL<\/code> se fait avec la notation :append<\/code>. Cette extension remplace,  depuis la mi-2021 la pr\u00e9c\u00e9dente notation _append<\/code>.<\/p>\n\n\n\n
H\u00e9ritage<\/h2>\n\n\n\n
Nous avons donc deux builds<\/em> distincts dans le m\u00eame menu, chacun pour une cible sp\u00e9cifique. L’un deux utilise un layer<\/em> particulier. Bien s\u00fbr, dans l’exemple ci-dessus le layer<\/em> en question est l’ultra-courant meta-oe<\/code>, mais il pourrait s’agir d’un support sp\u00e9cifique pour une plateforme mat\u00e9rielle ou un ensemble de recettes pour le code applicatif m\u00e9tier.<\/p>\n\n\n\n
Approfondissons encore cet exemple avec deux nouveaux builds<\/em>. L’un pour Raspberry Pi 3 et l’autre pour Raspberry Pi 4.<\/p>\n\n\n\n
Il nous faut d’abord indiquer le d\u00e9p\u00f4t sp\u00e9cifique \u00e0 t\u00e9l\u00e9charger pour l’architecture Raspberry Pi.<\/p>\n\n\n\n
  \"sources\" : [\n    { \"url\": \"git:\/\/git.yoctoproject.org\/poky\", \"branch\": \"dunfell\", \"rev\": \"yocto-3.1.13\" },\n    { \"url\": \"git:\/\/git.openembedded.org\/meta-openembedded\", \"branch\": \"dunfell\", \"rev\": \"ab9fca48\" },\n    { \"url\": \"git:\/\/git.yoctoproject.org\/meta-raspberrypi\", \"branch\": \"dunfell\", \"rev\": \"934064a0\" }\n  ],<\/code><\/pre>\n\n\n\n
Puis nous cr\u00e9ons les deux builds<\/em> n\u00e9cessaires. Ils devront inclure ce nouveau layer. Et dans l’attribut local.conf<\/code>, nous ajoutons quelques lignes de configuration mat\u00e9rielle propre \u00e0 ces cartes.<\/p>\n\n\n\n
  \"builds\" : {\n     [...]\n\n    \"rpi3<\/strong>\" : {\n      \"target\": \"core-image-base\",\n      \"layers\" : [\n        \"meta-raspberrypi\n      ],\n      \"local.conf\" : [\n        \"MACHINE = 'raspberrypi3'  \",\n        \"ENABLE_UART = '1'         \",\n        \"ENABLE_SPI_BUS =  '1'     \",\n        \"ENABLE_I2C =  '1'         \",\n        \"HDMI_FORCE_HOTPLUG = '1'  \",\n        \"CONFIG_HDMI_BOOST = '1'   \"\n      ],\n    },\n\n    \"rpi4<\/strong>\" : {\n      \"target\": \"core-image-base\",\n      \"layers\" : [\n        \"meta-raspberrypi\n      ],\n      \"local.conf\" : [\n        \"MACHINE = 'raspberrypi4'  \",\n        \"ENABLE_UART = '1'         \",\n        \"ENABLE_SPI_BUS =  '1'     \",\n        \"ENABLE_I2C =  '1'         \",\n        \"HDMI_FORCE_HOTPLUG = '1'  \",\n        \"CONFIG_HDMI_BOOST = '1'   \"\n      ],\n    }\n  }<\/code><\/pre>\n\n\n\n
J’ai peut-\u00eatre un peu forc\u00e9 le trait, mais je suppose que vous comprenez le probl\u00e8me : ces deux builds<\/em> qui ne diff\u00e8rent que par leurs noms et les  variables MACHINES<\/code> sont oblig\u00e9s de r\u00e9p\u00e9ter une grosse poign\u00e9e de lignes identiques.<\/p>\n\n\n\n
Contrairement \u00e0 la ligne IMAGE_FEATURES += 'empty-root-password'<\/code> que nous avons pr\u00e9c\u00e9demment inscrite dans l’attribut local.conf<\/code> global \u00e0 tout le menu, les lignes de configuration ci-dessus ne concernent que les deux builds<\/em> pour Raspberry Pi 3 et 4, pas les autres builds<\/em>. Il n’est donc pas possible de rajouter ces \u00e9l\u00e9ments dans la propri\u00e9t\u00e9 local.conf<\/code> du menu.<\/p>\n\n\n\n
Pour simplifier le menu et le rendre plus maintenable en \u00e9vitant les r\u00e9p\u00e9titions, il est possible d’utiliser un m\u00e9canisme d’h\u00e9ritage<\/strong>.<\/p>\n\n\n\n
Nous pouvons d\u00e9finir un objet dans l’ensemble des builds<\/em> qui ne sera pas compil\u00e9 par lui-meme mais dont les attributs seront ajout\u00e9s aux builds<\/em> qui demandent \u00e0 en h\u00e9riter.<\/p>\n\n\n\n
Pour rendre un build<\/em> non compilable, deux possibilit\u00e9s s’offrent \u00e0 nous :<\/p>\n\n\n\n