Slashdot Mirror
Linux Now Has its First Open Source RISC-V Processor (designnews.com)
"SiFive has declared that 2018 will be the year of RISC V Linux processors," writes Design News. An anonymous reader quotes their report:
When it released its first open-source system on a chip, the Freeform Everywhere 310, last year, Silicon Valley startup SiFive was aiming to push the RISC-V architecture to transform the hardware industry in the way that Linux transformed the software industry. Now the company has delivered further on that promise with the release of the U54-MC Coreplex, the first RISC-V-based chip that supports Linux, Unix, and FreeBSD... This latest development has RISC-V enthusiasts particularly excited because now it opens up a whole new world of use cases for the architecture and paves the way for RISC-V processors to compete with ARM cores and similar offerings in the enterprise and consumer space...
"The U54 Coreplexes are great for companies looking to build SoC's around RISC-V," Andrew Waterman co-founder and chief engineer at SiFive, as well as the one of the co-creators of RISC-V, told Design News. "The forthcoming silicon is going to enable much better software development for RISC-V." Waterman said that, while SiFive had developed low-level software such as compilers for RISC-V the company really hopes that the open-source community will be taking a much broader role going forward and really pushing the technology forward. "No matter how big of a role we would want to have we can't make a dent," Waterman said. "But what we can do is make sure the army of engineers out there are empowered."
"The U54 Coreplexes are great for companies looking to build SoC's around RISC-V," Andrew Waterman co-founder and chief engineer at SiFive, as well as the one of the co-creators of RISC-V, told Design News. "The forthcoming silicon is going to enable much better software development for RISC-V." Waterman said that, while SiFive had developed low-level software such as compilers for RISC-V the company really hopes that the open-source community will be taking a much broader role going forward and really pushing the technology forward. "No matter how big of a role we would want to have we can't make a dent," Waterman said. "But what we can do is make sure the army of engineers out there are empowered."
I think the big take-away that will drive the adoption of an open source CPU, is the fact that governments and corporations can be sure that there's no secret spying implemented within it.
This presumes that you can trust whoever ends up making these CPUs based on the design.
READY.
PRINT ""+-0
I am a huge supporter of open hardware projects, especially the ESA and Oracle supported opensparc architectures.
https://en.m.wikipedia.org/wik...
However without a trusted silicon foundry to make chips without hardware back doors, all of the vetting of the hardware design "source" RTL won't be enough to establish trust. Even running netlists in FPGAs won't be enough if you can't trust the FPGA manufacturer or the foundry that built it.
In the end, we as consumers are stuck without any truly secure hardware options, free of backdoors.
My advice, assume all processors have backdoors and select those designed and made in places that cannot be compelled by the country in which you live for backdoor access.
How do the J2/3/4 open source SuperH designs compare?
I've not looked at SuperH in detail, so I can't really compare.
I seem to remember there were other pitfalls to their architecture, but getting a processor that is Management Engine (Aka Clipper+Palladium+TPM) free is a huge boon to the future of computer security
I disagree. A TPM, secure enclave, or equivalent, is increasingly vital for computer security. It is absolutely essential that you have some write-only storage for encryption keys into a coprocessor that will perform signing / signature verification / encryption / decryption, but which does not allow the keys to be exfiltrated. Anything less than this and a single OS-level compromise means that you need to reset every password and revoke every key that you've used on that machine.
Having said all this: Is it perhaps time for a different CPU project, or a fork of RISC-V with these missing features added, at the risk of binary incompatibility, but to the benefit of performance and perhaps security?
There are lots of extensions to RISC-V, but the problem there is fragmentation. You need the A extension if you want to run a real OS. You probably need the C extension, because compilers are starting to default to using it. The M extension is useful, so people will probably start using it soon. Hardware floating point is expensive on low-end parts, so you're going to end up with some having F, some having D, and some having neither (this was a pain for OS support for ARM until recently - now ARM basically mandates floating point on anything that is likely to run an OS), and a few will support Q. L is unlikely to be used outside of COBOL and Java, so isn't too much of an issue (one is niche, the other is typically JIT'd so it doesn't matter too much if only some targets support it). And that's before there's any widely deployed silicon. Expect vendors to add their own special RISC-V instructions, making their own versions of toolchains and operating systems incompatible.
RISC-V isn't the first project to try this. OpenRISC has been around for a lot longer, but RISC-V managed to get a lot more momentum. I don't think that a competing project would find it easy to get any of this. It remains to be seen whether this momentum can translate to a viable ecosystem.
I am TheRaven on Soylent News