Is the training suitable for beginners?

Yes, that is its purpose. It assumes programming experience in C or C++ and basic Linux command line skills. Embedded experience is welcome but not required – we build the system model from the ground up.

How does this differ from the Yocto training?

This training explains how an embedded Linux system works; the Yocto training explains how to build your own distribution for it. Teams needing both take them back to back – five days is a sensible frame and the transition is seamless.

Do we work on real hardware?

Yes. We work on development boards so that the boot process, serial console and flashing are not simulated. If you would rather use your own target platform, we arrange that in advance.

Do we get materials to refer back to?

Yes, your team keeps the exercise guides and examples. The exercises are written to work as a later reference – that is what most participants actually reach for afterwards.

Embedded Linux Training: From Bootloader to Your Own Application

Two days after which an embedded Linux system stops being a black box. We walk the whole chain from power-on to a running application – on real hardware, not on slides.

Level: Beginner
Duration: 2 days
Formats: On-site · Remote

Start a project All trainings

Focus areas

Boot process & U-Boot
Kernel & device trees
Root filesystems
Cross compilation

Who this training is for

Engineers who have worked on the desktop or on microcontrollers and are now expected to look after a product running embedded Linux. Equally for teams who inherited a finished system from a vendor and can operate it without really seeing through it.

The typical trigger: something goes wrong during boot, the log holds messages nobody can place, and the mental model needed to search systematically instead of guessing is missing.

Day 1 – The chain from power-on to a shell. What the SoC does at startup, the role of boot ROM and SPL, and where U-Boot takes over. We work inside the U-Boot command line, load kernel and device tree by hand, and come to understand what the bootloader actually hands the kernel. Then the kernel itself: configuration, modules versus built-in, and the device tree as the description of the hardware – why a driver stays silent when something there is wrong.

Day 2 – From root filesystem to your own application. Anatomy of a root filesystem, init systems and startup ordering, read-only root and why it is often the more robust choice for devices. Cross compilation: toolchain, sysroot, and the usual stumbling blocks when linking. We bring a custom application onto the board and get it running – including troubleshooting via serial console, dmesg and strace.

What your team can do afterwards

Read a boot sequence and name the phase where it stalls. Add a device tree node and verify that the driver actually binds to it. Cross-compile an application and get it running on the target. And above all: when a problem appears, decide whether it lives in the bootloader, the kernel, the filesystem or the application – the skill that separates an hour of debugging from three days.

Prerequisites

Programming experience in C or C++. Basic Linux command line skills. No prior embedded experience required.

Format and delivery

Two days, on site at your premises or remote. We work on development boards so that serial console, flashing and the boot process are tangible – for bootloader work in particular, nothing substitutes for that.

This training is frequently booked as the entry point with the Yocto training immediately after: first understand how the system works, then learn to build it yourself.

Frequently asked questions

Is the training suitable for beginners?: Yes, that is its purpose. It assumes programming experience in C or C++ and basic Linux command line skills. Embedded experience is welcome but not required – we build the system model from the ground up.
How does this differ from the Yocto training?: This training explains how an embedded Linux system works; the Yocto training explains how to build your own distribution for it. Teams needing both take them back to back – five days is a sensible frame and the transition is seamless.
Do we work on real hardware?: Yes. We work on development boards so that the boot process, serial console and flashing are not simulated. If you would rather use your own target platform, we arrange that in advance.
Do we get materials to refer back to?: Yes, your team keeps the exercise guides and examples. The exercises are written to work as a later reference – that is what most participants actually reach for afterwards.

Articles on this topic

Going deeper, from our blog – the same topics at length.

July 30, 2026 · 7 min read

Device Tree in Practice: Describing Hardware Instead of Guessing at Drivers

How the device tree really works in embedded Linux projects: compatible matching, pinctrl and clocks, overlays for hardware variants, and the debugging recipes that narrow down bring-up problems.

Embedded Linux
Device Tree
Kernel

August 3, 2026 · 6 min read

Optimizing Embedded Linux Boot Time: Measure Before You Tune

From power-on to first frame: how to measure an embedded Linux device's boot time credibly and find the levers in bootloader, kernel and user space that actually save seconds.

Embedded Linux
Boot Time
Performance

August 1, 2026 · 7 min read

Real-Time Linux: What PREEMPT_RT Delivers – and What It Does Not

Determinism, not speed: how PREEMPT_RT makes Linux real-time capable, how to measure latency credibly with cyclictest, and which system and application mistakes undo every bit of tuning.

Real-Time
PREEMPT_RT
Embedded Linux

Other trainings

3 days

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