Device Tree (dtb)

The Device Tree Blob (or binary) is a file containing information about the board and its hardware.

Why is it needed?

Most embedded platforms do not provide a way of discovering the hardware they have. You either have to resort to guesswork (which is not viable), or provide the Linux kernel with information about the board and the peripherals.

Before the dtb was introduced, each board needed a kernel specifically compiled for them, which was hardcoded to use the peripherals. With the dtb, a single kernel can run on multiple devices, if it is given the right dtb at boot time.

How is it created?

The dtb is created from device tree source (dts) files. Those contain the hardware description in a readable format. The dtb format merely exists to make loading them simpler for the kernel. As such, dts can be converted to and from dtb with a device tree compiler, dtc, which is available on most linux distributions.

How is it used?

The dtb is loaded in memory by the bootloader (often uboot) before the kernel is started.

Some older versions of uboot do not support loading a separate dtb file, which means that the dtb has to be embedded in the kernel zImage.

QCDT

Some Qualcomm devices also use the QCDT format, where the dtb is appended to the end of the filesystem (boot.img) instead of the zImage.

Where can I find a dts for my device?

Extract the dts from a boot.img

When a dts is not present in the kernel source code at all, or when it is not immediately apparent which file is the correct one for your device, a dts can be extracted from a boot.img for your device.

This is done with extract-dtb and unpackbootimg (both packaged in postmarketOS). The resulting dtb can be converted back to a source file with the dtc compiler (though the comments will be lost, as well as the includes).

If dtc gives this error:

FATAL ERROR: Blob has incorrect magic number

Then you are likely working with a dtb that has an offset (Samsung does this). The offset can be identified with binwalk. For Samsung dtb, it is 0x40. The following command will remove the 0x40 offset and use dtc to create a file called dts from an input file called dtb.img:

dd if=dtb.img skip=$((0x40)) iflag=skip_bytes | dtc -I dtb -o dts

If all else fails, you can always use strings on the dtb file. The output will be messy and not directly useful, but may give you keywords (such as a model number) to look for within the kernel source code to help you locate and identify the correct .dts file.

Locate the dts in the kernel source

The dts files are generally present in the kernel fork your device uses. Look in the boards/ directory, or in arch/your_device_arch/boot/dts.

When a board is mainlined, the corresponding dts file is mainlined as well (though those may be put in a separate repository in the future).

If you cannot immediately find or identify the correct .dts in your downstream kernel source, analyse the boot.img as described above. You can use the information contained in the extracted dts, such as the model name, to find a matching file in the kernel source. Note that the .dts in the kernel source will almost definitely not look like the extracted dts. It will be much shorter, as most of the code comes from the includes.

Writing a device tree

When mainlining a board, it is often needed to write one's own device tree (see also Mainlining_Guide#Device_Tree_Source). Indeed, while the physical description part won't change, the name of the drivers will probably. Thus, you need to find kernel drivers that are compatible with your own device, and put them in the device tree (assuming there is one). You should at least read carefully the description on elinux.org. Another good tutorial to writing your device trees is present on xillybus.com.

Links