| |||||||||||||
KS2009: Generic device trees
Device trees have been the subject of some acrimonious mailing list
discussions in the past, but developers don't always have a good sense for
what the term means. In an effort to clarify the situation, Grant Likely
and Ben Herrenschmidt ran a session on how this abstraction works.
In essence, a device tree is a data structure for describing the hardware on a system. It has its origins in OpenFirmware, and it retains the format which was laid out there. The tree structure is simple, containing nodes (devices) which have an arbitrary number of properties. A typical device tree entry looks something like the following (taken from arch/powerpc/boot/dts/ep88xc.dts in the kernel source):
ethernet@e00 {
device_type = "network";
compatible = "fsl,mpc885-fec-enet",
"fsl,pq1-fec-enet";
reg = <0xe00 0x188>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <3 1>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY0>;
linux,network-index = <0>;
};
Most of the fields should be relatively self-explanatory; this node describes an Ethernet adapter, where its hardware resources are to be found, how it is connected into the system, and so on. Traditionally, embedded Linux kernels run on special-purpose systems with hardware which cannot be probed for automatically. The configuration of the system usually comes down to some board-specific platform code which knows how the hardware has been put together. Device trees are an attempt to move that information out of the code and into a separate data structure. When done right, device trees can make it possible for a single kernel to support a wide range of boards - something which is hard to do when the system configuration is hardwired into the code. It can even be possible to support systems which do not exist when the kernel is built. Device tree proponents assert that the "board port mindset" is broken. It should not be necessary to modify the kernel for each board which comes along. These modifications, beyond being ugly and painful, lead to a lot of ifdefs and platform-specific code paths in the kernel, all of which is hard to maintain. Device trees also make it possible to get the hardware configuration from a running kernel, even if the vendor is otherwise not forthcoming with that information. The device tree abstraction is used by the PowerPC and MicroBlaze architectures now. There is a lot of interest in using it in the ARM architecture code, but the ARM maintainer is a bit skeptical of the idea. Still, it seems like it might be possible to convince him by carefully porting a subarchitecture or two to device trees first. There were some supportive words from the audience; Greg Kroah-Hartman liked how device trees made it possible to remove static device structures from the kernel, while Thomas Gleixner observed that his employees are much happier about doing ports to boards where device trees are used than to other systems. So the use of device trees in the kernel may expand, but, to a great extent, that depends on architecture maintainers who were not present at the summit. (Log in to post comments)
KS2009: Generic device trees Posted Oct 19, 2009 21:42 UTC (Mon) by klossner (subscriber, #30046) [Link] Device trees are an attempt to move that information out of the code and into a separate data structure.More to the point, device trees are a standard way for the boot code to communicate platform configuration to the kernel. For example, the kernel needs to be told how much RAM exists. The device tree replaces a hodgepodge of ad hoc "boot records," "BIOS information structures," and hyper-extensions of the kernel cmdline.
KS2009: Generic device trees Posted Nov 4, 2009 10:00 UTC (Wed) by HalfMoon (guest, #3211) [Link] Those trees are a way to communicate standard information. But embedded boards have little of that. They're heavy on the customization, the one-off, the new-in-this-revision stuff. See, that's the reason these "trees" don't work so well. Hardware is very customizable. New chips come out all the time and they need a lot more information. This one has a dozen pins for random uses that drivers need to understand about, or in some cases board setup code. Three other variants of the chip have *different* uses for those pins, and need very different configuration. NOT STANDARD. Gotta come up with some way to cram it into the device tree. Committee negotiations slow that process down. Multiply that by, say, six instances of that problem on your new board that's got to enter testing next quarter... And when you get to the point where some "device tree" can solve that ... you're really just growing chip-specific customizations, which still require C code to handle. At that point, there's no benefit to having to come up with some board or chip specific declarations in the "device" tree and then come up with corresponding C code. Easier to just have the C code to cope with, and to do it without needing to involve outside "experts" who have their own ideas about how your hardware should work, and don't have your own product timetables (or success) as priorities. Who may want some fancy Architecting before they add new mechanisms... The reason some folk like that stuff is that when you can use it, you're starting with a simple problem. That's why there's a time saving: they're both derived from having simple hardware. But a LOT of hardware is nowhere near simple — or regular! — enough to use that approach.
KS2009: Generic device trees Posted Nov 4, 2009 10:18 UTC (Wed) by johill (subscriber, #25196) [Link]
Eh? I hate to say it, but your comment reads a lot like FUD.
First of all, I think you're confused about how the DT bindings are created -- there's no "committee" or "outside 'experts'" involved. Yes, there's peer review of bindings, but from what I've seen it's been mostly technical.
Then, you're ignoring the fact that DTs work very well for a large number of boards. Yes, there will be new types of devices that need new drivers ... invariably, boards don't just get faster! But they still include a plethora of standard devices. Serial ports, RAM, IRQ routing, PCI(e) busses, etc. None of that is usually re-architected every time a new board is created, that would be way too expensive!
As a result DTs can (and in practice do, I've seen it done) solve a large percentage of a new board port, up to 100%.
KS2009: Generic device trees Posted Oct 24, 2009 5:13 UTC (Sat) by landley (guest, #6789) [Link]
It also potentially makes life for QEMU, which can take a flattened device tree and parse it to know what emulated hardware to _provide_, and then the built in bootloader (the -kernel option) can feed that device tree on to the kernel.
KS2009: Generic device trees Posted Oct 24, 2009 11:24 UTC (Sat) by nix (subscriber, #2304) [Link]
Yeah, theoretically. If QEMU's emulated hardware wasn't a very limited
selection of antiquated stuff then this might be useful :))
(well, with virtualization hardware now allowing one VM to gain dedicated
KS2009: Generic device trees Posted Oct 24, 2009 19:16 UTC (Sat) by landley (guest, #6789) [Link]
You're putting Descartes before a gift horse so he can look in its mouth.
The lack of a device tree has made emulating new boards extremely fiddly. A board is essentially a collection of devices. So the lack of variety in hardware peripheral emulation is a _symptom_ of what I'm talking about. Bringing up the symptom as an objection to the proposed solution seems weird to me.
You've missed the point at a more fundamental level: QEMU currently isn't about kernels, it's about userspace. It has "a hard drive", "a network card", "a sound card", and so on. Doesn't currently matter which, they're just there to do a job by connecting the emulated environment to the host. They're not there to regression test your drivers.
Once you've booted into a working userspace, you can run (even natively build) a PPC version of arbitrary packages on a standard laptop. A developer can regression test their software on various different targets from a cron job or from a coffee shop, without needing to drag a half-dozen different hardware boxes around.
And you can point an upstream package maintainer at a tarball like http://impactlinux.com/code/firmware/downloads/binaries/s... and tell them: download that, extract it, execute the "./run-emulator.sh" script, cd /home, wget your source tarball from the internet and build it in there, and then do THIS to reproduce the problem I'm seeing on arm. (The fact they didn't have an arm environment in which to reproduce the problem? No longer an issue, here's one that runs under qemu.)
That's useful today.
Adding device tree support would make it useful in additional contexts, able to more closely emulate a wider range of boards out there. Then it could _start_ being a good thing to regression test kernels against, at some point in the future.
Rob
KS2009: Generic device trees Posted Oct 24, 2009 20:06 UTC (Sat) by nix (subscriber, #2304) [Link]
Aha. I see. (Not that I was really 'objecting', it was less strenous than
that.)
btw, "You're putting Descartes before a gift horse so he can look in its
KS2009: Generic device trees Posted Oct 28, 2009 20:11 UTC (Wed) by roelofs (guest, #2599) [Link] btw, "You're putting Descartes before a gift horse so he can look in its mouth" deserves some sort of award.The "Quip with Existential Mixed-metaphor Undertones" Award? :-)
|
|||||||||||||