On Thu, Jan 4, 2024 at 2:20 PM segaloco via COFF <coff(a)tuhs.org> wrote: We've been there for a while. I've been swimming in these waters for a couple of years now, and it _is_ an issue. That said, I can kind of sympathize with the vendors to an extent; they're between a rock and a hard place in a lot of ways. Starting up a modern CPU (even one in an end-user device like a phone or a laptop) is, I imagine, a bit like starting the engines on a container ship. You don't just press a switch and have massive two-story diesel pistons start firing in enormous cylinders; instead, you push a switch which starts an electric motor which turns on something like a V8 engine, which starts up a larger engine that starts the process of compressing the big pistons so the thing can start; it's a slow, multi-stage process out of physical necessity. Modern CPUs follow a similar process: you apply power to a board and it's going to do all sorts of stuff like power sequencing for DIMM sockets, asking them what's there, whether they're working properly, etc. Then there's turning on thermal sensors, the IO bus, flash, etc. A slew of internal diagnostics are going to run across a number of components. And all of this is happening before you even begin bringing the CPU socket online, let alone allowing the CPUs to come out of reset. And most of this is going to be done with FPGAs or little rinky-dink microcontrollers embedded in various places (an interesting exercise might be trying to count the number of CPUs on a modern mainboard): and that's not even counting the CPUs on IO devices. Most of those aren't just hidden, they're invisible to anyone other than the device manufacturer. Even if I had the documentation and the means to replace the images in those disparate components, it'd be a daunting task from a time/reward perspective. Most of the time, it's just not possible. How did we get here? Well, in part because systems are a lot more complex now than they were in the past, and that has reflected itself back onto software. The reality is that, for most users, even those who care about what software they run, most of this stuff just isn't that _interesting_. We care what runs on the x86 CPU (or whatever) sure, but how many people even _know_ about the little CPU embedded in their USB flash stick? So there's little incentive for the software vendors to put a lot of effort into supporting this stuff, and so it falls on board vendors, who just do what they've got to do to ship a product. I've mentioned the Oxide architecture before: we have no UEFI and we have no BIOS. We also designed our own custom boards. At Oxide, we build a service processor board based on an ARM Cortex-M profile microcontroller that runs its own OS that we built in-house most of the pre-CPU-poweron tasks. And yet, there are still some things that we can't get away from (firmware on peripherals, and the aforementioned PSP). The PSP is an interesting case in point; even if we _wanted_ to bypass it entirely, we can't; it's built into the CPU SoC complex and it's just how the thing works. And we build the computers! Imagine the situation for a user of a commodity COTS system. I think most people just want a computer (or phone, tablet, whatever) at all and the entire system has congealed (again, to use Roscoe's term) around the way that things are now. Even for those of us who don't like it, it's damned hard to change the status quo. - Dan C.