RISC-V Hardware So Far Isn't Entirely Open-Source | Hacker News Reader

RISC-V Hardware So Far Isn't Entirely Open-Source

phoronix.com

80 pointspjmlp25 comments

The RISC-V CPU cores are open source. The other stuff on the chip is the same proprietary IP you find on any other silicon. The example given in the article is the DRAM controller, which they probably bought from the foundry.

I don't really see this as a ding against HiFive, per se. They only have so many engineer minutes to spend, and making a whole chip is hard. Someone needs to sit down and generate open source DRAM[1] and clock/PLLs and power gating frameworks and GPIO and ADC/DAC and I2C and SPI and flash[2] and USB and...

These guys are great and they make great products. We just need more. This is like writing an article in 1985 about how GNU isn't "really" open source because all this RMS guy has is an editor and a compiler.

[1] Which really means the analog signaling end, not the "controller" interface which is pretty simple.

[2] Particularly hard, given that the cell dimensions themselves are usually foundry trade secrets.

It is inevitable that the first sentence will itself become false. As things go forward the ISA will be open source but the cores themselves will cease to be.

That's not the way it happened in software. As free implementations come to dominate it's the proprietary products that tend to wither. The existence of ANSI C89 as an open standard didn't result in an explosion of proprietary yet compatible compilers, instead GCC ate the world within a decade.

I mean, sure. You can make a closed-off RISC-V. But I don't see why that's required or "inevitable".

GCC is licensed under the GPL, RISC-V chose a license that allows for proprietary modifications. Inevitable might be taking things too far, but it's certainly within the realm of possibilities and thanks to the license always will be.

Why? There are many different organisations including universities companies and so on that want to use the open cores and many of them either develop new stuff fully open or partly open.

Also, the chips can be both, you can have open source implementations and close source implementations and when you are building a chip you have to make the choices just as in software.

