$70 RISC-V Computer from Pine64 Goes on Sale April 4 – OMG Linux
omglinux.com
omglinux.com
It looks like they're off to a good start but appearances can be deceiving. Kernel is a fork and who knows if it's missing anything. It's all pretty new so I wouldn't expect it in mainline. GPU (Imagination BXE4-32) also seems to have a pipeline towards upstreaming.
https://wiki.pine64.org/wiki/STAR64
It's nice to see that it has onboard wifi. Barrel jack for power, rather than USB-C, is a little disappointing.
Yeah, it's at an awkward point right now where you wouldn't expect to have drivers upstream, so it's harder to predict whether it will get where we want it.
also, on my raspberry pi i at least stood a chance of running a headless chrome for some silly scrape job i had. RISC-V pretty much guarantees that's not the case, right?
I can confirm both chromium and firefox run.
They even have javascript JIT, so the performance is good.
However, what does matter is that the RISC-V ISA will be cheaper and more flexible for device manufacturers to use. That's why it's superior to ARM and has already partly supplanted it for smaller chips (there are over 1 billion RISC-V chips in use already).
* if you want to support the development of RISC-V as an alternative to x86 Arm /have some preference for not supporting x86 or Arm.
* if you are writing code generators, you may find RISC-V easier to generate code for.
If you don't care about these, then I would agree, keep using what works best for you.
But we're only talking 10% or 20% difference here.
The big difference is Arm is owned by a single company that can and does change its contract terms and prices, sues its customers, obsoletes old stuff at will etc.
RISC-V is managed by a non-profit that is steering along a path agreed by its hundreds of member companies, but can't and doesn't stop anyone from adding custom stuff as long as they stay compatible with the core ISA. There is a promise to only add capability over time, but keeping compatibility with the core 32 and 64 bit ISAs published in 2015 and ratified in 2019 ... forever.
There are already a dozen or more companies competing to design the best and most competitive and compatible RISC-V cores and chips, and that's only going to increase. If the company you are using falls behind or raises prices or goes out of business then you can just switch to another -- as long as you didn't drink their proprietary extension cool-aid (it can be very tasty).
The current limits of the RISC-V ecosystem are (I currently have one sitting in front of me, and ssh access to the other):
- WCH CH32V003 microcontroller with 2 KB RAM and 16 KB flash in an 8 pin package for 10c each or 20 pin package for $14.6c https://www.aliexpress.us/item/3256804850399956.htm
- Sophon SG2042 64x 2.0 GHz OoO cores similar to Arm A72, each core with a 256 bit vector unit, 64K L1 cache, 1M L2 (shared per 4 cores), 4M L3 local to a cluster of 4 cores, with the other 15x 4 MB L3 accessible via NoC at ~half the local bandwidth. 32 lanes of PCIe gen 4. https://www.sophon.ai/product/introduce/sg2042.html
I'm curious about standardization of the rest of the system - the way x86 operating systems more or less work on any x86 machine, whereas ARM seems to basically require a device-specific OS image for every single device. Is there any work going into addressing that and making RISK-V more like x86 and less like ARM systems?
RISC-V is in a much better position than ARM and x86 already, because this is well underway and the boot specs have been available for years now.
In ARM, there was too little, too late. Most vendors do not follow the relevant specs.
As for the PC, the platform became so by accident (IBM PC clones happened) and there's of course a serious amount of historical cruft.
0. https://github.com/riscv/riscv-platform-specs/blob/main/risc...
I feel like RISC V has really started to pick up momentum over the last year or two, which is awesome to see. There have also been a bunch of tiny RISC V softcores for FPGAs too.
They list an NVMe SSD adapter board with PCIe x4, I wonder if that works together and can be booted from? I know with my RPi getting away from SD card boot made a huge difference.
It's still possible (with an adapter) to use PCIe cards.
It is already possible (with current u-boot patchset) to boot from NVMe. It has been possible for months to have root on NVMe.
It is indeed much faster than your average SD card.
https://en.m.wikipedia.org/wiki/AMD_Am29000
The article says it got designed in to a bunch of laser printers, but not which ones.
There were a bunch of RISC designs floating around then. The ones still relatively familiar are those that were being used as workstation CPUs -- SPARC, MIPS, POWER/PowerPC, DEC Alpha. But there were also the 29k, the Motorola 88000, and Intel i860. Probably others I'm not remembering.
This particular CPU is not open source.
They may have memory models that make guarantees that are insignificantly secure or impede optimisation.
There is something about condition codes vs explicit checks that made speculative execution difficult. I don't recall the details about this one.
MIPS has cruft in things such as architectural load and branch delay slots. Helped in the first, simple, implementation but just (worse than) useless baggage after that. Instructions that trap on overflow too. Helped on some programs on simple implementations, but on an OoO implementation just the mere existence vastly complicates the pipeline even if programs don't use them.
With Arm, the bitmapped arbitrary set of registers load/store/push/pop is cruft that helped the first simple implementations (especially ones without icache). Same with the predication on every instruction. It uses a ton of instruction encoding space, doesn't get used much outside of conditional branches, and in modern implementations branch prediction is usually so good that you don't want to predicate instructions -- certainly not several in a row. Arm is deprecating IT* predication in Thumb2 now also. Also PC as a general register is harmful to modern implementations. ANY instruction with r15 as the destination can change control flow -- load, add, xor .. whatever. At least you can tell at instruction decode time, but it needs both opcode and dst register to tell.
Aarch64 fixes most of the traditional Arm cruft (everything mentioned above) and is a pretty good ISA. The main faults are that it still has condition codes (no other high performance ISA designed after 1990 does), insistence on the purity of 4-byte instructions only (Thumb2 showed that the benefit is well worth the small cost), and just the simple fact that there is TOO MUCH of it and no subsets allowed, making it impractical for small CPUs e.g. microcontrollers.
0. https://www.amazon.com/RISC-V-Reader-Open-Architecture-Atlas...
The big thing that is different than other "open" ISAs in the past is that there is an open specification / standard that isn't encumbered by restrictive licensing or patents. This allows software (think compilers) and hardware designers to target the ISA without fears of getting sued for using the ISA or having to have restrictive licenses.
It can also be simple to implement, but there are commercial, highly performant cores available too, for example, sifive.
The other salient is political: ARM, x86, etc are Western aligned while RISC-V is attractively nonaligned. ARM's government mandated Chinese subsidiary went rogue against ARM itself which endangers the use of ARM chips in China. RISC-V hedges against this risk for China.
I care because David Patterson is a badass who was right about everything. :)
You don't until you do. Like all the corps which need to replace the Huawei tech unexpectedly.
There are multiple cores available under permissive licenses all the way through to ASIC or FPGA implementation. There is also quite a bit of academic research happening now, which may not be formally open source but is shared and published.
> even that doesn't really mean much as interfaces have dubious copyright protection
There's a big difference between "given a license to use this" and "might not get sued, or at least might win if we do, if we use this without permission."
Today, board developers have to pay if they want to license ARM. And with recent developments coming out of ARM, the price to pay is going up by a lot, very soon. If RISC-V can develop to the point of more or less parity with ARM, then that will enable cheaper products that are just as good, equally priced products that are better, or equivalently positioned products that return a better profit to their manufacturers (which is good for you even if only indirectly—better profitability means easier entry for competition, better financial stability behind whatever ecosystem you're buying into, lower chances of companies crashing and leaving behind unmaintainable e-waste, etc).
IMO, reduced rent-seeking is good for everybody no matter what sector. I want more collaboration and less human effort/ingenuity/resource dissipating to waste heat. Open source makes Moloch cry.
IMHO the biggest issue right now with ARM is the uncertainty surrounding it, their Chinese subsidiary went rogue and they are trying to raise prices significantly in preparation for a sale or IPO.
More important is that more competition may lead to better designs and the RISC-V gives more freedom for firms to innovate.
As for the 10c a core on average, there will be billions of 1c/core royalties for things you don't even realise have a CPU in them, and tens of millions of much much higher royalties on the kinds of chips that go into smartphones and SBCs. Maybe as much as $10 a chip?
[1] tens of millions is wrong and it clearly not true that Arm charges ‘as much as $10’ for an SBC that will cost $40 retail.
Apple sells 70 or 80 million phones per quarter and they are only a small fraction of the market. Android phones sell over a billion a year.
Now we can discuss what the scope is for RISC-V companies to charge for cores or chips.
Jim Keller said yesterday that in 2024 his company will have an 8-wide RISC-V core, on a chip, that performs on a par with Apple M1/M2 and Zen 5.
Performance gap between RISC-V and x86 down to zero.
I suspect that in 2024 he means expensive shuttle run chips. But working and able to be demoed. Mass-production chips are usually 12-24 months later.
Edit: Or is 32-bit x86 so old that you could "just" clone it because all the patents have expired?
On a more general level, the idea of RISC is to have a very very simple instruction set instead of a thousand 'clever' features that are mostly underused, so that you can optimize your software project out the yin-yang if you're more concerned with pure performance than versatility.
On the other hand, existing GPU company Think Silicon spent six weeks in October/November 2019 adding some GPU instructions to RISC-V, showed it running in an FPGA at their booth at the December 2019 RISC-V Summit, and are shipping the resulting product now: