EMB-201 · Embedded Linux & BSP
U-Boot Porting & Customisation
The bootloader layer: board bring-up, environment, boot scripts and recovery paths.
Who this course is for
BSP engineers porting Linux to new or custom boards, for whom the bootloader is the first code that runs and the last thing standing between the product and a brick.
Prerequisites
Course outline
Day 1 — U-Boot architecture and the boot flow
- What the boot ROM hands off: SPL, TPL and the stage chain
- U-Boot's driver model and how it differs from the kernel's
- Device tree in U-Boot: same syntax, different consumers
- Console, MMC and network bring-up order on a new board
- Reading an SPL banner and early boot log as a diagnostic tool
Day 2 — Porting to a board
- Board port anatomy: defconfig, board files and device tree
- Environment storage: MMC, flash and nowhere — and the trade-offs
- Boot scripts, bootstd and distro boot compared
- Network boot: TFTP, DHCP and bootp for development loops
- Updating U-Boot safely on a board you cannot afford to brick
Day 3 — Speed and survival
- Measuring boot time from reset to kernel handover
- Falcon mode: SPL booting the kernel directly, and what you give up
- Recovery paths: DFU, fastboot, netconsole and vendor rescue modes
- Failsafe and A/B boot logic from the bootloader side
- An anti-bricking checklist: what to verify before field deployment
Hands-on labs
Labs follow the academy model — 35% principles, 20% guided investigation, 45% engineering studio. Every claim you make in a lab is backed by a trace, a counter or a measurement you captured yourself. How we teach
- Lab: Establish serial control of the lab board's SPL and U-Boot, and map each banner line to a stage of the boot flow
- Lab: Port or enable a peripheral in U-Boot (MMC or network) on the lab board and prove it works from the U-Boot shell
- Lab: Write a boot script with a fallback path, store the environment persistently and test both paths
- Lab: Measure boot-to-handover time, enable falcon mode, and quantify what it saved and what it cost
- Lab: Corrupt the boot flow deliberately (bad environment, bad kernel image) and recover using a documented procedure
This course uses lab hardware. In-person cohorts get boards on the desk; online cohorts get remote board access over SSH and JTAG.
Capstone project
Take the lab board from stock to a defensible boot configuration: a ported or customised U-Boot with persistent environment, a scripted boot with a tested fallback, a measured boot-time budget and a written recovery procedure — demonstrated live, including one induced failure recovered without a debugger.
What you leave with
- A working U-Boot port or customisation on real hardware
- Fluency with the boot flow: SPL, handoff, device tree, driver model
- Boot scripts and environment design with tested fallbacks
- Falcon mode and boot-time measurement experience
- A recovery and anti-bricking procedure you have actually executed
How it runs
Every course follows the same model: 35% principles, 20% guided investigation, 45% engineering studio. You leave with working code, raw measurements and an evidence-based report — not a certificate of attendance. Read the methodology or see a full sample lesson.
Material is adapted to your kernel version, hardware and workload before a private delivery. For public cohorts, the environment is provided and configured.
Questions
Who is this course for?
BSP engineers porting Linux to new or custom boards, for whom the bootloader is the first code that runs and the last thing standing between the product and a brick. It sits at advanced level within the Embedded Linux & BSP track.
What do I need to know already?
Specific prerequisites for this course: Comfort with serial consoles and embedded boot concepts; C and basic ARM architecture knowledge; Yocto or Buildroot experience helpful (lab boards provided). We confirm levels before the cohort starts and adapt if a group is stronger or weaker than expected.
Can this run privately for my team?
Yes. Any course runs on-site at your offices anywhere, or live online for a distributed team, with labs adapted to your hardware and codebase.
What is the difference between in-person and online?
In person is 3 full days with hardware on your desk, capped at 14. Online is 6 half-day sessions across about two weeks so you can keep working, capped at 20, with remote lab access.
Do you invoice companies?
Yes. Purchase orders are accepted and invoicing is available in USD, EUR, GBP, SAR and CAD.
Upcoming dates
| Dates | Where | Seats | Early bird | Regular | |
|---|---|---|---|---|---|
| 18 Oct – 20 Oct 20263 full days | RiyadhIn person · KAFD Conference Centre | 3 of 14 | — | SAR 9,000 | |
| 25 Oct – 27 Oct 20263 full days | Kuwait CityIn person · Al Hamra Tower | 8 of 14 | — | KWD 740 | |
| 25 Oct – 27 Oct 20263 full days | MuscatIn person · Knowledge Oasis Muscat | 3 of 14 | — | OMR 920 | |
| 1 Nov – 8 Nov 20266 half-days | Gulf bandLive online · 09:00–13:00 GMT+3 | 3 of 20 | — | US$1,750 | |
| 2 Nov – 4 Nov 20263 full days | OttawaIn person · Kanata North Tech Park | 8 of 14 | — | CAD 3,260 | |
| 9 Nov – 11 Nov 20263 full days | TorontoIn person · MaRS Discovery District | 3 of 14 | CAD 2,930until 10 Oct | ||
| 9 Nov – 11 Nov 20263 full days | LondonIn person · Shoreditch Works | 8 of 14 | GBP 1,680until 10 Oct | ||
| 9 Nov – 16 Nov 20266 half-days | Europe bandLive online · 09:00–13:00 CET | 8 of 20 | US$1,580until 10 Oct | ||
| 9 Nov – 16 Nov 20266 half-days | Americas bandLive online · 13:00–17:00 ET | 13 of 20 | US$1,580until 10 Oct | ||
| 16 Nov – 18 Nov 20263 full days | BerlinIn person · Factory Görlitzer Park | 3 of 14 | EUR 1,990until 17 Oct |
Dates shown for the next few months. If nothing fits, tell us where and when — cohorts are added on demand, and private delivery can be scheduled any week.
More in Embedded Linux & BSP
EMB-1014 days
Yocto Project Fundamentals
BitBake, layers and recipes, from a first build to an image you would actually ship.
Practitioner-taught
SAR 10,500Next 15 Nov
EMB-1104 days
Custom BSP Layers
Writing a board support layer from scratch: machine configuration, kernel recipe, bootloader and device tree.
Practitioner-taught
SAR 12,000Next 25 Oct
EMB-1203 days
Buildroot in Practice
The lighter alternative to Yocto: when Buildroot is the right call and how to use it well.
Practitioner-taught
SAR 7,880Next 11 Oct
EMB-2103 days
Secure Boot & Chain of Trust
Establishing and maintaining a verified boot chain from ROM to userspace, including key management reality.
Practitioner-taught
SAR 9,000Next 15 Nov
EMB-2202 days
Init Systems & Fast Boot
systemd and the alternatives, plus measuring and cutting boot time to a target.
Practitioner-taught
SAR 5,250Next 1 Nov
EMB-3013 days
Read-Only Rootfs & OTA Updates
Update strategies that survive power loss in the field, and the filesystem layout that makes them possible.
Practitioner-taught
SAR 7,880Next 8 Nov
EMB-3102 days
SBOM & Licence Compliance
Producing a defensible software bill of materials and meeting open source licence obligations — now a regulatory matter, not just good practice.
Practitioner-taught
SAR 5,250Next 25 Oct
EMB-3202 days
Long-Term Maintenance Strategy
Keeping a shipped product secure and buildable for a decade, which is where most embedded programmes fail.
Practitioner-taught
SAR 6,000Next 22 Nov