Since the other stuff on the chip is the main obstacle to running open source software like Linux, Coreboot, u-boot or even your own OS on typical ARM SoCs, this means that these RISC-V chips aren't actually an improvement in this area. Having to reverse-engineer the proprietary, undocumented DRAM controller is basically the same as bringing up (say) one of Allwinner's much cheaper SoCs. (Except Allwinner released the DRAM init code as open source a few years back, so I don't think you even have to do that for most of their SoCs these days.)

As it currently stands, I think the $10 quad-core ARM board based around a set top box chip currently sitting on my desk is running a more open software stack than anything available for SiFive's $1000 board. (To be fair, the SiFive board does have sixteen times the RAM.)

Of course not. RISC-V is open instruction set, not open microarchitecture.

There will be some totally open RISC-V microarchitectures, but they are not competitive with commercial ones. Maybe some verified and intentonally very simple designs for security applications.

I would like to be proven wrong, so if there is some IC experts who can explain the business case where someone invests $300-$500M to develop new top notch open source microarchitecture (patent free?) every 5-10 years that can compete with Intel, AMD and others, I would like to see it.

That's not the openness this article talks about

My point is that entirely open source has never been viable option outside some very limited uses. Coreboot is just different corner of "Not entirely open source".

It (sort of) is. The issue is that SiFive bought some proprietary DDR IP, because DDR RAM is really complex to control. The DDR IP comes with proprietary software to configure it and that can't be redistributed. (Apparently there is a table of constants that are programmed into the hardware which is Super Secret! - as if no one can use a disassembler)

Make all the hardware and software bits needed to control DDR RAM under a free license and loads of people will be very happy to use it.

(BTW I'm now interested in how the Talos board initializes its DDR RAM)

IBM seems to be all in on this "OpenPower" concept.

https://github.com/open-power/docs/blob/master/hostboot/Host...

So it seems like the Power8 initialization process is simply open source, thanks to IBM.

Have IBM released open DRAM initialization hardware, and if so under what precise license and where's the Verilog for it? As far as I know, OpenPOWER hardware is not open source in anything like the same way as RISC-V's Rocket and BOOM cores.

adding money to the considerations in the heavy-handed way (above) is a common rhetorical way to close discussion on the topic as if there is no other 'realistic' option.

> I would like to be proven wrong, so if there is some IC experts who can explain the business case where someone invests $300-$500M to develop new top notch open source microarchitecture (patent free?) every 5-10 years that can compete with Intel, AMD and others, I would like to see it.

To develop an open-motherboard marketplace where code can be shared openly between motherboard designers. Or maybe even "daughterboard" features.

You know, like OpenPower / Power9. Where additional boot-level capabilities (ie: OpenBMC) are open source and standardized and documented.

https://openpowerfoundation.org/presentations/openbmc-a-refe...

-------------

A practical use of this, is to have the BMCs of servers report status (IE: power, temperature, etc. etc.) in a secure, open, and extendable way. BMCs also have the ability to act as a remote terminal, such as a serial-over-ethernet port. These sorts of features have security concerns that Open Source / openly-vetted code would at least make some people feel better.

We're talking about a component that has the ability to remotely reboot, remotely attach keyboards / mice, and virtual terminals at the hardware level. So yeah, security is pretty important.

------------------

Consider this article as why people want Coreboot / Open Source boots: https://www.raptorengineering.com/coreboot/kgpe-d16-bmc-port...

If you can't trust the bootup procedure of your computer, then you can't trust the computer at all!

All of what you describe are not done, or guaranteed, by RISC-V. RISC-V only refers to the CPU cores, the same way Arm refers to the CPUs as well.

Actually, Arm cores don't force any kind of proprietary board architectures or binary blobs in order to be manufactured and shipped. Why do people expect that this will change with RISC-V?

And that's all this article is bringing attention to.

Some people care about open-source, and they care quite strongly. I'm not necessarily part of open-boot or coreboot... but I at least understand their sentiment.

For these OSS advocates, they really believe in controlling the full computer with fully open source hardware. They feel like calling RISC-V an "Open Source" core dillutes the term.

At the end of the day, its just a blogpost on a popular OSS benchmarking website dedicated to the server market. RISC-V doesn't serve their purposes (yet), so that's all they're writing about.

99% of the Phoronix content is about Linux Benchmarks btw. So its not like they publish these internet politics issues too often.

RISC-V is just an ISA but the foundation and all the people who have bought in have given some political power and dynamism into the movement that it didn't have before.

Just the amount of people meeting and starting to work together on some of these issue makes RISC-V valuable.

Its adoption in research will also lead to some nice stuff (and already has).

So I agree with your core point but we when talking about RISC-V we should think about it more broadly.

Intel and AMD already provide most of the necessary code to motherboard manufacturers. Why would a motherboard manufacturer want to share their code with their competitors?

It really depends on your business. If you are a foundry, it makes a lot of sense to commoditize everything that's complementary (the chip design, for instance) to your business (making the wafers, cutting, testing, encapsulating). Much like a lot of chip makers provide free reference designs you can use.

You're going to need a lot more than half a billion dollars and 5 years to create processors that can compete with the single thread cost/performance of Intel or AMD chips. I don't believe that's what people who are getting into the RISC-V game are necessarily aiming for anyway.

Well, I love the promise of RISC-V but let's not delude ourselves. Some of the potential for RISC-V is to allow manufacturers to extend the ISAs with their own features. Some of those are bound to include undisclosed instruction sets. So it should come as no surprise that beyond that, SoC designers will likely be bound by their suppliers to keep some bits secret.

This doesn't seem to be about instruction sets so much as it's about the boot process; in particular, the first stage boot loader.

Quote from linked email: "A high-level list of tasks that FSBL performs is in the manual[1]:

   • Switch core frequency to 1 GHz (or 500 MHz if TLCLKSEL =1) by
     configuring and running off the on-chip PLL
   • Configure DDR PLL, PHY, and controller
   • Set GEM GXL TX PLL to 125 MHz and reset it
   • If there is an external PHY, reset it
   • Download BBL from a partition with GUID type
     2E54B353-1271-4842-806F-E436D6AF69851
   • Scan the OTP for the chip serial number
   • Copy the embedded DTB to DDR, filling in FSBL version, memory
     size, and MAC address
   • Enable 15 of the 16 L2 ways (this removes almost all of the L2
     LIM memory)
   • Jump to DDR memory (0x8000_0000)

The manual can be found by googling for that GUID. https://static.dev.sifive.com/FU540-C000-v1.0.pdf

I think the demand for "open source" hardware needs to accept that, because there are fundamental physical limitations on software freedoms 2 and 3 (https://www.gnu.org/philosophy/free-sw.en.html), the market for open hardware is going to behave differently. We can certainly keep asking for more openness, but perfect openness will probably not be acheivable.

I'm inclined to be more optimistic. Compared to how much Free/Open hardware progress has been made in the last couple years with RISC-V, getting a pure FOSS boot loader sounds like a cakewalk, no?

Its quite a bit more complicated than "bootloader" might make it sound. From the mailing list:

"The original boot chain on the SiFive FU540 looks like this:

  MSEL (ROM0) -> ZSBL (ROM1) -> FSBL (SPI) -> bbl (SPI/SD) -> Linux

Where the individual pieces mean this:

MSEL: The "Mode select" ROM, consisting of a register that represents the state of four pins on the chip, and six instructions, which jump to the selected boot device or ZSBL. Fully documented (with an instruction listing) in the manual.

ZSBL: The "Zeroth stage bootloader", several kilobytes of code in ROM, which parses a GPT header on SPI flash or an SD card and loads the next stage. Short, high-level documentation in the manual; I haven't seen the source code.

FSBL: The "First stage bootloader", where interesting things like RAM init happen. High-level documentation in the manual; I haven't seen the source code.

BBL: The "Berkeley bootloader". Its most important role, as far as I understand it, is to implement the SBI. The source code is public.

See also chapter 6 (Boot process) of the FU540-C000 Manual[4].

With the unfinished coreboot port, I want it to look like this (although a lot of work has to be done on coreboot first, and I'm currently not actively working on that, for a few months):

  MSEL (ROM0) -> ZSBL (ROM1) -> coreboot (+bbl?) -> Linux,  or
  MSEL (ROM0) -> coreboot (+bbl?) -> Linux

ZSBL can be skipped, so you don't need to run closed source ROM code, at least as far as the hardware is concerned.

(And note that this is just the situation on this particular SoC. Other SoCs from SiFive or other vendors may boot differently.)"

Anyone who's interested in learning about how RISC-V works via open source should check out the Bitwise project. It's a series of coding streams building a RISC-V based computer from scratch on an FPGA, all open source. https://github.com/pervognsen/bitwise/

Reply on news.ycombinator.com