Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Tuesday June 26 2018, @03:49AM   Printer-friendly [Skip to comment(s)]
from the not-there-yet dept.

Spotted over on Phoronix:

While free software/hardware advocates have been ecstatic about the RISC-V open-source, royalty-free processor architecture, hardware so far hasn't been as open as desired.

While this processor ISA is entirely open and living up to its merits, it turns out the RISC-V implementations so far haven't been quite as open as one would have thought. A Phoronix reader pointed out to us some remarks by developers on the main RISC-V development board out so far, the SiFive HiFive Unleashed

Ron Minnich who has run the Coreboot project for more than the past decade and spearheads the effort of getting Coreboot on new Chrome OS devices at Google, commented on the Unleashed development board this weekend:

All this said, note that the HiFive is no more open, today, than your average ARM SOC; and it is much less open than, e.g., Power. I realize there was a lot of hope in the early days that RISC-V implied "openness" but as we can see that is not so. There's blobs in HiFive.

Open instruction sets do not necessarily result in open implementations. An open implementation of RISC-V will require a commitment on the part of a company to opening it up at all levels, not just the instruction set.

The issue stems from the use of third party IP used to complete the SoC as Risc-V is an instruction set, not a physical hardware design. The actual silicon of the CPU must be designed in order to implement the instruction set as actual hardware and glue logic to tie the CPU to other hardware like memory and bus controllers. In the case, the HiFive Unleashed features a DRAM controller from Cadence which uses a proprietary binary blob to initialize the DRAM controller. This makes open firmware implementations legally difficult.


Original Submission

Related Stories

Intel May Attempt to Acquire SiFive for $2 Billion 8 comments

Intel (INTC) Reportedly Offers Over $2 Billion To Acquire the Fabless Semiconductor SiFive as the Consolidation Trend in the Industry Is Nowhere Close to Slowing Down

[According] to Bloomberg, Intel has reportedly offered over $2 billion to acquire the fabless semiconductor SiFive, a provider of commercial RISC-V processor IP and silicon solutions based on the RISC-V instruction set architecture.

Should this deal become a reality, it would mark the climax of growing bonhomie between Intel and SiFive. For instance, back in 2018, Intel was one of the participants in the Series C funding round of SiFive. Thereafter, in March 2021, SiFive announced a collaboration with the Intel Foundry Business (IFB) to develop innovative new RISC-V computing platforms.

Of course, unlike legacy Instruction Set Architectures (ISAs), RISC-V's proponents believe that it addresses the skyrocketing cost of designing and manufacturing increasingly complex new chip architectures, given that that the ISA is layered, extensible, and flexible. It is hardly surprising, therefore, that some believe RISC-V to be the future.

Bear in mind that SiFive was last valued at $500 million, as per the data available at PitchBook. This means that Intel would be paying a premium of over 300 percent relative to SiFive's 2020 valuation.

Previously: SiFive HiFive Unleashed Not as Open as Previously Thought
Qualcomm Invests in RISC-V Startup SiFive
SiFive Announces a RISC-V Core With an Out-of-Order Microarchitecture
GlobalFoundries and SiFive Partner on High Bandwidth Memory (HBM2E)
SiFive to Debut a RISC-V PC for Developers in October
SiFive Announces HiFive Unmatched Mini-ITX Motherboard for RISC-V PCs


Original Submission

SiFive to Debut a RISC-V PC for Developers in October 9 comments

SiFive to Debut RISC-V PC for Developers based on Freedom U740 next-gen SoC

In recent years, people have discussed the need to have Arm-based PCs or workstations for developers to work directly on the target hardware, and there are now several options including SynQuacer E-Series 24-Core Arm PC, Ampere eMAG 64bit Arm Workstation, and HoneyComb LX2K 16-core Arm Workstation.

Now it appears we'll soon get something similar for RISC-V architecture with SiFive to debut the first RISC-V PC for developers at the Linley Fall Processor Conference 2020 taking place on October 20-22 and October 27-29. The PC will be powered by Freedom U740 next-generation RISC-V processor that will also be introduced at the event.

