What is Using the Flattened Device Tree - Linux Kernel

Question

I am reviewing the boot process of Uboot and the kernel. What is the use of FDT (flat device tree)?

Many of the links I read indicate that uboot passes the board and SOC configuration information to the kernel as FDT

https://wiki.freebsd.org/FlattenedDeviceTree

Why does the kernel require configuration information for the board?

I ask this question because when we make a device driver on Linux, we use to initialize the device when calling probe () or module_init () and use the request_mem_region () and ioremap () functions to get the address range & amp; then set the clock and another register of the driver.
What does request_mem_region () do and when is it necessary?

Now, if my device drivers for onchip and offchip devices are fully initializing the board.
Then what is the flattened device tree for the kernel used for?

Answer 1

You are right in believing that board files and device trees are needed to initialize embedded units and peripherals outside the chip.

• When loading, the appropriate drivers for all SoC embedded units and peripheral peripheral devices connected to it must be “checked”, that is, loaded and called. On buses such as USB and PCI, peripheral devices can be physically detected and listed, and their corresponding driver checked. However, in general, such a tool is NOT available, this is the case of other peripheral devices on other buses, such as I2C, SPI, etc.

• In addition to the above, when examining a device driver, it is also necessary to provide some information on how we intend to configure and use the equipment. It depends on the use case. For example, the baud rate at which we would like to use the UART port.

Both of the above classes of information, i.e.

• Physical hardware topology.
• Hardware configuration options.

usually defined as structs in the board file.

However, using the file board approach required re-assembling the kernel, even to simply change the custom option for a different value during initialization. Also, when there are several physical cards that differ slightly in their topology / configuration, the approach to the board file becomes too cumbersome to maintain.

Hence the interest in storing this information separately in the device tree. Any device driver can analyze the corresponding branches and leaves of the device tree to obtain the required information.

---

When developing your own driver device, if your platform supports the device tree, you are advised to use the device tree to store the "platform data" required by your device driver. This should help you clearly distinguish between:

• The generic driver code for your device in the driver.c file and

• device configuration parameters specific to this platform into the device tree .

A step-by-step approach to porting the Linux kernel to the board / SoC should help you appreciate the nuances and benefits of using the device tree.