LWN: Comments on "Device tree overlays"

Device tree overlays

matwey — Sat, 28 Mar 2015 11:58:31 +0000

Do I understand correctly, that currently there is still no way to modify device tree from user space in 4.0?

Device tree overlays

etienne — Tue, 17 Feb 2015 11:12:57 +0000

Yes, but one question is: is that board needed to boot?
If not, then is the pre-initialisation system the right place to do that kind of things?
How is it different than some equipment plugged in a serial port, like a modem, that you initialize in user mode when you need it?
I understand that having a single place to describe the hardware is nice, but modifying that place (device tree) may trigger a bug which stops the system booting - and so make it more difficult to recover.
You may want to "insert" a device tree overlay after boot in user mode, but then isn't it complexifying the system compared to inserting a module with some parameters.

Device tree overlays

Kamilion — Mon, 16 Feb 2015 20:52:38 +0000

Have a look at this, It's a pretty good example of what can be done with a beaglebone cape (as well as being generally useful to a lot of folks doing EE)

https://github.com/abhishek-kakkar/BeagleLogic/wiki/The-B...

Very simple design, two ICs and some headers on a PCB from dirtypcbs.com.
There's just some unpopulated shunt-resistors for the I2C EEPROM, as it assumes it will be the lowest board in the stack. Not surprising, considering it's set up to be a 100Mhz multichannel logic analyzer.
Software side of it has something like 20+ common protocol decoders.

The TI 74LVCH16T245 16-bit buffer chip doesn't really have any means of identification, as it's just a logic part. And yet the I2C EEPROM still says "I got here first" on the pins it's contents requests, for the capes that may be stacked on top. Maybe a cellular module, maybe a 30Mhz SPI display... If you've got a raspberry pi or a odroid C1 or something right now and try to stick one of the cheap 30Mhz SPI displays floating around out there right now, you still need to track down the right kernel module, tell it which GPIOs go where when you modprobe stuff.

modprobe spicc
modprobe fbtft_device name=odroidc_tft32 rotate=270 gpios=reset:116,dc:115 speed=32000000 cs=0

Kinda squicky; we can do better. Loading Devicetree fragments is at least a signpost along the path.

And yes, the loaded i2c rom can potentially be very large (256K+) and contain just about anything after the relatively small header the beaglebone code will attempt to parse, which is about 256 bytes.

Device tree overlays

jem — Tue, 28 Oct 2014 09:43:44 +0000

The EEPROM is on the cape and is pre-programmed by the maker of the cape. The I2C address of the EEPROM is one of four fixed addresses; the cape should also include a two position switch to select which of the four addresses it responds to. If several capes are stacked (up to four), the user must take care the switches are in different positions on each cape.

The EEPROM contents are defined in the BeagleBone Black System Reference Manual, and contain information like Manufacturer Name, Part Number, Pin Usage, etc.

Device tree overlays

giraffedata — Mon, 27 Oct 2014 17:20:01 +0000

The EEPROM is non-volatile memory and will only contain information about what's present (e.g. which cape), whereas the device tree contains information about how to use it (e.g. the I²C bus address of the cape's chip).

Where is the EEPROM and who programs it? Who chooses the I²C bus address of the cape's chip?

Does "which cape" mean which model of cape? If so, it sounds a lot like PCI vendor and device ID, which seems like all Linux needs to know to know how to use the cape (assuming the requisite knowledge were programmed in, as for most PCI devices).

Is there some reason the EEPROM can't contain information about how to use a cape?

What is more, the user could also hard-code in a script which device tree overlay must be loaded, because she knowns what cape the board is equipped with.

But I'm sure she'd rather not, which is why I'm trying to understand what is different about the world in which Beaglebone lives that Linux can't detect what cape the board is equipped with like it does in the bigger systems.

Device tree overlays

dlang — Mon, 27 Oct 2014 08:11:54 +0000

so where are these snippets of devicetree data coming from? are they being compiled into the kernel, loaded from userspace somehow, or what?

without device tree snippets, you had drivers that looked for an id on some bus and then knew what devices were where when they saw that ID (hard coded in the driver), it sounds like this is trying to avoid the hard-coding into a driver, but it's not clear where the data is arriving from.

