LWN: Comments on "Device trees as ABI" https://lwn.net/Articles/561462/ This is a special feed containing comments posted to the individual LWN article titled "Device trees as ABI". en-us Thu, 16 Oct 2025 09:45:17 +0000 Thu, 16 Oct 2025 09:45:17 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net Device trees as ABI -- flag the stable ones https://lwn.net/Articles/563902/ https://lwn.net/Articles/563902/ mmarq <div class="FormattedComment"> I don't know. <br> <p> Its not a question of code but more a question of design philosophy. It would had to be the maintainers of the subsystems addressed that know more (should) than anyone else how things in their side work, to give you an answer. But the philosophy which i think is quite pertinent and true, is that the answer can vary according to the subsystem, this generalist approach may not be the best approach.<br> <p> I'm starting from the principle that a device, can have things different even from devices of the same family, firmware, bus characteristics etc<br> <p> So if we agree in this point which seems to me very logic, and very true, the idea is quite simple, what could be "discrete and unique" goes DKMS like, what could easily be addressed in a generalist way is "in kernel" (modules or other doesn't matter).<br> <p> And in this *logic* (which sometimes is missing from OSS due to politics), this DKMS should be different from subsystem to subsystem. Userland drivers perhaps wouldn't need DKMS anything i think, and it will be for the maintainers to "draw the line in the sand" for the different *long term stable APIs* that would be dynamically exposed by this DKMS, APIs that could have capabilities to restrict to where they "talk/interact" with the kernel, and even how they talk among themselves... that is why i talked of several DKMS not one, more so because different subsystems could have different "lines in the sand".<br> <br> So what would this "new DKMS" dynamically load ?... not sure... but not much more than load the firmware and a low level driver that initializes the devices and exposes the very low configs to the kernel.<br> <p> Would there be worries about locks (and other things) ? ... don't know... i think the maintainers would have the last word, but it would be nice to hear the implementors/vendors/IDMs.<br> <p> And is not about allowing closed sourced blobs in the kernel, matter of fact OSS drivers for a lot of devices could use the "new DKMS" scheme, matter of fact every pertinent device (falling in the category that apply), should use the "new DKMS" either the source is available or not (its about predictability, and the logic of unique vs generalist characteristics)... and if hardened with a safe fall back, this "new DKMS" could be even grand for OSS driver development (and proprietary to), and cherry on top of cake, due to predictability, to reverse engineer if the case comes along.<br> <p> In a "political" view that is what i call allowing some privileges, but take advantage of it lol. <br> </div> Mon, 19 Aug 2013 13:00:28 +0000 Device trees as ABI -- flag the stable ones https://lwn.net/Articles/563777/ https://lwn.net/Articles/563777/ dlang <div class="FormattedComment"> so how exactly is your super DKMS going to figure out that the module now needs to do locking because the code that calls it no longer grabs a lock (a standard thing to happen as locks get more fine-grained)?<br> </div> Sat, 17 Aug 2013 09:59:13 +0000 Device trees as ABI -- flag the stable ones https://lwn.net/Articles/563771/ https://lwn.net/Articles/563771/ mmarq <div class="FormattedComment"> <font class="QuotedText">&gt; DKMS also fails somewhat regularly as the kernel internals change. This is also why the nvidia and ATI proprietary drivers frequently don't work with a new kernel. The changes made elsewhere in the system can frequently break modules, especially ones that are as demanding as the video drivers.</font><br> <p> Yes its a shame...but don't have to be that way.<br> <p> DKMS as it is, is too must encompassing, its not harden (no fail safe fall backs), and it has no security but what the kernel provides( could have capabilities as example). The DKMS i had in mind is much more restricted, much more things that are "generalist" in a POV could be "in the kernel", so the chance of breaking something in the DKMS APIs would be more diminutive, and since it could be officially maintained, those APIs could also be "extended" according to Kernel changes... and most of times without breaking old stuff... i think...<br> <p> Sorry for the too much pragmatic views... but i've always been trained that to better solve a problem is to think outside the problem, not to live with it. <br> </div> Sat, 17 Aug 2013 06:41:44 +0000 Device trees as ABI -- flag the stable ones https://lwn.net/Articles/563444/ https://lwn.net/Articles/563444/ dlang <div class="FormattedComment"> <font class="QuotedText">&gt;&gt; no, all the different drivers do not have to exist. support for all the devices needs to exist</font><br> <p> <font class="QuotedText">&gt; What is the fundamental difference in principle ?</font><br> <p> If you say that the drivers must exist, then the status quo is fine, but if you say support for the devices is what must exist, then there is a lot of room for cleanup in the existing code.<br> <p> <font class="QuotedText">&gt;&gt; The other way is to take the first driver, change the constants to DT parameters (defaulting to the old constants if not defined), and then you don't need yet another driver.</font><br> <p> <font class="QuotedText">&gt; Isnt exactly how is done today ? ... if yes, why doesn't it work ? (meaning maintainers drown in load, implementers complaining etc )</font><br> <p> this is part of the problem today. Far too many of the existing device drivers in ARM (and to be fair, in other embedded architectures) are cut-n-paste jobs when they should be consolidated.<br> <p> Maintainers haven't been pushing back enough. This was one of the items in the discussions that triggered the "the linux-kernel list is not professional" a few weeks ago.<br> <p> <font class="QuotedText">&gt; ...wouldn't be the entire kernel the ABI ?</font><br> <p> <font class="QuotedText">&gt; I think what you say is not possible, is already done by DKMS. Every distro i use, uses DKMS, though is not officially supported(AFAIK).</font><br> <p> DKMS also fails somewhat regularly as the kernel internals change. This is also why the nvidia and ATI proprietary drivers frequently don't work with a new kernel. The changes made elsewhere in the system can frequently break modules, especially ones that are as demanding as the video drivers.<br> <p> Yes, it would be possible to create a module API that would not need to care about some of this stuff, but it would be far more limited in what the module could do and how well it could do it. The kernel developers have opted not to go this route (see the stable ABI nonsense document if you aren't familiar with it)<br> <p> the only time I've seen DKMS actually used is for vmware drivers. The various distros may include it, but I don't see them using it much.<br> <p> DKMS "works (mostly)" pretty well for minor kernel updates (distro kernel patches), but if you try to use it across larger updates, you will see how badly it starts to fail.<br> <p> Just because something is popular, doesn't mean that it's the right thing to do. The situation where lots of people were running nvidia modules, and so suffering kernel crashes and as a side effect running into problems with KDE config file updates disappearing on them a year or so ago is a good example of this.<br> <p> <font class="QuotedText">&gt; The "plus" for perspective is that it would follow the "LOGIC", a lot of (devices) are almost identical... but not quite...</font><br> <p> actually, in the ARM space, this really is the case. A lot of the different drivers are for the exact same thing connected at a different address.<br> <p> This does fall naturally out of the 'normal' embedded development process, where a programmer is assigned to make Linux work on chip/device X, and frequently all the company cares about _is_ making it work on that chip/device. once that chip/device ships, the programmer never expects to deal with it again, so they don't care about upgrading things. For these people, the cunt-n-paste, modify constants approach is just fine.<br> <p> This is part of the oft-repeated claim that "embedded is special, it shouldn't have to follow the rules"<br> <p> However, the Linux-kernel developers have to maintain things over the long run, and many of the larger companies doing embedded development are starting to learn that they really do want to have the support upstream so they don't have to repeat the driver development for the next kernel/project.<br> <p> As ARM is stabilizing, they are working to clean this up, but it's a lot of work, and Device Trees are a very significant part of that cleanup.<br> </div> Thu, 15 Aug 2013 03:25:46 +0000 Device trees as ABI -- flag the stable ones https://lwn.net/Articles/563441/ https://lwn.net/Articles/563441/ mmarq <div class="FormattedComment"> <font class="QuotedText">&gt; The "plus" for perspective is that it would follow the "LOGIC", a lot of drivers are almost identical... but not quite...</font><br> <p> Oops... i meant "a lot of *devices* are almost identical"... not *drivers* ... the sentence above doesn't make sense, drivers should follow the devices, not devices following drivers ( what some Linux aficionados seems to want)<br> <p> And in reality there can be quite a lot of differences even for devices implemented around the same processing element (NIC, sound, graphics, storage etc)<br> </div> Thu, 15 Aug 2013 02:52:07 +0000 Device trees as ABI -- flag the stable ones https://lwn.net/Articles/563438/ https://lwn.net/Articles/563438/ mmarq <div class="FormattedComment"> <font class="QuotedText">&gt; no, all the different drivers do not have to exist. support for all the devices needs to exist</font><br> <p> What is the fundamental difference in principle ?<br> <p> <font class="QuotedText">&gt; One way to do this is to do a cut-n-paste of an existing driver, change some constants and create a new driver.</font><br> <p> <font class="QuotedText">&gt; The other way is to take the first driver, change the constants to DT parameters (defaulting to the old constants if not defined), and then you don't need yet another driver.</font><br> <p> Isnt exactly how is done today ? ... if yes, why doesn't it work ? (meaning maintainers drown in load, implementers complaining etc )<br> <p> <font class="QuotedText">&gt; arguing that there should be a stable ABI isn't going to get you anywhere. It's not something that can be implemented on a per-driver or per-subsystem basis because part of the ABI the driver would need is the kernel locking rules, power management interfaces, and other things that affect the entire kernel.</font><br> <p> After all it was a "piss off" your earlier post lol <br> <p> I don't want to go anywhere, i'm not an implementer. But if that is true wouldn't be the entire kernel the ABI ? lol and there wouldn't be possible to device other ABIs without starting from scratch. I don't think that is the case.<br> <p> I think what you say is not possible, is already done by DKMS. Every distro i use, uses DKMS, though is not officially supported(AFAIK).<br> <p> I think the basic is NOT a question of code but more a question of perspective. You dared to mention the "free candy" of upstream "free maintenance" and why complain... i dare to mention the "corporative interest" in keeping everything in house (so to speak), even when everything in house comes very short in lot of aspects and why these complains.<br> <p> Employing logic, what i said is, if DMKS works, and it does otherwise no distro would use it, why not improve that tremendously, harden it, not one but several DKMSs... i mean, it could have some rules different according the subsystems addressed, it could use Dbus, it could use capabilities for safety... etc.. the genius of programing wouldn't take long advancing several innovative mechanisms, inclusive interacting with DTs in a way that would ease maintenance by a great deal...<br> <p> The "plus" for perspective is that it would follow the "LOGIC", a lot of drivers are almost identical... but not quite... what is identical will be kernel, what could vary, is a low level "module" that could be dynamically loaded (like DKMS), and that could be in binary form (as happens with DKMS), and is more logic and sane because the "not quite" means every device could/should/must have its own low level module, and it would be good even for the all OSS drivers IMHO.<br> <p> Is this an ABI ? ... is this a long (put long in this, only change if no other choice) stable API ? ( a bit like kernel 3.10 prespective lol) <br> </div> Thu, 15 Aug 2013 02:34:23 +0000 Device trees as ABI -- flag the stable ones https://lwn.net/Articles/563330/ https://lwn.net/Articles/563330/ broonie <div class="FormattedComment"> That's the theory - in practice what's happened is that in order to get to the point where there is enough DT support in the kernel to allow anything to actually boot people have just been using DT as a replacement for board files (which are embedded in the kernel). Now that platforms are able to run usefully from DT only that is changing which is what the discussion is about.<br> </div> Wed, 14 Aug 2013 11:20:58 +0000 Device trees as ABI -- flag the stable ones https://lwn.net/Articles/563198/ https://lwn.net/Articles/563198/ dlang <div class="FormattedComment"> <font class="QuotedText">&gt; I think that is exactly the problem that must be made to work, there are too many drivers that are almost identical ... "almost"... but all are needed</font><br> <p> no, all the different drivers do not have to exist. support for all the devices needs to exist<br> <p> One way to do this is to do a cut-n-paste of an existing driver, change some constants and create a new driver.<br> <p> The other way is to take the first driver, change the constants to DT parameters (defaulting to the old constants if not defined), and then you don't need yet another driver.<br> <p> arguing that there should be a stable ABI isn't going to get you anywhere. It's not something that can be implemented on a per-driver or per-subsystem basis because part of the ABI the driver would need is the kernel locking rules, power management interfaces, and other things that affect the entire kernel.<br> <p> </div> Mon, 12 Aug 2013 21:21:31 +0000 Device trees as ABI -- flag the stable ones https://lwn.net/Articles/563065/ https://lwn.net/Articles/563065/ mmarq <div class="FormattedComment"> <font class="QuotedText">&gt; What they should be doing instead is making the Device Tree say "this is device of type X at address Y" so that the kernel source can eliminate all the tables of hardware and drivers that are almost, but not quite identical.</font><br> <p> I think that is exactly the problem that must be made to work, there are too many drivers that are almost identical ... "almost"... but all are needed<br> <p> <font class="QuotedText">&gt; Watching for duplicates, and pushing back on such submissions, telling the submitters that they need to use/update the generic versions is a painful task, both for the maintainers pushing back and the people submitting the updates.</font><br> <p> I think "they" state "generic" wont fit the bill... AFAI understand... otherwise i don't think no one dared to purpose a low level kernel ABI, after so many years when the slightest mention of that have been enough for an immediate a total incineration of the offender.<br> <p> OTOH i think they are more than happy to maintain all that bindings and drivers crowd outside of kernel, as long as the interfaces are long duration and stable.<br> <p> Let them have what they want, but take advantage of it... AFAI understand (not a developer) those "bindings" can be embedded into drivers, so **negotiate** subsystem to subsystem ( not one ABI but several) the wrapper/shims (whatever) binary interfaces exposed, but harden it, use capabilities. Those blobs could be dynamically loaded(trace parallels with DKMS), a "specific" binding, "specific" firmware and more generalist low level "gluing" driver could be a module for a new advanced DKMS system ( ? possible ? crazy ?), and a SOC could have many of those from the same device tree (as i understand). <br> <p> I think this could be a very good think, more *robust*, more supportive, more portable, more crossplatform, more flexible, more *maintainable*, even to all OSS drivers ( don't have to carry hundreds of drivers code around only to use a few thens of them for each system)... at least follows the "hardware logic", SOCs, boards, platforms, can be varied inside the same family..."almost identical"... yet those minimal differences can be critical for full support and or stability ( and half backed drivers is what linux has to spare). <br> </div> Mon, 12 Aug 2013 10:49:21 +0000 Device trees as ABI -- flag the stable ones https://lwn.net/Articles/563047/ https://lwn.net/Articles/563047/ dlang <div class="FormattedComment"> <font class="QuotedText">&gt; and so instead of DT buried in firmware blobs, it could provide much more, well defined interfaces and behavior that could be "negotiated" subsystem to subsystem,</font><br> <p> I think this indicates that one of us isn't understanding what Device Trees are.<br> <p> Device Trees are not a bunch of things embedded into drivers or in binary blobs.<br> <p> Device Trees are a description of the hardware that the bootloader hands to the kernel at boot time. Drivers then look at parts of the Device Tree to find the constants that they need to configure hardware (to know that it's there to be configured, and usually configuration information)<br> <p> One problem is that some people are putting all their config info in the driver, then using the Device Tree to say "create device ABC", this isn't any better than the OOXML spec saying "manage dates like Excel version X did"<br> <p> this approach means that the drivers have to be updates for every variation of the device, and every different address the device lives at.<br> <p> What they should be doing instead is making the Device Tree say "this is device of type X at address Y" so that the kernel source can eliminate all the tables of hardware and drivers that are almost, but not quite identical.<br> <p> Watching for duplicates, and pushing back on such submissions, telling the submitters that they need to use/update the generic versions is a painful task, both for the maintainers pushing back and the people submitting the updates.<br> <p> But trying to cry that "we are embedded, we can't take the time to follow the process" isn't going to win sympathy<br> </div> Mon, 12 Aug 2013 04:59:19 +0000 Device trees as ABI https://lwn.net/Articles/563038/ https://lwn.net/Articles/563038/ mmarq <div class="FormattedComment"> 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...<br> <p> 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.<br> </div> Mon, 12 Aug 2013 02:18:33 +0000 Device trees as ABI -- flag the stable ones https://lwn.net/Articles/563029/ https://lwn.net/Articles/563029/ mmarq <div class="FormattedComment"> <font class="QuotedText">&gt;The problem is that the cry of "we're embedded, we can't take the time to do things right, we just need to ship product" has been heard far too many times on far too many topics.</font><br> <p> and<br> <p> <font class="QuotedText">&gt; If they want to do their own thing, they can keep their stuff out of the kernel and maintain it on their own forever. But they are (slowly) learning that they don't like the results of that, so they want their work to be in the upstream kernel to save them effort in the future, part of the deal to get things into the upstream kernel is that they are done in a way that allows them to be maintained reasonably, which means that it's no longer a free for all.</font><br> <p> Congratulations for the daring... but both parts are contradictory.<br> <p> Wasn't there a previous thread were the maintainer said he was drowning in load ? ... i don't think "they" want to be babysit and enjoy some free candy...<br> <p> If you care to listen the "cries" then you have to provide a solution... out of kernel, like an ABI, is exactly what has been purposed, and so that "maintain it forever" sounds more like "piss off" than "lets find a cure".<br> <p> Why can't DT interfaces be dynamic some way like with low DKMS drivers ?<br> <p> It could be hardened providing a very well knowned safe fall-back for gross errors, it could use "capabilities" so that a DT blob don't go pocking around where it shouldn't... and bolbs already most of the firmware are...<br> <p> This would kill 2 birds with one stroke... low level dynamic drivers, yes _more_that_simple_DT_interfaces... and so instead of DT buried in firmware blobs, it could provide much more, well defined interfaces and behavior that could be "negotiated" subsystem to subsystem, and OTOH if a vendor wants more in the future then it would be forced to go into kernel development, that is, instead of getting free candy we will be forced to offer some.<br> <p> At least sounds better than "piss off"... hey! it could be even be great as example for open source graphic drivers to use the low level binary kernel drivers that **without exclusion are now loaded via DKMS**... well defined interfaces would provide hints for possible reverse engineering if must...<br> <p> In the end "they" don't need and shouldn't be babysit, at least at this low level, there isn't the factor of upstream "free" maintenance, there should be that presumption, the contrary a ask for help, simply because any software without hardware is completely pointless(at this levels). <br> <p> </div> Mon, 12 Aug 2013 01:33:02 +0000 Device trees as ABI -- flag the stable ones https://lwn.net/Articles/561931/ https://lwn.net/Articles/561931/ rvfh <div class="FormattedComment"> <font class="QuotedText">&gt; Once U-boot can access DDR ram and FLASH, it has basically finished its job and just loads two files in memory (linux kernel and DT) without looking at their content.</font><br> <p> OK. On TI OMAPs we have U-Boot/SPL initialising the DDR ans SD card, so U-Boot is directly loaded into it (and the DT could be too.) To some extent, this means the DT info is partly duplicated into U-Boot/SPL.<br> <p> <font class="QuotedText">&gt; In the embedded world there is no well-know addresses, but there is no place to store such a database neither.</font><br> <p> Yes, and anyway, there is not necessary a way to determine the board type (and thus choose the correct DT), so the board type is likely hard-coded into the boot loader.<br> <p> But that's OK to me: it's the SoC case. It remains IMO that in the PC case a DT can be in the /boot partition because we can get there thanks to BIOS/standards/...<br> </div> Fri, 02 Aug 2013 08:58:46 +0000 Device trees as ABI -- flag the stable ones https://lwn.net/Articles/561823/ https://lwn.net/Articles/561823/ pizza <div class="FormattedComment"> <font class="QuotedText">&gt; In other words, the 4 year old SoC were expected to still be available for another 30 years or so.</font><br> <p> In all fairness, most SoC vendors have products they designate for long-term availability, though that usually translates to the 10-year lifespan automotive components require.<br> <p> But in my experience, far too often management chooses an SoC simply because it's cheap, not realizing it's only cheap because it is almost End-of-Lifed. Having to source components on the grey market to fulfill unexpected orders is not a fun undertaking.<br> <p> (Another approach I've seen is to order a massive quantity of the critical parts at the outset of the production run, enough to cover the total projected lifecycle, at the outset. This can get expensive, but does hedge you when you have a relatively low-volume but long-lived product.<br> </div> Thu, 01 Aug 2013 18:36:10 +0000 Device trees as ABI -- flag the stable ones https://lwn.net/Articles/561798/ https://lwn.net/Articles/561798/ Jonno <div class="FormattedComment"> <font class="QuotedText">&gt; With ARM SoCs, the reference designs I have seen have a shelf life of 2 years</font><br> At my last work, I was developing a new medical product based on a 4 years old ARM SoC design on a custom PCB. The product was intended to be manufactured using the same ARM SoC for 10 to 15 years after we were done, with each manufactured product having a lifespan (with support and component replacement) for 15-20 years. In other words, the 4 year old SoC were expected to still be available for another 30 years or so.<br> <p> Most of us engineers figured it would break down by 2038, seeing how arm32 uses a 32 bit time_t, but there was no telling management that ;-).<br> <p> <font class="QuotedText">&gt; yes, but there is no expectation of running a vanilla kernel on those</font><br> We were using a mainline 2.6.39 kernel with a few vendor-supplied 2.6.37-based drivers we forward-ported ourselves.<br> </div> Thu, 01 Aug 2013 16:23:32 +0000 Device trees as ABI https://lwn.net/Articles/561750/ https://lwn.net/Articles/561750/ jengelh <div class="FormattedComment"> Systems using OpenFirmware already had device trees for a long time, did they not? So what is the difficulty with the DT ABI here?<br> </div> Thu, 01 Aug 2013 12:50:14 +0000 Device trees as ABI https://lwn.net/Articles/561735/ https://lwn.net/Articles/561735/ t.figa <div class="FormattedComment"> I would like to clarify one little thing. My words might have been misunderstood a bit, as I did not advocate for DT instability. Instead I just showed two possible extreme DT usage examples that we should consider and proposed creating a process that would be something in the middle, trying to get the best of both extreme worlds (i.e. separate stable and staging bindings).<br> </div> Thu, 01 Aug 2013 11:26:30 +0000 Device trees as ABI -- flag the stable ones https://lwn.net/Articles/561667/ https://lwn.net/Articles/561667/ martin.langhoff <div class="FormattedComment"> <font class="QuotedText">&gt; deeply embedded in automotive, industrial control, airplane and military products</font><br> <p> yes, but there is no expectation of running a vanilla kernel on those, nor a generic linux distro. So as long as the ODM kept the relevant kernel tree around, and someone can grok it, they can support it.<br> <p> <font class="QuotedText">&gt; reference designs is a third class of devices - these have a mid-length lifecycle of </font><br> <font class="QuotedText">&gt; some 5-10 years, and are used as a base for mobile handsets and tablets</font><br> <p> With ARM SoCs, the reference designs I have seen have a shelf life of 2 years, and essentially have to survive in a crowded market. So some die an early death, some dominate a given generation (and perhaps get... 4 years life?). <br> <p> The cost/benefit isn't there, even for reference designs, if we think about getting to "stable DT". An unstable (but reasonably well done) DT in their own kernel trees is probably OK. But the benefit is more marginal, or at least looks marginal at implementation time.<br> </div> Wed, 31 Jul 2013 19:41:27 +0000 Device trees as ABI -- flag the stable ones https://lwn.net/Articles/561625/ https://lwn.net/Articles/561625/ jgg <div class="FormattedComment"> There will never be a fast way to get a binding defined. Since it is considered an ABI everything gets bike-shedded to death. People have been working on bindings now for Kirkwood for over a year, and it still isn't fully in mainline. :(<br> </div> Wed, 31 Jul 2013 16:49:52 +0000 Device trees as ABI -- flag the stable ones https://lwn.net/Articles/561587/ https://lwn.net/Articles/561587/ etienne <div class="FormattedComment"> <font class="QuotedText">&gt; &gt; Remember that if something is wrong on a PC, you can always count on the BIOS to get to the point you can fix things - not so on an ARM embedded board.</font><br> &gt;<br> <font class="QuotedText">&gt; I don't understand this fully... The BIOS is a pre-bootloader program as you find in the ROM code of your SoC, no?</font><br> <p> On that SOC, you have a very small ROM which can do DHCP/TFTP boot when the FLASH is blank, but that is a recovery system only.<br> A standard boot (i.e. cold reset vector) brings you to U-boot without any other layer, U-boot has to initialise itself the external DDR ram; you have no other software whatsoever.<br> If you are using the new NOR FLASH (bigger size for lower price), only the first few sectors of that FLASH are present in the address space; you also need to have a driver to read the other sectors.<br> <p> So U-boot runs in a very restricted environment, and cannot access the DT which is stored in FLASH before initialising both DDR ram and FLASH.<br> So the constants to initialise the DDR ram and the FLASH are not really needed in the DT.<br> Once U-boot can access DDR ram and FLASH, it has basically finished its job and just loads two files in memory (linux kernel and DT) without looking at their content.<br> <p> <font class="QuotedText">&gt; I don't understand that, sorry. How can a new device 'appear'?</font><br> <p> I was more talking of a DT on a PC, but even on embedded you have chips upgraded during production without software change, or external USB connectors where newer devices can be connected and not auto-probed.<br> In short you cannot store the DT in real ROM, you may have to update it.<br> <p> <font class="QuotedText">&gt; Sorry if I am missing your point, which I am sure is valid.</font><br> <p> For instance, in the PC world the PCI interface is at well-known I/O address 0xCF8; that is compiled as a constant into every ia32/amd64 Linux kernel. There is no point to write that address into a DT located on a hard disk because the hard disk cannot be discovered before the PCI address.<br> In the embedded world there is no well-know addresses, but there is no place to store such a database neither.<br> </div> Wed, 31 Jul 2013 16:33:39 +0000 Device trees as ABI https://lwn.net/Articles/561594/ https://lwn.net/Articles/561594/ raven667 <div class="FormattedComment"> 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.<br> </div> Wed, 31 Jul 2013 16:05:53 +0000 Device trees as ABI https://lwn.net/Articles/561591/ https://lwn.net/Articles/561591/ raven667 <div class="FormattedComment"> 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.<br> </div> Wed, 31 Jul 2013 15:58:48 +0000 Device trees as ABI -- flag the stable ones https://lwn.net/Articles/561586/ https://lwn.net/Articles/561586/ raven667 <div class="FormattedComment"> I'm not an expert in this area but isn't the DT something that should be burned into the board when it is manufactured, at that time all those multi-function pins will be connected to something and that needs to be described so that the firmware and bootloader can start, enough to get the kernel loaded and for the kernel to find all the hardware. The PC world has the same problems but they are/were solved by multi-vendor conventions and standards and by building auto-discoverabilty into the hardware at every possible level.<br> <p> So parts that can be auto-discovered later don't need to be described in a burned-in data structure but parts that are needed for low-level boot strapping do need to be described and initialized by burned-in code. That's not really different than the PC world, is it? It seems that this discussion of device tree is really working around a discussion of having some sort of firmware standard for ARM, like BIOS and uEFI and ACPI and whatnot in the PC world, so that the hardware is self-sufficient enough to be able to load a kernel in a standard way such that a standard kernel image could be created.<br> </div> Wed, 31 Jul 2013 15:53:01 +0000 Device trees as ABI -- flag the stable ones https://lwn.net/Articles/561583/ https://lwn.net/Articles/561583/ rvfh <div class="FormattedComment"> <font class="QuotedText">&gt; So you assume that there is only one Hard Disk with one /boot partition (with a known partition scheme and known filesystem) and containing one DT with a discoverable name.</font><br> <p> On a PC the bootloader knows where to load the kernel and initrd from. If it needs a DT then all it needs is store that info too. And yes the BIOS does the init before the kernel re-discovers everything (but I am sure you know all that!)<br> <p> <font class="QuotedText">&gt; In the PC world, people would say: try everything you can think of to find that DT, and yes by specification a hard disk can take 31 seconds to appear - the process might take time.</font><br> <p> See reply below, if I understand what you are saying correctly...<br> <p> <font class="QuotedText">&gt; In embedded world, people would say: the list of non-volatile memory devices is not known, define it in the DT; the priority of those devices is not known, in the DT; the partition scheme (MBR, GPT, BSD disk slices,...) is not known, in the DT; the filesystem of /boot is not known, in the DT; the filename of the DT is not known, write it in the DT...</font><br> <p> And again the bootloader is what knows where the DT is, so it can<br> - use it<br> - pass it to the kernel<br> <p> <font class="QuotedText">&gt; Remember that if something is wrong on a PC, you can always count on the BIOS to get to the point you can fix things - not so on an ARM embedded board.</font><br> <p> I don't understand this fully... The BIOS is a pre-bootloader program as you find in the ROM code of your SoC, no?<br> <p> <font class="QuotedText">&gt; Also, if a new device (new name) appears and is 100% compatible with an old one, you have to modify the DT to add a "compatible = "new_device_name";" line - so you have to be able to update the DT.</font><br> <p> I don't understand that, sorry. How can a new device 'appear'? Embedded systems tend not to evolve, which I think is the definition of embedded, compare to a PC to which you can change/add/remove core components such as CPU/GPU/memory/storage...<br> <p> Sorry if I am missing your point, which I am sure is valid.<br> </div> Wed, 31 Jul 2013 15:26:27 +0000 Device trees as ABI -- flag the stable ones https://lwn.net/Articles/561577/ https://lwn.net/Articles/561577/ etienne <div class="FormattedComment"> So you assume that there is only one Hard Disk with one /boot partition (with a known partition scheme and known filesystem) and containing one DT with a discoverable name.<br> In the PC world, people would say: try everything you can think of to find that DT, and yes by specification a hard disk can take 31 seconds to appear - the process might take time.<br> In embedded world, people would say: the list of non-volatile memory devices is not known, define it in the DT; the priority of those devices is not known, in the DT; the partition scheme (MBR, GPT, BSD disk slices,...) is not known, in the DT; the filesystem of /boot is not known, in the DT; the filename of the DT is not known, write it in the DT...<br> <p> Remember that if something is wrong on a PC, you can always count on the BIOS to get to the point you can fix things - not so on an ARM embedded board.<br> <p> Also, if a new device (new name) appears and is 100% compatible with an old one, you have to modify the DT to add a "compatible = "new_device_name";" line - so you have to be able to update the DT.<br> </div> Wed, 31 Jul 2013 15:10:51 +0000 Device trees as ABI -- flag the stable ones https://lwn.net/Articles/561575/ https://lwn.net/Articles/561575/ linusw <div class="FormattedComment"> It's a bit of both/and I would say - mobile handset and tablet chipsets has this quick turn-around feature. Many of these kernel trees and potential device trees are not even in the upstream kernel.<br> <p> Then there is a class of embedded chipsets that are deeply embedded in automotive, industrial control, airplane and military products with a support cycle of 20+ years. Here is Atmel AT91 and some MIPS products. For these, the support cycle is always longer than you think, even if you take into accoun that the support cycle is longer than you think.<br> <p> Reference designs is a third class of devices - these have a mid-length lifecycle of some 5-10 years, and are used as a base for mobile handsets and tablets among other stuff.<br> </div> Wed, 31 Jul 2013 14:12:14 +0000 Device trees as ABI https://lwn.net/Articles/561573/ https://lwn.net/Articles/561573/ mbizon <div class="FormattedComment"> It was/is already possible to boot a single kernel image for multiple boards, you don't need DT for this.<br> <p> 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.<br> <p> 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.<br> <p> </div> Wed, 31 Jul 2013 13:28:06 +0000 Device trees as ABI https://lwn.net/Articles/561572/ https://lwn.net/Articles/561572/ karim <div class="FormattedComment"> Can you elaborate on the benefits of this?<br> </div> Wed, 31 Jul 2013 13:13:12 +0000 Device trees as ABI -- flag the stable ones https://lwn.net/Articles/561567/ https://lwn.net/Articles/561567/ rvfh <div class="FormattedComment"> A DT is not meant to describe what is discoverable, so on a PC it could be in the /boot partition.<br> </div> Wed, 31 Jul 2013 12:50:44 +0000 No kernel upgrade in the embedded world https://lwn.net/Articles/561566/ https://lwn.net/Articles/561566/ rvfh <div class="FormattedComment"> <font class="QuotedText">&gt; Many (most?) ARM SoC creators and the ODMs around them are focused on a quick turnaround, short production runs and not easily hackable nor easily upgradable devices.</font><br> <p> And my experience on smartphones (I suppose applies to a lot of embedded devices too) is that even when you get an Android upgrade, you keep the same kernel version, as nobody wants to forward-port all the hacks they managed to make work to a newer kernel.<br> </div> Wed, 31 Jul 2013 12:47:54 +0000 Device trees as ABI https://lwn.net/Articles/561565/ https://lwn.net/Articles/561565/ pizza <div class="FormattedComment"> <font class="QuotedText">&gt; Some missing context for me: why was it decided to move from board files to device tree?</font><br> <p> 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.<br> <p> </div> Wed, 31 Jul 2013 12:43:42 +0000 Device trees as ABI -- flag the stable ones https://lwn.net/Articles/561550/ https://lwn.net/Articles/561550/ etienne <div class="FormattedComment"> <font class="QuotedText">&gt; we can't take the time to do things right</font><br> <p> FYI, I use few systems on chip, one has more than 1000-Pin BGA Package with more than 145 multi-functions pins.<br> If one had such reconfigurability in the PC world, I think one would have the same problem on PC.<br> Also, the PC world has a BIOS in FLASH hiding a lot of details of the boot process, and a secondary storage (hard disk) storing all interesting data.<br> Where would you put a device tree if you had one on PC: in the FLASH BIOS or the hard disk?<br> If you put the DT in the FLASH BIOS, costumer will complain that they cannot edit it, and you will get a lot of costumer support calls/returns.<br> If you put it on the hard disk, describing the disk subsystem, disk partitions (and device tree location) inside the device tree is not really good design.<br> Embedded world do not have two storage area (FLASH BIOS + HD), and the boot-loader has to handle everything from the reset vector (initialising external memory from limited SOC internal memory, initialising NOR FLASH before being able to read it, recovery and tests from command line...).<br> The boot process will need constants to progress, some of them before a device tree can be read. It is not really good design to put in the device tree constants which may be different to the value which has been used.<br> <p> Now, do you need a device tree on PC, to describe:<br> - if you want EFI BIOS or regular BIOS<br> - EFI password and keys<br> - partition table format (MBR/GPT/BSD)<br> - partition tables themselves<br> - location and IRQ of serial/parallel ports<br> - USB keyboard and mouse<br> - keyboard language layout and user language<br> - ....<br> and please ask windows and BSD to support that device tree.<br> </div> Wed, 31 Jul 2013 11:48:32 +0000 Device trees as ABI https://lwn.net/Articles/561557/ https://lwn.net/Articles/561557/ nelljerram <div class="FormattedComment"> Some missing context for me: why was it decided to move from board files to device tree?<br> <p> 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?<br> <p> </div> Wed, 31 Jul 2013 11:28:29 +0000 Device trees as ABI -- flag the stable ones https://lwn.net/Articles/561534/ https://lwn.net/Articles/561534/ dlang <div class="FormattedComment"> The problem is that the cry of "we're embedded, we can't take the time to do things right, we just need to ship product" has been heard far too many times on far too many topics.<br> <p> It does mean that there needs to be a fast way to get bindings defined, but it doesn't meant that the current free-for-all is the right thing to have happen.<br> <p> If they want to do their own thing, they can keep their stuff out of the kernel and maintain it on their own forever. But they are (slowly) learning that they don't like the results of that, so they want their work to be in the upstream kernel to save them effort in the future, part of the deal to get things into the upstream kernel is that they are done in a way that allows them to be maintained reasonably, which means that it's no longer a free for all.<br> </div> Wed, 31 Jul 2013 06:39:50 +0000 Device trees as ABI -- flag the stable ones https://lwn.net/Articles/561530/ https://lwn.net/Articles/561530/ pbonzini <div class="FormattedComment"> ARM servers might be using ACPI instead of device trees.<br> </div> Wed, 31 Jul 2013 05:19:03 +0000 Device trees as ABI -- flag the stable ones https://lwn.net/Articles/561514/ https://lwn.net/Articles/561514/ martin.langhoff <div class="FormattedComment"> Having seen this up close, I think Jason Gunthorpe's email is spot on (and worth a read of the complete email). <br> <p> Many (most?) ARM SoC creators and the ODMs around them are focused on a quick turnaround, short production runs and not easily hackable nor easily upgradable devices. For them, there is no point in investing in getting the DT Just Right on the hardware side, nor the DT "ABI" on the driver side. <br> <p> The short production runs and limited hackability fragment and limit the "community" side. This is unfortunate but true even in the absence of DRM.<br> <p> On the other hand, there is a handful of ODMs and OEMs building ARM servers. It seems likely that they will want to invest on a stable DT ABI for the relevant drivers, so they bake a DT into their server kit, land drivers promptly and as pay off future Linux releases will Just Work (modulo bugs, as usual).<br> <p> Oh, and perhaps someone takes up the mantle TI left behind in terms of good Linux support upstream. Perhaps a smart SoC maker can define a good DT early enough for their hw that it's useful for their ODMs.<br> </div> Wed, 31 Jul 2013 01:42:44 +0000