Mehmet Akif Erdem

What Is a Device Tree?

2026-08-07T00:00:00+00:00

If you have ever tried to bring Linux up on an embedded board, sooner or later you meet a file ending in .dts</code>. Usually at the worst possible moment: the board won't boot, nothing comes out on the screen, and someone tells you to "check your device tree". This is about what that file is, why it exists, and what you are actually looking for inside it.</p>

The Problem It Solves</h2>
On a desktop, the kernel can largely find the hardware by itself. PCI and USB are formally specified, enumerable buses (1). Devices announce themselves with a vendor and product ID; a driver lists the IDs it supports in a table, and the kernel calls that driver's probe()</code> for every device matching an entry (2). USB works the same way through its own ID table (3). Nobody has to tell anybody anything in advance.</p>
Embedded boards do not get that luxury. The kernel's own documentation draws the line plainly: peripherals integrated into a system-on-chip hang off buses with minimal infrastructure, "as opposed to large formally specified ones like PCI or USB", and what those devices have in common is direct addressing from a CPU bus (1). An I²C sensor or a display controller hanging off SPI does not announce itself; it just sits there, at that address, wired to that interrupt line. The only way the kernel knows about it is if somebody says so.</p>
For a long time that somebody was the code itself. Every board had a file inside the kernel tree describing in C which device was wired where — the kernel still describes this path, where board-specific setup code registers the devices one by one (1). On ARM these files multiplied so badly that in 2011 Linus Torvalds took the situation apart in an email, saying the ARM code was heading somewhere unsustainable. The way out that got adopted was the device tree.</p>
The Idea</h2>
A device tree is a data file describing how the hardware is wired. It is not code — it does not run, and it is not compiled into the kernel. It is a description: there is a controller at this address, it uses this interrupt line, it is fed by this clock, and these devices hang beneath it.</p>
The format itself rests on a formal specification (4). It is called a tree because it genuinely is one. It starts at a root node, buses branch off it, and the devices attached to those buses branch off them — mirroring how the hardware is physically connected:</p>
Rather than an invented example, here is a real one. The node below comes from k3-am62p-main.dtsi</code> in the U-Boot tree for TI's J722S/AM67A family — the actual description an AM67A board reads when it boots:</p>
main_i2c0: i2c@20000000 {</span></span>
    compatible = "ti,am64-i2c", "ti,omap4-i2c";</span></span>
    reg = <0x00 0x20000000 0x00 0x100>;</span></span>
    interrupts = <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>;</span></span>
    #address-cells = <1>;</span></span>
    #size-cells = <0>;</span></span>
    power-domains = <&k3_pds 102 TI_SCI_PD_EXCLUSIVE>;</span></span>
    clocks = <&k3_clks 102 2>;</span></span>
    clock-names = "fck";</span></span>
    status = "disabled";</span></span>
};</span></span></code></pre>
Every line here means something. reg</code> gives the controller's address in the memory map — 0x20000000</code>, length 0x100</code>. The addresses are written as pairs of numbers because the address space is 64-bit; the first number carries the upper 32 bits. interrupts</code> says which interrupt line is used; names like GIC_SPI</code> and IRQ_TYPE_LEVEL_HIGH</code> come from included header files, so although device tree source is plain data, it still goes through the C preprocessor.</p>
It is worth noticing that compatible</code> carries two values: "ti,am64-i2c"</code> and "ti,omap4-i2c"</code>. The list is read most-specific first. The kernel looks for a driver specific to am64, and failing that falls back to the older, more general omap4 driver (5). That way a new chip can work without anyone writing a new driver for it.</p>
clocks</code> and clock-names</code> say where the device gets its clock: output 2 of device 102 on &k3_clks</code>, which the driver will find under the name "fck"</code>. power-domains</code> wires up the power domain the same way. These are not frequency settings</em> — they describe the wiring, which clock goes where.</p>
The last line matters: status = "disabled"</code>. The chip vendor describes the peripheral but leaves it off, because it cannot know whether that I²C bus is used on your board. Turning it on is the job of the board's own .dts</code>. In the J722S EVM's board file it looks like this:</p>
&main_i2c0 {</span></span>
    status = "okay";</span></span>
    pinctrl-names = "default";</span></span>
    pinctrl-0 = <&main_i2c0_pins_default>;</span></span>
    clock-frequency = <400000>;</span></span>
</span>
    exp1: gpio@23 {</span></span>
        compatible = "ti,tca6424";</span></span>
        reg = <0x23>;</span></span>
        gpio-controller;</span></span>
        #gpio-cells = <2>;</span></span>
    };</span></span>
};</span></span></code></pre>
The leading &main_i2c0</code> is a reference to the node above — it does not create a new node, it writes over the existing one. status</code> is switched on, pins are assigned, the speed is set to 400 kHz, and a real device is added underneath: a TCA6424 GPIO expander sitting at address 0x23</code> on the I²C bus. Because the controller declared #address-cells = <1></code>, that address is written as a single number, unlike the controller's own reg</code>.</p>
This is how a device tree works in practice: the vendor describes the SoC once, and you say what is wired to your board.</p>
The property that really matters is compatible</code>. This is where the kernel looks to pair a driver with a piece of hardware. A driver says "I am compatible with ti,tca6424</code>", a node in the device tree carries the same string, and the kernel puts the two together. Which is why typos fail silently: if the string doesn't match, there is no error — the device simply never appears.</p>
Worth keeping in mind: a device tree describes hardware, not driver configuration. The kernel's guide to writing bindings stresses this boundary in particular (6). The line blurs constantly in practice, and it is the single most argued-about subject on the kernel lists — "is this genuinely a property of the hardware, or is it your preference?"</p>
The Files</h2>
You will see three extensions, and they are easy to confuse (11).</p>
.dts</code> is the source you write, the human-readable form. .dtsi</code> is a fragment other files can include — the "i" is for include. A chip vendor typically describes the whole SoC in a .dtsi</code>; you write a short .dts</code> for your own board, include it, and add only what is specific to your board.</p>
.dtb</code> is the compiled form — the device tree blob. This is what the kernel actually reads. The compiler is dtc</code> (7):</p>
dtc</span> -I dts -O dtb -o my-board.dtb my-board.dts</span></span></code></pre>
It also runs the other way, which is invaluable when hunting a problem. If you have a working .dtb</code>, you can open it up and look inside:</p>
dtc</span> -I dtb -O dts -o decoded.dts my-board.dtb</span></span></code></pre>
On a running system you can also read the device tree straight from the filesystem. The kernel exposes the tree it is actually using here:</p>
ls</span> /proc/device-tree/</span></span></code></pre>
This is the fastest answer to "is the file I edited the file that got loaded?" A surprising share of the time, the answer is no.</p>
What Happens at Boot</h2>
The order goes like this: the bootloader — usually U-Boot (8) — loads the .dtb</code> into memory, loads the kernel, and then hands the kernel the blob's memory address in a register as it starts it. On ARM that register and the conditions the bootloader must meet are set out in the kernel's booting document (9). Before the kernel brings up any of its drivers, it reads that tree, extracts the devices from it, and matches drivers against the compatible</code> strings.</p>
The practical consequence is that the kernel and the device tree can be updated separately. Adding a new sensor rarely means rebuilding the kernel; updating the .dtb</code> is usually enough. But that cuts both ways — because they are independent, they can drift apart. Boot a new kernel with an old .dtb</code> and the board quietly comes up incomplete, and it takes a while to work out why.</p>
There is also the idea of overlays: fragments applied on top of an existing tree at runtime (10). This is what happens when you plug a HAT into a Raspberry Pi — the main tree stays as it is and a small fragment gets laid over it. Useful when the base board is always the same and only the module plugged into it changes.</p>
When Something Doesn't Work</h2>
Device tree faults have a particular kind of unpleasantness, because they usually don't produce an error. The device is simply absent. Working through it in this order saves time.</p>
Start by checking whether the device was created at all. Is the node there under /proc/device-tree</code>? If not, the problem is not in the file you edited — most likely the wrong .dtb</code> is being loaded, or the node is switched off a level up with status = "disabled"</code>. That second one happens constantly: peripherals usually arrive disabled in the vendor's .dtsi</code> files, and you are expected to turn them on one by one with status = "okay"</code> in your board's .dts</code>.</p>
If the node is there but no driver attached, put your eye on the compatible</code> string. Find the of_device_id</code> table in the driver's source and compare the strings character by character. One comma, one hyphen is enough.</p>
There is also this: dtc warnings arrive switched off in most projects, and they genuinely tell you useful things. Address and reg</code> mismatches, a missing #address-cells</code> — exactly the sort of fault that turns into a silent failure at boot. It is worth keeping warnings on when you build.</p>
Closing Thought</h2>
What makes a device tree hard to grasp is that nobody says up front what it actually is. It looks like a configuration file, but it isn't; it looks like a driver, but it isn't that either. The most useful framing is to think of it as the contract between hardware and software: how the board is wired, written down in a language the kernel understands.</p>
Once it sits in that frame, the rest follows. Why compatible</code> is so critical, why the .dtb</code> lives separately from the kernel, why /proc/device-tree</code> is the first place to look when something is missing — all of it falls out of the same idea.</p>

