I've realized that my only interest in RISC-V all along has been the disruptive opportunity to possibly get open and auditable firmware and hardware (for human rights, empowerment, and security).
If AOSP on RISC-V helps promote RISC-V in a way that increases the likelihood of viable open firmware and hardware emerging in the ecology, that's great.
However, if, like some dev boards I've seen, we end up heading down a path of more of the same problem we already have with user-hostile platforms (just musical chairs of who's making the money from it), I'll save myself some trouble, and just keep using x86-64 and ARM.
Most devices will continue to be blackboxes. Most of the support for RISC-V comes from players looking to [commodotise their complements](https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/) and avoid the ARM-licensing tax. They have no interest in openers, just in less material cost and more flexibility for themselves. However, this will allow for a parallel community of open hardware to be built (in a way that you can't due to the patents, licensing, and overall cruft of x86/x86-64) that is compatible with the tools and software that is being built for these ARM-tax dodgers. So you'll be able to build a desktop that runs a fully open RISC-V CPU and board at 10 times the price and half the cost of a blackbox solution and while it will only run at half the speed, you will be able to be a legitimate Windows license for it. That is a realistic dream.
At least with RISC-V you can always synthesize the core yourself in an fpga. It's vastly easier than it used to be and cheap fpga boards are becoming quite powerful. Something like the upduino board has a low barrier to entry. I'm particularly excited by the artix-7 line which also has open source toolchain support, though i haven't tried it myself yet.
Putting it in an fpga isn't as efficient as using the same area of silicon to make an asic, but for alot of applications it's totally fine. Plus you can actually hack on the architecture to suit your needs. An open and adaptable computing fabric that can be synthesized on demand sounds pretty disruptive to me.
I know theoretically this is a problem, and I've heard people make similar statements, but I'm having a failure of imagination at thinking of specifics.
If you are using a fully open source toolchain what does the threat model actually look like in the real world? Even if a device itself is malicious, what can it actually do to exfiltrate information about what's happening inside it without being incredibly obvious? How can it know what register bits are even of interest given some configuration bitstream? It just seems like there are so many hypotheticals that it isn't worth being concerned about. Would love to be educated about this.
You should be able to take that AOSP and run it on hardware you designed yourself. Getting RISC-V and AOSP together pulls in thousands of more folks from the mobile phone ecosystem. This can only be a good thing.
The low end always eats the high end, so if AOSP is running on budget RISC-V SoCs, it is only a matter of time before it is encroaching on the middle and highend.
Because it's a disruption moment, and people will be designing new things around it, and some of those things conceivably might be people getting on some version of the open train, and doing the rest of the system open.
Maybe this could end up rising around some other ISA. The closest I can think of is Raptor's impressive work around IBM Power9, but even the entry-level Blackbird board they did a few years ago is pricey, and I haven't yet seen an explosion of open boards at other price points and configurations. https://www.raptorcs.com/content/base/products.html
> Because it's a disruption moment, and people will be designing new things around it,
But this is just wishful thinking. There is nothing in riscv that will automatically lead to open fw and open hw.
In fact, from what we have seen so far the big commercial vendors have added the usual secret sauce and we have ended up with development boards that are neither open or standard
Yep. The RISC-V cores themselves will run the same instructions, but there will almost certainly be a lot of proprietary devices on the SoC they reside on. Chip vendors save money by not paying ARM for a license. Maybe that savings will be passed on to customers. Probably not.
There is another advantage - price. Since there's no ARM licensing to pay for it's possible to make cheaper devices. This creates some new possibilities particularly at the lower end of the market.
Alibaba cloud supporting this effort with developer hours is a smart play. Migrating away from Western-controlled technologies (the complicated story of ARM
China notwithstanding) is a good political play. I would wager that an independant and further-developed China will before too long start to push their own propietary systems once their chip and software industries approach American maturity.
That aside, oh how I love seeing open source thrive, regardless of the reason.
It seems to only load consistently for me if I navigate to it from the front page of riscv.org, but it might just be some intermittent issue in their CMS.
IMO RISC-V will steamroll ARMv8 eventually, just like Linux and open source did to proprietary unixes and other operating systems. The only real question is whether ARMv8 grows to beat x86 in PC and server space before that happens or not. And I don't say this as a fan of the RISC-V architecture or process.
ARM is no less proprietary than x86, which is something that a lot of people don't really understand. Arguably it's actually more restrictive because x86 at least has two suppliers that compete on roughly equal terms. Intel might bully AMD somewhat, but a situation like amd64 where AMD unilaterally made an extension to the architecture against Intel's wishes could never happen with ARM. AMD also does not pay royalties on the cross license, I believe. (On the other hand, Intel/AMD are much less inclined to license to 3rd parties, so you can also argue it's less restrictive in some ways).
And the ARM Ltd. architecture royalties are just a drag. An inefficiency. ARM provides almost no technological value in the ISA. ARMv8 is just a warmed over RISC that's slightly modernized for the age as you would expect, there is very little real innovation in it. Certainly not to the tune of a billion dollars a year. I say that lovingly, I like RISCs and I like ARMv8, and I would even rather OpenPOWER ahead of RISC-V, but it's the truth. It's also no disparagement of ARM architects and designers who developed the specification, it is a highly skilled and difficult task to develop a complete and coherent architecture even if you do go a conservative route and mostly follow existing ones. Writing specifications just has a limit on output.
What ARM Ltd is mostly charging for is compatibility with their proprietary ISA and ecosystem. Which is fine, I mean good on them if they can get money that way, but it's the same proprietary lock-in that the Intel/AMD duopoly enjoy, and it is what many proprietary software vendors like the vertically integrated unix corporations enjoyed in the past before open source destroyed a lot of their business. Though to be fair, many have held off competition from OSS to greater or lesser degree, MS and Apple are obvious examples, so I don't see this open-source-izatoin as inevitable. On the other hand, an ISA these days is pretty much an API. Like a Java API or a C API. I think trying to extract a lot of money out of that kind of thing is on thin ice. I wouldn't call it rent seeking but it's not that far off it. At some point the market may quite well decide they don't actually need to pay anywhere close to a billion dollars a year to get the same result.
If AOSP on RISC-V helps promote RISC-V in a way that increases the likelihood of viable open firmware and hardware emerging in the ecology, that's great.
However, if, like some dev boards I've seen, we end up heading down a path of more of the same problem we already have with user-hostile platforms (just musical chairs of who's making the money from it), I'll save myself some trouble, and just keep using x86-64 and ARM.