|
|
Subscribe / Log in / New account

Device trees I: Are we having fun yet?

Device trees I: Are we having fun yet?

Posted Nov 14, 2013 20:16 UTC (Thu) by mjg59 (subscriber, #23239)
In reply to: Device trees I: Are we having fun yet? by rwmj
Parent article: Device trees I: Are we having fun yet?

Because there's no fixed device tree ABI, and if you ship a DTB in flash there's no guarantee that you'll be able to boot newer kernels. It's actually worse than that, in that vendor kernels and mainline are often ABI-incompatible when it comes to Device Tree, so if a board vendor ships with the SoC vendor kernel you wouldn't be able to boot a mainline kernel.


to post comments

Device trees I: Are we having fun yet?

Posted Nov 14, 2013 21:24 UTC (Thu) by scottwood (guest, #74349) [Link]

Not having a fixed device tree ABI breaks use cases such as a boot loader fixing up portions based on run time information, or a hypervisor using it to tell the guest OS what devices the VM has been configured with, or sharing the tree with other OSes (we do all of these on Freescale PPC, and on some ARM boards the device tree is shared with U-Boot -- not just to pass to the kernel, but for U-Boot to learn about the hardware). A fixed ABI is how it works with actual Open Firmware, and is how ACPI works, etc. Likewise with PCI -- it works because there's a standard, that isn't subject to revision as part of Linux patch acceptance.

Granted, it's harder to standardize things well when the hardware being described is changing so rapidly, but by treating the device tree as a Linux implementation detail rather than an ABI, you take away the incentive to get it (reasonably close to) right the first time. You could still have a separate Linux-internal tree (we already do -- struct device and friends) that encodes Linux concepts and/or fixes quirks in the hardware tree, which is generated from the hardware tree plus quirk code in the kernel, and possibly some supplementary external data file which *is* a Linux implementation detail and not meant for sharing with other components. In extreme cases the "quirk and supplementary external data" could be an entire replacement tree, if the standard one is hopeless for anything other than identifying which replacement tree to use, but most cases should not be that bad.

Moving the hardware tree outside the kernel source would send a clear message that it is not a Linux implementation detail (and thus compatibility between the trees and OSes including but not limited to Linux needs to be considered), and that things which are need to go somewhere else.

Also note that the dts sometimes contains implementation details of the bootloader -- it may make assumptions about how the loader sets up the address map, or it may make assumptions about what things the loader will fill in before passing the tree to the kernel. Both of these are true on Freescale PPC. In those cases ideally the trees would be stored in the bootloader tree.

Device trees I: Are we having fun yet?

Posted Nov 14, 2013 22:14 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (3 responses)

> if a board vendor ships with the SoC vendor kernel you wouldn't be able to boot a mainline kernel.

Sounds like a job for GPL enforcement ;) .

Device trees I: Are we having fun yet?

Posted Nov 14, 2013 22:48 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (2 responses)

Why? GPL doesn't require that you be able to boot the mainline kernel.

Device trees I: Are we having fun yet?

Posted Nov 14, 2013 22:52 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (1 responses)

No, but it can get you the source that you would need to use a custom kernel.

Device trees I: Are we having fun yet?

Posted Nov 15, 2013 0:06 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

Getting the vendor tree typically isn't a problem. Finding a vendor tree that's up to date with security fixes, on the other hand...


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