Related Reading</h2>

The Embedded Linux Boot Chain</a> — how the bootloader hands control to the kernel</li>
What Is DFU?</a> — flashing firmware over USB when there is no other way in</li>
</ul>
References</h2>

Platform Devices and Drivers</a> — why SoC peripherals are not enumerable the way PCI and USB are, and how board-specific code registers them.</li>
How To Write Linux PCI Drivers</a> — the pci_device_id</code> table and the probe()</code> call for matching devices.</li>
USB Device Drivers</a> — ID-based driver matching on the USB side.</li>
Devicetree Specification</a> — the formal definition of the format.</li>
Linux and the Devicetree</a> — how the kernel reads the tree and matches drivers.</li>
Writing Devicetree Bindings</a> — the boundary between describing hardware and configuring a driver.</li>
dtc — Device Tree Compiler</a> — the compiler's own repository and usage.</li>
U-Boot: Devicetree Control</a> — how U-Boot handles the device tree.</li>
Booting ARM Linux</a> — which register the bootloader uses to hand the blob to the kernel.</li>
Devicetree Overlay Notes</a> — how overlays are applied at runtime.</li>
Device Tree Reference (eLinux)</a> — community reference with worked examples.</li>
</ol>



Git: Deleting Branches, Merging, and Undoing a Bad Push
2026-08-02T00:00:00+00:00
These three things come up all the time, and somehow the commands never quite stick between one time and the next. So here they are, written down properly.</p>
Deleting a Branch</h2>
git</span> branch -d feature-x</span></span></code></pre>
This is the safe version — Git checks first, and refuses if feature-x</code> has commits that never made it into your current branch. If you're sure, you can override it: (1)</p>
git</span> branch -D feature-x</span></span></code></pre>
That only deletes it locally, though. If the branch also exists on the remote (GitHub, say), you need to delete it there separately:</p>
git</span> push origin --delete feature-x</span></span></code></pre>
One thing worth knowing: deleting a branch doesn't actually delete its commits. They just become unreferenced and sit in the repository until Git's garbage collector eventually sweeps them up, which can take a while. So git branch -D</code> is more forgiving than it looks — if you delete the wrong branch, there's usually still a way back (more on that in the reflog section below). I wouldn't rely on that as a plan, but it's good to know it's there.</p>
Merging Branches</h2>
The usual shape is: check out the branch you want to merge into</em>, then merge the other one in.</p>
git</span> checkout main</span></span>
git</span> merge feature-x</span></span></code></pre>
What happens next depends on whether main</code> has moved since you branched off. If it hasn't, Git just slides the main</code> pointer forward to match feature-x</code> — a fast-forward</strong>, no merge commit involved. If main</code> has moved on in the meantime, Git creates an actual merge commit that ties both histories together (2).</p>
Sometimes you want that merge commit even when a fast-forward would've been possible — it leaves a visible marker in history that a feature branch existed and was merged, rather than the change quietly blending in. For that:</p>
git</span> merge --no-ff feature-x</span></span></code></pre>
If the same lines were touched on both sides, Git stops and leaves the conflict for you to sort out:</p>
git</span> status</span></span></code></pre>
That'll list which files are conflicted. Open each one, you'll see <<<<<<<</code>, =======</code>, and >>>>>>></code> markers around the competing changes — pick what should actually stay, delete the markers, then:</p>
git</span> add resolved-file.txt</span></span>
git</span> commit</span></span></code></pre>
And if it turns into more of a mess than it's worth, you can just walk away from the whole thing:</p>
git</span> merge --abort</span></span></code></pre>
That puts everything back exactly how it was before you started merging.</p>
Undoing a Bad Push</h2>
This is the one people panic about, and honestly the panic is usually unwarranted — but which fix you reach for actually matters here.</p>
If there's any chance someone else has already pulled the branch, don't touch history. Add a new commit that undoes the old one instead:</p>
git</span> revert</span> <</span>bad-commit-sh</span>a</span>></span></span>
git</span> push</span></span></code></pre>
This is the boring, always-safe option. It doesn't rewrite anything — it just adds a commit on top that cancels out the mistake, so everyone's history stays in sync without anyone having to do anything special on their end (3).</p>
If the branch is genuinely just yours and nobody's pulled it yet, you can rewind and rewrite: (4)</p>
git</span> reset --hard</span> <</span>last-good-commit-sh</span>a</span>></span></span>
git</span> push --force-with-lease</span></span></code></pre>
Use --force-with-lease</code>, not plain --force</code>, out of habit if nothing else. The difference matters more than it seems: --force-with-lease</code> checks that nobody has pushed to the branch since you last fetched, and refuses if they have. Plain --force</code> doesn't check anything — it'll happily overwrite someone else's work without so much as a warning (5).</p>
And if you're staring at your terminal trying to remember what the last good commit even was — git log</code> won't help here, since it only shows commits reachable from where you currently are, which doesn't include whatever you already reset away from. What you want is:</p>
git</span> reflog</span></span></code></pre>
It shows every place your branch has recently pointed to, including the ones that fell out of normal history. Scroll back to before things went wrong, then: (6)</p>
git</span> reset --hard HEAD@{</span>2</span>}</span></span></code></pre>
(swap in whatever position or SHA actually matches your case). The reflog is local to your machine and generally hangs onto entries for about 90 days, so it's less "emergency undo for bad pushes" and more a general safety net for "I think I just broke something" — worth remembering it exists even outside this specific situation.</p>
Closing Thought</h2>
All three of these lean on the same underlying fact: Git almost never throws anything away immediately. Deleted branches, reset commits, old positions on a branch — they all linger around longer than they seem to. That's really what makes -D</code>, reset --hard</code>, and force-pushing safe enough to use day to day, as long as you know where to go looking if one of them turns out to be a mistake.</p>

