[wolfgke]

> RISC-V, save us!

You presented evidence that hardware vendors write awful firmware code - why will these people write decent firmware as soon as RISC-V comes, i.e. what evidence do you have that we won't have the "accepted" behaviour of having RISC-V and bad firmware?

[wtallis]

The point is that RISC-V will be documented; you don't need to blindly accept whatever firmware is bundled, because it's possible to write alternative firmware. This is actually the case for a lot of embedded processors and SoCs too, but it doesn't do as much good their because even when things are sufficiently documented they're still not actually standardized. Given the opportunity, projects like coreboot and OpenWRT produce great results.

[Sanddancer]

The problem there is that x86 is well-documented too. Painfully so in a lot of cases. Overly so in some. You can get, with a few clicks, the documentation, including pinouts, register settings, etc for any processor Intel has, the chipset, peripheral controllers, pretty much everything. The biggest thing you can't get documentation for is the $10 thunderbolt controller some boards have, for asinine reasons. The problem more is the companies that make the boards farm out the coding to the lowest common denominator, so all that gory documentation goes to waste all too often. RISC-V isn't going to save us from crappy motherboards, unfortunately.

[zanny]

I like to hope and pray that since RISC-V was found on the principles of royalty free open instruction sets and blueprints that anyone who sockets the architecture might follow through.

A lot of the problems with x86 motherboard vendors is probably that they legally cannot disclose a lot of the internal documentation and code handed them from Intel, because Intel uses some of it as a trade secret against ARM / AMD.

[Sanddancer]

Intel gives a fuckton of information to any and everyone, they submit code to the TianoCore project, they pretty much bend over backward to say, "here, take this, make your stuff not suck." The UEFI forum's pretty similar in access to tools and specifications. This all comes down to a race to the bottom for coders because software's a liability to a lot of the companies developing hardware, even if things are handed to them pretty much on a silver platter.

Poke around Intel's firmware developer center http://firmware.intel.com/develop . There's pretty much everything there you need to make a firmware that isn't terrible, but companies will find a way to provide one anyway.

[wtallis]

I'm not seeing where firmware.intel.com has any documentation for stuff that's lower-level than EFI modules and drivers. They've got a Firmware Support Package that "provides a binary package to initialize the processor, memory controller, and Intel chipset initialization functions", but only for some mobile and embedded platforms. Otherwise, they seem to just refer you to Phoenix, AMI, and friends so you can license their buggy stuff to build a custom GUI for. There's really not much benefit to the community in making it possible to build better EFI modules if you've got no way to integrate them into a usable replacement firmware for your existing hardware.

[LeifCarrotson]

The real problem is that SoCs are SoCs, not Cs. The peripherals (networking, graphics, disk interface, etc.) don't necessarily need to be open on a RISC-V processor.

[userbinator]

This is also true with ARM, which is why I doubt RISC-V is a solution to the problem of bad firmware and/or lack of SoC documentation. ARM is "open" in the sense that the CPU architecture is publicly documented --- you just can't legally implement the CPU without licensing it from ARM.

FYI the pre-Pentium subset of x86 has been public-domain and free of patents for a long time, and I believe several more Pentium-level patents are going to expire soon, so in that sense a lot of the basic x86 instruction set is more open than ARM. No doubt if RISC-V becomes popular there will be plenty of proprietary extensions to it too.