EngineerExperiences
On this page

Part 16 of 16 YoctoCI/CDSSTATE

Building a Production Embedded Linux Image

Reproducible builds, SSTATE caches, CI, common beginner mistakes, a practical workflow and taking a board to a product.

Why this is useful for embedded products

Imagine we manufacture 1,000 embedded devices.

We do not want to configure each device manually.

Instead:

One reproducible image is flashed to every device in the fleet Source Code Yocto Build Reproducible Image Device 1 Device 2 Device 3 Device 1000
One build produces an image that is then flashed to every device, however many that turns out to be.

If the configuration is maintained properly, the same build process can produce the same software image for every device.

This is one of the strongest reasons to use Yocto in professional embedded Linux development.

SSTATE cache

The shared-state cache is one of the reasons subsequent builds can be much faster.

Instead of compiling everything from scratch, Yocto can reuse previously generated results.

Conceptually:

First build compiles everything, second build reuses the SSTATE cache First build Second build Source Compile Output Source Check SSTATE Reuse output SSTATE cache
SSTATE is what turns a long first build into a short loop: the second build recompiles only what actually changed.
```

This is particularly important in CI/CD environments where build time matters.

Reproducibility

One of the most important goals of a good Yocto project is reproducibility.

We should be able to take:

Source
+
Configuration
+
Layers
+
Recipes

and produce the same software system.

This is particularly important when an embedded product remains in production for many years.

A build system should not depend on:

“This works on my development computer.”

Instead:

Repository, automated build and release image flow Git Repository Yocto configuration Custom layers Recipes Patches Automated Build Release Image
Nothing is built by hand: the same command produces the shipped image on every run.

Yocto in a professional embedded project

A real product may look something like this:

Application source and Yocto layers meeting in the CI pipeline Git Application Yocto Layers CI Pipeline BitBake U-Boot Kernel RootFS Product Image Target Device
The application is only ever built against the layers it declares, so the image stays reproducible.

This gives the team a controlled way of producing embedded Linux releases.

A practical workflow

My preferred way of approaching an embedded Yocto project is:

1. Identify hardware
       ↓
2. Identify BSP
       ↓
3. Select MACHINE
       ↓
4. Configure layers
       ↓
5. Build minimal image
       ↓
6. Boot target
       ↓
7. Verify hardware
       ↓
8. Add networking
       ↓
9. Add required packages
       ↓
10. Create custom layer
       ↓
11. Add application
       ↓
12. Add services
       ↓
13. Customize kernel/device tree
       ↓
14. Create reproducible build

This approach keeps the problem manageable.

From development board to product

The real power of Yocto becomes apparent when moving from a development board to a real product.

During development:

The inner development loop from source change to a running board Developer Yocto Build Development Board
Everything above this loop only automates it; the loop itself never changes.

For production:

One release build produces every kind of image Git CI/CD Reproducible Yocto Build Release Artifact Factory OTA Update Recovery Image Development
The same source tree yields the factory, recovery and development images.

The same build infrastructure can become part of the product lifecycle.

Final thoughts

Yocto initially looks complicated because there are many new concepts:

  • BitBake
  • Recipes
  • Layers
  • Classes
  • BSPs
  • Machine configurations
  • Device trees
  • Tasks
  • Packages
  • SSTATE
  • Root filesystems

But these concepts become much easier once the overall architecture is understood.

The basic idea is actually simple:

From a written requirement to a booted board Describe what your embedded Linux system needs Yocto Build everything required Generate Linux image Boot hardware
Everything downstream depends on this description, so vagueness here costs days later.

For platforms such as the i.MX7 and Raspberry Pi 3, Yocto provides a structured way to move from a development board to a customized embedded Linux system.

The most valuable part is not simply knowing how to execute:

bitbake <image>

The real skill is understanding what BitBake is building, where the configuration comes from, how the layers interact, and how to modify the system without destroying maintainability.

Once those concepts are clear, Yocto becomes a powerful tool for building professional embedded Linux systems.