What is a device tree and a device tree blob?
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
I’ve only heard of them, not really dealt with them. Basically, it’s something passed from the firmware or bootloader to the kernel, to tell it what hardware exists on the system. Here are a few links: elinux.org/Device_Tree git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/…
3 Answers 3
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:
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.
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/ .
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 = ; interrupts = ; interrupt-controller; #interrupt-cells = ; clocks = ; clock-names = "apb_pclk"; lkmc-asdf = ; >; Then, by using a Linux kernel module to interact with the device, we will test the following DTS features:
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 = ; , which is read with of_property_read_u32
- the device tree is passed to QEMU’s firmware with the -dtb argument
- device that reads a register and generates interrupts
- insert device into -M versatilepb
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.
- indispensable elinux tutorial: http://elinux.org/Device_Tree_Usage
- play around with dtc for purely syntaxical questions. E.g., it shows how nodes are simply merged by path: https://unix.stackexchange.com/a/375923/32558
- https://stackoverflow.com/questions/17488320/how-to-program-linux-dts-device-tree-files
Введение
Данная статья посвящена механизму описания структуры периферии, использующемуся в частности в ядре Linux для архитектур armh и aarch64.
Одноплатные компьютеры семейств RaspberryPi, OrangePi, Repka Pi3 и многие прочие подобные используют в качестве процессора микросхему — систему на кристалле (SoC). Микросхема SoC нуждается только во внешнем ОЗУ, при этом она реализует в одном чипе множество возможных, часто взаимоисключающих конфигураций периферии интерфейсов ввода-вывода.
Таким образом должен быть механизм, позволяющий передать ядру, какая из конфигураций соответствует тому, что распаяно на печатной плате, а также какое поведение инженер-разработчик ожидает от внешних универсальных контактов (штырьков) ввода-вывода платы (GPIO). Данным механизмом и является описываемое здесь дерево устройств — Device Tree.
Форматы файлов
*.dtb файл
Device Tree Binary — иерархическое описание структуры периферии в бинарном формате. Именно в таком формате оно подргужается в ядро Linux в качестве аргумента через загрузчик. Ядро использует структуру, чтобы узнать о периферийных устройствах — какие включены, какие модули ядра задействовать, символические имена.
*.dts файл
Device Tree Source (aka Strings) — представление дерева устройств в человекочитаемом формате, в виде исходного кода. Синтаксис языка похож на JSON. Для связи с описанием в *.dtb формате используется утилита dtc.
Компилятор/декомпилятор dtc
Для работы с описанием дерева устройств предназначен компилятор dtc (пакет dtc).
Для конвертации бинарного дерева устройств в текстовое представление:
Для компиляции текстового описания дерева устройств обратно в бинарное представление:
Оверлеи *.dtbo
В специализированном дистрибутиве Raspbian реализован механизм, позволяющий во время загрузки накладывать на *.dtb файлы патчи. Такой патч, включающий какую-то аппаратную возможность платы, называется оверлеем. Формат файла — такой же, как у .dtb — файл можно прочитать при помощи утилиты dtc.
Файлы находятся в папке /boot/dtb/overlay системы Raspbian. Исследование их помогает понять, как исправить дерево устройств, чтобы включить какую-либо нужную фичу.
Вроде бы, загрузчик U-Boot умеет их применять. Данный вопрос требует дальнейшего исследования.
Настройки
Ванильные *.dtb файлы ядра
Вместе с ядром Linux (проверено для ядер для 5.*) поставляется библиотека *.dtb файлов под разные одноплатные компьютеры, модули и системы. При установке ядра файлы оказываются в папке
Для каждого чипа и платы имеется свой файл — одна и та же микросхема может оказаться на разных платах разных производителей.
Настройка устройств под себя
Конфигурации *.dtb, поставляемые вместе с ядром для каждой платы, описывают некоторую базовую конфигурацию, которая подойдёт всем. Учитывая настраиваемость платы, однако же, может потребоваться эту конфигурацию изменить. Для этого следует вскрыть *.dtb файл утилитой dtc, отредактировать его в *.dts формате и сохранить обратно. Какой из многих файлов загружается — можно посмотреть в выводе загрузчика U-Boot во время старта системы, этот файл будет единственный с именем, соответствующем модели платы.
Обновление ядра
Очевидна проблема — при обновлении ядра исправления будут утеряны. Это не является проблемой, если сборка подготавливается для встраиваемой системы, которую не будут обновлять. Иначе следовало бы написать скрипт, делающий исправления автоматически, и прописать его как-то в механизм /etc/initrd.mk. Эта секция требует уточнения.
Синтаксис
Синтаксис *.dts файла достаточно понятен (очевидно!) =) Лучший способ исследования — вскрыть файл и посмотреть, что там внутри.
Приглашаю всех практикующих инженеров писать сюда свои примеры 😉
Включение и отключение устройств
В исходном, «ванильном» дереве многие устройства описаны, но отключены. Примеры таких устройств — контроллеры шины i2c, контроллер uart (serial). Для включения устройства достаточно поправить один параметр.
Отключённое устройство имеет в своём описании поле:
Для включения устройства следует исправить:
Ссылки