The separate device tree (#3) is not as big an issue as the first ones. If you are making a Linux kernel for an ARM device, you will have to make a device tree, and it should not change once written.
That’s true, it’s less of an issue than the others, but it’s still a per-device difference that the kernel needs to know about before you bring the system online. If you’re trying to make an installer that’ll run on any ARM device like those on x86, that’s a problem - how does the installation image know what device tree to use?
The device tree is part of the solution, not part of the problem. The reason PCs are able to handle this is that the really gnarly stuff (pincfg, gpios, I2C, SPI, random power management), is handled by per board tables in ACPI, and device tree handles the same niche.
The problem is that the device trees are half assed since they run against a hacked up kernel, not that they exist in the first place.
Ah, interesting. I think I have some reading to do; there clearly are multiplatform images out there now (Debian for example https://wiki.debian.org/DebianKernel/ARMMP) so my understanding of the situation was somewhat mistaken.
If I remember when I did it for the Novena, you had to include that specific dtb file for the install. That does make it a pain, as you are correct, the installation image is board/chip specific