Yocto Training: Owning Your Own Linux Distribution
Three days that turn "it builds somehow" into a build your team understands and can reproduce. We work on the living object: BitBake, layers, recipes and an image that boots on real hardware at the end – yours, if you like.
- Level
- Intermediate
- Duration
- 3 days
- Formats
- On-site · Remote
Focus areas
- BitBake & metadata
- Custom layers & recipes
- Image & BSP customization
- Builds in CI
Who this training is for
Development teams building a product on embedded Linux who have reached the point where a vendor image no longer suffices. Typically a Yocto setup already exists – inherited from the SoC vendor or assembled by a predecessor – that works fine as long as nobody touches it. That unease is exactly what we clear up.
The training addresses software engineers, build and integration owners, and anyone expected to maintain a product’s BSP going forward.
Contents
Day 1 – Understanding the model. Why Yocto is built the way it is. BitBake as a task engine, the difference between recipe, class and configuration, and how metadata becomes a dependency graph. We build a first image and look at what actually happens along the way – including the directories you end up in when debugging.
Day 2 – Custom layers and recipes. Building a product layer from scratch: structure, layer.conf, priorities. Writing recipes for your own applications: fetching sources, patching, configuring, installing. Extending existing recipes through bbappends without modifying third-party layers. Kernel configuration and device tree as part of the layer rather than local edits in the kernel tree.
Day 3 – Production. Image customization and custom image recipes, the SDK for application teams, package feeds. The shared state cache and what invalidates it – the single biggest lever for tolerable build times. Reproducible builds in CI, handling versions and LTS branches. Finally license manifests, SBOM and cve-check, the tooling that makes the difference for regulated products.
What your team can do afterwards
Bring a new package into a product image cleanly, without touching a third-party layer. Reproduce a build that ran six months ago. Recognize why a rebuild suddenly takes forty minutes, and use shared state deliberately. And judge which changes belong in the product layer and which belong upstream.
Prerequisites
Confidence on the Linux command line. A basic grasp of how a Linux system is structured. A machine with enough CPU and disk for a Yocto build – we agree the exact requirements beforehand. No prior Yocto experience needed.
Format and delivery
The training runs three days, on site at your premises, remotely by video conference, or as a combination. Well over half the time is hands-on – lecture blocks are short and serve to frame the next exercise.
We pitch the content at where your team actually is: a team already maintaining a Yocto BSP gets different emphases than one just starting out. Before the training we hold a short call to establish that starting point and collect the questions your team wants answered.
Frequently asked questions
- What prior knowledge do participants need?
- Confidence on the Linux command line and a basic grasp of how a Linux system is put together. Yocto experience is explicitly not required. Anyone who has never built an embedded Linux system from source is better served by our Embedded Linux training first.
- Can the training be tailored to our own hardware?
- Yes, and that is the norm. Tell us the board and BSP in advance and we prepare the exercises around them, so your team finishes the training having worked on exactly the platform it will maintain afterwards. Alternatively we work on a reference platform we provide.
- How large should the group be?
- Four to eight participants is ideal. Yocto is learned by doing, and beyond roughly ten people there is too little time to look over everyone's shoulder during their own build. For larger teams we prefer to split into two runs.
- Is the training held on site or remotely?
- Both work. On site has the advantage that your real hardware is on the table; remote saves distributed teams the travel and lets everyone work on their usual machine. The content is the same.
Articles on this topic
Going deeper, from our blog – the same topics at length.
Advantages of Yocto in Industrial Environments
Why the Yocto Project pays off for long-lived industrial products – from reproducible builds and license compliance to safe update strategies.
- Yocto
- Embedded Linux
- Industry
Yocto vs. Buildroot: Choosing the Right Embedded Linux Build System
Buildroot or Yocto? A decision-guided comparison of the two dominant embedded Linux build systems: learning curve, scale, updates and compliance.
- Yocto
- Buildroot
- Embedded Linux
The Cyber Resilience Act and Secure OTA Updates for Embedded Linux
How the EU Cyber Resilience Act raises the bar for connected embedded Linux devices — and why secure, signed OTA updates are the backbone of compliance.
- Security
- OTA
- Cyber Resilience Act
Other trainings
Modern C++
From move semantics and smart pointers to the additions in C++20/23: write safe, expressive and performant modern C++ code.
3 daysQt & QML in Practice
A hands-on introduction to the Qt world: building applications with Qt Quick and QML, connecting C++ logic and designing performant user interfaces.
2 daysEmbedded Linux Fundamentals
Understand the anatomy of an Embedded Linux system – from bootloader and kernel to the root filesystem and your own application on real hardware.
2 daysGit & Version Control
Version control that holds up in a team: branching strategies, a clean history, code review workflows and how to handle the situations where Git hurts.
This training for your team?
Tell us how many participants, where they stand and your timeframe – we'll come back with a proposal and dates.
Start a project