I feel like we're kind of mixing up a bunch of things here, or maybe I am.

The reason you don't need to mess with GRUB or you BIOS when you change your hardware is that modern hardware interfaces have built-in discovery and resource allocation features. Before that you had to deal with pesky low level details like IRQ allocations and the like (which was a thing on PC not that long ago).

That's not really a feature of "PC" per se, it's a feature of USB, PCI etc... That stuff works exactly the same on ARM or anywhere else.

The things that need to be described in the device tree are generally internal components of the SoC and motherboard, things like IO expanders, SPI interfaces, serial interfaces, and of course the USB/PCI/... controllers themselves.

I think there maybe some confusion because of the term "bootloader". It's true that both u-boot and GRUB are bootloaders, but bootloaders in the ARM world have a lot more to do than PC bootloaders, they're effectively the equivalent of UEFI + GRUB, not just GRUB. You can write a simplistic boot sector loader for PC in a few hundred ASM opcodes, that would be a lot more difficult for the average ARM bootloader because there's a lot more to do before you can just call into Linux. In general you won't even have RAM or caches available when u-boot begins executing.

And I think it's actually a better design, because it means that proprietary built-in firmware crap is usually kept to a minimum on ARM: the BOOTROM usually just initializes the bare minimum to be able to load u-boot (or some other loader) into on-chip SRAM and then it's over. Of course that means that the loader is significantly more complex, but that complexity has to be some place or an other.

The practical upshot is: On PC, I can take a single disk with a single GRUB version and boot it on an arbitrary machine. If ARM machines can do that with their own UEFI/ACPI/ServerReady setup, then great. But if I need to alter that disk for each machine I want to use it on (inject board.dtb, add a custom u-boot, whatever), then that's not okay. I would happily accept u-boot and whatever else being on an onboard flash chip that I could update but didn't need to care about otherwise - that would get us back to "your PC boots via a UEFI system that's a whole OS unto itself, but it chainloads GRUB via standard interface so who cares".

We completely agree here. If ARM desktop becomes mainstream there will probably be some kind of abstraction layer needed at this level that doesn't really exist at this moment. I'm fairly optimistic that it will happen when it's really needed though.

Ah, okay, yeah. And honestly, the tech may already exist - I'm a little unclear on whether it's sufficient or not, but ARM UEFI is a thing - but I definitely look forward to seeing things standardize and have boards that actually work like that without extra hacks.

> You can write a simplistic boot sector loader for PC in a few hundred ASM opcodes, that would be a lot more difficult for the average ARM bootloader because there's a lot more to do before you can just call into Linux. In general you won't even have RAM or caches available when u-boot begins executing.

This is exactly the point OP's getting at though, and the exact "discovery" features you handwave away. If I write an OS (or bootloader) on x86 w/ BIOS/uEFI, I can easily query available memory and start using it. Meanwhile u-boot has to be told via an external resource how much RAM is available before it begins initializing. This is fine for embedded/bespoke development (since you'll know the hardware you're developing for and can make assumptions), but a pain for general OS development where you have to inform the bootloader/OS of every devices capabilities.