8

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 ?

Community
  • 1
  • 1
Katoch
  • 2,709
  • 9
  • 51
  • 84
  • 3
    Some of your concepts of how a device driver is configured are now obsolete with Device Tree. No offense intended, but here's a [video](http://www.youtube.com/watch?v=m_NyYEBxfn8) of the intent of using Device Tree. Thomas Petazzoni also has some slide presentations at [Free Electrons](http://free-electrons.com/docs/). – sawdust Feb 16 '14 at 23:42
  • @sawdust so you means to say that prob(0 & module_init() or init_module() these functions are not used for driver initialization ... but i have use same concept on my RPi harware .. means create a loadable module which use to perform all its initialisation in init_module() function ... loaded this module using insmod() command & used it ... so you want to say now we do not use concept of lodable kernel module in Linux kernel ... ? please suggest ... !! – Katoch Feb 17 '14 at 11:30
  • *"so you means to say that..."* -- I did not write or imply anything close to what you speculate. The old method of **board file** and **platform data** *versus* **Device Tree** are clearly described in that video and slide presentations already mentioned. So instead of guessing and wildly misinterpreting the simple sentence that I wrote, click on those links. – sawdust Feb 18 '14 at 09:13
  • yes that video explains every thing .. one thing i will like to know .. which version of kernel was the first one to move towards device tree implementation ... ? Does all the modern SOC these days follow Flatterned device tree to pass information to kernel or still old approach is used in industry ..? – Katoch Feb 19 '14 at 11:28
  • For ARM the Device Tree first appeared in Linux 3.1. Your second question does not have mutually exclusive terms on each side of the 'or'. – sawdust Feb 19 '14 at 20:43
  • mutually exclusive .. means to say what .. ? – Katoch Feb 20 '14 at 11:32
  • @Katoch Currently, very few of the vast number of SoCs supported in the Linux kernel have adopted the device-tree approach. The general consensus is that device trees are beneficial in most cases and is slowly being adopted. – TheCodeArtist Apr 02 '14 at 05:28
  • Possible duplicate of [How to program Linux .dts device tree files?](https://stackoverflow.com/questions/17488320/how-to-program-linux-dts-device-tree-files) – Ciro Santilli OurBigBook.com Jul 09 '17 at 09:35

1 Answers1

9

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.

TheCodeArtist
  • 21,479
  • 4
  • 69
  • 130