I sorta disagree with the premise of that talk, although the problem is real.
Its just that even that talk vastly underestimated just how many microcontrollers exist on a modern machine.
In the past those controllers were isolated to a few areas (disk controllers, higher end network cards), but the drive over the past decade+ for more efficient devices and "universal" packetized buses (ex PCIe, USB), has sprinkled them in places simply to monitor utilization and adjust bus clocks, as well as packet scheduling and error/retry logic, etc, etc, etc. I was reading about some of the latest m.2 NVMe controllers a while back and IIRC there were something like a half dozen independent Arm's just inside the controller. The last fully open disk stack on a PC was probably an MFM/RLL controller in the mid 1980's.
So, while I would love if the manufacture of every little USB device or whatever published the full register documentation, firmware listings, whatever, that ship has long sailed. The worst part isn't looking for the piles of scattered SPI flash eeproms on random boards, its the integrated "Secure" sides of these devices which happen to be all but invisible. None of that is going to be documented anytime in the near future. Every single one of these companies hides their "secret sauce" in the firmware of these devices, be that how to minimize latency on a NVMe device, to how to get maximum throughput on a wifi chip, to how to increase a DRAM controllers power efficiency. In some of these cases, the firmware probably isn't even that special, they are doing basically the same thing as every one of their competitors, but you will never get them to admit it.
So, imagining that an "OS" can control this mess like a 1960's mainframe is nonsense. Modern mainframes don't even control stuff at that level anymore.
So like software abstractions, we have hardware abstractions which provide higher level constructs for low level software to talk to. Be that something like XHCI where the system talks to generic endpoint queues and a processor does all the low level packet building/scheduling or its something like the tiny integrated cores making decisions about which parts of a CPUs clock and power domains need to be dynamically enabled/disabled for a given perf/power profile and the OS talks to generic firmware interfaces to set policies. To even LBA disk layouts which abstract away all the details of flash channels, COW, wear leveling, NAND error correction, bit pattern sensing, page/block erase sizes, etc.
In the end, if someone wanted to actually work on this problem, the first step towards open hardware isn't really building a RISC-V system, its building competitive NIC's, keyboards, USB controllers, etc, etc, etc with open hardware designs. What we have today is like linux, everyone wants to work on the kernel, no one wants to maintain old crufty code in Make. So, in the end swapping an x86 for a RISC-V doesn't give you more open hardware if its still got its own management processors tied to the same closed hardware IP for literally everything else in the machine.
I agree that having an integrated OS control every random co-processor in a machine would be undesirable, and that hardware abstractions are a good thing.
But co-processors that can break OS' assumptions (regarding security, for example) sound like they should be under OS control. Not that this means under control of a single kernel but, at least, under control of some set of components that are developed together.
"the first step towards open hardware isn't really building a RISC-V system, its building competitive NIC's, keyboards, USB controllers, etc, etc, etc with open hardware designs"
Actually it's building the software tools to emulate these, USB is a dense standard, you will have more luck emulating a working USB device first pass before building out the supporting infrastructure.
Once you can emulate/design your open chip computer, then you can start doing test runs/production runs. The market for such a thing will be limited to engineers and tech enthusiasts, at least until some hardware tech startup starts outcompeting the other players on the market.
Its just that even that talk vastly underestimated just how many microcontrollers exist on a modern machine.
In the past those controllers were isolated to a few areas (disk controllers, higher end network cards), but the drive over the past decade+ for more efficient devices and "universal" packetized buses (ex PCIe, USB), has sprinkled them in places simply to monitor utilization and adjust bus clocks, as well as packet scheduling and error/retry logic, etc, etc, etc. I was reading about some of the latest m.2 NVMe controllers a while back and IIRC there were something like a half dozen independent Arm's just inside the controller. The last fully open disk stack on a PC was probably an MFM/RLL controller in the mid 1980's.
So, while I would love if the manufacture of every little USB device or whatever published the full register documentation, firmware listings, whatever, that ship has long sailed. The worst part isn't looking for the piles of scattered SPI flash eeproms on random boards, its the integrated "Secure" sides of these devices which happen to be all but invisible. None of that is going to be documented anytime in the near future. Every single one of these companies hides their "secret sauce" in the firmware of these devices, be that how to minimize latency on a NVMe device, to how to get maximum throughput on a wifi chip, to how to increase a DRAM controllers power efficiency. In some of these cases, the firmware probably isn't even that special, they are doing basically the same thing as every one of their competitors, but you will never get them to admit it.
So, imagining that an "OS" can control this mess like a 1960's mainframe is nonsense. Modern mainframes don't even control stuff at that level anymore.
So like software abstractions, we have hardware abstractions which provide higher level constructs for low level software to talk to. Be that something like XHCI where the system talks to generic endpoint queues and a processor does all the low level packet building/scheduling or its something like the tiny integrated cores making decisions about which parts of a CPUs clock and power domains need to be dynamically enabled/disabled for a given perf/power profile and the OS talks to generic firmware interfaces to set policies. To even LBA disk layouts which abstract away all the details of flash channels, COW, wear leveling, NAND error correction, bit pattern sensing, page/block erase sizes, etc.
In the end, if someone wanted to actually work on this problem, the first step towards open hardware isn't really building a RISC-V system, its building competitive NIC's, keyboards, USB controllers, etc, etc, etc with open hardware designs. What we have today is like linux, everyone wants to work on the kernel, no one wants to maintain old crufty code in Make. So, in the end swapping an x86 for a RISC-V doesn't give you more open hardware if its still got its own management processors tied to the same closed hardware IP for literally everything else in the machine.