Related Reading</h2>

Understanding Make</a> — what actually triggers a rebuild</li>
</ul>
Further Reading</h2>

git-branch</a> — branch creation, listing, and deletion.</li>
git-merge</a> — merge strategies and conflict resolution.</li>
git-revert</a> — undoing commits by creating new ones.</li>
git-reset</a> — moving a branch pointer, with the difference between --soft</code>, --mixed</code>, and --hard</code>.</li>
git-push: --force-with-lease</a> — why it's safer than --force</code>.</li>
git-reflog</a> — recovering commits that no longer appear in normal history.</li>
</ol>


Understanding Make
2026-08-01T00:00:00+00:00
make</code> shows up in almost every embedded and systems project I've touched — Yocto recipes, kernel builds, U-Boot, small firmware repos. It's also one of those tools people use for years by imitation, copying a Makefile from the last project without ever quite pinning down the model underneath it. Here's that model, laid out directly.</p>
What is Make?</h2>
Make is a build automation tool: it reads a file (a Makefile</code>) describing a set of targets</strong>, the prerequisites</strong> each target depends on, and the recipe</strong> (shell commands) needed to produce that target from its prerequisites. Given that description, make</code> figures out which targets are out of date and runs only the recipes needed to bring them up to date — nothing more.</p>
main</span>:</span> main.o utils.o</span></span>
	gcc -o main main.o utils.o</span></span>
