Comment by Quentincestino
1 year ago
I still cannot understand your problem with Device Trees after reading your article, I used to write a ARMv8 and a x86 kernel and found out that ACPI and Device Trees had same capacities, but less headhaches with DT.
I run NetBSD on several ARMv8 boards. One is ACPI only, all the rest use DeviceTree. Basically impossible to add any extra functionality to the ACPI only one, no problem doing this on the others.
Where do the device trees come from?
You may find https://en.wikipedia.org/wiki/Devicetree
It discusses this, alongside an interesting history of it, and the current state.
It just doesn't mention the actually interesting stuff. Like, take PCI, for example: there is a way [0] to enumerate all the devices, and it also supports PCI-to-PCI bridges. Nice! And I also understand where the information comes from: the introspection. With the device tree the info apparently (judging from the sibling comments) comes from the vendor who baked it into whatever storage and apparently it's static.
[0] https://en.wikipedia.org/wiki/PCI_configuration_space#Bus_en...
The same place ACPI tables come from. A flash chip on the motherboard.
That was the original dream for DT that so far hasn't been very successful.
In practice the kernel only wants to add support for DTs that conform to a reviewed and approved schema, but most/no manufacturer wants to do the effort of having every single thing on their DT schema bikeshedded to death on the device tree mailing list before the device is manufactured. So the vendor just makes up whatever kind of unapproved DT schema that only their own vendor kernel fork supports, and if mainline support is ever added it will have its own DT.
So I can't change the system's composition? Or do the ACPI/DT only show me the controller chips soldered to the motherboard, but not the devices that connected to them?
2 replies →
Usually they are shipped with the Linux kernel rather than mobo flash.
3 replies →
I was expecting to read “… a stork” lol