Good! We need more small systems. Not just CPUs-on-a-board for hackers to prototype with but an alternative to Intel NUCs and smaller fully integrated computers with inexpensive low power CPUs.
It's astonishing to me how behind the ARM ecosystem is on this. I still can't buy something like a low-end amd64 computer easily with ARM. There's a few laptops and a few cantankerous oddballs like the ROCKPro64. Then again it's Pine64 mentioned in the RISC V article, so maybe we have more years of oddballs to go.
"Supports UEFI Boot" ← This sounds good already for booting generic Linux distributions, now the question is how well the mainline kernel supports this board. Having to use a special-patched kernel is a no-go if you care about using this board after a few years when it becomes niche. The Libre Computer boards are a good example in this regard (https://libre.computer/products/) they are very niche but since the mainline kernel supports them and they use UEFI by default, you can use most generic Linux distros without a problem.
4 big cores and 4 little cores at 8nm, 2 gigibit ethernets, an AI processor, Wifi6, 5G, 32G RAM, PCIe 3.0, M.2, 4 SATA, 2 HDMI, VGA, HDMI in, RS232, CAN… and idles at 1.3W. Typical ~4W, max 20W.
$460 for basic 4G RAM, 16G storage, prices go up from there.
Hah, apparently I missed that when I looked a little while ago. That's a very pleasant surprise. Looks like PCIe, SATA, USB and Ethernet all sit behind it.
I visited the FireFly offices in Zhongshan a few years ago and expressed interest in helping them get hardware to open source maintainers. A number of devs (predominantly European) expressed interest, I provided the details, and FireFly never sent the hardware. Didn't exactly breed confidence in their brand. The earlier hardware of theirs required off-tree patched kernels to run, and had middling documentation which is far too much development overhead unless you're doing volume. Unsure how much that's changed, I stopped looking.
4xSATA ports so it will be a fairly modest NAS, also at that price point it has a lot of competition from budget CPUs and mini-ITX mainboards.
It looks like it could be a pretty nice little SFF desktop. The low power draw means you don't need active cooling and it has everything built in so you won't need some dongle (other than power) to integrate. The only issue is that it's not Intel so if your employee needs to run MS Office or be managed from the domain it won't work. But for the receptionist or for a kiosk or many other uses this could be pretty nice, especially if you are trying to cut down on energy use.
It also has an M.2 slot for the I/O heavy stuff. There is a natural limit to how fast you want to stream movies from disk, so I wouldn't care. Its just that for the same price, I can get a Synology with a 4C Celeron which wouldn't be much worse at far less effort.
It also has a PCIe x4 Gen 3 slot that you could drop a SATA card in if you really want to go big.
A 10 second search turns up plenty of options that will turn that port into 10+ SATA ports for like $65. Dunno about the driver situation in that case though.
The single M.2 slot would probably be used for the OS and maybe a cache. Having just 1 fast drive in an array usually isn't a win.
It’s not RISC-V ‘gunning’ for RPi, it’s certain SBC manufacturers who think that a RISC-V board will enable them to compete with RPi.
It may, but the success of these boards will largely depend on other factors. RPi has succeeded because of their clear focus and really strong execution.
It will probably disappoint many but having a CPU with an open ISA isn’t going to be an overriding factor in determining whether any particular SBC succeeds in the market.
They're rarely in stock even at Micro Center. I ended up dragging out an Asus Tinkerboard, languishing in a drawer, for a project. I was a lot happier with it after I ditched the "Tinker OS" image in favor of Armbian.
Completely agree! I bought a couple of Orange Pi Zero's a while ago to make a small cluster. As soon as you want to do something slightly more than just booting it into linux, you quickly fall into a space with little to no documentation. If you're lucky, you can find a sketchy media share site with some documents, or an abandoned forum post. Incredibly annoying when you just want to get something running.
The Broadcom chip, yes, but the NDA-encumbered firmware has been reduced to such an extent that you can in fact boot this either fully-functional with very few closed blobs, or almost-fully-functional with no closed blobs at all.
All device drivers onwards are just open and can be kept up to date and used in custom kernels all you want. This is the big difference with other SBCs where you can't really use the devices without closed, version-locked drivers and blobs, and there is no incentive for the manufacturer to make a super-thin encumbered shim to give the most leverage and freedom for everyone else to build on top of that.
The popularity didn't arrive before the intent and work was done to make it hackable, it was the other way around. That, in turn, created the mindshare to make community-driven drivers and alternate firmwares for the VideoCore boot stage.
This is also why they kept the BCM lineage as simple as possible across the PI revisions so all the public reverse engineering and hard work wasn't for nothing and was still portable.
None of this can be said about any RockChip, MediaTek or HiSilicon SoC. Those are more of a consume-and-throw-away type of deal, except for maybe the high-end long-life platforms that share IP with Android devices that also happen to have PM-OS or some XDA fanbase to work on it. Even then they usually lack community knowledge and commercial effort to make it worthwhile.
The closest was the TI-based series like the BeagleBone, and that was for precisely the same reason the Pi got a good start. The bad thing about the BeagleBone was that it didn't have a "see something on your monitor out of the box" experience.
There's also the Olimex boards (and related Freedombox project)[1], which can boot with no binary blobs :)
They have an interesting philosophy in their definition of OSHW includes making it easy for others to produce their boards. So not just publishing schematics, but facilitating manufacturing as much as possible.
> Olimex's A20 OLinuXino Lime2 is a fully Open Source Hardware (OSHW) single board computer. This means that the designer is actively helping people using the platform for their own designs, and supports them in adding hardware functionality and production advice. This is a part of freedom that is often overlooked, but very much aligned with the FreedomBox goals.
The issue with the AllWinner Sunxi chips is somewhat similar to the VideoCore booter where an internal ROM is required to boot the CPU; this has been open sourced somewhat recently, but we can't really inspect or change it.
On the other hand, it's not really that much of a big deal since unlike some other chips, it doesn't lock you out of anything, it just does normal basic stuff like making sure the WDT doesn't reset your CPU before you have had a chance to setup the bare minimum of registers and interrupt tables. For me, I'd either have a chip that has a boot vector outside of itself (i.e. some fixed SPI address) or something so small and measurable that it doesn't really matter much (like this BROM).
The big 'next gen' problem we have is somewhat separate but regarding root of trust in hardware it's nearly impossible to make trusted hardware (from a software perspective) without some device specific PKI that is inside the main CPU and cannot be modified from the outside. The big downside is that there is no way to do this after the fact (otherwise a malicious person could do the same), and doing it ahead of time ties it to the hardware vendor or even the chip fab. Sharing things like private keys to whoever buys the chip doesn't work either, as that would make all of the other chips vulnerable as well. PKI-per-chip doesn't work either, as you wouldn't want to maintain a PKI and re-sign everything for evert individual chip.
eFuses seem to be the only other way, or (E)PROM, but those can be attacked using power hacks (i.e. using a ChipWhisperer).
Perhaps a free and open hardware root of trust is just not feasible.
i have olimexs sunxi boards and they have a blob bootloader with no sources so they are not completely covered, only hardware as it mentions. but this is common for arm of course.
on the flipside thats still leagues above rpis and you can buy the chips for your own use unlike the broadcom ones
Thun sunxi family of chips is really badly supported by the manufacturers, but the mainlining effort (as documented at https://linux-sunxi.org/Linux_mainlining_effort) is going pretty well. It's still a bit risky if you don't buy an entire integration package from one of the big vendors and at that point you're NDA'ed so hard you might as well go Broadcom or Qualcomm.
BeagleBones also don't seem to get updated very often. The BeagleBone black is overdue for a version 2 with a faster CPU, double the memory, and double the built-in eMMC; especially at the $50 price point.
The i.MX SoCs seem really nice, it's probably one of the few mainstream ones I haven't personally worked with (only wrote software that targeted it while fully remote).
Most of the fully open designs seem to be limited to a handful of silicon like Freescale PowerPC, a few ARM and MIPS SoCs and RISC-V-based systems which can still have closed Boot ROMs of course (like Intel and AMD x86 CPUs).
At some point I had high hopes there would be a reverse engineering effort for the Marvell Armada chips but that never really went anywhere and a ton of otherwise useful boards are essentially useless nowadays.
I dunno. I've been shipping iMX-based designs for over a decade now and I think it's about as open as you can get. Yeah, there's a blob for GPU and a microcode blob for DMA-based blocks but otherwise I can whip u-boot and a Yocto package and make it do whatever I want. If you need a desktop to make your system fly, I don't know what to tell you.
IMO the people stressing about open designs are the ones that don't want to pay for anything above RPi prices. Like I said: job security.
It's not immune to supply issues as well, but that's because a ton of mid-range automakers use it in their IVI systems. The 7 is a safe haven because it doesn't have the video and camera codecs in hardware.
I keep an eye on RISC-V as well, but until I can get one with a 5-10 year production horizon I'll wait to order eval kits.
Yeah the near-term and long-term RISC-V products haven't materialised yet. Software hasn't matured all that much either.
I was looking at the iMx8 but like you said, anything with automotive or embedded applications in mass produced systems is hard to get. I've seem them used in security devices that do a bit of on-device pre-authentication and even there I'm hearing about supply issues. It was mostly Apalis COM based but they had the benefit of switching between a Tegra and iMx version whenever supply was getting constrained. (or essentially the prices started getting bumped before the next order cycle) I think the lead times for some models became over 36 months at some point (either the imx8 ones or the Tegra ones)... yikes.
Regarding the GPU and DMA blocks: that seems to be the standard at this stage. I guess it's because it's mostly licensed IP and because they need to honour the NDA from their upstream vendor, we're just getting the blobs as a side-effect. Same with the Zinq and some of the Sitara GPU cores they got from PowerVR. Luckily, that last one has gotten a lot of FOSS attention and besides loading some startup firmware or microcode it's largely free.
The whole 'freedom' thing doesn't have to be an ultimate goal here, but it does have the nice side-effect that it opens up the use of mainline source trees, broadly used and well-maintained tools and toolchains etc. instead of just some giant tarball the vendor prepared for a specific kernel and boot loader combination. And if the vendor decides to focus on the next new shiny thing, you can just port/upstream sources as needed to keep your project going, vendor be damned.
I've been using Toradex as well lately because of the pin compatibility. Apalis and Colibri are pretty solid products. Kind of makes me wish the SOM standardization movement hadn't fizzled out because that might have made some of the supply issues less problematic. Or maybe not.
Also, the SODIMM connector is long in the tooth and gives off a shitton of RF radiation especially when you're driving an LCD over the rails. But the alternatives like the Hirose mezz connectors aren't optimal either.
NXP/Freescale's kernel isn't the greatest but at least they try to get close to mainline. TI gets a thumbs up as well.
Oh yeah, the interface definitely leaves a lot to be desired. It's almost like it's getting PC104-legacy-ish at this point. On the other hand, the high density interconnects (even the ones way back from when Motorola and Apple started to make PowerPC daughter boards) are a PITA to work with when you need to do anything except one-off assembly...
Perhaps some form factor with a required low-density power + slow data interface and an optional high-density high-speed data interface would be the sweet spot. But if even something like M.2 standardisation tells us anything, even that is going to be a mess.
I guess we're stuck with foil tape for the time being.
I would strongly recommend that Raspberry Pi explore a RISC-V line of SBCs. They already have established that they are not locked to ARM with the recent Pico device (https://www.raspberrypi.com/products/raspberry-pi-pico/), so they might as well do a RISC-V line.
RISC-V is much more open than ARM, but it is definitely lacking in performance and widespread support (and integrated GPU?.) Thus do not dump the ARM line, but add an alternative so as this market further develops, Raspberry Pi is there.
Broadcom don't want an open hardware platform. Look at the license on the Pi bootloader and their legal behaviour when Odroid started selling a Pi clone. The entire Pi hardware ecosystem is setup so that the Pi Foundation are at the top of the food chain and it's been a massive success. RISC-V is the last thing Broadcom want on a Raspberry Pi.
Don't misunderstand this as a criticism either. The rest of the hobbyist SBC ecosystem has had no such guidance or overarching plan, and it's a complete mess of overpriced and/or poorly supported boards. Broadcom put in the hard yards to make their product successful and we're all better off for it.
Does Boardcom own Raspberry Pi? Or are they independent entities? Is there a contractual obligation between the two that prevents Raspberry Pi from using other CPU vendors?
If there is a requirement to stick with Boardroom, can Broadcom start experimenting with RISC-V? It is probably strategy for Broadcom as well...
All the Pi Foundation engineers are either Broadcom employees or ex employees still affiliated with the parent. So yes, Broadcom do effectively own and control the Raspberry Pi Foundation.
Again that's fine and the 10+ years of excellent Raspberry Pi user experience speak for themselves. I'm glad Broadcom did this.
But the purpose is to sell Broadcom SBCs, not to make an open source hardware platform.
IF there is a RISC-V Pi, it'll be because Broadcom see benefit for the rest of their product lines. Not to make open source Linux and ISA nerds happy.
> All the Pi Foundation engineers are either Broadcom employees or ex employees still affiliated with the parent. So yes, Broadcom do effectively own and control the Raspberry Pi Foundation.
And yet RP2040 exists; an in-house ARM design manufactured by TSMC.
> All the Pi Foundation engineers are either Broadcom employees or ex employees still affiliated with the parent. So yes, Broadcom do effectively own and control the Raspberry Pi Foundation.
Both parts of this are completely wrong. I live and work in Cambridge UK, and know several people who work for Raspberry Pi.
A small number of the original Pi staff (primarily Eben Upton) are former Broadcom employees who maintain a good relationship with Broadcom because it's good sense to remain friendly with the source of all your chips. Notably Eben is not an employee of Broadcom any more. He used to be both but hasn't for a couple of years.
The Raspberry Pi foundation is a charity that is not controlled by Broadcom. Broadcom are merely a key supplier.
> But the purpose is to sell Broadcom SBCs, not to make an open source hardware platform.
RPi’s purpose is educational - consistent with their charitable status - it’s definitely not to sell Broadcom SoCs or (except to the extent that this overlaps with their educational purpose) to make an open source hardware platform - although it seems a lot of commenters here think it is or should be.
A less tinfoil-hat view is that Raspberry Pi, who have been members of the RISC-V foundation for years, will evaluate the possibility of a RISC-V Pi when someone capable of producing a RISC-V SoC in volume offers to produce one at an attractive price.
I believe the meaning is that RISC-V is trying to take market share from Raspberry Pi and Legacy Chips. It's a rarely used meaning for the word "guns" which is probably why it's confusing. A better title might be "RISC-V Seeks to Challenge Raspberry Pi and Legacy Chips".
I get it now, and feel dumb - the idiom "gunning for", etc. But my brain instantly latched onto it as a noun, and kept imagining some feature of RISC-V that maybe "shoots" code into other chips.
I had the same trouble as you. I think the problem is that I’ve only ever seen “gunning for”, specifically. For example, I’ve never seen “gun for” as in “Man, that’s one determined team! I bet they gun for nothing less than the win!” — I would expect that to be phrased “… are gunning for nothing less …”.
The required number of instructions to implement for basic Linux support is rather larger on Power ISA than RISC-V. But you'd have currently better software support as a result, so it may be a wash depending on where your development effort goes.
this person makes one important point with regards to the reasons for adaptability of RISC-v.
X86 is a monopoly of the US government via intel and amd. they can literally force these companies to pull out of a nation, crippling their entire life through and through.
people do not like that believe it or not. its not fun having the USA hold your country hostage because you do not have alternatives. ARM is the same so RISC-V is a good contender to get behind for entire nations because they can fall back on this and besides, if there is no monopoly of x86/arm in the first place because RISC-v or some other architecture is common, the american armtwisting is reduced as the attack surface would be smaller.
china, russia, iran, india can develop their own thing, separate or together but not dependent on american generosity that can turn hostile, as it has in the past
It's all about the peripherals. Make them not suck and document them well and you could have a chance. Follow ESP32's lead and you'll just be another also-ran.
I would like to write 64bits assembly code paths directly. I know RISC-V ISA has good 64bis->32bits compatibility, but I am looking for something definitive here.
Why is "Guns" capitalized if the word is being used as a verb? Anybody else wonder for a moment what guns have a CPU architecture style? LOL Nobody else? Ok, carry on.
It's astonishing to me how behind the ARM ecosystem is on this. I still can't buy something like a low-end amd64 computer easily with ARM. There's a few laptops and a few cantankerous oddballs like the ROCKPro64. Then again it's Pine64 mentioned in the RISC V article, so maybe we have more years of oddballs to go.