- feeds
- popular
- recent
- reader
- about
- story
- technologies
- what is rss
- connect
- dmca
- contact
- Feed Preview LWN: Comments on "Device trees as ABI"
Device trees as ABI -- flag the stable ones
I don't know. 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 ...
Device trees as ABI -- flag the stable ones
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 ...
Device trees as ABI -- flag the stable ones
> 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 i...
Device trees as ABI -- flag the stable ones
>> no, all the different drivers do not have to exist. support for all the devices needs to exist > What is the fundamental difference in principle ? If you say that the drivers must exist, ...
Device trees as ABI -- flag the stable ones
> The "plus" for perspective is that it would follow the "LOGIC", a lot of drivers are almost identical... but not quite... Oops... i meant "a lot of *devices* are almost identical"... not *dr...
Device trees as ABI -- flag the stable ones
> no, all the different drivers do not have to exist. support for all the devices needs to exist What is the fundamental difference in principle ? > One way to do this is to do a cut-n-paste...
Device trees as ABI -- flag the stable ones
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...
Device trees as ABI -- flag the stable ones
> 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 no, all the different drivers do not ha...
Device trees as ABI -- flag the stable ones
> 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 ...
Device trees as ABI -- flag the stable ones
> 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, I think this indicates that...
Device trees as ABI
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 perva...
Device trees as ABI -- flag the stable ones
>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. and > If t...
Device trees as ABI -- flag the stable ones
> 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. OK. On TI OMAPs we have...
Device trees as ABI -- flag the stable ones
> In other words, the 4 year old SoC were expected to still be available for another 30 years or so. In all fairness, most SoC vendors have products they designate for long-term availability, ...
Device trees as ABI -- flag the stable ones
> With ARM SoCs, the reference designs I have seen have a shelf life of 2 years At my last work, I was developing a new medical product based on a 4 years old ARM SoC design on a custom PCB. Th...
Device trees as ABI
Systems using OpenFirmware already had device trees for a long time, did they not? So what is the difficulty with the DT ABI here?
Device trees as ABI
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 tha...
Device trees as ABI -- flag the stable ones
> deeply embedded in automotive, industrial control, airplane and military products yes, but there is no expectation of running a vanilla kernel on those, nor a generic linux distro. So as lon...
Device trees as ABI -- flag the stable ones
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 yea...
Device trees as ABI -- flag the stable ones
> > 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. > > I don't understand this fully... ...
Device trees as ABI
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 Fo...
Device trees as ABI
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 manuf...
Device trees as ABI -- flag the stable ones
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 ...
Device trees as ABI -- flag the stable ones
> 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. On a PC the bootl...
Device trees as ABI -- flag the stable ones
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. In the PC world, peo...
Device trees as ABI -- flag the stable ones
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 ker...
Device trees as ABI
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...
Device trees as ABI
Can you elaborate on the benefits of this?
Device trees as ABI -- flag the stable ones
A DT is not meant to describe what is discoverable, so on a PC it could be in the /boot partition.
No kernel upgrade in the embedded world
> 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. And my experience on sm...
Device trees as ABI
> 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...
Device trees as ABI -- flag the stable ones
> we can't take the time to do things right FYI, I use few systems on chip, one has more than 1000-Pin BGA Package with more than 145 multi-functions pins. If one had such reconfigurability i...
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 ...
Device trees as ABI -- flag the stable ones
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. It does mean ...
Device trees as ABI -- flag the stable ones
ARM servers might be using ACPI instead of device trees.
Device trees as ABI -- flag the stable ones
Having seen this up close, I think Jason Gunthorpe's email is spot on (and worth a read of the complete email). Many (most?) ARM SoC creators and the ODMs around them are focused on a quick t...