PicoRio Linux RISC-V SBC is an open-source alternative to Raspberry Pi board
cnx-software.com
cnx-software.com
China is quite interested in RISC-V gaining traction as trade and security barriers rise and they work to build up their domestic technology sector.
Going into wild-ass speculation mode, if this board really is affordable, I wonder if it's being subsidized by the Chinese gov't to encourage RISC-V adoption.
If I understand correctly, it's hard to make a cheap RISC-V Linux board with a price in the same order of magnitude as Raspberry Pi, because the Pi benefits from the availability of cheap, powerful ARM-based CPUs that were mass-produced for the mobile phone market. Linux-capable RISC-V parts have nowhere near these economies of scale.
China could create the economies of scale needed to drive prices down. I saw something where NVIDIA was using RISC-V in part of its GPU’s.
It shipped first in a STB for Roku, but that was happenstance vs any design intention.
The market for separate cell phone GPUs died off, but the die was manufactured still for the RPi.
I like your idea because I could see the Chinese government doing this to help prop up SMIC too. The RPi4 isn't any smaller than 16nm, and SMIC needs 14nm customers.
Shoot for the 500MHz target listed, which is achievable with Victorian era style over engineering. Next sell those more or less at cost after the government footed the bill for initial capital (probably paying back .gov.cn first). Then using the massive body of software you expect from the new ecosystem around the first wave of chips to reoptimize the cores and inch your way towards really competitive chips. All the while SMIC gets great experience at their lower node with a pretty low risk, but high volume project.
Total speculation, but fun speculation. If someone pulls that off they probably win the whole Made in China 2025 thing for homegrown computers in an interesting enough niche to have a foreign audience too.
https://www.cnx-software.com/wp-content/uploads/2020/09/Pico...
Thanks for the citation!
TSMC has massive economies of scale and are just very hard for alternatives to compete with.
https://www.reuters.com/article/us-usa-china-smic-exclusive/...
Exclusive: Trump administration weighs blacklisting China's chipmaker SMIC
This is the exact reason why RISC-V is getting increasingly more attentions.
You might find this[1] meeting with Steven Zhao interesting. Steven Zhao is the guy behind Orange Pi, raspberry pi alternative. Interesting part translated:
Steven announces that Orange Pi can buy a good quality WiFi component for $1, that his cards will have a good WiFi connection for that price.
- Uh, if the purchase of the component is $1, inevitably the exit price will be a little higher for the end customer, Mr. Zhao? - If you tell me the price, I will know your margin ... -
- No, because today all Orange Pi cards are sold at the BOM (Bills Of Material) price.
- Does that mean that the cost of engineers, premises, development hardware, design and all that ... isn't impacted in the price of a card?
- That's right.
- But how is that possible?
- We benefit from government grants.
And here's a statement that takes your breath away. Orange Pi is a private company in a state dumping system. This can be said from a Western point of view, of the international agreements and of all the conceptual set-up intended to protect the big established industrialists.
1: https://www.minimachines.net/a-la-une/orange-pi-steven-zhao-...
Also the pricing of low end Pi models is probably very close to BOM cost too.
EDIT: Removed a bit of the comment from a misunderstanding from reading the article
It would be up to picorio being more open than the pi (easy to do, but not if they fuck up by including a powervr gpu) and/or using less power.
[0]: https://carrv.github.io/2020/papers/CARRV2020_paper_15_Zhao....
It was pricey at $999 because the chips are from low volume "shuttle run" aka MPW production (probably $300 or $400 each -- would be maybe $10 in volume production) and the board has 8 GB DDR4 2400 and other expensive things such as FMC connector.
But it's well faster than a Pi 3 and I've had 2.5 years of use out of it already...
Depends on your expectations, technically NES had 60 FPS GPU.
If you want to drive a FullHD at that rate, and render GUI comparable to modern phones - you need 3D acceleration, ideally programmable shaders, and the fillrate.
GPU is unavailable at launch, they say it will appear in later versions, and it will be a PoverVR. Never said which PowerVR.
Here's hoping their close brush with death opened them to the idea of open sourcing their code.
My first thought as well. On the other hand... baby steps. We need a chip like this very much. If the first ones are slow or too proprietary that may be OK, it is still pushing the RISC-V ecosystem in the right direction. It will help validate a lot of software which will enable more open designs by having things ready to go.
However, I'm primarily interested in Rust development on the RISC-V. For bare-metal programming, the K210 is enough for me to get my feet wet. Thanks to the wonderful community, you can already run gdb for source-level debugging of Rust on that platform, with the addition of a $7 USD JTAG adapter.
That said, as long as the PicoRio board (even without a GPU) is available for less than $100 USD, I am totally buying one as soon as they are available for order.
Another board for the landfill, forever doomed to some 80s throwback Unix timeshare shell application.
You'd expect that kind of thing to be brittle when you don't have source access, but the drivers themselves were remarkably clean when I spent some time reversing them. It's just a shame that they're so afraid of open source too, because the above really compounds that pain.
I'd rather unaccelerated graphics. Hell, take any display solution from opencores.
But don't give me proprietary garbage and especially not PowerVR. I'm OK with no graphics as an alternative. Hell, I could always use some USB display solution.
Then you'll be fine with the first version of this, since it's exactly that.
The Foundation's charitable objective is education, so sure, it's not necessary, but there really seems to be no reason for it to be closed - I suppose it's just 'closed by default'?
About the only way to make a device with an LCD is to use the built-in HDMI.
https://github.com/anholt/linux/wiki/Raspberry-Pi-and-other-...
This is a theme with the RPi. They generally implement new hardware in their proprietary firmware first, for lack of skills/time to do a proper upstream job of it (or the convience of copy-pasting some vendor code), then pay someone to develop an open-source driver. For example, here is a massive 80 patch series nearing merge for the new display pipeline in the RPi 4:
There is a little thing called Google... ;-)
It is open to a degree:
https://www.raspberrypi.org/documentation/hardware/raspberry...
Device Tree and other things help with this, although you do still require certain BLOB's to access the GPU and other features.
The 4’s hardware support is still being merged upstream last I heard though, so the easy way for that is still to use the Foundation’s kernel (which is what Ubuntu does, probably to also make overlays work as expected).
https://github.com/librerpi/rpi-open-firmware https://github.com/itszor/vc4-toolchain/issues/7
Arguments that Broadcom is forcing their hand on this simply don't add up. It's not Broadcom that's stopping them from publishing even basic schematics of the board; that was their decision. Sure, they'd never be able to open the chip itself, but nobody is particularly asking them to (it's not like people have fabs in their garages).
Moreover it's pretty clear at this point that Broadcom is making SoCs custom-order for rpi at this point; see their original announcement on the rpi4, which makes it quite clear they were involved in the design process. Based on what I know about Broadcom's MO, it's simply not plausible that with that amount of money on the table, release of datasheets and register manuals couldn't be negotiated; it seems clear it's not a priority for rpi.org.
And as mentioned, rpi boards include vendor-lockin DRM in their binary blob boot firmware designed to prevent people from using third-party camera boards.
Not only is this unacceptable in itself, it also means rpi is actively depending on this boot firmware remaining closed, else people could easily remove this antifeature. People have been hoping for years that the firmware blobs required to boot the boards will eventually be opened, and pointed to some vague noises in this direction which were made by rpi.org years ago, but the fact that they're now relying on the fact of it being closed to enforce DRM causes me to find this increasingly unlikely.
I have worked with much more mundane integrated circuits where the manufacturer required you to sign an NDA before getting any kind of design support from them. One of the terms of the NDA was not publishing the schematic of the device using their product. I don't see why Broadcom wouldn't do something similar for their SoCs.
Broadcom is notorious for demanding NDAs for their datasheets, completely pointlessly. I've also heard of companies demanding their parts be redacted on schematics if published, even more ridiculously, though as far as I know Broadcom isn't one of them (I've seen public schematics with Broadcom parts).
Still, from what I've heard of Broadcom specifically, they're pathologically secretive with their documentation unless some star customer dangles enough money in front of them. rpi.org certainly fits that description. So I don't really buy this excuse for rpi here.
In reality, I suspect it's more the fact that rpi.org was started by ex-Broadcom engineers and they brought their culture of secrecy with them.
Yet the chips weren't sold by any distributor. To even just get engineering samples from the manufacturer you had to sign this draconian NDA that covered everything from software to hardware docs even remotely connected to their part. Even after signing the NDA they wouldn't disclose full datasheet for e.g. what some registers did. For some things the comments in the Linux kernel turned out to be more informative than anything we got through official channels.
But if they're the only source of parts you have to use, you have to dance by their rules. Ruin the relationship by breaching the NDA and you might just as well bury the product you spent a year developing.
That's not very OSHW if you ask me. I'd rather an unaccelerated framebuffer, or even no graphics at all.
They don't seem to understand what kind of market there is for this sort of device. If I didn't care about this sort of thing, I would just grab one of the many proprietary-encumbered SBCs, any of which faster and cheaper than this board is going to be.
That's one of the neat things about how programmable their cores are; you can resolve in the tile to just about any surface format since it's all done in software anyway, so it's really easy to integrate with other scan IP blocks.
TL;DR: You'll probably get a simple un-accelerated framebuffer (maybe with a few planes) with a PowerVR off to the side that you can just ignore if you want.
The problem is that I can't, and most people who care about freedom and thus could be interested in a slower, more expensive board... can't either.
If it's a separate chip, that's better, because I can cut power to it, or outright desolder it.
Still, I'd be uncomfortable having paid for a chip I did not want. Much like being forced to pay for Windows when buying a laptop to run netbsd on.
My point, if you missed it, is that this is not the sort of purchasing experience those who'll pay extra coin for a board with a slower chip that's also less power efficient just because it's more open would actually desire. And thus, it is not sensible to include such a chip.
> Exceptons (sic): foundry related IPs and high-speed commercial interface, but gradually reduce close source (sic) usage over time
Wonder what the FSF will make of it. They've long lamented that Raspberry Pi depends on non-Free software.
This is RISC-V, with a neural co-processor (runs YOLO), camera, GPIOs, leds etc. For $25.
It runs MicroPython out of the box, but someone has Linux booting on the board equivalent.
I have one, and there are teething pains but the platform seems pretty capable.
Meh. I wish they would realize that SD cards are not made to be a system disk. I need SATA or NVME ports and lots of them so I can build my own NAS!
Separate from what the software&OS drive is, for a small NAS, 2 SATA ports for data storage (RAID mirrored) would be nice, but doesn't have to be in the general-purpose hobby $35 (or whatever) size board. For larger NAS needing more SATA ports, I definitely wouldn't expect or want that in the $35 board, but seems like there's probably a market for a board like that.
Rpi Zero W and the corresponding Banana Pi M2 Zero meet all criteria except the 5GHz. Beside these, I have a really hard time finding any cheap alternative.
There's plenty of embedded devices for iot, from arduino to all others. But 100% of the iot I have in my apartment are actually powered and don't need a batter/extremely low consumption. I much rather enjoy the flexibility of running linux (or android) vs flashing a firmware.
What do people mean _exactly_ by 'IP' in contexts like this related to computing boards such as SBCs and FPGAs?
The only 'IP' I know is a term pertaining to legal concepts like patents, where 'IP' and 'patent' are almost synonymous. In the current context, what does it mean to 'release' this 'IP'? How do you 'release' a patent?
It's a logic or semiconductor layout design for a component (e.g. a processor core, or a peripheral like a UART, DMA controller, etc.). "IP" for hardware is roughly analogous to "source code" for software.
In semiconductors an IP is often some logic block, often supplied by a third-party to paste into your design, or part of your own company's library.
For example on SoCs a cache, a USB PHY, a CPU core, an AES unit, an Ethernet controller, a PCI controller, a video decoder, an audio decoder, etc.
A design unit you could imagine selling to be used inside other company's designs. That's why you can "release an IP".
I find the use of "IP" for these things a bit distasteful, so I try not to use the term myself, but it's very common in the field.
There's various reasons for a new ISA. The most appealing right now is the patent pool. Most other open ISAs are explicitly patent encumbered (recent MIPS versions) or provide zero protection (openrisc). The chances of getting sued over RISCV seem very small until you start moving to non-ISA parts of the chip.
For an ISA to succeed, the ISA itself is a distant second to the ecosystem as x86 shows so well. The amount of money an R&D being poured into RISCV would single-handedly be enough reason to adopt.
IIRC the code density beats ARMv8 and x86_64 in most situations.
Right now, x86 needs one set of instructions for each SIMD data size. That’s why we have SSE, AVX, AVX512, etc. This introduces complexity for both hardware designers and software designers. You have to actively update software to work with newer chips with larger SIMD registers. In the proposed RISCV design, you wouldn’t have to. It would just work on all sizes.
RISC-V will need to do the same, so expect to see multiple versions of the "V" extension over time.
If you look at the encodings, many of them are actually the same opcodes as the original MMX, but with prefixes.
In the proposed RISCV design, you wouldn’t have to. It would just work on all sizes.
That doesn't make sense --- how would the code know how much to increment pointers by, how many times to loop, alignment, etc. ? Unless they added some really un-RISC instructions to do automatic vectored operations (like if x86 had a REP ADDSB), I don't see how you wouldn't need to change software for changing SIMD widths.
You ask the hardware. The current vector width is a register that can be set and queried.
Configuring a grouping of 8 registers for a vector of 16 elements might look like overkill because 128 bit vector registers are sufficient and should be widely available. On the other hand, there might be a CPU with "V" support that just implements - say - 64 bit vector registers where we would need to group 2 registers. Since a grouping thus may be needed it really doesn't hurt to configure the maximum here.
...seems to imply that the generated code may still need to assume certain widths.
It's just that if your code doesn't need 32 different vector variables then you can step down to, say, 4 variables with 8x longer registers for more efficiency. You need to know how many live variables your code has (which the compiler knows), not how long the registers are.
The RISC-V ISA with the Compressed extension is very competitive and often better pretty much anything else.
RISC-V also has an innovative modular structure that allows it to be optimally used in many different industries while sharing a lot of code.
The RISC-V Vector extension is really good and innovative. And so are some of the other extension.
Do you have any in mind? From what I can tell even POWER is not as open as RISC-V. They only show schematics to their partners, not the public at large.
POWER opened up only after RISC-V.
Relevant Wikipedia page: https://en.wikipedia.org/wiki/Comparison_of_instruction_set_...
Of course, what would be really good would be a CHIP-Pro style module that is a complete Linux SBC suitable for inclusion in a IoT PCB design. Thus far, the CHIP-Pro (ARM-32) and Onion Omega2 (MIPS-32) have been the only viable reasonably priced embeddable Linux modules I've seen.
EDIT: The reboot was called Source Parts but it looks like they may have gone under also. Too bad, the CHIP-Pro was pretty nice.
(Which is why I use the 3A+ for most of my stuff, really. Four cores and full-size HDMI and USB are very useful indeed.)
The RPi-specific userspace bits are just (in the past year or so) starting to become more standard (like moving the stuff in /opt/vc to standard system locations, having a normal kernel headers package).
I don't want a specially-built OS just for one piece of hardware. I want to run stock Debian, with a stock kernel. And yes, I can do that, but as you hit at, the experience is sometimes lacking (for a while I couldn't get sound to work with stock Debian).
I've been looking at some of the RPi workalike boards that run Armbian... I haven't dug into it yet to evaluate the quality of Armbian, but I at least like the overall approach of having one OS that can support different chipsets and boards.
1st few players grow it important 2nd it becames a big monopoly, we all depend on 3rd other players need 10 years to build competition ( needed time to build cable/towers) ( needed time to develop processors ) 4th you have a bunch of players, all with FIX COSTS and with a 1$ variable cost for new customers, the competition squeez the margins to arround Zero. 5th you still have to keep up with the improvements ( 5G?? / 7nm??, 6nm?? ), so just to keep going investments are needed, and so profits disappear in the industry
airlines, Telecom, .... next chipmakers
The phase 1 SoC is all I'm interested in for now. The lowest-size LPDDR4 part I could find is 256MB, which isn't a lot, but enough for what I want to do. Having that RAM, and networking or USB, will be enough for me to buy one. Assuming a reasonable price, of course.
I've been laser focused on RV64, but RV32 is nearly identical. It is a shame the current VexRiscv bitstream for this board doesn't seem to support atomics though.
That would be amazing. RISC V has thus far not struck me as something within reach of the average casual consumer.
Ah, how quickly we forgot the GMA500/Poulsobo chip.
https://arstechnica.com/information-technology/2009/12/pouls...
What sort of person describes a board with a closed-source GPU firmware as "Open Source"?