I think that BSD supported autoconfiguration on the VAX well before
OpenBoot; the OpenBSD man page says it dates from 4.1 (1981) and was
revamped in 4.4.
I can verify that. The PDP-10's had it first, then VMS. During the VMS vs UNIX war at ARPA, when Joy did the FASTVAX work, autoconfig
first appeared. Sam rewrote it with what eventually became 4.2 with his configuration system.
At the point of the vendors like, DEC, DG, HP, then Masscomp, Apollo and Sun all had their own boot systems. For Vaxen that was ok, as the busses were DEC defined, but folks like Xylogics, Emulex and such wanted to sell boards for the Multibus, VME as well as Unibus or proprietary busses. So boot driver were something they had to offer in source, at least to their OEM's [actually Masscomp (Paul Cantrell) wrote Xylogic's reference code for a number of them and licenses them back, which Sun used later as it turns out].
Larry and Rob G can comment on the OpenBoot stuff what was birthed later on as a way to solve some of that problem. IIRC, the SPARC may have been a partial driver for that as offering boot rooms and driver for 68000 or 8086 based boards was not going to be helpful for that market.
SBI was/is an attempt to define a common interface to different
devices using RISC-V CPUs, but it's growing wildly and tending more
towards UEFI+ACPI than something like OpenBoot, which was much
simpler.
UEFI+ACPI got/gets a bad rep because of the original IBM BIOS implementations.
In general, the idea of a BIOS isn't terrible: provide an interface
that decouples the OS and hardware.
Exactly - the idea is actually a good one. But the problem was the BIOS designed/implemented by HW people, but OS folks. Things like concurrency minimum use of the CPU was not in the higher order bits.
But in practice, no one has come
up with a particularly good set of interfaces yet. Ironically,
BSD-style autoconfig might have been the best yet.
??Maybe because it was OS types who knew what the OS needed to discover/report/deliver back from the HW.