Devicetree makes this better but not 100% as simple as the old "legacy" PC boot sequence was. Ironically these days PCs are quite hard to boot too with UEFI.
Here's what I think would help: (warning: lots of work!)
1. Large database of free peripherals and foundational blocks. Not just UARTs and SATA controllers, but also network interconnects (crossbar), SDRAM controllers, and all the other bits that go into a modern System-On-Chip (SoC). Power management is a huge pain in general, and is widely different among chip families even from the same vendor.
1.A. Obviously, the above implies a decent set of open-source drivers for multiple operating systems for the peripherals. At the very least, you need support for a bootloader, a real-time OS, and Linux. Preferably with no binary blobs.
2. A standard for enumeration of these on-chip peripherals. There should be a way to query the chip itself to see what is included in the SoC, what device addresses they have, what options are enabled (like how many interrupts), and how the peripheral lines (if any) are connected (IO mapping).
3. Some widely-accepted standard for storing the board configuration as well. This could just be a I2C EEPROM, but it has to have a listing of everything connected to the SoC and how. This I2C is mapped to these pins, and has this accelerometer connected at this I2C address. And all the hardware manufacturers (who produce the boards) have to be convinced this is a good idea to have this extra cost (and space) built into their products.
Only after all that would you have a fighting chance to boot a relatively generic kernel and have it actually run. And then have a fighting chance to have the ability for the end-user to upgrade the software after the manufacturer has ceased support.
The cross-platform situation with PCs is light-years ahead of where we are in the embedded space.
And then there's clock configuration, which is kind of a mess, because everything is hooked up differently on different SoCs that I've seen.
It would also be nice if vendors always shipped up-to-date device tree source files for any board they ship.
But the calculation of when it's safe to power down any of the power domains can be very complicated -- you can't turn off a power supply unless everything that depends on it is unused, so there's a subtle and board-dependent graph/dependency problem to solve.
There's a lot going on in a modern (or even one from 10 years ago) SoC with regards to power management. Just the processor cores themselves can run at different voltages and frequencies, and these are tied to the software workload.
And then you've got the big / little stuff from ARM now, which is an asymmetric multiprocessor, and which cores you use depends on the workload.
At how it works and the interface to it changes from vendor to vendor, sometimes from chip to chip. So it usually isn't implemented all that well, nor is it maintained for very long either.
If (big if) we had more standardized interfaces to this functionality, we could use common drivers that can be upgraded independently.
Like I said, the desktop people may not realize how easy they've got it, where most things are accessed via a standardized bus interface (PCIe or USB). There's no virtuous cycle of software and interface re-use, like there is in desktop land.
Let's hope RISC-V can avoid something stunningly complex like ACPI while they are at it. You might be trying to write a secure OS of well reviewed code, then suddenly find that to reliably shut down a PC you need ACPI which drags in 100000 lines of code including an interpreter capable of accessing arbitrary physical addresses. (Or you just try all the shutdown mechanisms you've ever heard of and hope one of them nails the machine you are running on.)
I wonder if hardware is easy enough now that a platform could require that all optional hardware respond with a UUID during an enumeration phase. That would have been a burden back in early ISA days when things were as simple as a couple registers on a card, but maybe now it isn't. Then the OS can handle the ones it knows about and leave the rest alone.
Should it really be up to every hardware block to support full introspection?
Doesn't that start to turn into PnPIsA?
The eeprom solution starts to sound a lot like how Dimms are identified and configured.
I suspect it’s such a hidden part of the whole process of using a computer that few repercussions are felt. Since not enough negative PR value, it changes but slowly. Though it sure does suck for portability.
We should be able to write gpio chip drivers for the actual hardware which the interpreter normally targets and eventually eliminate ACPI from our systems.
Not only hidden, but mostly does its job these days, and has been ignored by everyone so they can get on to writing "Uber but with ML".
There's a shocking amount of stuff like that, made decades ago and still there just because... well, it's still working.
Some of the Hackintosh folks know how much this can be false. As soon as you step out of real mode / VESA graphics, all bets are off, those ACPI tables can be a real PITA, and you may have to fix stuff by extracting, editing and recompiling your SSDT/DSDT, at which point you generally wonder how the stock ones worked at all in the first place: missing symbols, broken CPU state tables... (well, deep inside you know, Windows/Linux are doing a hell of a job doing their best at working around all that mess)
That makes me deeply sad.
OpenPOWER apparently does something similar, i.e. a minimal firmware that loads a Linux kernel + simple userspace from flash.
Leaving aside the issue of user-replacable signing keys if some kind of measured boot system is in use, and availability of documentation so you can replace the firmware if you want, which isn't really UEFI's fault, there's other issues with UEFI as well. Such as:
- Why does it take 8 minutes to boot a UEFI server vs. 17 seconds with NERF? Minnich's opinion is that it's the braindead way UEFI initializes stuff. E.g. if thingy A needs thingy B, it will initialize thingy B regardless of whether it has already been initialized, etc.. Leading to a combinatorial explosion. Whereas Linux builds a dependency tree and initializes each thing only once, in the correct order.
- UEFI option ROM's apparently mostly contain x86-64 code and not UEFI byte code. Some clever guys at SUSE had managed to work around that on aarch64 by using qemu to run the option ROM's, and since the x86-64 and aarch64 data structure layouts are more or less the same (endianness, alignment etc.) they could share the memory space. I mean, it's an awesomely clever hack, but do we really want a Frankenstein thing like this be the bright future we're striving for?
- UEFI is amazingly complicated. Say if you want to load the kernel over HTTPS, you need a TCP stack, HTTP, TLS etc. Sure, Linux is also complicated, but I'm sure Linux is 1000x more battle tested than the UEFI stack. And, if you're going to run Linux anyway, you're not increasing the attack surface by running Linux as your firmware & boot loader. And, if you're using booting Linux from the rom flash, you can use Linux native drivers to access the NIC, storage, USB, whatever and don't need the kind of hacks mentioned above on non-x86.
Sure, using Linux as firmware & boot loader might be politically untenable to some proprietary OS vendors. But so what? Let them solve their own problems!