
RISC-V Hardware So Far Isn't Entirely Open-Source - pjmlp
https://www.phoronix.com/scan.php?page=news_item&px=RISC-V-Not-All-Open-Yet
======
ajross
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.

~~~
foobiekr
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.

~~~
ajross
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".

~~~
flukus
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.

------
Nokinside
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.

~~~
dragontamer
> 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...](https://openpowerfoundation.org/presentations/openbmc-a-reference-
firmware-stack/)

\-------------

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...](https://www.raptorengineering.com/coreboot/kgpe-d16-bmc-port-
offer.php)

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

~~~
sweden
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?

~~~
dragontamer
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.

------
wyldfire
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.

~~~
pjc50
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](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](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.

~~~
MaxBarraclough
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?

~~~
ac29
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.)"

------
modeless
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/](https://github.com/pervognsen/bitwise/)

