{"id":5973,"date":"2022-02-03T09:00:00","date_gmt":"2022-02-03T08:00:00","guid":{"rendered":"https:\/\/www.blaess.fr\/christophe\/?p=5973"},"modified":"2022-02-02T15:25:43","modified_gmt":"2022-02-02T14:25:43","slug":"5973","status":"publish","type":"post","link":"https:\/\/www.blaess.fr\/christophe\/2022\/02\/03\/5973\/","title":{"rendered":"Imbriquer des syst\u00e8mes Linux avec Yocto Cooker"},"content":{"rendered":"\n<div class=\"wp-block-image\"><figure class=\"alignright size-medium\"><a href=\"https:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2022\/02\/matriotux.png\"><img loading=\"lazy\" decoding=\"async\" width=\"300\" height=\"249\" src=\"https:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2022\/02\/matriotux-300x249.png\" alt=\"\" class=\"wp-image-5974\" srcset=\"https:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2022\/02\/matriotux-300x249.png 300w, https:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2022\/02\/matriotux.png 500w\" sizes=\"auto, (max-width: 300px) 100vw, 300px\" \/><\/a><\/figure><\/div>\n\n\n\n<p>Cet article d\u00e9crit un petit projet exp\u00e9rimental sans grande utilit\u00e9, mais qui a aiguis\u00e9 ma curiosit\u00e9 pendant quelques temps. Nous allons imbriquer  les uns dans les autres des \u00e9mulateurs de syst\u00e8mes compil\u00e9s avec Yocto  Project.<\/p>\n\n\n\n<p>Outre le challenge un peu surr\u00e9aliste que cela repr\u00e9sente, nous verrons  que cette exp\u00e9rience permet de comprendre certaines d\u00e9pendances entre <em>packages<\/em> et d&rsquo;affiner une recette pour embarquer notre outil <a href=\"https:\/\/www.blaess.fr\/christophe\/2022\/01\/13\/yocto-cooker-1-3\/\" data-type=\"post\" data-id=\"5897\">Yocto Cooker<\/a>.<\/p>\n\n\n\n<!--more-->\n\n\n\n<h2 class=\"wp-block-heading\" id=\"problematique-initiale\">Probl\u00e9matique initiale<\/h2>\n\n\n\n<p>Je me suis demand\u00e9, il y a quelques ann\u00e9es, s&rsquo;il serait envisageable d&rsquo;utiliser des cartes ARM bon march\u00e9 pour cr\u00e9er un <em>cluster<\/em> de compilation suffisamment puissant pour qu&rsquo;un <em>build<\/em> cons\u00e9quent (une image \u00e0 cr\u00e9er avec Yocto Project par exemple) s&rsquo;ex\u00e9cute en un temps sensiblement plus rapide que sur un PC de bureau de milieu de gamme. Les premi\u00e8res exp\u00e9riences que j&rsquo;avais tent\u00e9es avec des Raspberry Pi mod\u00e8le 1B n&rsquo;\u00e9taient pas tr\u00e8s concluantes, autant \u00e0 cause du faible d\u00e9bit r\u00e9seau de cette carte qu&rsquo;en raison des limites de son processeur.<\/p>\n\n\n\n<p>J&rsquo;ai alors assist\u00e9 \u00e0 l&rsquo;occasion de la session 2016 de <em>Kernel Recipes<\/em> \u00e0 une pr\u00e9sentation fort int\u00e9ressante de Willy  Tarreau qui d\u00e9crivait une ferme de compilation pour le <em>kernel<\/em> bas\u00e9e sur des cartes MiQi. Cette pr\u00e9sentation a d&rsquo;ailleurs  fait l&rsquo;objet d&rsquo;un compl\u00e9ment en <em>lighting talk<\/em> des <em>Kernel Recipes<\/em> 2017.<\/p>\n\n\n\n<p>Ces conf\u00e9rences sont disponibles sur YouTube&nbsp;:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>Kernel Recipes 2016 &#8211; <em>Speeding up development by setting up a kernel build farm<\/em> &#8211; Willy Tarreau (<a href=\"https:\/\/www.youtube.com\/watch?v=vwQ-KcjskRw\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/www.youtube.com\/watch?v=vwQ-KcjskRw<\/a>)<\/li><li>Kernel Recipes 2017 &#8211; <em>Build farm again<\/em> &#8211; Willy Tarreau (<a href=\"https:\/\/www.youtube.com\/watch?v=sJwMRA34_SI\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/www.youtube.com\/watch?v=sJwMRA34_SI<\/a>)<\/li><\/ul>\n\n\n\n<p>Je n&rsquo;ai pas vraiment prolong\u00e9 mes exp\u00e9riences en ce sens, mais c&rsquo;est un sujet qui continue \u00e0 m&rsquo;int\u00e9resser. Comme Willy l&rsquo;indique dans sa conf\u00e9rence, il est indispensable que tous les noeuds utilisent exactement le m\u00eame compilateur et les m\u00eames versions de biblioth\u00e8que. Il sugg\u00e8re d&rsquo;utiliser <a href=\"https:\/\/github.com\/crosstool-ng\/crosstool-ng\">Crosstool-ng<\/a> pour produire le compilateur. Pour ma part, je pr\u00e9f\u00e9rerais g\u00e9n\u00e9rer une image compl\u00e8te avec <a href=\"https:\/\/www.yoctoproject.org\/software-overview\/downloads\/\">Yocto Project<\/a> ou <a href=\"https:\/\/buildroot.org\/\">Buildroot<\/a> afin de ma\u00eetriser enti\u00e8rement son contenu.<\/p>\n\n\n\n<p>Lorsque je pr\u00e9sente des sessions de formation <a href=\"https:\/\/www.logilin.fr\/formations-a-distance\/linux-embarque-avec-yocto-project-formation-a-distance\/\">Linux embarqu\u00e9 avec Yocto Project<\/a>, j&rsquo;indique qu&rsquo;une des diff\u00e9rences entre une image produite avec Buildroot et une compil\u00e9e par Yocto est que cette derni\u00e8re peut facilement inclure un environnement de d\u00e9veloppement sur la cible.<\/p>\n\n\n\n<p>Cette option est facile \u00e0 mettre en oeuvre, il suffit d&rsquo;indiquer<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\"> <code>IMAGE_FEATURES += 'tools-sdk'<\/code> <\/pre>\n\n\n\n<p>dans le fichier <code>local.conf<\/code> du  <em>build<\/em>. On se retrouve alors avec les outils habituels de d\u00e9veloppement de la <em>toolchain<\/em> Gnu (<code>gcc<\/code>, <code>g++<\/code>, <code>make<\/code>, etc.)  directement install\u00e9s sur la cible.<\/p>\n\n\n\n<p>Ceci n&rsquo;est habituellement pas employ\u00e9 pour un syst\u00e8me en production, mais peut n\u00e9anmoins rendre service dans  certains cas pour le d\u00e9veloppement et la mise au point du code applicatif m\u00e9tier.<\/p>\n\n\n\n<p>Lors d&rsquo;une session de formation, quelqu&rsquo;un m&rsquo;a demand\u00e9 \u00ab\u00a0<em>Mais alors, on pourrait refaire le build Yocto sur la cible&nbsp;?<\/em>\u00a0\u00bb .<\/p>\n\n\n\n<p>Spontan\u00e9ment, j&rsquo;ai r\u00e9pondu \u00ab\u00a0<em>Dans le principe s\u00fbrement, mais en pratique je ne suis pas s\u00fbr que tous les outils et biblioth\u00e8ques n\u00e9cessaires soient disponibles sous forme de recettes<\/em>\u00a0\u00bb .<\/p>\n\n\n\n<p>En y r\u00e9fl\u00e9chissant un peu plus, je me suis dit qu&rsquo;<em>a priori<\/em> rien ne l&rsquo;interdisait et qu&rsquo;il serait int\u00e9ressant d&rsquo;avoir une liste des  <em>packages<\/em> n\u00e9cessaires pour qu&rsquo;une cible soit capable de g\u00e9n\u00e9rer une image Yocto Project.<\/p>\n\n\n\n<p>Sans avoir vraiment d&rsquo;id\u00e9e d&rsquo;application pratique, il me semblait amusant qu&rsquo;une image soit capable de se r\u00e9pliquer elle-m\u00eame. J&rsquo;ai commenc\u00e9 par lister les <em>packages<\/em> n\u00e9cessaires pour r\u00e9aliser cette op\u00e9ration.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"packages-de-developpement-necessaires\">Packages de d\u00e9veloppement n\u00e9cessaires<\/h2>\n\n\n\n<p>Pour pouvoir faire confortablement du d\u00e9veloppement sur une cible produite par Yocto Project, j&rsquo;ai s\u00e9lectionn\u00e9 les packages suivants, pr\u00e9sents dans les <em>layers<\/em> de <code>poky<\/code> ou ceux de <code>meta-openembedded<\/code>.<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li><code>bash<\/code>, <code>nano<\/code>, <code>resolvconf<\/code> et <code>ssh-server-openssh<\/code> pour pouvoir se connecter et travailler sur notre cible un peu plus confortablement qu&rsquo;avec les outils de <code>busybox<\/code>.<\/li><li><code>dev-pkgs<\/code> et <code>tools-sdk<\/code> nous fournirons une <em>toolchain<\/em> et les fichiers <em>headers<\/em> des <em>packages<\/em> install\u00e9s.<\/li><li><code>chrpath<\/code>, <code>cpio<\/code>, <code>git<\/code>, <code>perl<\/code>, <code>perl-modules<\/code>, <code>python3<\/code>, <code>rpsvc-proto<\/code>, <code>tar<\/code>, <code>wget<\/code> font partie des outils que l&rsquo;on installe syst\u00e9matiquement pour travailler avec Yocto Project. Les distributions les int\u00e8grent dans des meta-<em>packages<\/em> comme <code>build-essential<\/code> par exemple.<\/li><\/ul>\n\n\n\n<p>Depuis bient\u00f4t deux ans que nous avons entam\u00e9 le projet <a rel=\"noreferrer noopener\" href=\"https:\/\/www.blaess.fr\/christophe\/2022\/01\/13\/yocto-cooker-1-3\/\" target=\"_blank\">Yocto Cooker<\/a> avec mon confr\u00e8re Patrick Boettcher, je n&rsquo;utilise quasiment plus les composants de Yocto Project (Poky, <code>bitbake<\/code>, <code>meta-openembedded<\/code>, etc) hors de <code>cooker<\/code>.<\/p>\n\n\n\n<p>Il me semblait donc indispensable d&rsquo;inclure les packages capables de faire fonctionner Yocto Cooker&nbsp;: <code>python3-pkg-resources<\/code>, <code>python3-urllib3<\/code> et <code>python3-jsonschema<\/code>. Il m&rsquo;a \u00e9videmment fallu d\u00e9velopper une recette pour int\u00e9grer le script <code>cooker<\/code> sur la cible.<\/p>\n\n\n\n<p>Cette recette pour <code>cooker<\/code> est disponible dans le layer <code>meta-stacking<\/code> se trouvant dans le <a href=\"https:\/\/github.com\/cpb-\/stacking-yocto\">d\u00e9p\u00f4t Git suivant<\/a>.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># yocto-cooker_1.2.0.bb\nSUMMARY = \"Yocto Cooker - a meta-buildtool for Yocto Project\"\nHOMEPAGE = \"https:\/\/github.com\/cpb-\/yocto-cooker\"\nLICENSE = \"GPL-2.0\"\nLIC_FILES_CHKSUM = \"file:\/\/${COMMON_LICENSE_DIR}\/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6\"\n\ninherit pypi setuptools3\n\nSRCREV = \"${PV}\"\nPYPI_PACKAGE = \"yocto-cooker\"\nPYPI_SRC_URI = \"git:\/\/git@github.com\/cpb-\/yocto-cooker.git\"\n\nS = \"${WORKDIR}\/git\"\n\nRDEPENDS:${PN} += \"       \\\n    python3-core          \\\n    python3-urllib3       \\\n    python3-pkg-resources \\\n    python3-jsonschema    \\\n\"\n\nBBCLASSEXTEND = \"native\"<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"recette-d-image\">Recette d&rsquo;image<\/h2>\n\n\n\n<p>Pour regrouper les <em>packages<\/em> \u00e0 compiler, j&rsquo;ai cr\u00e9\u00e9 une recette d&rsquo;image afin de pouvoir reproduire facilement le <em>build<\/em> pour plusieurs architectures.<\/p>\n\n\n\n<p>Cette recette est pr\u00e9sente dans le <em>layer<\/em> <code>meta-stacking<\/code> \u00e9galement. Elle s&rsquo;appelle <code>staking-image.bb<\/code> et incorpore les packages indiqu\u00e9s&nbsp;:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Base image.\ninherit core-image\n\n# Comfortable shell and editor.\nIMAGE_INSTALL_append = \" bash\"\nIMAGE_INSTALL_append = \" nano\"\n\n# Network configuration (extended by one of our recipe).\nIMAGE_INSTALL_append = \" resolv-conf\"\n\n# Developpement packages on the target.\nIMAGE_FEATURES += \"ssh-server-openssh\"\nIMAGE_FEATURES += \"dev-pkgs\"\nIMAGE_FEATURES += \"tools-sdk\"\n\n# Yocto Project needed tools.\nIMAGE_INSTALL_append = \" chrpath\"\nIMAGE_INSTALL_append = \" cpio\"\nIMAGE_INSTALL_append = \" git\"\nIMAGE_INSTALL_append = \" perl\"\nIMAGE_INSTALL_append = \" perl-modules\"\nIMAGE_INSTALL_append = \" python3\"\nIMAGE_INSTALL_append = \" resolvconf\"\nIMAGE_INSTALL_append = \" rpcsvc-proto\"\nIMAGE_INSTALL_append = \" tar\"\nIMAGE_INSTALL_append = \" wget\"\n\n# Yocto Cooker needed packages.\nIMAGE_INSTALL_append = \" yocto-cooker\"\nIMAGE_INSTALL_append = \" python3-pkg-resources\"\nIMAGE_INSTALL_append = \" python3-urllib3\"\nIMAGE_INSTALL_append = \" python3-jsonschema\"<\/code><\/pre>\n\n\n\n<p>Elle contient \u00e9galement une d\u00e9finition d&rsquo;un utilisateur nomm\u00e9 <code>stack<\/code> ayant le mot de passe <code>stack<\/code> et autoris\u00e9 \u00e0 appeler la commande <code>sudo<\/code>.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># A non-priviledged user to run the build.\ninherit extrausers\nEXTRA_USERS_PARAMS_append = \"usermod -P 'root'   root;\"\nEXTRA_USERS_PARAMS_append = \"useradd -P 'stack' stack;\"\nEXTRA_USERS_PARAMS_append = \"usermod -a -G sudo stack;\"\nIMAGE_INSTALL_append = \" sudo\"<\/code><\/pre>\n\n\n\n<p>Une petite extension de recette pour <code>sudo<\/code> est pr\u00e9sente dans le r\u00e9pertoire pour autoriser toutes les actions privil\u00e9gi\u00e9es aux utilisateurs du groupe <code>sudo<\/code>.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># sudo_%.bbappend\ndo_install_append () {\n        install -d -m 0750 ${D}${sysconfdir}\/sudoers.d\n        echo \"%sudo ALL=(ALL:ALL) ALL\" &gt; ${D}${sysconfdir}\/sudoers.d\/sudo\n        chmod 640 ${D}${sysconfdir}\/sudoers.d\/sudo\n}\n\nFILES_${PN} += \"${sysconfdir}\/sudoers.d\/sudo\"<\/code><\/pre>\n\n\n\n<p>Enfin, un package suppl\u00e9mentaire est ajout\u00e9 dans le fichier d&rsquo;image, nous en reparlerons plus bas&nbsp;:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>IMAGE_INSTALL_append = \" kernel-module-tun\"<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"choix-d-une-cible\">Choix d&rsquo;une cible<\/h2>\n\n\n\n<p>Comme je sentais que j&rsquo;aurai \u00e0 rep\u00e9ter plusieurs dizaines de fois le m\u00eame <em>build<\/em> en corrigeant certains aspects \u00e0 chaque fois, j&rsquo;ai pr\u00e9f\u00e9r\u00e9 \u00e9viter de devoir copier les images sur une cible externe (ou une carte SD) pour tester mon r\u00e9sultat. J&rsquo;ai donc d\u00e9cid\u00e9 de travailler avec Qemu.<\/p>\n\n\n\n<p>Le projet Qemu est capable d&rsquo;\u00e9muler de nombreuses machines diff\u00e9rentes. Pour ce premier <em>build<\/em> je vais m&rsquo;int\u00e9resser \u00e0 une \u00e9mulation de processeur Arm 64-bits.<\/p>\n\n\n\n<p>Pour rendre le build ais\u00e9ment r\u00e9p\u00e9table, je cr\u00e9e un fichier-menu pour Yocto Cooker.<\/p>\n\n\n\n<p>J&rsquo;incorpore directement le menu dans le d\u00e9p\u00f4t <code>stacking-yocto<\/code> d\u00e9crit plus haut, cela lui \u00e9vitera de devoir t\u00e9l\u00e9charger le menu <code>meta-stacking<\/code> qui sera directement pr\u00e9sent \u00e0 c\u00f4t\u00e9 du menu. Il faudra n\u00e9anmoins charger les d\u00e9p\u00f4ts <code>poky<\/code> et <code>meta-openembedded<\/code> habituels. Voici donc les sections <code>sources<\/code> et <code>layers<\/code> du menu&nbsp;:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>  \"sources\" : &#91;\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\" : &#91;\n    \"poky\/meta\",\n    \"poky\/meta-poky\",\n    \"poky\/meta-yocto-bsp\",\n    \"meta-openembedded\/meta-oe\",\n    \"meta-openembedded\/meta-python\",\n    \"meta-stacking\"\n  ],<\/code><\/pre>\n\n\n\n<p>Dans la section <code>builds<\/code> je cr\u00e9e une premi\u00e8re cible (nous en ajouterons une seconde ensuite) tr\u00e8s simple&nbsp;:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>  \"builds\" : {\n    \"stacking-arm\" : {\n      \"target\": \"stacking-image\",\n      \"local.conf\": &#91;\n        \"MACHINE = 'qemuarm64'                 \",\n        \"IMAGE_ROOTFS_EXTRA_SPACE = '83886080' \"\n      ]\n    }\n  }<\/code><\/pre>\n\n\n\n<p>La ligne <code>IMAGE_ROOTFS_EXTRA_SPACE<\/code> s&rsquo;assure que la cible dispose d&rsquo;un espace libre dans son <em>root filesystem<\/em> d&rsquo;au moins 80 Go. Cette valeur est un peu excessive, une cinquantaine aurait largement suffit, mais si on veut faire des <em>builds<\/em> Yocto, il vaut mieux pr\u00e9voir large question espace de stockage&nbsp;!<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"premier-build\">Premier build<\/h2>\n\n\n\n<p>Je lance le <em>build<\/em>, sa dur\u00e9e d\u00e9pend de la machine de compilation et de l&rsquo;acc\u00e8s Internet, en g\u00e9n\u00e9ral il prend une \u00e0 deux heures.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>$ <strong>cooker  cook  menus\/stacking-yocto.json  stacking-arm<\/strong>\n&#91;...]\nBuild Configuration:\nBB_VERSION           = \"1.46.0\"\nBUILD_SYS            = \"x86_64-linux\"\nNATIVELSBSTRING      = \"universal\"\nTARGET_SYS           = \"aarch64-poky-linux\"\nMACHINE              = \"qemuarm64\"\nDISTRO               = \"poky\"\nDISTRO_VERSION       = \"3.1.13\"\nTUNE_FEATURES        = \"aarch64 armv8a crc\"\nTARGET_FPU           = \"\"\nmeta-oe              \nmeta-python          = \"HEAD:ab9fca485e13f6f2f9761e1d2810f87c2e4f060a\"\nmeta-stacking        = \"master:5cf6382098e39cafa2062ebcec98d625a0acfaf5\"\nmeta                 \nmeta-poky            \nmeta-yocto-bsp       = \"HEAD:795339092f87672e4f68e4d3bc4cfd0e252d1831\"\n&#91;...]\n$ <\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"premier-lancement\">Premier lancement<\/h2>\n\n\n\n<p>Pour lancer l&rsquo;\u00e9mulateur Qemu, je vais utiliser le script <code>runqemu<\/code> fourni dans le d\u00e9p\u00f4t <code>poky<\/code>. Pour cela, il faut que les  variables d&rsquo;environnement de Poky soient correctement initialis\u00e9es, et que nous nous placions dans le r\u00e9pertoire de <em>build<\/em>. C&rsquo;est le r\u00f4le du script <code>oe-init-build-env<\/code> que l&rsquo;on appelle g\u00e9n\u00e9ralement lorsqu&rsquo;on d\u00e9bute une session de travail pour Yocto.<\/p>\n\n\n\n<p>Ici, nous utilisons Yocto Cooker, aussi vais-je appeler une action sp\u00e9cifique d\u00e9volue \u00e0 ce travail&nbsp;: <code>cooker shell<\/code>.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#91;stacking-yocto]$ <strong>cooker  shell  stacking-arm<\/strong>\n&#91;build-stacking-arm]$ <\/code><\/pre>\n\n\n\n<p>Nous pouvons d\u00e9marrer l&rsquo;\u00e9mulateur. Pour pouvoir faire des compilations dans de bonnes conditions, je vais <em>booster<\/em> un peu la machine \u00e9mul\u00e9e en demandant \u00e0 Qemu de simuler 8 coeurs et de r\u00e9server 8 Go de Ram. Bien s\u00fbr il faut que le PC sous-jacent soit capable d&rsquo;offrir ces ressources.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#91;build-stacking-arm]$ <strong>runqemu  nographic qemuarm64  qemuparams=\"-smp cores=8 -m 8192\"<\/strong>\n &#91;...]\n&#91;    0.000000] Booting Linux on physical CPU 0x0000000000 &#91;0x411fd070]\n&#91;    0.000000] Linux version 5.4.158-yocto-standard (oe-user@oe-host) (gcc version 9.3.0 (GCC)) #1 SMP PREEMPT Tue Nov 9 16:43:38 UTC 2021\n&#91;    0.000000] Machine model: linux,dummy-virt\n&#91;    0.000000] Memory limited to 8192MB\n &#91;...]\n&#91;    0.050395] smp: Bringing up secondary CPUs ...\n&#91;    0.054475] Detected PIPT I-cache on CPU1\n&#91;    0.055085] CPU1: Booted secondary processor 0x0000000001 &#91;0x411fd070]\n&#91;    0.059503] Detected PIPT I-cache on CPU2\n&#91;    0.059662] CPU2: Booted secondary processor 0x0000000002 &#91;0x411fd070]\n&#91;    0.061141] Detected PIPT I-cache on CPU3\n&#91;    0.061261] CPU3: Booted secondary processor 0x0000000003 &#91;0x411fd070]\n&#91;    0.062670] Detected PIPT I-cache on CPU4\n&#91;    0.062788] CPU4: Booted secondary processor 0x0000000004 &#91;0x411fd070]\n&#91;    0.064316] Detected PIPT I-cache on CPU5\n&#91;    0.064442] CPU5: Booted secondary processor 0x0000000005 &#91;0x411fd070]\n&#91;    0.065838] Detected PIPT I-cache on CPU6\n&#91;    0.065979] CPU6: Booted secondary processor 0x0000000006 &#91;0x411fd070]\n&#91;    0.067396] Detected PIPT I-cache on CPU7\n&#91;    0.067540] CPU7: Booted secondary processor 0x0000000007 &#91;0x411fd070]\n&#91;    0.068284] smp: Brought up 1 node, 8 CPUs\n&#91;    0.068341] SMP: Total of 8 processors activated.\n &#91;...]\n&#91;    2.730577] Freeing unused kernel memory: 960K\n&#91;    2.735481] Run \/sbin\/init as init process\n&#91;    2.806731] usb 1-2: new high-speed USB device number 3 using xhci_hcd\nINIT: version 2.96 booting\n&#91;    2.968571] input: QEMU QEMU USB Keyboard as \/devices\/platform\/4010000000.pcie\/pci0000:00\/0000:00:02.0\/usb1\/1-2\/1-2:1.0\/0003:0627:0001.0002\/input\/input1\n&#91;    3.027371] hid-generic 0003:0627:0001.0002: input: USB HID v1.11 Keyboard &#91;QEMU QEMU USB Keyboard] on usb-0000:00:02.0-2\/input0\n&#91;    3.234872] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready\nStarting udev\n&#91;    3.835170] udevd&#91;146]: starting version 3.2.9\n&#91;    3.908128] udevd&#91;148]: starting eudev-3.2.9\n&#91;    4.356677] EXT4-fs (vda): re-mounted. Opts: (null)\n &#91;...]\n\nPoky (Yocto Project Reference Distro) 3.1.13 qemuarm64 ttyAMA0\n\nqemuarm64 login:<\/code><\/pre>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"alignright size-full\"><a href=\"https:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2022\/02\/imbrications-1.png\"><img loading=\"lazy\" decoding=\"async\" width=\"384\" height=\"216\" src=\"https:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2022\/02\/imbrications-1.png\" alt=\"\" class=\"wp-image-5994\" srcset=\"https:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2022\/02\/imbrications-1.png 384w, https:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2022\/02\/imbrications-1-300x169.png 300w\" sizes=\"auto, (max-width: 384px) 100vw, 384px\" \/><\/a><\/figure><\/div>\n\n\n\n<p>Je n&rsquo;ai conserv\u00e9 que quelques lignes int\u00e9ressantes du <em>boot<\/em> du syst\u00e8me. Je me trouve donc aux commandes d&rsquo;une machine dot\u00e9e d&rsquo;un processeur ARM 64-bits, \u00e9mul\u00e9es dans l&rsquo;espace utilisateur d&rsquo;un syst\u00e8me tournant sur PC x86-64.<\/p>\n\n\n\n<p>Je peux me connecter et passer quelques commandes pour v\u00e9rifier ma machine.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>qemuarm64 login: <strong>stack<\/strong>\nPassword: <em><strong>(stack)<\/strong><\/em>\nqemuarm64:~$ <strong>lscpu<\/strong> \nArchitecture:                    aarch64\nCPU op-mode(s):                  32-bit, 64-bit\nByte Order:                      Little Endian\nCPU(s):                          8\nOn-line CPU(s) list:             0-7\nThread(s) per core:              1\nCore(s) per socket:              8\nSocket(s):                       1\nVendor ID:                       ARM\nModel:                           0\nModel name:                      Cortex-A57\nStepping:                        r1p0\nBogoMIPS:                        125.00\nVulnerability Itlb multihit:     Not affected\nVulnerability L1tf:              Not affected\nVulnerability Mds:               Not affected\nVulnerability Meltdown:          Not affected\nVulnerability Spec store bypass: Vulnerable\nVulnerability Spectre v1:        Mitigation; __user pointer sanitization\nVulnerability Spectre v2:        Vulnerable\nVulnerability Srbds:             Not affected\nVulnerability Tsx async abort:   Not affected\nFlags:                           fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid\n\nqemuarm64:~$ <strong>free<\/strong>\n              total        used        free      shared  buff\/cache   available\nMem:        8146940       78824     2778852         400     5289264     7972820\nSwap:             0           0           0\n\nqemuarm64:~$ <\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"second-build\">Second build<\/h2>\n\n\n\n<p>Maintenant que nous sommes dans notre \u00e9mulateur, nous allons v\u00e9rifier si notre configuration est suffisante pour re-g\u00e9n\u00e9rer une image \u00e9quivalente \u00e0 celle dans laquelle nous \u00e9voluons.<\/p>\n\n\n\n<p>Commen\u00e7ons par t\u00e9l\u00e9charger le d\u00e9p\u00f4t <code>stacking-yocto<\/code> d\u00e9crit plus haut.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>qemuarm64:~$ <strong>git  clone  https:\/\/github.com\/cpb-\/stacking-yocto<\/strong>\nqemuarm64:~$ <strong>cd  stacking-yocto\/<\/strong><\/code><\/pre>\n\n\n\n<p>Pour varier un peu les plaisirs, j&rsquo;ai d\u00e9cid\u00e9 de changer la cible, et de ne plus g\u00e9n\u00e9rer d&rsquo;image pour \u00e9mulateur Arm, mais pour \u00e9mulateur x86.<\/p>\n\n\n\n<p>Le <em>build<\/em> suivant est ajout\u00e9 dans le fichier-menu de <code>cooker<\/code> :<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>  \"stacking-x86\" : {\n    \"target\": \"stacking-image\",\n    \"local.conf\": &#91;\n      \"MACHINE = 'qemux86-64'                \",\n      \"IMAGE_ROOTFS_EXTRA_SPACE = '41943040' \"\n    ]\n  }<\/code><\/pre>\n\n\n\n<p>J&rsquo;ai demand\u00e9 un espace disponible de 40 Go sur le <em>root filesystem<\/em> de la nouvelle image. En r\u00e9alit\u00e9 c&rsquo;est inutile car je ne compte pas relancer un troisi\u00e8me build imbriqu\u00e9. Toutefois cela me permet de valider que cela soit possible si besoin.<\/p>\n\n\n\n<p>Je lance alors la compilation. Attention, celle-ci dure beaucoup plus longtemps que la pr\u00e9c\u00e9dente. Sur mon poste de  travail, le premier <em>build<\/em> a dur\u00e9 environ 1 heure et celui-ci 34 heures&nbsp;!<\/p>\n\n\n\n<p>Il faut bien comprendre qu&rsquo;avec Qemu, nous ne sommes pas dans la m\u00eame situation qu&rsquo;avec des outils comme <em>Virtual Box<\/em> ou <em>Vmware<\/em> qui nous offrent un PC virtuel dans un PC r\u00e9el en tirant parti des sp\u00e9cificit\u00e9 du processeur mais en restant sur la m\u00eame architecture.<\/p>\n\n\n\n<p>Ici, nous avons une machine bas\u00e9e sur un processeur ARM qui fonctionne dans une machine bas\u00e9e sur processeur x86. Cela n\u00e9cessite beaucoup plus de travail de traduction d&rsquo;instructions et de simulation de mat\u00e9riel.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>qemuarm64:~\/stacking-yocto$ <strong>cooker  cook  menus\/stacking-yocto.json  stacking-x86<\/strong>\n# Update layers in project directory\n# Downloading source from  git:\/\/git.yoctoproject.org\/poky\n# Updating source \/home\/stack\/stacking-yocto\/layers\/poky... \n# Downloading source from  git:\/\/git.openembedded.org\/meta-openembedded\n# Updating source \/home\/stack\/stacking-yocto\/layers\/meta-openembedded... \n# Generating dirs for all build-configurations\n# Building stacking-x86 (stacking-image)\n  &#91;...]\nNOTE: Tasks Summary: Attempted 5081 tasks of which 8 didn't need to be rerun and all succeeded.\nSummary: There was 1 WARNING message shown.\n\nqemuarm64:~\/stacking-yocto$<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"second-lancement\">Second lancement<\/h2>\n\n\n\n<p>Une fois le long <em>build<\/em> termin\u00e9, nous allons vais lancer l&rsquo;\u00e9mulateur <code>qemux86-64<\/code> \u00e0 l&rsquo;int\u00e9rieur de l&rsquo;\u00e9mulation <code>qemuarm-64<\/code>.<\/p>\n\n\n\n<p>Comme le script <code>runqemu<\/code> essayer d&rsquo;\u00e9tablir un bridge avec l&rsquo;interface <code>tun<\/code>, il faut charger ce module dans le noyau. C&rsquo;est  pour cela que j&rsquo;avais ajout\u00e9 le package <code>kernel-module-tun<\/code> dans l&rsquo;image.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>qemuarm64:~\/stacking-yocto$ <strong>sudo  \/sbin\/modprobe  tun<\/strong>\nPassword: <em><strong>(stack)<\/strong><\/em>\n&#91;126823.002017] tun: Universal TUN\/TAP device driver, 1.6\n\nqemuarm64:~\/stacking-yocto$ \n<\/code><\/pre>\n\n\n\n<p>Pour lancer <code>runqemu<\/code>, je vais proc\u00e9der comme au niveau pr\u00e9c\u00e9dent, en appelant <code>cooker shell<\/code> pour pr\u00e9parer les variables d&rsquo;environnement n\u00e9cessaires.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>qemuarm64:~\/stacking-yocto$ <strong>cooker  shell  stacking-x86<\/strong>\n\nsh-5.0$<\/code><\/pre>\n\n\n\n<p>Il me faut ajouter dans la variable <code>PATH<\/code> le chemin <code>\/sbin\/<\/code> pour que le script puisse trouver la commande <code>ip<\/code><\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">sh-5.0$ <strong>PATH=$PATH:\/sbin\/<\/strong>\nsh-5.0$ <strong>sudo runqemu nographic qemux86-64<\/strong>\nrunqemu - INFO - Running MACHINE=qemux86-64 bitbake -e ...<\/pre>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"alignright size-full\"><a href=\"https:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2022\/02\/imbrications.png\"><img loading=\"lazy\" decoding=\"async\" width=\"384\" height=\"341\" src=\"https:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2022\/02\/imbrications.png\" alt=\"\" class=\"wp-image-5980\" srcset=\"https:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2022\/02\/imbrications.png 384w, https:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2022\/02\/imbrications-300x266.png 300w\" sizes=\"auto, (max-width: 384px) 100vw, 384px\" \/><\/a><\/figure><\/div>\n\n\n\n<p>Prenons un instant de recul pour assimiler la situation&nbsp;:<\/p>\n\n\n\n<p>La <strong>machine de base<\/strong> (la plus externe sur le sch\u00e9ma ci-contre) est un PC de type X86 64-bits dont les ressources sont g\u00e9r\u00e9es par le noyau Linux fourni par une distribution classique.<\/p>\n\n\n\n<p>Dans l&rsquo;espace utilisateur de ce PC nous faisons fonctionner l&rsquo;application Qemu qui simule un processeur Arm 64-bits et tous les p\u00e9riph\u00e9riques n\u00e9cessaires.<\/p>\n\n\n\n<p>Dans cette <strong>seconde machine<\/strong> nous chargeons un noyau Linux et un espace applicatif fournis par l&rsquo;image Yocto produite sur le PC. Sur cet environnment Arm-64 \u00e9mul\u00e9, nous avons, dans un premier temps, utilis\u00e9 les outils embarqu\u00e9s par Yocto pour g\u00e9n\u00e9rer une seconde image.<\/p>\n\n\n\n<p>Dans l&rsquo;espace utlisateur de la machine Arm 64-bits, nous ex\u00e9cutons de nouveau Qemu, pour simuler cette fois un processeur x86 64-bits.<\/p>\n\n\n\n<p>Le d\u00e9marrage du kernel de ce <strong>troisi\u00e8me syst\u00e8me<\/strong> dure assez longtemps, mais il nous fournit un acc\u00e8s \u00e0 la machine interne, et nous pourrions en th\u00e9orie continuer \u00e0 imbriquer des syst\u00e8mes les uns dans les autres, avec la seule limite de la taille m\u00e9moire et de l&rsquo;espace disque disponibles.<\/p>\n\n\n\n<p>Cette fois le <em>boot<\/em> dure beaucoup plus longtemps que pr\u00e9c\u00e9demment (environ une heure de <em>boot<\/em>, \u00e7a m&rsquo;a rappel\u00e9 une mise \u00e0 jour du syst\u00e8me HP-9000 de mon \u00e9cole que nous avions d\u00fb faire lorsque j&rsquo;\u00e9tais \u00e9tudiant).<\/p>\n\n\n\n<p>Durant le boot, il y a plusieurs notification d&rsquo;erreur de <em>timers<\/em> <code>hpet<\/code> mais il progresse quand m\u00eame.<\/p>\n\n\n\n<p>En voici, quelques lignes repr\u00e9sentatives, ainsi que ma connexion dans la nouvelle machine \u00e9mul\u00e9e et quelques commandes.<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">[ 0.000000] Linux version 5.4.158-yocto-standard (oe-user@oe-host) (gcc version 9.3.0 (GCC)) #1 SMP PREEMPT Tue N1\n[ 0.000000] Command line: root=\/dev\/vda rw console=ttyS0 mem=256M ip=192.168.7.2::192.168.7.1:255.255.255.0 opro\n[ 0.000000] x86\/fpu: x87 FPU will use FXSAVE\n[ 0.000000] BIOS-provided physical RAM map:\n[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable\n[ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved\n[ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved\n[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000000ffdafff] usable\n[ 0.000000] BIOS-e820: [mem 0x000000000ffdb000-0x000000000fffffff] reserved\n[ 0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved\n  [...]\n[   91.949907] EXT4-fs (vda): mounted filesystem with ordered data mode. Opts: (null)\n[   91.972343] VFS: Mounted root (ext4 filesystem) on device 253:0.\n[   92.076125] devtmpfs: mounted\n[   93.985423] Freeing unused kernel image memory: 1592K\n[   94.019320] Write protecting the kernel read-only data: 20480k\n[   94.133314] Freeing unused kernel image memory: 2004K\n[   94.164625] Freeing unused kernel image memory: 908K\n[   94.184161] Run \/sbin\/init as init process\nINIT: version 2.96 booting\nStarting udev\n [...]\n\nPoky (Yocto Project Reference Distro) 3.1.13 qemux86-64 ttyS0\n\nqemux86-64 login: <strong>stack<\/strong>\nPassword: <em><strong>(stack)<\/strong><\/em>\n\nqemux86-64:~$ <strong>uname  -a<\/strong>\nLinux qemux86-64 5.4.158-yocto-standard #1 SMP PREEMPT Tue Nov 9 16:42:29 UTC 2021 x86_64 x86_64 x86_64 GNU\/Linux\n\nqemux86-64:~$ <strong>free<\/strong>\n              total        used        free      shared  buff\/cache   available\nMem:         236708       30204      165348         264       41156      197720\nSwap:             0           0           0\n\nqemux86-64:~$ <strong>lscpu<\/strong>\nArchitecture:                    x86_64\nCPU op-mode(s):                  32-bit, 64-bit\nByte Order:                      Little Endian\nAddress sizes:                   40 bits physical, 48 bits virtual\nCPU(s):                          1\nOn-line CPU(s) list:             0\nThread(s) per core:              1\nCore(s) per socket:              1\nSocket(s):                       1\nVendor ID:                       GenuineIntel\nCPU family:                      6\nModel:                           15\nModel name:                      Intel(R) Core(TM)2 Duo CPU     T7700  @ 2.40GHz\nStepping:                        11\nCPU MHz:                         999.564\nBogoMIPS:                        1999.12\nL1d cache:                       32 KiB\nL1i cache:                       32 KiB\nL2 cache:                        4 MiB\nL3 cache:                        16 MiB\nVulnerability Itlb multihit:     Processor vulnerable\nVulnerability L1tf:              Mitigation; PTE Inversion\nVulnerability Mds:               Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown\nVulnerability Meltdown:          Mitigation; PTI\nVulnerability Spec store bypass: Vulnerable\nVulnerability Spectre v1:        Mitigation; usercopy\/swapgs barriers and __user pointer sanitization\nVulnerability Spectre v2:        Mitigation; Full generic retpoline, STIBP disabled, RSB filling\nVulnerability Srbds:             Not affected\nVulnerability Tsx async abort:   Not affected\nFlags:                           fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush acpi mmx\n                                  fxsr sse sse2 syscall nx lm constant_tsc rep_good nopl cpuid pni monitor ssse3 cx16\n                                  hypervisor lahf_lm pti\n\nqemux86-64:~$ <strong>\/sbin\/ip  addr<\/strong>\n1: lo: &lt;LOOPBACK,UP,LOWER_UP&gt; mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000\n    link\/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00\n    inet 127.0.0.1\/8 scope host lo\n       valid_lft forever preferred_lft forever\n    inet6 ::1\/128 scope host \n       valid_lft forever preferred_lft forever\n2:<strong> eth0<\/strong>: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 1500 qdisc pfifo_fast state UP group default qlen 1000\n    link\/ether 52:54:00:12:34:02 brd ff:ff:ff:ff:ff:ff\n    inet <strong>192.168.7.2\/24<\/strong> brd 192.168.7.255 scope global eth0\n       valid_lft forever preferred_lft forever\n    inet6 fe80::5054:ff:fe12:3402\/64 scope link \n       valid_lft forever preferred_lft forever\n3: sit0@NONE: &lt;NOARP&gt; mtu 1480 qdisc noop state DOWN group default qlen 1000\n    link\/sit 0.0.0.0 brd 0.0.0.0\n<\/pre>\n\n\n\n<p>Si nous essayons d&rsquo;utiliser le r\u00e9seau depuis la machine la plus interne, cela ne fonctionne pas. Pour comprendre pourquoi, nous pouvons nous connecter en SSH sur la machine interm\u00e9diaire depuis le PC&nbsp;:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#91;~]$ <strong>ssh  stack@192.168.7.2<\/strong>\nstack@192.168.7.2's password: <em><strong>(stack)<\/strong><\/em>\n\nqemuarm64:~$ <strong>\/sbin\/ip  addr<\/strong>\n1: lo: &lt;LOOPBACK,UP,LOWER_UP&gt; mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000\n    link\/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00\n    inet 127.0.0.1\/8 scope host lo\n       valid_lft forever preferred_lft forever\n    inet6 ::1\/128 scope host \n       valid_lft forever preferred_lft forever\n2: <strong>eth0:<\/strong> &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 1500 qdisc pfifo_fast state UP group default qlen 1000\n    link\/ether 52:54:00:12:34:02 brd ff:ff:ff:ff:ff:ff\n    <strong>inet 192.168.7.2\/24<\/strong> brd 192.168.7.255 scope global eth0\n       valid_lft forever preferred_lft forever\n    inet6 fe80::5054:ff:fe12:3402\/64 scope link \n       valid_lft forever preferred_lft forever\n3: sit0@NONE: &lt;NOARP&gt; mtu 1480 qdisc noop state DOWN group default qlen 1000\n    link\/sit 0.0.0.0 brd 0.0.0.0\n4: <strong>tap0:<\/strong> &lt;BROADCAST,MULTICAST&gt; mtu 1500 qdisc noop state DOWN group default qlen 1000\n    link\/ether 92:30:d5:fa:5e:c6 brd ff:ff:ff:ff:ff:ff\nqemuarm64:~$ <\/code><\/pre>\n\n\n\n<p>Un petit inconv\u00e9nient appara\u00eet ici&nbsp;: Qemu utilise le sous-r\u00e9seau <code>192.168.7.0\/24<\/code> sur l&rsquo;interface <code>eth0<\/code> qu&rsquo;il simule entre la machine interm\u00e9diaire et le PC.<\/p>\n\n\n\n<p>Lorsqu&rsquo;on d\u00e9marre la seconde \u00e9mulation imbriqu\u00e9e, Qemu essaye d&rsquo;utiliser le m\u00eame sous-r\u00e9seau sur l&rsquo;interface <code>tap0<\/code> qui sert \u00e0 acc\u00e9der \u00e0 la machine la plus interne. Le routage \u00e9choue et la machine interne n&rsquo;a pas acc\u00e8s au r\u00e9seau externe. Il faudrait demander \u00e0 Qemu de changer de sous-r\u00e9seau, mais je n&rsquo;ai pas eu le courage de relancer le boot (qui dure une heure) de la seconde \u00e9mulation.<\/p>\n\n\n\n<p>Apr\u00e8s quelques minutes, j&rsquo;arr\u00eate la machine la plus interne, et je retourne sur l&rsquo;\u00e9mulateur interm\u00e9diaire (la commande <code>halt<\/code> ne prend pas autant de temps que le <em>boot<\/em>, mais il faut quand m\u00eame un peu de patience).<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">qemux86-64:~$ <strong>sudo  \/sbin\/halt<\/strong>\n\nBroadcast message from root@qemux86-64 (ttyS0) (Wed Feb  2 13:54:19 2022):\n\nThe system is going down for system halt NOW!\nINIT: Switching to runlevel: 0\nINIT: Sending processes configured via \/etc\/inittab the TERM signal\nStopping OpenBSD Secure Shell server: sshdstopped \/usr\/sbin\/sshd (pid 324)\n.\n * Stopping Avahi mDNS\/DNS-SD Daemon: avahi-daemon\n *iled to kill daemon: Timer expired                                                                     ]\nStopping bluetooth: bluetoothd.\nStopping system message bus: dbus.\nstopping mountd: done\nstopping nfsd: [14043.507768] nfsd: last server has exited, flushing export cache\ndone\nStopping syslogd\/klogd: stopped syslogd (pid 374)\nstopped klogd (pid 377)\n [...]\nSending all processes the TERM signal...\nlogout\nSending all processes the KILL signal...\nUnmounting remote filesystems...\nDeactivating swap...\nUnmounting local filesystems...\n[14411.850884] EXT4-fs (vda): re-mounted. Opts: (null)\n[14449.613391] ACPI: Preparing to enter system sleep state S5\n[14449.765252] reboot: Power down\nrunqemu - INFO - Cleaning up\n\nsh-5.0$ <\/pre>\n\n\n\n<p>Nous voici de retour dans l&rsquo;\u00e9mulateur interm\u00e9diaire, j&rsquo;en profite pour voir le volume de <em>root filesystem<\/em> qui a \u00e9t\u00e9 utilis\u00e9 par le <em>build<\/em> Yocto Project&nbsp;:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">sh-5.0$ <strong>df<\/strong>  \nFilesystem     1K-blocks     Used Available Use% Mounted on\n\/dev\/root       78822416 58268392  16305412  79% \/\ndevtmpfs         4072988        0   4072988   0% \/dev\ntmpfs            4073468      108   4073360   1% \/run\ntmpfs            4073468      328   4073140   1% \/var\/volatile\nsh-5.0$ <\/pre>\n\n\n\n<p>Un peu moins de 60 Go sont occup\u00e9s pour stocker le syst\u00e8me lui-m\u00eame, ainsi que les sources et les fichiers binaires produits par la compilation. Je termine en arr\u00eatant cet \u00e9mulateur pour revenir sur mon shell (fourni par Yocto Cooker) du PC.<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">sh-5.0$ <strong>sudo  \/sbin\/halt<\/strong>\nPassword: <em><strong>(stack)<\/strong><\/em>\n\nBroadcast message from root@qemuarm64 (ttyAMA0) (Wed Feb  2 14:18:36 2022):\nThe system is going down for system halt NOW!\nINIT: Switching to runlevel: 0\n[...]\nSet 'tap0' nonpersistent\n\n[build-stacking-arm]$ <strong>exit<\/strong>\nexit\n\n[stacking-yocto]$ <\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"conclusion\">Conclusion<\/h2>\n\n\n\n<p>Finalement nous nous sommes \u00e9loign\u00e9s de l&rsquo;id\u00e9e initiale qui avait motiv\u00e9 cette s\u00e9rie d&rsquo;exp\u00e9rimentations, et qui concernait plut\u00f4t les fermes de <em>build<\/em> et la compilation distribu\u00e9e.<\/p>\n\n\n\n<p>N\u00e9anmoins, m\u00eame si cette exp\u00e9rience n&rsquo;est pas tr\u00e8s utile en pratique, j&rsquo;en conviens volontiers, elle nous a permis d&rsquo;\u00e9tablir la liste des <em>packages<\/em> n\u00e9cessaires pour mener \u00e0 bien une compilation d&rsquo;une  image avec Yocto Project. En outre j&rsquo;ai pu en profiter pour r\u00e9diger la recette servant \u00e0 embarquer Yocto Cooker.<\/p>\n\n\n\n<p>Notons quand m\u00eame que cette s\u00e9rie de compilations nous permet de valider le fait qu&rsquo;une image produite avec Yocto Project (et avec les layers de <code>meta-openembedded<\/code>) peut \u00eatre auto-suffisante et peut  embarquer tous les outils n\u00e9cessaires pour se reg\u00e9n\u00e9rer int\u00e9gralement.<\/p>","protected":false},"excerpt":{"rendered":"<p>Cet article d&eacute;crit un petit projet exp&eacute;rimental sans grande utilit&eacute;, mais qui a aiguis&eacute; ma curiosit&eacute; pendant quelques temps. Nous allons imbriquer les uns dans les autres des &eacute;mulateurs de syst&egrave;mes compil&eacute;s avec Yocto Project. Outre le challenge un peu surr&eacute;aliste que cela repr&eacute;sente, nous verrons que cette exp&eacute;rience permet de comprendre certaines d&eacute;pendances entre [&hellip;]<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5,8,21],"tags":[],"class_list":["post-5973","post","type-post","status-publish","format-standard","hentry","category-embarque","category-linux-2","category-yocto-project"],"_links":{"self":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts\/5973","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/comments?post=5973"}],"version-history":[{"count":25,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts\/5973\/revisions"}],"predecessor-version":[{"id":6019,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts\/5973\/revisions\/6019"}],"wp:attachment":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/media?parent=5973"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/categories?post=5973"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/tags?post=5973"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}