The option rom frequently is required to init the hardware so the OS can view something normal. Modern PC's aren't using 16-bit int services, rather UEFI GOP dr

The option rom frequently is required to init the hardware so the OS can view something normal. Modern PC's aren't using 16-bit int services, rather UEFI GOP drivers sourced from option roms for early display, without which you can't interface with the machine until the OS starts. If you want something like a phone where you can't replace the OS, that is how one goes about it. Even uboot has noticed that standards matter as they slowly transform themselves into yet another UEFI firmware. I have a guruplug too, or rather an openrd, because all the guruplugs died. But that is 1980's PC level of simple HW, and its not SMP, doesn't support virtualization, or any power mgmt to speak of. The list of things it can't do is longer than the list of things you can do with it compared to a modern piece of HW. Modern PC's with ACPI aren't "standardized" outside of a few interfaces being used by the OS, that is my point. All those regulator drivers, clock controllers, pin muxing, I2C'ing, SPI'ing, to manage the platform is whatever the vendor put there in PC land (and arm land for that matter) is still there, only the OS doesn't have to worry about those details because it simply asks to power something on, and it happens, and some other processor takes over picking perf profiles and idling links/etc when needed. If there was a standard PMIC, wired up in a standard way it might make sense to attempt to use it, but there isn't. Instead its a bucket of parts wired up in every way imaginable. ACPI, doesn't dictate what is on the other side, it could be a SMM trap, or it could be a mgmt processor, or a BMC, or the function can be completely written in AML. That is the point, its just an OS API surface, it could just as well be a standardized pile of HW registers but that would remove the ability to run in cases where the vendor wants to save a penny and run everything on the main core as you suggest doing with DT. A large part of why you provide these interfaces is because having the main core waking up to fittle with some 100Khz SPI bus to flash a led is dumb, wastes power, and eats perf doing work that would be better handled with a small mgmt core. Your basic argument seems to be that you don't want the OS wasting cycles in the firmware, but your perfectly ok with the OS wasting even more cycles all the time doing these functions sub optimally in a kernel that doesn't understand the intricacies of power management on the most pwoer hungry core in the system. You seem to think ACPI is always just a SMM trap, and that isn't the case. The reason I conflate is its because in the case where the remote is a BMC/etc your effectively just poking a mailbox to get some other piece of hardware to do the work and those mailbox interfaces are no more standard than PMICs, so now you have thousands of them needed to talk to battery mgmt controllers, power/standby buttons, you name it. Instead of standardizing all that garbage, a software API was created. Its no different from openGL or any other standard except that it uses a bytecoded function call interface (ala openfirmware's forth). Do you hate openGL too because your game isn't fittling fake HW registers? And now that I point out what happens when a vendor just tosses those register maps you want over the wall you change the topic to how they are just creating beta level products while refusing to acknowledge that someone has to do the work. From the perspective of a vendor it costs a tiny fraction to have some closed source firmware that works across dozens of OS's and allows them to redesign their hardware vs hiring experts in a half dozen OSs to write piles of custom power mgmt code accessing dozens of drivers talking on dozens of SPI/I2C/mailbox/etc interfaces for a single machine. Its actually a little bit crazy that people in the arm space are trying this while simultaneously complaining about the HW vendors creating piles of patches that they can't get upstream so they build their own custom linux forks. Its the natural result of making the same claims your making. A vendor can either spend years fighting with kernel maintainers, or they can fork linux and ship it to their customers with a pile of patches that only work in linux. The middle ground is where a number of them have been going, its the rpi's proprietary mailbox interface that talks to the videocore to set the processor frequency. Multiply that mailbox by a few dozen SoC providers and you have the future of DT on arm and risc-v. In a decade or two they will end up standardizing the mailboxs and reinventing ACPI and openfirmware in order to support cross platform mailbox interfaces.