DRV-120 · Device Drivers
Platform Drivers & Device Tree
Describing non-discoverable hardware and writing the drivers that consume that description.
Who this course is for
Embedded engineers bringing up drivers for non-discoverable hardware on ARM or RISC-V SoCs, where the device tree — not the bus — tells the kernel what exists.
Prerequisites
Course outline
Day 1 — Device tree as data
- DTS syntax: nodes, properties, phandles and labels
- Compiling with dtc and decompiling a running system's DTB
- How the FDT becomes device_nodes and then platform_devices
- Addressing: reg, #address-cells, #size-cells and ranges
- compatible, status and the matching chain to a driver
Day 2 — Bindings that survive review
- What a binding must document and what it must not
- DT schema in YAML: properties, required, patternProperties
- Validating with dt_binding_check and dtbs_check
- Writing a binding document acceptable upstream
- Common review failures: generic names, vendor prefixes, unit-address mistakes
Day 3 — The driver side of the tree
- of_* property parsing: scalars, strings, phandles, arrays
- platform_get_resource and devm_ioremap_resource for MMIO
- IRQ mapping from the interrupts property
- Clocks, resets, regulators and GPIOs as DT-described resources
- Deferred probe when a dependency is not ready yet
Day 4 — Debugging and overlays
- Why a node never probes: compatible mismatch, disabled status, silent deferral
- Reading /sys/kernel/debug/devices_deferred and initcall_debug output
- Pinmux and pinctrl from the driver's seat
- Writing and applying a DT overlay at runtime
- Verifying a change: decompile, diff, reboot, re-check
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: Decompile the lab board's live DTB and trace one peripheral from its node to the registered platform_device
- Lab: Write a YAML binding for a simple device, pass dt_binding_check, then break it and read the validation errors
- Lab: Implement a platform driver that parses custom properties and takes a clock, a reset and a GPIO from the tree
- Lab: Diagnose an injected never-probes fault using devices_deferred and boot logs — fix the DT, not the driver
- Lab: Apply and remove a DT overlay on a running board and verify the new device appears and probes
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
From a supplied schematic excerpt for a lab-board peripheral, deliver the complete chain: a YAML binding that passes dtbs_check, the DTS node, and a platform driver that probes, acquires clock/reset/regulator/IRQ resources and survives injected failures — with a probe-chronology log and validation output as the evidence pack.
What you leave with
- A working binding-plus-driver chain you built from a schematic
- YAML binding skills that will pass upstream review
- Fluent of_* resource acquisition: clocks, resets, regulators, GPIOs, IRQs
- A repeatable method for never-probes debugging
- Overlay workflows for iterating without full rebuilds
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?
Embedded engineers bringing up drivers for non-discoverable hardware on ARM or RISC-V SoCs, where the device tree — not the bus — tells the kernel what exists. It sits at practitioner level within the Device Drivers track.
What do I need to know already?
Specific prerequisites for this course: DRV-110 or solid device-model knowledge; C and basic kernel build experience; Enough electronics to follow a schematic excerpt (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 4 full days with hardware on your desk, capped at 14. Online is 8 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 | |
|---|---|---|---|---|---|
| 11 Oct – 14 Oct 20264 full days | RiyadhIn person · KAFD Conference Centre | 7 of 14 | — | SAR 10,500 | |
| 18 Oct – 21 Oct 20264 full days | Kuwait CityIn person · Al Hamra Tower | 12 of 14 | — | KWD 870 | |
| 18 Oct – 21 Oct 20264 full days | MuscatIn person · Knowledge Oasis Muscat | 7 of 14 | — | OMR 1,080 | |
| 25 Oct – 3 Nov 20268 half-days | Gulf bandLive online · 09:00–13:00 GMT+3 | 13 of 20 | — | US$2,000 | |
| 26 Oct – 29 Oct 20264 full days | OttawaIn person · Kanata North Tech Park | 12 of 14 | — | CAD 3,810 | |
| 26 Oct – 4 Nov 20268 half-days | Europe bandLive online · 09:00–13:00 CET | 18 of 20 | — | US$2,000 | |
| 2 Nov – 5 Nov 20264 full days | TorontoIn person · MaRS Discovery District | 7 of 14 | — | CAD 3,810 | |
| 2 Nov – 5 Nov 20264 full days | LondonIn person · Shoreditch Works | 12 of 14 | — | GBP 2,180 | |
| 2 Nov – 11 Nov 20268 half-days | Americas bandLive online · 13:00–17:00 ET | 7 of 20 | — | US$2,000 | |
| 9 Nov – 12 Nov 20264 full days | BerlinIn person · Factory Görlitzer Park | 7 of 14 | EUR 2,320until 10 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 Device Drivers
DRV-1013 days
Character Devices & sysfs
Your first working driver: character device registration, file operations, and exposing state through sysfs.
Practitioner-taught
SAR 6,750Next 15 Nov
DRV-1103 days
The Unified Device Model
Buses, devices, drivers and classes — the abstraction that makes probe and bind work across every subsystem.
Practitioner-taught
SAR 7,880Next 25 Oct
DRV-2013 days
I2C & SPI Drivers
Client drivers for the two buses embedded hardware is built from, including regmap and error recovery.
Practitioner-taught
SAR 7,880Next 18 Oct
DRV-2104 days
USB Device Drivers
The USB stack from descriptors to URBs, on both the host and gadget sides.
Practitioner-taught
SAR 10,500Next 15 Nov
DRV-2204 days
PCI & PCIe Drivers
Enumeration, BARs, MSI-X and DMA for PCIe devices, which is where most accelerator drivers live.
Practitioner-taught
SAR 12,000Next 1 Nov
DRV-3013 days
DMA Engines & Mappings
Moving data without the CPU: the DMA API, coherency, IOMMU interaction and the bugs that only appear under load.
Practitioner-taught
SAR 9,000Next 8 Nov
DRV-3103 days
Interrupts & Threaded IRQs
Interrupt handling from the hardware edge to the bottom half, and how to keep hard IRQ context short.
Practitioner-taught
SAR 7,880Next 18 Oct