Comment by ChocolateGod
6 hours ago
Needing the kernel to be changed for each device is an Androidism that encourages ewaste and we should fight against it.
Instead Qualcomm should improve their ACPI implementation and improve the kernels handling of it
> Needing the kernel to be changed for each device is an Androidism
It's an Armish not an Androidism. It's an embedded legacy that really doesn't make sense anymore. But inertia is powerful enough that even Apple is still using device trees, even on their M series SoCs ( https://asahilinux.org/docs/fw/adt/ )
Someone from Qualcomm posted a "DT-ACPI Hybrid Mode" set of patches a while back that let you call ACPI table functions, etc even while booting with the device tree, allowing you to control some things like keyboard lightning/power management independently. That would be a good first step but I'm not sure it went anywhere in the meantime. In theory supporting Device Tree by including the blob in a ROM somewhere shouldn't be much more work (if any) than including working ACPI tables, but we all know how that works out in practice!
> supporting Device Tree by including the blob in a ROM somewhere shouldn't be much more work (if any) than including working ACPI tables, but we all know how that works out in practice!
This is definitely a thing in some embedded systems I’ve used. There are some Marvell boards which do this. They all use U-boot though.
The problem is that the content of the device tree isn't really stable -- if a new kernel version has a driver with a new required parameter for instance, suddenly your ROM device tree is out of date and much less useful.
Oh, that's a good point I forgot about; I suppose DT interfaces aren't considered part of the stability contract for users... Really Device Tree is somewhat "Linux-specific"-enough and low level enough that issues like this aren't ideal. But if we could just get to the point that was a problem, I'd be happier than now, I suspect!
There's no universally good solution for connecting varied kernels with varied hardware. Device tree is okay.
Kernels always have to be changed for different hardware, that's nothing new. x86 kernels don't run on ARM machines, full stop. Gameboy Advance kernels don't run on Switch 2. IBM mainframe kernels don't run on AWS EC2.
As part of good engineering practice we like to separate the parts that are volatile with regard to hardware changes from the parts that are nonvolatile. But that's a kernel implementation detail and we shouldn't pretend it means the combined kernel doesn't need to be changed.
We can also embed several volatile components for several different hardware configurations. That's called inefficiency, or bloat.
There were several attempts for hardware to incorporate the volatile component itself and be self-describing. ACPI (in ROM) is one; device-tree-in-ROM is another. Neither turned out to work well, because it turns out you actually want to evolve that code and so kernels contain lists of ROM patches anyway, which isn't much better than just including whatever was in the ROM to begin with.