We have very few details about this point in time, but the company points the SiFive Freedom U740 (FU740) SoC will enable professional developers to create RISC-V applications from bare-metal to Linux-based. The processor is said to combines[sic] a heterogeneous mix+match core complex with modern PC expansion capabilities, which probably means PCIe, SATA etc.., and the company will provide tools to ease professional software development.

Freedom U740 details are unknown, but Freedom U540 is a quad-core CPU that was used in the HiFive Unleashed single-board computer.

Related: SiFive Introduces RISC-V Linux-Capable Multicore Processor
SiFive HiFive Unleashed Not as Open as Previously Thought
SiFive Announces a RISC-V Core With an Out-of-Order Microarchitecture
GlobalFoundries and SiFive Partner on High Bandwidth Memory (HBM2E)


Original Submission

Qualcomm Invests in RISC-V Startup SiFive 4 comments

Qualcomm Invests in RISC-V Startup SiFive

Investors are zeroing in on the open standard RISC-V instruction set architecture and the processor intellectual property being developed by a batch of high-flying chip startups.

Last fall, Esperanto Technologies announced a $58 million funding round. The chip IP vendor is incorporating more than 1,000 RISC-V cores onto a single 7-nm chip. Data storage specialist Western Digital is an early investor in Esperanto, Mountain View, Calif.

This week, another RISC-V startup, SiFive, announced a $65.4 million funding round that included new investor Qualcomm Ventures. SiFive, San Mateo, Calif., has so far raised more than $125 million, and is seen as a challenger to chip IP leader Arm.

Observers note that wireless modem leader Qualcomm is among Arm's biggest customers, making its investment in SiFive intriguing. Also participating in the Series D round were existing investors Chengwei Capital of Shanghai along with Sutter Hill Ventures and Spark Capital. Intel Capital and Western Digital also were early investors.

Also at EE Times.

See also: SiFive Acquires USB 2.0 and 3.x IP Portfolio to Strengthen RISC-V SoCs

Previously: RISC-V Projects to Collaborate
SiFive and UltraSoC Partner to Accelerate RISC-V Development Through DesignShare
SiFive Introduces RISC-V Linux-Capable Multicore Processor
SiFive HiFive Unleashed Not as Open as Previously Thought
Linux Foundation and RISC-V Proponents Launch CHIPS Alliance

Separately, a handful of RISC-V proponents launched the CHIPS Alliance, a project of the Linux Foundation to develop a broad set of open-source IP blocks and tools for the instruction set architecture. Initial members include Esperanto, Google, SiFive, and Western Digital. CHIPS stands for Common Hardware for Interfaces, Processors, and Systems.

Esperanto Technologies and SiFive look like the names to watch.

