I get there might be a saving for not having to pay ARM a royalty of some kind, but are RISC-V chips cheaper in practice as a result?
I was under the impression (rightly or wrongly) that the arm royalties per chip were really small.
There are better boards than the Raspberry Pi (strictly speaking specifications here). I took that path of playing with a lot of alternative boards, my biggest issue is lack of support, some boards had kernels never updated, etc...(YMMV).
If Raspberry Pi released a RISC-V board I have no reason to believe the community would not be just as strong. Sure in the beginning they would support both, but eventually the ARM support would wither.
If you are going to learn computer architecture, you will learn something cheap you have on hand
The Amiga 500 didn't make people stick to the m68k. They went IBM PC as did everyone else.
Assuming performance and software support is comparable. Which obviously won't be the case for a long long time.
But there are few things as irrelevant as the CPU instruction set. (Part from specific extensions, like AES support enabling quick crypto etc.)
The technology is what people know. Using a different SoC board, camera, ... requires adds more time to gain the same level of knowledge.
Doctors will latch onto a single product solution so they don't have to spend the time learning how to operate an alternative. Hospitals need to stock consumables based not on the best products but on what doctors know.
Airlines retain the same air crafts to reduce time spent learning to operate an alternative. Boeing marketed this as a sales feature with 737 MAX, no extra flight training required!
Software developers will often stick with the same language, even though others better fit the domain problem. Few seem willing to take the time to try and play with new concepts, languages, and operating systems.
Trying new and different things drives innovation not the world.
Some things will surely change because the hardware backed features work in a different way, but mostly it will be similar enough.
Going from a raspberry pi to an orange pi could be a much bigger leap than switching to an raspberry with RISC-V that has mature software support.
I’m going to have to disagree with that statement…
… but only because I’m in the middle of goofing around with ARM assembly on an RPi as we speak.
As much as I love tinkering, this is why I stick with RPi boards and not others. RPis do everything I need, and have amazing support in software.
That said, I'll tolerate some regression in support to switch to a RISC-V based competitor.
Want your own custom boot rom so you can start up in half a second rather than the default 3 seconds before linux gets loaded? - sorry, we can't share the code for that with you, nor the specs for you to write it yourself!
My memory told me it was the GPU that needed the blobs. So I asked at DDG
https://duckduckgo.com/?t=ftsa&q=binary+blobs+and+the+Raspbe...
Turned up this: https://wiki.debian.org/RaspberryPi and it says...
> All Raspberry Pi models before the 4 (1A, 1B, 1A+, 1B+, Zero, Zero W, 2, 3, Zero 2 W) boot from their GPU (not from the CPU!), so they require a non-free binary blob to boot
So the 4 (and I suppose the 5, if it ever actually comes...)
Goes on to say:
> Since then, Broadcom publicly released some code, licensed as 3-Clause BSD, to aid the making of an open source GPU driver. The "rpi-open-firmware" effort to replace the VPU firmware blob started in 2016. See more at https://news.ycombinator.com/item?id=11703842 . Unfortunately development of rpi-open-firmware is currently (2021-06) stalled.
So there you are. Not wrong, are you, but not strictly correct, depending on "...to run properly" definition
https://github.com/librerpi/rpi-open-firmware has updates 3-months ago
NetBSD provides a filesystem image containing one kernel that will boot on all supported ARMv8 boards, you may need to write a board-specific build of u-boot to the start of that image. A Linux distribution could do the same as this.
It's already happening. RISC-V doesn't need the Raspberry Pi.
Yet it would indeed be an accelerator, but I'm not sure how big. ARM are certainly very afraid.
The ability to modify the design for your application and be able to apply a plethora of cores where they are needed at only the cost of silicon area.
Apple has been moving their management cores on their M-series parts from Arm to RV and they have an architectural license.
Everyone has an architectural license for RISC-V, you can add your own instructions, change the mix of available instructions. A whole parametric RV32 or RV64 will be available on every node at every fab.
This move by Arm is absolutely to block RPI from moving to RISC-V. They have mindshare and distribution.
Art is not just about no limit, but what you do with the limitation including illuminating there is a limit. Not just about beyond it but of course you could.
Moreover, those royalties put fences on what might otherwise be more open and collaborative. It would be sad, if the tinkering goals set out originally by Raspberry Pi were curtailed by ISA license restrictions. RISC-V inherently has an edge over ARM in that dimension.
Once such a switch was made, Pi could even consider using free and open source cores for their low-end devices where margins are slim (an area where RISC-V has already been gaining ground rapidly).
These are the newest OoO cores with full 1.0 vector extensions, right?
[0] https://forum.sophgo.com/t/about-the-sg2380-oasis-category/3...
These cores have just been announced, and are available for licensing. You can contact SiFive if you're interested.
If what you want is hardware somebody's already made, that's going to take 2-3 years as per tradition.
>These are the newest OoO cores with full 1.0 vector extensions, right?
Yes, but so are multiple generations of predecessors. It seems that hardware based on P670[0] and X280[1] (both match that description) will be available for purchase in less than 10 months from now[2].
0. https://sifive.cdn.prismic.io/sifive/7be0420e-dac1-4558-85bc...
1. https://sifive.cdn.prismic.io/sifive/9405d3d0-35a1-4680-a259...
2. https://forum.sophgo.com/t/about-the-sg2380-oasis-category/3...
Whilst the RISC-V instruction set is free from licence/patent fees, the design of those chips will be made by a company that will need to recover costs, so there will be a cost. Compared to ARM who already offer up free core designs for use for free like the cortex-m0 and others. I know the Raspberry PICO uses a cortex-m0x.
Over time, but that will be when you get open-source RISC-V chips that compete with the designs of the market offerings other companies make and sell. Which as a mindset may cause the evolution of RISC-V issues as people could get burned due to expectations exceeding the reality and finding the get what you pay for those to still hold stronger than envisioned. Yes, eventually open-source CPU cores will get there, but production costs and scale will still become a factor, as to many aspects that all add up to the final cost. This is even on a level of software stack tried and fully robust of equality, which is still behind ARM.
ARM may well kill off x86 as a mainstream before RISC-V fully bites it.
Look at how long ARM took to get where it is, and started with microcontrollers, used in many things. That is where RISC-V will and is starting to get traction, but scaling beyond that, whilst could be faster than ARM's history, it's not as clear-cut as many foresee.
Today, the c910 is an Apache 2, hardware proven out of order core on GitHub here https://github.com/T-head-Semi/openc910 a little slower than an RPi3's core.
Additionally it's very competitive in PPA metrics for it's gate count, so cheaper than similar cores in terms of wafer area as well.
https://www.aliexpress.us/item/3256805346421328.html?gateway...
RISC-V is very very popular already, but most RISC-V cores are not user accessible. They're controllers in hard drives, embedded management cores in SoCs, etc. Definitely nice to not have to pay for licensing that, and verification doesn't matter so much since you are more likely to be able to work around bugs in software.
I suspect it won't make a huge difference to visible CPUs. Probably the biggest impact will be flexibility.