</span>
main.o</span>:</span> main.c</span></span>
	gcc -c main.c</span></span></code></pre>
Run make</code>, and it builds main.o</code> only if main.c</code> is newer than main.o</code> (or main.o</code> doesn't exist yet), then links main</code> only if main.o</code> or utils.o</code> changed. Nothing is rebuilt unnecessarily.</p>
Who is it for?</h2>
Make was written by Stuart Feldman at Bell Labs in April 1976. By his own account, the trigger was a colleague — Steve Johnson, author of yacc</code> — losing a morning debugging a program that was, in fact, correct; the binary simply hadn't been relinked after a source change. Feldman received the 2003 ACM Software System Award for it. The tool that came out of that afternoon — track dependencies once, let the machine figure out what needs redoing — became one of the most widely copied ideas in software tooling. GNU Make, the version almost everyone uses today, is a free reimplementation from the GNU Project (1) (5) (6).</p>
In practice, it's for anyone assembling a non-trivial artifact — a compiled binary, a document, a set of generated files — from smaller pieces, where rebuilding everything from scratch on every change would be wasteful or slow. That covers C/C++ projects, kernel and bootloader builds, LaTeX documents, and plenty of ad-hoc automation that has nothing to do with compiling code at all.</p>
When should you reach for it?</h2>
Make earns its keep when three things are true at once:</p>

There's a real dependency graph</strong> — some outputs depend on others, and rebuilding is not simply "regenerate everything."</li>
Rebuilds are expensive enough</strong> that skipping unnecessary ones matters (a two-second compile doesn't need this; a twenty-minute kernel build does).</li>
The rules are reasonably stable</strong> — Make's file-timestamp model doesn't handle wildly dynamic pipelines as gracefully as a task runner with explicit invalidation might.</li>
</ul>
For a handful of files with no interdependencies, a shell script is often simpler and more honest. Make starts paying off once "did this actually need rebuilding?" becomes a question worth asking automatically instead of by hand.</p>
Where does it sit in the toolchain?</h2>
Make usually sits one layer above the compiler and one layer below whatever a human runs. In a typical C project: source files → (compiler, driven by Make) → object files → (linker, driven by Make) → final binary. Make itself doesn't compile or link anything — it invokes the tools that do, as shell commands in each recipe.</p>
It also tends to sit underneath</em> higher-level build-configuration tools. CMake, Autotools, and Yocto's BitBake, for instance, don't replace Make so much as generate Makefiles (or drive an equivalent) as their actual execution backend. So even projects that never show you a Makefile directly are often running one somewhere in the pipeline.</p>
Why does it work the way it does?</h2>
The core design choice — comparing file modification times to decide what's stale — is what makes Make fast on large trees: checking a timestamp is cheap, so a rebuild of a huge project after a one-line change can skip almost everything and still be correct, provided the dependency graph given to it is accurate</em>.</p>
That last clause is the source of almost every "Make is broken" complaint people run into, and it's worth sitting with: Make is only ever as correct as the graph it's told about. If a .c</code> file #include</code>s a header that isn't listed as a prerequisite of the corresponding .o</code> file, editing that header won't trigger a rebuild — not because Make is confused, but because nothing ever told it that dependency existed. This is why real-world Makefiles almost always pair with a compiler-generated dependency step (-MMD -MP</code> with GCC/Clang) rather than hand-written header lists — the compiler already knows the true include graph, so it's the only reliable source for it (4).</p>
How does it actually work?</h2>
Targets, prerequisites, recipes.</strong> The basic unit is:</p>
target</span>:</span> prerequisite1 prerequisite2</span></span>
	recipe line 1</span></span>
	recipe line 2</span></span></code></pre>
Recipe lines must be indented with a tab</strong>, not spaces — a famous historical wart that still trips people up today.</p>
Automatic variables</strong> cut down on repetition:</p>
%.o</span>:</span> %.c</span></span>
	gcc -c $< -o $@</span></span></code></pre>
$@</code> is the target, $<</code> is the first prerequisite — this pattern rule alone can build every .o</code> from its matching .c</code> file without one line per file.</p>
.PHONY</code> targets</strong> mark names that don't correspond to real files — clean</code>, all</code>, test</code> — so Make doesn't get confused if a file with that name happens to exist, and always runs the recipe rather than checking timestamps: (2)</p>
.PHONY</span>:</span> clean</span></span>
clean</span>:</span></span>
	rm -f *.o main</span></span></code></pre>
Variables</strong> avoid repeating flags everywhere and make cross-project reuse easier:</p>
CC</span> =</span> gcc</span></span>
CFLAGS</span> =</span> -Wall -O2</span></span>
</span>
main.o</span>:</span> main.c</span></span>
	$(CC) $(CFLAGS) -c main.c</span></span></code></pre>
Automatic dependency generation</strong> closes the gap described above:</p>
CFLAGS</span> =</span> -Wall -O2 -MMD -MP</span></span>
-include</span> $(</span>wildcard</span> *.d</span>)</span></span>
</span>
%.o</span>:</span> %.c</span></span>
	$(CC) $(CFLAGS) -c $<</span></span></code></pre>
-MMD</code> makes the compiler emit a .d</code> file per object, listing every header actually pulled in during that compile. -include</code> folds those files back into the Makefile so the dependency graph stays accurate as headers change — without anyone maintaining it by hand (3).</p>
Closing thought</h2>
Most of what looks like Make's quirks — the timestamp comparisons, the insistence on tabs, the way a missing dependency fails silently instead of loudly — falls out of one design decision made in 1976: keep the model simple and the check cheap, and trust the Makefile to describe reality accurately. Once that's the lens, most "Make is being weird" moments turn out to be "the graph I gave it was incomplete" — which is a much easier thing to fix.</p>

Related Reading</h2>

Git: Deleting Branches, Merging, and Undoing a Bad Push</a> — the everyday branch and push commands</li>
</ul>
References</h2>

Feldman, S. I. (1979). Make — A Program for Maintaining Computer Programs</a>. Software: Practice and Experience</em>, 9(4), 255–265. — Feldman's own paper introducing Make, including the original motivation.</li>
GNU Make Manual</a> — the complete, authoritative reference for GNU Make's syntax and semantics.</li>
GNU Make Manual: Automatic Prerequisites</a> — the -MMD</code>/-include</code> pattern in the maintainers' own words.</li>
GCC: Preprocessor Options (-M</code> family)</a> — what -MMD</code> and -MP</code> do under the hood.</li>
Make (software) — Wikipedia</a> — general history and lineage of Make implementations (BSD Make, GNU Make, NMAKE, etc.).</li>
Stuart Feldman — Wikipedia</a> — background on Feldman's work at Bell Labs and the 2003 ACM Software System Award.</li>
</ol>


The Embedded Linux Boot Chain
2026-07-30T00:00:00+00:00
Last time I wrote about DFU</a> as a way to flash firmware over USB. That post skipped a question worth answering on its own: what actually happens between pressing the power button and a shell prompt showing up? DFU is just one branch off this path, so it's worth walking the whole thing once.</p>
The stages</h2>
Drawn as a Mermaid flowchart, the chain (with DFU's place in it) looks like this:</p>
flowchart TD</span></span>
    A[Power-on / Reset] --> B[Boot ROM<br/>immutable, on-chip]</span></span>
    B --> C{Valid image on<br/>boot media?}</span></span>
    C -->|No / forced| D[ROM recovery mode<br/>UART / USB]</span></span>
    C -->|Yes| E[SPL<br/>first-stage bootloader]</span></span>
    E --> F[U-Boot<br/>second-stage bootloader]</span></span>
    F --> G{Enter DFU?}</span></span>
    G -->|Yes| H[DFU mode<br/>waiting for firmware over USB]</span></span>
    G -->|No| I[Load kernel + device tree]</span></span>
    I --> J[Linux kernel]</span></span>
    J --> K[Mount root filesystem]</span></span>
    K --> L[init / systemd]</span></span></code></pre>
And rendered:</p>

Boot ROM</h3>
Baked into the silicon at manufacturing time — nothing about it can be changed after the fact. Its only job is to find something</em> bootable on one of a small set of boot media (eMMC, SD, QSPI flash, sometimes USB) according to boot-mode pins or eFuses, and jump to it. If it can't find anything valid, most SoCs fall back to a minimal UART or USB recovery mode at this stage — the very first place you can talk to the chip at all.</p>
SPL</h3>
Short for Secondary Program Loader (U-Boot's term for it; other vendors call it FSBL or similar). It runs from a small amount of on-chip SRAM, before DRAM is even initialized, so it has to be tiny. Its main job is exactly that: bring up DRAM, then load the next stage — full U-Boot — into it.</p>
U-Boot proper</h3>
This is the bootloader most people mean when they say "bootloader." It has drivers, a shell, environment variables, network support, and a command interpreter. It's also where DFU actually lives — running dfu 0 mmc 0</code> (or similar) drops U-Boot into DFU mode instead of continuing the normal boot, which is the mode dfu-util</code> talks to from the host side. Otherwise, it loads the kernel image and device tree blob into memory and jumps to the kernel.</p>
Kernel and userspace</h3>
The kernel decompresses itself, brings up the console, probes hardware using the device tree it was handed, and mounts a root filesystem — often the same eMMC or SD card the bootloader booted from, sometimes NFS during development. Once the root filesystem is mounted, the kernel hands off to PID 1 — usually systemd</code> on a Yocto-built image — and that's where "userspace" actually starts.</p>
Why this matters for DFU</h2>
DFU only makes sense once you see where it sits: it's a detour U-Boot can take instead of</em> loading the kernel, not a separate thing bolted on top. That's also why DFU can't rescue every failure mode — if the boot ROM itself can't find a valid SPL, you never reach U-Boot at all, and you're relying on whatever recovery mode the boot ROM supports instead (which varies a lot by vendor and is a good topic for another post).</p>
Further reading</h2>

U-Boot: Generic SPL framework</a> — how SPL is built and what it's responsible for.</li>
Trusted Firmware-A: Firmware Design</a> — the more elaborate multi-stage boot flow (BL1/BL2/BL31/BL32/BL33) used on many modern Arm SoCs with a secure boot chain, which sits underneath U-Boot on those platforms.</li>
</ul>

Related Reading</h2>

What Is a Device Tree?</a> — how hardware is described to the kernel</li>
What Is DFU?</a> — flashing firmware over USB when there is no other way in</li>
</ul>


What Is DFU?
2026-07-29T00:00:00+00:00
If you've ever plugged an embedded board into your computer and watched it enumerate as a strange, driver-less USB device, there's a good chance it was sitting in DFU mode</strong> — Device Firmware Update.</p>
What DFU actually is</h2>
DFU is a USB device class defined by the USB Implementers Forum, originally meant for updating firmware on USB peripherals without any product-specific tooling. A device that supports it exposes a small, standardized interface: a host-side tool can query it, send a new firmware image, and trigger a reboot into the new code — all over the same USB cable used for everything else.</p>
On embedded boards, "DFU mode" usually means the bootloader itself (U-Boot, for example) is running a minimal DFU stack instead of booting Linux. The board shows up on the host as a DFU-class USB device, and a tool like dfu-util</code> can list the flashable targets (partitions, memory regions, whatever the bootloader chooses to expose) and write to them directly.</p>
Why it matters</h2>
A few things make DFU genuinely useful in embedded development and production:</p>

No extra hardware.</strong> No JTAG probe, no UART adapter — just the USB port the board already has.</li>
Recoverability.</strong> If a board is bricked or has no valid OS on flash, DFU mode (often triggered by a strap pin or a boot ROM fallback) is frequently the last line of defense to get it flashable again.</li>
Standardization.</strong> Because it's a real USB class with real drivers, it works the same way across operating systems without a vendor-specific kernel driver.</li>
</ul>
It's worth contrasting DFU with adjacent mechanisms you'll bump into on the same boards: fastboot</code> (Android's protocol, similar goal, different wire format), and full system-image tools like swupdate</code> or RAUC</code>, which handle update delivery and rollback</em> once Linux is already running — DFU typically operates one layer below that, closer to the bootloader.</p>
A rough workflow</h2>
A typical DFU session from the host side looks like:</p>
# see what the board exposes in DFU mode</span></span>
dfu-util</span> -l</span></span>
</span>
# flash an image to a specific alt-setting/partition</span></span>
dfu-util</span> -a</span> 0</span> -D firmware.bin</span></span></code></pre>
The board resets into the bootloader's DFU handler, the host tool negotiates the transfer, and the image lands wherever the bootloader mapped that alt-setting — often a specific eMMC/NAND partition or a staging area the bootloader flashes on next boot.</p>
Closing thought</h2>
DFU is one of those pieces of infrastructure that's invisible when it works: you plug in a cable, run one command, and a board that couldn't boot a minute ago is back up. Most of the interesting engineering is in getting the bootloader side right — what gets exposed, how it maps to real storage, and how it fails safely when the transfer gets interrupted halfway through.</p>
This was a short one — I'll go deeper into specific implementations (and where they get hairy) in a future post.</p>
Further reading</h2>

Universal Serial Bus Device Class Specification for Device Firmware Upgrade, Revision 1.1</a> — the official USB-IF spec DFU is based on.</li>
dfu-util</a> — the host-side tool used in the example above.</li>
U-Boot: Device Firmware Upgrade (DFU)</a> — how DFU is implemented in the bootloader most embedded Linux boards use.</li>
</ul>

Related Reading</h2>

The Embedded Linux Boot Chain</a> — how the bootloader hands control to the kernel</li>
What Is a Device Tree?</a> — how hardware is described to the kernel</li>
</ul>