5

What exactly is a device tree, and a device tree blob? Where can I get its source code for a particular linux version? I found such name while running linux on xilinx chips (having ARM 9), for example: here

5

Have you tried consulting the Xilinx wiki?

This howto looks like it has everything you need to get what you want. There's links to a git repository with code as well as directions on how to build it. Here's the command to download the device-tree sources.

$ git clone git://github.com/Xilinx/device-tree.git

The Xilinx website also provides a excellent Getting Started resource if you're new to their toolhchain workflow. Here's a diagram that shows where the device trees fit in:

    ss of xilinx workflow

Given these details a very specific to a variance of Linux for the Xilinx platform I'm not going to include any of the details beyond the above here on U&L, since that wiki is maintained by a hardware vendor, Xilinx, that's supporting that version of the kernel for their hardware products to use.

2

Google refers to Wikipedia, which refers to www.devicetree.org which describes your "device tree" as:

The Device Tree is a data structure for describing hardware. Rather than hard coding every detail of a device into an operating system, many aspect of the hardware can be described in a data structure that is passed to the operating system at boot time. The device tree is used both by Open Firmware, and in the standalone Flattened Device Tree (FDT) form.

Seems like this is a completely different "device tree" than the "device tree" under /dev/.

1

Minimal reg + interrupt example with QEMU virtual device

As others said, the device tree is provided by hardware vendors, and it tells the Linux kernel how to talk to devices.

Maybe the two most notable pieces of information that the Linux kernel needs are:

  • register addresses. In ARM-land, you talk to devices by writing to magic physical memory locations that go to the device instead of memory. This is how you tell the device to start working.
  • interrupt line numbers. This is how the device tells the kernel it has finished doing something.

Our example will add the following device tree node to the versatilepb device tree which QEMU will use due to -M versatilepb:

lkmc_platform_device@101e9000 {
    compatible = "lkmc_platform_device";
    reg = <0x101e9000 0x1000>;
    interrupts = <18>;
    interrupt-controller;
    #interrupt-cells = <2>;
    clocks = <&pclk>;
    clock-names = "apb_pclk";
    lkmc-asdf = <0x12345678>;
};

Then, by using a Linux kernel module to interact with the device, we will test the following DTS features:

  • registers addresses
  • IRQs
  • read custom properties from the driver

These are the main components of the example:

  • Linux versatile .dts patch on Linux fork
    • reg and interrupt match numbers hard-coded in the QEMU versatile machine (which represents the SoC)
    • compatible matches the platform_driver.name in the kernel module, and informs the kernel which module will handle this device
    • we also pass a custom property to the driver: lkmc-asdf = <0x12345678>;, which is read with of_property_read_u32
    • the device tree is passed to QEMU's firmware with the -dtb argument
  • QEMU fork:
  • kernel module Writes to memory on probe to test things out, which also generates an IRQ.

Device trees have many more features that we haven't covered, but this example should get you started, and easily allow you to play around with any new features that come up.

Further resources:

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.