Understanding The FDT
In this blog, we’ll explore the basics of FDT, its structure, and its significance in enabling flexible hardware configurations, but first let’s dive into the basics.
So what exactly is a FDT ❓
The device tree is a tree structure that describes the hardware in a system. It replaces device-specific code in the kernel, allowing the same kernel image to work on different hardware versions. The device tree blob, a separate binary, contains hardware-specific code. The bootloader passes this blob to the kernel, configuring the hardware accordingly. The device tree also supports overlays, which are additional files that can be dynamically loaded and applied to the main device tree.
So to add some perspective, we programmers write and modify device tree source files (dts files) which are compiled to a device tree blob (dtb file) using a device tree compiler (dtc).
Overlays allow incremental modifications to the hardware description without recompiling the entire device tree or kernel. This flexibility enables easy configuration changes and support for various hardware configurations without the need for separate kernel images.To add an overlay we write device tree source overlays (dtso files ) which are complied to device tree blob overlays (dtbo files).
Lets have a look basic structure of FDT
i2c0: i2c@44e0b000 {
compatible = "ti,omap4-i2c";
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c1";
reg = <0x44e0b000 0x1000>;
interrupts = <70>;
status = "disabled";
};In this example, we have a device tree node representing an I2C controller, specifically “i2c0,” at the memory address “0x44e0b000.”
Node: In device tree, a node represents a hardware component in the system. In this case, “i2c0” is the node that describes the I2C controller.
Get Aryan Sachin Karawale’s stories in your inbox
Join Medium for free to get updates from this writer.
Properties: Properties provide additional information about the node or the hardware it represents. In this node, there are several properties:
- address-cells and size-cells: These properties define how the device tree should interpret the “reg” property .
- Interrupt associated with the node
- compatible: The “compatible” property indicates the device or driver that this node is compatible with. It is used by the kernel to find the appropriate driver to manage this hardware. In this case, the “ti,omap4-i2c” string specifies that this node is compatible with the Texas Instruments OMAP4 I2C controller.
GPIO
A GPIO(General Purpose Input Output) driver is software that allows communication and control of GPIO pins on a microcontroller or SoC. It handles pin configuration, read/write operations, interrupt handling, multiplexing, and power management for efficient interfacing with external devices and sensors.
Basic representation of a GPIO controller
gpio1: gpio@0 {
compatible = "ti,omap4-gpio";
gpio-ranges = <&am33xx_pinmux 0 0 8>,
<&am33xx_pinmux 8 90 4>,
<&am33xx_pinmux 12 12 16>,
<&am33xx_pinmux 28 30 4>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
reg = <0x0 0x1000>;
interrupts = <98>;
};A GPIO controller is a hardware component responsible for managing GPIO pins on a microcontroller or SoC. GPIO controllers, includes a node that represents the GPIO controller, providing detailed characteristics and properties of the controller. This information allows the kernel to identify and initialize the GPIO controller, making the GPIO pins accessible for interacting with external devices and sensors.
Pinmux module
A “pinmux” or “pin multiplexer” is a hardware component its primary purpose is to manage and control the routing of signals between various peripherals and the Input/Output (I/O) pins of the chip. So most importantly a pinmux module enables a single pin to be used for various peripherals.
But then this description itself does no justice to what exactly is the job of the pinmux and in the end what does it have to do with GPIO which is the driver that I am working on. So in the next blog we shall explore the relationship of Pinmux and GPIO, the current working of the GPIO driver in the beagle bsp and finally the integration of FDT to the bit i.e where do i come to the picture 😉.






