{"id":50455866,"url":"https://github.com/bootlin/yocto-kiss","last_synced_at":"2026-06-01T02:30:49.356Z","repository":{"id":355798864,"uuid":"1224561962","full_name":"bootlin/yocto-kiss","owner":"bootlin","description":null,"archived":false,"fork":false,"pushed_at":"2026-05-05T09:00:13.000Z","size":159,"stargazers_count":0,"open_issues_count":0,"forks_count":1,"subscribers_count":0,"default_branch":"main","last_synced_at":"2026-05-05T11:03:31.085Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"BitBake","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/bootlin.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2026-04-29T12:03:14.000Z","updated_at":"2026-05-05T09:00:16.000Z","dependencies_parsed_at":null,"dependency_job_id":"1983934d-1f25-4e7c-a0ee-d98ed03faf33","html_url":"https://github.com/bootlin/yocto-kiss","commit_stats":null,"previous_names":["bootlin/yocto-kiss"],"tags_count":null,"template":false,"template_full_name":null,"purl":"pkg:github/bootlin/yocto-kiss","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bootlin%2Fyocto-kiss","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bootlin%2Fyocto-kiss/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bootlin%2Fyocto-kiss/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bootlin%2Fyocto-kiss/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/bootlin","download_url":"https://codeload.github.com/bootlin/yocto-kiss/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bootlin%2Fyocto-kiss/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":33757790,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-06-01T02:00:06.963Z","response_time":115,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2026-06-01T02:30:48.684Z","updated_at":"2026-06-01T02:30:49.351Z","avatar_url":"https://github.com/bootlin.png","language":"BitBake","funding_links":[],"categories":[],"sub_categories":[],"readme":"# simplest-yocto-setup\n\n`simplest-yocto-setup` is an example of the simplest, but realistic and\nworking, Yocto/OpenEmbedded setup.\n\nIt aims at providing an example of how Yocto/OE can be used as the embedded\nLinux build system for end products without unnecessary complications.\n\n# Why?\n\nWhile working for several Bootlin customers on their Yocto/OpenEmbedded\nsetups we have seen many problems caused by unnecessary complications in\ntheir layers.\n\nWe have spent a lot of time in educating to writing clean layers, which\noften involved fixing problems by removing a lot of the code they had\nwritten or they had taken from existing third-party layers. In other words:\nmaking the code simple and \"stupid\", resulting in a more understandable,\nmore efficient, easier to upgrade and less buggy build environment.\n\nThis repository is implementing a similar setup, aiming at being a\nreference for product companies in need to set up a Yocto/OpenEmbedded\nbuild environment or to clean up what they already have.\n\n# What's inside?\n\nThis repository is composed of:\n\n * `.config.yaml`: a kas configuration file\n * `meta-kiss`: the layer with the (fictitious) metadata for the products\n   of a (fictitious) company\n\nThe `.config.yaml` is the configuration file for the\n[kas](https://kas.readthedocs.io/) utility, which allows to easily download\nall the required third-party components in the correct place and enable\nthem in the configuration. In this example it downloads and enables:\n\n * the `bitbake` build engine\n * the `openembedded-core` repository which contains the `meta` layer\n   with all the \"core\" recipes\n * the `meta-arm` repository which contains the `meta-arm` and\n   `meta-arm-toolchain` layers\n * the `meta-kiss` layer, not downloaded as it is already part of this\n   repository, but enabled in `build/conf/bblayers.conf`\n\nUsing kas is not mandatory to use Yocto/OpenEmbedded, but we found it\nsimple and convenient. You can use another tool for your project if so you\nprefer.\n\n# The `meta-kiss` layer\n\n`meta-kiss` is a layer that demonstrates how a realistic layer for a\nproduct company can (and, in our opinion, should) look like.\n\nIt is named after the KISS principle which \"states that most systems work\nbest if they are kept simple rather than made complicated\" (source:\n[Wikipedia](https://en.wikipedia.org/wiki/KISS_principle)).\n\nHere we used \"kiss\" as the hypothetical name of a fictitious company. The\nmachine configurations in meta-kiss implement fictitious products, but\nexcept for their name they are actual development boards and the output\nimages can be used on these boards. In real world use cases a layer\nimplementing company products can reasonably be called\n`meta-\u003ccompany-name\u003e` and the machine names should be named after the\nproduct names.\n\nThe `meta-kiss` layer provides:\n\n * support for two machines\n * a distro configuration\n * a few recipes, including kernel, U-Boot, a userspace application and an\n   image recipe\n\nNote that `meta-kiss` is a single layer. The `bitbake` Yocto/OE build\nengine is powerful enough to handle lots of machines, recipes and even\nmultiple distros in a single layer. Thus using a simple layer in your\ncompany is perfectly fine and encouraged, unless your need are so complex\nthat splitting it into multiple layers proves useful.\n\n## Machines\n\nThe meta-kiss layer contains two machine configurations, called\n**dogbonedark**, **stompduck** and **freiheit93**.\n\nThe **dogbonedark** machine describes a fictitious product which in reality\nimplements the [BeagleBone®\nBlack](https://www.beagleboard.org/boards/beaglebone-black). In order to\nimplement it we took the relevant content from [the BeagleBone machine\nconfiguration](https://git.yoctoproject.org/meta-ti/tree/meta-ti-bsp/conf/machine/beaglebone.conf)\nfound in the meta-ti-bsp layer.\n\nWe could of course have used the meta-ti-bsp layer directly, however since\nthe hardware is very well supported by the mainline kernel and U-Boot we\nonly needed to write (or copy and paste!) only a small amount of code.\n\nSeveral BSP layers provided by hardware vendors bring in extra complexity,\ndeviation from standard coding practices and even bugs and unnecessarily\ncomplex code. In the spirit of this project, we chose to provide an example\nof how you can do without them in many cases.\n\nThe **stompduck** machine describes a fictitious product which in reality\nimplements the\n[STM32MP157A-DK1](https://www.st.com/en/evaluation-tools/stm32mp157a-dk1.html). For\nthe same motivations, the minimum necessary code in this case was taken\nfrom [the STM32MP1 machine\nconfiguration](https://github.com/STMicroelectronics/meta-st-stm32mp/blob/mickledore/conf/machine/stm32mp1.conf)\nfound in the meta-st-stm32mp layer.\n\nIn addition to the steps needed to implement the `dogbonedark`, for the\n`stompduck` machine we additionally chose to boot it using\n[TrustedFirmware-A (TF-A)](https://www.trustedfirmware.org/projects/tf-a/).\nIn order to build TF-A, using [the existing\nrecipe](https://git.yoctoproject.org/meta-arm/tree/meta-arm/recipes-bsp/trusted-firmware-a)\nfrom the meta-arm layer looked like a good choice given the balance between\nthe code quality of the meta-arm layer itself and the complexity required\nfor a recipe to build TF-A. So we added this layer to the kas configuration\nfile together with the meta-arm-toolchain layer it depends on.\n\nThe **freiheit93** machine describes a fictitious product which in reality\nimplements the [FRDM\ni.MX93](https://www.nxp.com/design/design-center/development-boards-and-designs/frdm-i-mx-93-development-board:FRDM-IMX93).\nHere the minimal necessary code was take from [meta-imx-frdm i.MX93 machine\nconfiguration](https://github.com/nxp-imx-support/meta-imx-frdm/blob/lf-6.6.36-2.1.0/meta-imx-bsp/conf/machine/imx93-11x11-lpddr4x-frdm.conf)\nand [meta-freescale i.MX93 machine\ninclude](https://git.yoctoproject.org/meta-freescale/tree/conf/machine/include/imx93-evk.inc).\nAdditionally, firmware recipe was taken from [meta-freescale boot\nfirmwares](https://git.yoctoproject.org/meta-freescale/tree/recipes-bsp/firmware-imx/imx-boot-firmware-files_8.27.bb).\n\nAs for the `stompduck` machine, we are relying on meta-arm to build the TF-A\nfirmware.\n\nHere we also showcase the handling of proprietary licenses that have to be\naccepted before building a component: the NXP firmwares require acceptance of\nthe NXP EULA, by adding `NXP_EULA_v57` and `NXP_EULA_v58` to the\n`LICENSE_FLAGS_ACCEPTED` variable.\n\n# How do I use it?\n\nAccording to the kas configuration file, after cloning this repository the\n`dogbonedark` board is configured by default. Here's how you can have a\nworking image for that board in a few steps:\n\n```bash\n# If you don't have kas yet (needed once only):\npip install kas\n\n# Use kas to download the third-party repositories needed\n# (required the first time, or after changes to .config.yaml)\nkas checkout\n\n# Initialize the build environment\n. openembedded-core/oe-init-build-env\n\n# The default MACHINE is dogbonedark. To build for another board set the\n# `MACHINE` variable in your shell, or in `site.conf` with one of these\n# commands:\necho 'MACHINE ?= \"stompduck\"' \u003e\u003e conf/site.conf\necho 'MACHINE ?= \"freiheit93\"' \u003e\u003e conf/site.conf\n\n# For the freiheit93 you additionally have to accept the NXP licenses,\n# after reading their text in meta-kiss/recipes-bsp/firmware-imx/files:\necho 'LICENSE_FLAGS_ACCEPTED += \"NXP_EULA_v57 NXP_EULA_v58\"' \u003e\u003e conf/site.conf\n\n# Run your first build\nbitbake kiss-image\n\n# Have dinner\n\n# Find the output images here (replace dogbonedark if building for another\n# machine):\nls -l tmp-glibc/deploy/images/dogbonedark/\n\n# Flash the image (replace machine name, and use your uSD card device\n# instead of XYZ!):\nsudo bmaptool copy tmp-glibc/deploy/images/dogbonedark/kiss-image-dogbonedark.rootfs.wic /dev/XYZ\n```\n\n# That's all!\n\nThat's all! Have a look around the code to know about the implementation\ndetails. We wrote some explanatory comments here and there which should\nhelp you understand the reason of several choices we made.\n\nWe also added some explanations in the git commit messages when the changes\nbeing committed were possibly not obvious. Look at the git history to\ndiscover the various steps we took, for example how we created the new\nmeta-kiss layer skeleton initially and the process we took to add and\nmodify a kernel defconfig.\n\nIn the end we hope you like the advantages of this clean setup:\n\n * uses Yocto scarthgap and builds on modern distros without the need of a\n   container -- which you can of course use when it makes sense to\n * no manual cloning of layers: kas does it all for you\n * no manual configuration, except of course for selecting a machine\n * a little amount of code: 333 lines in meta-kiss at the time of this\n   writing, documentation included, not including the kernel defconfigs\n * and, most important, readable code -- at least we hope so!\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fbootlin%2Fyocto-kiss","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fbootlin%2Fyocto-kiss","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fbootlin%2Fyocto-kiss/lists"}