Using the Device Tree

Modern computers are really complex systems composed of complex peripherals, which have tons of different configuration settings; that's why having all possible variants of device driver configurations in a dedicated file can solve a lot of problems. Having a logical description about how a system is structured (that is how they are interconnected to each other and not just their list) can allow system developers to focus their attention on device driver mechanisms without the boring job of managing all possible user settings.

Moreover, knowing how every peripheral is connected to the system (for example, which bus a peripheral is dependent on) allows the implementation of a really smart peripheral management system. Such a system can correctly activate (or deactivate), in the right order, all the subsystems needed, by a specific device, to work.

Let...

Technical requirements

You can find more information on this chapter in the Appendix.

The code and other files used in this chapter can be downloaded from GitHub at https://github.com/giometti/linux_device_driver_development_cookbook/tree/master/chapter_04.

Using the device tree compiler and utilities

We need proper tools to convert our code into a binary format that Linux can understand. Specifically, we need a way to convert a device tree source (DTS) file into its binary form: device tree binary (DTB).

In this recipe, we'll discover how to install the device tree compiler (dtc) on our system and how we can use it to generate the binary for any device tree.

Getting ready

To convert a DTS file into a DTB one we have to use the device tree compiler (named dtc) and a set of proper tools we can use to inspect or manipulate DTB files (device tree utilities).

Every recent Linux release has its own copy of the dtc program in the linux/scripts/dtc directory, which is used during...

Getting application-specific data from a device tree

Now we know how to read a device tree file and how to manage it in userspace. In this recipe, we will see how we can extract the configuration settings it holds within the kernel.

Getting ready

To do our job, we can use all the data stored in the DTB to boot our ESPRESSObin and then use the ESPRESSObin as a system test.

As we know, ESPRESSObin's DTS file is stored in kernel sources at linux/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts or it can be extracted from the running kernel by executing the dtc command as presented in the following code:

# dtc -I fs -o espressobin-reverted.dts /proc/device-tree/

Now let's take this file apart since we can use...

Using a device tree to describe a character driver

At this point, we have all the information needed to define a new character device by using a device tree. In particular, this time, to register our chrdev device, we can use the new API that we skipped in Chapter 3, Working with Char Drivers.

Getting ready

As stated in the previous paragraph, we can use a device tree node to add a new device to our system. In particular, we can obtain a definition as reported in the following:

chrdev {
    compatible = "ldddc,chrdev";
    #address-cells = <1>;
    #size-cells = <0>;

    chrdev@2 {
        label = "cdev-eeprom";
        reg = <2>;
    };

    chrdev@4 {
        label = "cdev-rom";
    ...

Downloading the firmware

By using the device tree, we're now able to specify a lot of different settings for our driver, but there is still one last thing we have to see: how to load firmware into our device. In fact, some devices may require a program for themselves to work which, for license reasons, cannot be linked within the kernel.

In this section, we're going to see some examples of how we can ask the kernel to load firmware for our device.

Getting ready

Some peripherals need firmware to work and then we need a mechanism to load such binary data into them. Linux provides us with different mechanisms to do this job and they all refer to the request_firmware() function.

Whenever we use a request_firmware(....

Configuring CPU pins for specific peripherals

As the device driver developer, this task is really important because to be able to talk with external devices (or internal ones but with external signal lines) we must be sure that each CPU pin is properly configured to talk with these external signals. In this recipe, we will look at how we can use the device tree to configure CPU pins.

How to do it...

Just as a simple example, let's try to modify the pin configuration for our ESPRESSObin.

1. First of all, we should take a look at the current configuration by looking at sysfs in the /sys/bus/platform/drivers/mvebu-uart/ directory, where we verify that only one UART is currently enabled:

# ls /sys/bus/platform/drivers/mvebu...