|
|
Subscribe / Log in / New account

Device trees as ABI

Device trees as ABI

Posted Jul 31, 2013 11:28 UTC (Wed) by nelljerram (subscriber, #12005)
Parent article: Device trees as ABI

Some missing context for me: why was it decided to move from board files to device tree?

The reasons I'd guess are efficiency of expression and/or not wanting the description to be baked into the kernel. If the latter _was_ one of the reasons, surely it was obvious immediately that this would be a new ABI and so raise the question of stability? If the latter is not a strong reason, why not avoid the stable ABI question by compiling the DT and baking it into the kernel?


to post comments

Device trees as ABI

Posted Jul 31, 2013 12:43 UTC (Wed) by pizza (subscriber, #46) [Link] (5 responses)

> Some missing context for me: why was it decided to move from board files to device tree?

So a single kernel image could be used to boot a wide variety of hardware, including boards that didn't exist when the kernel was released.

Device trees as ABI

Posted Jul 31, 2013 13:13 UTC (Wed) by karim (subscriber, #114) [Link] (3 responses)

Can you elaborate on the benefits of this?

Device trees as ABI

Posted Jul 31, 2013 15:58 UTC (Wed) by raven667 (subscriber, #5198) [Link] (2 responses)

I think the benefit is not having to maintain a separate fork of the kernel for each and every type of board manufactured that has baked-in carnal knowledge of how that particular board is manufactured. Once you can boot a standard kernel on many different types of boards you reduce the maintenance of the kernel and make it easy to do version upgrades, or offer standard software distributions that will work across many devices.

Device trees as ABI

Posted Jul 31, 2013 16:05 UTC (Wed) by raven667 (subscriber, #5198) [Link] (1 responses)

Another way to look at this is to ask how Linux 4.20.3 in 10 years is going to boot on hardware made today, is the kernel going to carry around detailed knowledge of how your FooBoard v3 (and FooBoard v4 and BixBoard model 42 and and and ...) was wired forevermore so that you can load it on your existing device or should we make a standard for detecting how the board is wired so that a generic kernel can use a standard method to enumerate the board and boot, both now and in the indeterminate future.

Device trees as ABI

Posted Aug 12, 2013 2:18 UTC (Mon) by mmarq (guest, #2332) [Link]

To have that standard you have to force every implementer/ODM to follow the standard, akin to have a Linux open platform... which is never going to happen because patents of every kind are pervasive, trade secrets are also pervasive, and ODMs take their IP as very valuable...

OTOH to break out of the "old" PC world, low level binary interfaces are almost mandatory, binary interfaces and Open Source are not mutually exclusive... at least take advantage of it, know and restrict what a blob is up to, but support them, doesn't matter if the source is available or not, of if info is NDA or not.

Device trees as ABI

Posted Jul 31, 2013 13:28 UTC (Wed) by mbizon (subscriber, #37138) [Link]

It was/is already possible to boot a single kernel image for multiple boards, you don't need DT for this.

You want DT if the kernel has no knowledge of how the hardware is layered and you want to provide that information on a separate channel. This requires that the kernel know the DT "schema" that you use to describe your hardware.

for example, DT would tell the kernel "you have a I2C/SPI/... hardware block of type xxxx at location xxxx", allowing the kernel to register the device without needing a platform/pci_register_device that you typically find inside board files.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds