what is the use of Flattened device tree - Linux Kernel

Question

I am going through the Uboot & kernel startup process. What exactly is the use of the FDT (Flat device tree) ?

Many link i have read they state that uboot pass the board & SOC configuration information to Kernel in the form of FDT

https://wiki.freebsd.org/FlattenedDeviceTree

Why kernel need the board configuration information ?

I am asking this question because when ever we make device driver in linux we use to initialize the device at probe() or module_init() call & use request_mem_region() & ioremap() function to get the range of address & then set the clock & other register of the driver.
What does request_mem_region() actually do and when it is needed?

Now if my device drivers for onchip & offchip devices are doing the full board initialisation.
Then what is the use of flattened device tree for the kernel ?

Answer 1

You are right in assuming that the board files and device-trees are required for initialisation of on-chip blocks and off-chip peripherals.

1. While booting-up, the respective drivers for all on-chip blocks of an SoC and off-chip peripherals interfaced to it need to be "probed" i.e. loaded and called. On bus-es like USB and PCI, the peripherals can be detected physically and enumerated and their corresponding driver probed. However in general such a facility is NOT available is case of the rest of the peripherals on the rest of the buses like I2C, SPI etc.

2. In addition to above, when the device-driver is probed, one also needs to provide some information to it about the way in which we intend to configure and utilise the hardware. This varies depending upon the use case. For example the baud-rate at which we would like to operate an UART port.

Both the above classes of information i.e.

• Physical Topology of the hardware.
• Configuration options of the hardware.

were usually defined as structs within the "board" file.

However using the board-file approach required one to re-build the kernel even to simply modify a configurable option to a different value during initialisation. Also when several physical boards differing slightly in their topology/configuration exist, the "board" file approach becomes too cumbersome to maintain.

Hence the interest in maintaining this information separately in a device-tree. Any device-driver can parse the relevant branches and leaves of the device-tree to obtain the information it requires.

---

When developing your own device-driver, if your platform supports the device-tree, then you are encouraged to utilise the device tree to store the "platform data" required by your device-driver. This should help you clearly separate :

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

• the device's config options specific to this platform into the device-tree.

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