4 ms·
I think device tree, as opposed to something that can enumerate whatever hardware is present, is part of the reason that you have separate ROMs for every single
by nfriedly 3y ago
I think device tree, as opposed to something that can enumerate whatever hardware is present, is part of the reason that you have separate ROMs for every single Android phone. (Whereas a single Linux ISO can run on just about any PC out there.)
- temac 3y agoThe DT is actually there to avoid recompiling the kernel for each specific device. But probably tons of vendor do not understand the purpose.
- londons_explore 3y agoIt's definitely only part of the reason. If it were the only reason, it would be easy enough for a 'unified' ROM to contain config/devicetrees for a few thousand models of phone, and auto-select which one to use at boot time depending, for example, on a commandline flag.
- tremon 3y agoThat's not the reason. Have you seen the size of the average kernel that can boot on just about any PC out there? It's 10MB kernel code and easily 100MB initramfs, depending on how many video card firmwares you intend to support. And that's on a relatively "standardized" PC platform, with generic ACPI/PCIe/SATA device abstractions in the hardware. ARM has none of that: no standardized platform, no device discovery through bus enumeration, no standard VESA graphics implementation. Device tree is a consequence of the non-standardization of ARM devices, not the cause. You could easily have the devicetree in the phone's ROM (just like ACPI, but without the executable code vector) and have the kernel read that data on startup. But you would need a kernel of at least the same size as the PC kernel+initramfs; and unlike on PC's, on phones people still (somewhat) care about code size and performance.