We’re excited to share some significant updates to our yocto-kiss project, our example of the simplest but realistic Yocto/OpenEmbedded setup. These changes improve the project’s organization, make it more scalable, and add support for a new ZynqMP-based platform.
A new name: from simplest-yocto-setup to yocto-kiss
The first change you’ll notice is that we’ve renamed the project from simplest-yocto-setup to yocto-kiss. While the old name was descriptive, it had two significant drawbacks: it was hard to find when searching, and it didn’t include the “kiss” suffix that’s used throughout all the layers within the project (meta-kiss, meta-kiss-ti, meta-kiss-st, etc.).
The new name is much more discoverable and creates a consistent naming between the repository name and the layers it contains. You can find the updated repository at github.com/bootlin/yocto-kiss.
Architectural improvements: separate layers per architecture
The most significant change is a restructuring of how the layers are organized. When we initially created this project, it supported only two machines. In that context, having everything contained in a single meta-kiss layer was the simplest approach – and staying simple is exactly what this project is about.
However, as the project has grown to support four different machines across different architectures, keeping everything in one layer is no longer the simplest solution. With multiple architectures, a single-layer approach means mixing TI-specific, STMicroelectronics-specific, NXP-specific, and soon AMD/Xilinx-specific code all together, making it harder to navigate and maintain. What was once simple becomes unnecessarily complex.
So we made the decision to separate the layers: one architecture-agnostic layer for the distro configuration, and one BSP layer per architecture for machine-specific code. This new structure looks like:
- meta-kiss: the base distro layer providing the distro configuration, common recipes (kernel, U-Boot, userspace applications), and the image recipe
- meta-kiss-ti: the BSP layer for TI-based boards (currently the dogbonedark/BeagleBone Black)
- meta-kiss-st: the BSP layer for STMicroelectronics boards (the stompduck/STM32MP157A-DK1)
- meta-kiss-nxp: the BSP layer for NXP boards (the freiheit93/FRDM i.MX93)
This demonstrates an important principle: “simple” doesn’t mean “always use the fewest layers possible.” Simple means choosing the organization that makes the code easiest to understand and maintain for your current scale. If some of the architectures in use require a significant amount of architecture-specific metadata, it probably makes sense to split them to BSP layers.
Each BSP layer now contains:
- A machine configuration file
- Machine-specific recipe customizations (kernel defconfig, U-Boot configuration, etc.)
- WIC configuration for image creation
This makes it much easier to maintain each product independently. When working on a specific board, developers only need to focus on the relevant machine-specific layer, while common functionality remains in the architecture-agnostic base meta-kiss layer. One key advantage of this separation is clarity: if you go to meta-kiss-st/ and run tree, you immediately see everything needed for the ST board – nothing less, nothing more. The organization itself documents what each piece of code is for.
Following this layer separation, we’ve reorganized the kas configuration files to match. The build process now uses a modular kas setup with one configuration file for the distro (kas/kiss.yaml) and one configuration file for each machine (kas/dogbonedark.yaml, kas/stompduck.yaml, kas/freiheit93.yaml). To build an image, you combine the base distro configuration with the machine-specific configuration:
kas build kas/kiss.yaml:kas/dogbonedark.yaml
This mirrors the layer organization: the base kas configuration sets up the distro layer and common dependencies, while the machine-specific kas configuration adds the architecture-specific layer and any additional dependencies needed for that platform. This makes it easy to understand what’s common to all builds versus what’s specific to each machine.
New platform support: krazymp (AMD Kria KD240)
Following our new layered architecture, we’ve added support for a fourth platform: the krazymp machine, which is based on the Xilinx ZynqMP architecture. The krazymp machine is a fictitious product designed for the AMD Kria KD240 Drives Starter Kit, a System-on-Module (SOM) platform featuring the Zynq UltraScale+ MPSoC. This addition demonstrates how the new layer structure scales to support additional architectures.
The krazymp support lives in a new meta-kiss-amd layer (AMD now owns Xilinx), and includes:
- Machine configuration for the ZynqMP platform
- Support for building the ZynqMP FSBL (First Stage Boot Loader) and PMU firmware (running on the Microblaze core)
- FPGA bitstream handling
- Integration with TrustedFirmware-A (TF-A)
- U-Boot configuration and patches specific to the platform
- Custom bootbin generation using Xilinx’s bootgen tool
The ZynqMP platform is more complex than our other supported boards, as it requires multiple firmware components and specialized tooling from Xilinx/AMD. However, by following the same principles of simplicity and clarity, we’ve kept the implementation as straightforward as possible. The entire machine-specific configuration is contained within meta-kiss-amd, demonstrating how even complex hardware platforms can be supported with clean, well-organized layers.
We’d like to thank Neal Frager from AMD for his valuable help with the building process of the PMUFW and FSBL, which were essential components for getting the ZynqMP platform working.
As with our other machines, you can build for krazymp using kas:
kas build kas/kiss.yaml:kas/krazymp.yaml
Why these changes matter
These updates reinforce the core principles behind yocto-kiss:
- Simplicity: Each layer has a clear purpose, and platform-specific metadata is clearly separated from common code making each easy to find
- Scalability: The structure naturally accommodates new platforms without growing unwieldy
- Maintainability: Changes to one platform don’t risk breaking others
This is exactly the kind of clean architecture we help our customers implement during our Yocto/OpenEmbedded consulting engagements. Over the years, we’ve seen how unnecessary complexity in layer organization leads to difficult-to-maintain build systems. By providing this reference implementation, we hope to help product companies start with a solid foundation or refactor their existing setups to be more manageable.
Try it yourself
The updated yocto-kiss project is available at github.com/bootlin/yocto-kiss. We encourage you to explore the code, try building for different machines, and use it as a reference for your own Yocto/OpenEmbedded projects. The git history shows our development process step-by-step, and we’ve added comments throughout the code to explain our choices.
If you have questions about yocto-kiss or need help with your Yocto/OpenEmbedded setup, don’t hesitate to reach out to us. We provide training and consulting services to help companies build clean, maintainable embedded Linux systems.