It's also not clear why the info about a particular device (cape or whatever) needs to be merged with the devicetree that was handed to the kernel at boot time. Why aren't the appropriate devices just configured and initialized without going to the trouble of merging the info about this cape into the tree that you were given at initialization time.

If this was being done in the bootloader, with the resulting devicetree being handed to the kernel, it would make perfect sense. But it seems to make far less sense after the kernel has initialized the system from the devicetree it was handed and is now running normally.

Device tree overlays

rvfh — Mon, 27 Oct 2014 08:00:52 +0000

The EEPROM is non-volatile memory and will only contain information about what's present (e.g. which cape), whereas the device tree contains information about how to use it (e.g. the I²C bus address of the cape's chip).

They are complementary.

What is more, the user could also hard-code in a script which device tree overlay must be loaded, because she knowns what cape the board is equipped with.

Device tree overlays

giraffedata — Mon, 27 Oct 2014 01:21:11 +0000

I'm still not getting it. Where is this Beaglebone EEPROM and what information is in it? And if it doesn't have all the information a Linux kernel needs to drive a device, so a device tree would not be necessary, why doesn't it?

Device tree overlays

HIGHGuY — Sat, 25 Oct 2014 08:01:47 +0000

In the absense of the device-tree overlay patchset in our 'old' 2.6.32 kernel we had to refrain to a close-enough hack.

Our device-tree contains all overlays and each node that is 'optional' contains an extra field indicating the overlays it is active in.
The bootloader then reads an EEPROM and fills in a /chosen entry.

The I2C subsystem and one custom driver were modified to compare the extra node field against the /chosen field and only probe the device when they match.

It's not perfect, but gets the job done sufficiently for the few plugin cards we expect in the future.

Device tree overlays

pantoniou — Thu, 23 Oct 2014 17:09:41 +0000

There are two levels of invalid file.

1) The file has syntax errors; this means the file won't compile - that's easy.

2) The file's syntax is correct but is not a valid description of the hardware. That's the hard part. I.e. a typo in one of the properties names is a valid DT file, but it's not going to work when you use it.

Device tree overlays

pantoniou — Thu, 23 Oct 2014 17:07:29 +0000

The kernel cannot detect the full set of hardware devices. It can however deduce what's there by reading an out-of-band marker that describes.

On the beaglebone you have an EEPROM, on other platforms you might encode the possible expansion board combination on GPIOs and so on.

For FPGAs you just have a-priori knowledge of what a bitstream loaded to the FPGA is providing.

Device tree overlays

jezuch — Thu, 23 Oct 2014 11:07:16 +0000

> The fact that the current device tree compiler performs no syntax checks does not help the situation; the first indication of an incorrect device tree file is typically a failure to boot.

So, um, what does it do if the file is invalid?

Device tree overlays

koenkooi — Thu, 23 Oct 2014 07:20:56 +0000

One of the use-cases is plugging in expansion boards (e.g. capes for the beaglebone, hats for the rpi) where the kernel can detect and read the EEPROM, but not the actual hardware. Using information from the EEPROM you can load a devicetree overlay for the new hardware. Maybe in the future you'll be able to put the overlay directly into the EEPROM.

Device tree overlays

bnorris — Thu, 23 Oct 2014 07:19:54 +0000

> Why does the device tree need to be involved if the kernel can detect the hardware?

I don't think the kernel can detect the hardware in the examples mentioned in the article. From the sound of it, dynamic patching of the device tree is controlled by the user in some form, either via sysfs or procfs. But admittedly, it's difficult to tell, since this article doesn't actually link to the relevant work.

[Preemptive edit:] It looks like this contains some of the work, although it surely can't be the latest:

http://lwn.net/Articles/600466/

In this work, overlays are provided by the user via configfs.

Device tree overlays

dlang — Thu, 23 Oct 2014 04:43:50 +0000

I'm missing something here. Device trees are needed because the system can't detect hardware, so the kernel needs to be told what hardware exists.

But this proposal is about having the kernel detect hardware and change the device tree.

Why does the device tree need to be involved if the kernel can detect the hardware?