Related: First Open Source RISC-V Implementations Become Available
Western Digital Unveils RISC-V Controller Design
Raspberry Pi Foundation Announces RISC-V Foundation Membership
Western Digital Publishes RISC-V "SweRV" Core Design Under Apache 2.0 License


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 0) by Anonymous Coward on Tuesday June 26 2018, @04:30AM

    by Anonymous Coward on Tuesday June 26 2018, @04:30AM (#698599)

    "Womp, womp."

  • (Score: 0, Flamebait) by MichaelDavidCrawford on Tuesday June 26 2018, @05:03AM (4 children)

    by MichaelDavidCrawford (2339) Subscriber Badge <mdcrawford@gmail.com> on Tuesday June 26 2018, @05:03AM (#698606) Homepage Journal

    You say that like it's a bad thing.

    --
    Yes I Have No Bananas. [gofundme.com]
    • (Score: 4, Insightful) by stormwyrm on Tuesday June 26 2018, @06:04AM (3 children)

      by stormwyrm (717) Subscriber Badge on Tuesday June 26 2018, @06:04AM (#698611) Journal

      It *is* a bad thing. It means one more thing that can't be easily audited for correctness and security independently: one more place for bugs and security loopholes to hide. It means one more thing that can't be changed easily or safely. One more thing that we can't study and learn from that anyone who wishes to to can improve on. If you don't see these as bad things, you must have a great deal more confidence and trust in the makers of proprietary systems than they deserve [gnu.org], from how they have so abused their position.

      --
      Numquam ponenda est pluralitas sine necessitate.
      • (Score: 5, Insightful) by ledow on Tuesday June 26 2018, @07:23AM (2 children)

        by ledow (5567) on Tuesday June 26 2018, @07:23AM (#698631) Homepage

        A proprietary binary blob interacting with the DRAM controller and putting it into an unknown state basically completely compromises any guarantees of memory isolation whatsoever. While you're sitting there worrying about Rowhammer, and process separation, that blob is able to act upon commands to bypass any and all restrictions the DRAM controller might have, and read the entirety of memory.

        "Only in theory", sure, but that's when you find out things like "3DFX drivers on Windows installed as admin and then allowed arbitrary DMA to any memory location whatsoever without permission", "This poorly-initialised chip in this model of machine allows full memory access and, thus, complete kernel compromise", "Attackers can use your firmware to gain privileged access through an undocumented opcode", "this TPM compromise came about using a third-party support chip with an insecure firmware", and so on. This is how that stuff gets into things like Intel's lights-off firmwares and things... and stays there until every chip on the market is vulnerable. Because nobody can see it, nobody can check it, nobody can verify it does what it claims, and nobody can patch it if it goes wrong (the manufacturer could put out an updated firmware, but only on their schedule).

        When processors themselves are allowing compromise of all the virtual machine guarantees, memory protection guarantees, prediction branch security, etc. then the last thing you need is yet-another-chip running yet-another-blob that you have no idea what it's doing.

  • (Score: 3, Insightful) by maxwell demon on Tuesday June 26 2018, @05:11AM (3 children)

    by maxwell demon (1608) on Tuesday June 26 2018, @05:11AM (#698609) Journal

    which uses a proprietary binary blob

    As opposed to non-binary blobs?

    --
    The Tao of math: The numbers you can count are not the real numbers.
    • (Score: 0) by Anonymous Coward on Tuesday June 26 2018, @05:13PM (1 child)

      by Anonymous Coward on Tuesday June 26 2018, @05:13PM (#698851)

      Yes, there really are only two choices here.

      • (Score: 2) by maxwell demon on Tuesday June 26 2018, @05:17PM

        by maxwell demon (1608) on Tuesday June 26 2018, @05:17PM (#698853) Journal

        So what is a non-binary binary large object?

        --
        The Tao of math: The numbers you can count are not the real numbers.
    • (Score: 1) by Sabriel on Thursday June 28 2018, @03:51AM

      by Sabriel (6522) on Thursday June 28 2018, @03:51AM (#699641)

      Depends on what definition you're using for blob.

      In the sense of "a module of code that performs a task", you could also have (for example) a proprietary pascal blob. While still legally encumbered, it would be considerably easier to audit.

  • (Score: 2, Disagree) by qzm on Tuesday June 26 2018, @05:23AM (2 children)

    by qzm (3260) on Tuesday June 26 2018, @05:23AM (#698610)

    Talk about a clickbaiting article.

    RISC-V is open, which means anyone is free to implement it, THAT is the point of it.

    What is being complained about here has NOTHING WHAT SO EVER tyo do with the openness of RISC-V, and smells more of someone trying to create some political pressure to get what they want.

    Their issue is actually with the system peripherals implemented on a SOC (system on a chip) next to the core, and THOSE are not RISC-V.
    Now, that is a common problem, that GPUs, memory interfaces, external busses, etc may not be as open as the CPU next to them, but ffs, that has NOTHING to do with RISC-V being open.
    It is like claiming the Linux kernel is not open because a particular distribution contains some binaries without source (not even in the kernel)..

    Still, decent journalism, decent technical reporting, and critical thinking all seems to have sailed past quite some time ago, so why not.

    • (Score: 5, Insightful) by ledow on Tuesday June 26 2018, @07:31AM

      by ledow (5567) on Tuesday June 26 2018, @07:31AM (#698635) Homepage

      These people are piggy-backing on an "open" project and then closing it.

      This is not "RISC-V is closed". This is "these people are closing it for their own purposes / laziness", and people need to be aware of that.

      If something appears in a shop with RISC-V on it, and people have been taught to associate RISC-V with "open", that's not going to end well when the binary blob contains a root-level compromise that nobody can see / fix until it's too late, is it?

      Also, there's no point having an open architecture if even a handful of the actual, physical examples you can realistically buy are not open. It just defeats the entire point.

      That's not to say they've done anything illegal, it just leaves a sour taste. They are taking and not giving back. And there are other DRAM controllers they could have used, and other ways they could have implemented them.

      Fact is that the RISC-V "open" architecture in any OS now has to carry around a bunch of closed-source binary blobs if you want it to boot on the machines that you can buy implementing that architecture. So... what's different between that and a Raspberry Pi, or an Intel, or anything else?

      If it were the graphics core, or the networking chip, or something completely secondary to the operation of the machine, you could avoid it, disable it, substitute it, etc. But it's the DRAM controller. The machine won't even turn on for more than a second without initialising that.

      It might be one model, one business decision, etc. but if that creep is allowed to continue then RISC-V as a practical, implemented architecture (i.e. the bits people can actually BUY) will lose its main advantage and be no different to anything else currently on the market. That's a lot of hard work down the drain.

      Combat it now, and you may yet still keep RISC-V and its implementations clean, by putting pressure on the company to licence and open that blob, or replace it with something equivalent.

    • (Score: 4, Informative) by Anonymous Coward on Tuesday June 26 2018, @07:53AM

      by Anonymous Coward on Tuesday June 26 2018, @07:53AM (#698645)

      The Phoronix title:

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

      The Soylent title:

      SiFive HiFive Unleashed Not as Open as Previously Thought

      Which of these are clickbait? Which of them claims RISC-V is not open? Both refer to current hardware implementations. Please do not invent clickbait in your head, there is enough to go around.

  • (Score: 0, Informative) by Anonymous Coward on Tuesday June 26 2018, @08:00AM

    by Anonymous Coward on Tuesday June 26 2018, @08:00AM (#698648)

    There are a dozen forum threads related to the controllers all explaining that they can only be released once the hardware reaches gold and the sources can be handed over to audit. IBM's OpenPOWER did the same thing with their controllers.

    As for the third-party bits, yeah, wasn't that obvious? I mean, it's just the cores and ISAs that were opened in the first place. You don't get the hard disk rotor controller's sources either... Seriously there's a lot of third party content in any given design (on or off SoC) that just can't be made open by any one party. It's why RISC-V is so promising: The modular design lets you bundle those blobs without having to close up the bits of your design you want to open. With OpenPOWER you have the audit section and the third-party disclosure sections that conflict with most licenses and NDAs so you end up having to use IBM's stuff unless you can do it all yourself...

    Seriously all of this been discusses to death years ago whenever OpenPOWER and lowRISC were mentioned... What's with the surprised faces people?

  • (Score: 0) by Anonymous Coward on Tuesday June 26 2018, @05:01PM (2 children)

    by Anonymous Coward on Tuesday June 26 2018, @05:01PM (#698848)

    Since we let government officials, right down to the street cop, break the law, we are allowed to show the same contempt (Si tu fumas yo puedo fumar tambein [youtube.com]). So, let's not worry if our firmware or software, or anything else is 'legal' or not. Just do your development and distribution anonymously, which means also you will need wide area network access without an ISP. HINT HINT!.

    • (Score: 2) by maxwell demon on Tuesday June 26 2018, @05:24PM (1 child)

      by maxwell demon (1608) on Tuesday June 26 2018, @05:24PM (#698858) Journal

      How do you download hardware over the internet?

      --
      The Tao of math: The numbers you can count are not the real numbers.
      • (Score: 0) by Anonymous Coward on Tuesday June 26 2018, @07:49PM

        by Anonymous Coward on Tuesday June 26 2018, @07:49PM (#698934)

        You have to produce the hardware yourself, from downloaded plans. Oh wait, no 3D printers and desktop smelters yet? Looks like somebody needs to get busy...

(1)