Simplify Embedded Linux Boot and Updates with Flattened Image Trees (FIT)

 

Struggling with mismatched kernel and DTB updates? Learn how Flattened Image Trees (FIT) bundle boot assets into one file for simpler embedded Linux updates and verified boot.

Have you ever struggled to keep a device’s kernel, device tree, and initramfs in sync during an update? When each component lives in its own file on the boot partition, a single mismatch can brick your embedded system.

In this post, you’ll learn how the Flattened Image Tree (FIT) format solves that problem by bundling everything into one container file. You’ll also see how to use it for verified boot and simpler deployment—without chasing multiple files.

What Is a Flattened Image Tree?

A FIT is a single container file that holds your Linux kernel, device trees, initramfs images, and even boot configuration data. Originally developed for U‑Boot, it builds on the Devicetree Blob (DTB) structure, so you can describe boot assets in a familiar format.

Why does that matter ?

Imagine you’re shipping a custom ARM board. Your manufacturing team flashes three separate files: Image, board.dtb, and initrd.img. Later, an over‑the‑air update changes the kernel but forgets the matching DTB. The board fails to boot.

With FIT, you combine all three into one myboard.fit file. U‑Boot unpacks the correct kernel, DTB, and initramfs from that single image. There’s no way to “forget” the DTB because it’s part of the same container.

Verified Boot Without the Headache

Security is critical for many embedded devices—think payment terminals or industrial controllers. Verified boot ensures that every component loaded by U‑Boot has not been tampered with.

FIT supports this naturally. Each image inside the container can have a hash node (SHA‑256, for example) and a signature node. U‑Boot verifies the hash against a public key stored in the device’s read‑only memory.

Example scenario:

You produce a medical monitoring device. A signed FIT image is flashed at the factory. Later, someone tries to replace the kernel with a malicious one. U‑Boot calculates the hash, finds it doesn’t match the stored signature, and refuses to boot. The device stays secure.

Managing Updates Without Chaos

When you store separate files, an update either overwrites each file individually or repartitions the flash. Both approaches are error‑prone and difficult to roll back.

With FIT, you update a single file. The device downloads the new system.fit, writes it to a dedicated partition, and U‑Boot boots from it. If the new image fails, you can fall back to the previous FIT stored in a second slot.

Real‑life example:

A smart‑home hub receives automatic updates. The update script downloads hub-v1.2.fit, verifies its signature, and reboots. 

Because the bootloader always loads fit-partition-a (primary) and fit-partition-b (backup), you can atomically swap slots. No more half‑applied updates that leave the device in an inconsistent state.

What the Current FIT Specification Brings

The FIT format has matured over years of use. The 1.0 specification now clearly documents security architecture, hash contents, and the signature process.

Key capabilities you can rely on:

• DM‑VERITY support – Verify whole filesystem images using kernel‑level integrity checking.

• Shared image data – Reference the same binary data from multiple configurations without duplication.

• Multi‑step loading – Load boot components in stages, useful for complex boot flows.

• Command‑line properties – Pass custom boot arguments directly from the FIT configuration.

These features are stable and ready for production embedded systems.

Three Actionable Steps to Try FIT Today

You can experiment with FIT on any board running U‑Boot. Here’s how:

  1. Install U‑Boot tools

On your build machine, install u-boot-tools (or uboot-tools). This gives you mkimage, the utility that creates FIT images.

1. bash

   sudo apt install u-boot-tools   # Debian/Ubuntu

  2. Write a FIT source file (.its)

Create a text file describing your kernel, DTB, and initramfs.

1. dts

   /dts-v1/;
   / {
       images {
           kernel { ... };
           fdt { ... };
           ramdisk { ... };
       };
       configurations {
           default = "conf-1";
           conf-1 { ... };
       };
   };

  3.  Build and test the FIT

Run mkimage -f myboard.its myboard.fit. Copy the resulting .fit file to your boot medium. In U‑Boot, load it into RAM and type:

text

bootm <fit-address>#conf-1

U‑Boot will automatically extract and boot the correct kernel, DTB, and initramfs.

Keep Your Embedded Booting Simple

Switching to a Flattened Image Tree removes the friction of managing multiple boot files. You gain verified boot, atomic updates, and a single source of truth for your device’s firmware.

Try creating a FIT for one of your development boards this week. Once you experience the convenience, you’ll wonder why you ever juggled separate kernel and DTB files.

Have you already used FIT in a project? Share your tips or questions in the comments below.