Okay, so is there actual documentation for the SoC used on this critter? I mean a full Databook / Technical Reference Manual, not maybe 30 pages of overview, maybe a list of register base addresses (if you're lucky), and a pile of Linux kernel patches (upstream if you're lucky, but still of less value to someone wanting to actually write code for / port something to the SoC) or an "SDK" containing a bunch of low quality vendor code for the peripherals.
I'd love to see a RISC-V SoC (not just a dinky little MCU) that has real / complete documentation. So far I have yet to find any for any of the various RISC-V based SBCs that have shipped.
RISC-V (and SiFive) caught a moment where it could be used is a way to squeeze ARM on pricing. It doesn't really meaningfully create openness on the interesting parts of the stack (core architecture, SoC architecture, etc.) on its own. In that sense, the hype is overblown.
It does _enable_ open-source cores to some degree, but that's it, someone has to take the leap to make a production-ready one. A few companies are trying, but an open-source SoC is even further down the road.
RISC-V was sold to us as the fully open CPU ecosystem but all it offered was an open design and some reference implementation in Chisel. That is not much different from MIPS which opensourced some CPUs 10-15 years ago.
A lot more is needed for a fully open RISC-V computer.
Nobody sold RISC-V as a fully open CPU or SOC ecosystem.
It simply allows for open source implementations to exists.
> but all it offered was an open design and some reference implementation in Chisel
You are confused between what RISC-V the foundation and what different people in the ecosystem do. RISC-V was started by Berkley and then they created a foundation. There are NO REFERENCE Implementation! Not in Chisel or anything else. Chisel is simply what Berkley used for some of their initial work.
And it has largely worked. There are lots of high quality open CPUs. This was certainty not the case in the past:
oh damn, I was about to go hard on an order bc I liked their location and the story. But I need more Chinese fabricated SoCs (which in 2023 are likely are pre-infected) like I need a hole in the head. I’ve seen quite a few crowds wind up in the garbage heap of history because “errbody is doing it” so forgive me while I plug my ears and scream the word No over and over again while I laugh at dem downvotin’ downvoters dat love cheap Chinese fabricated SoCs.
That's my biggest problem with personally enjoying RISC-V. I'd love to play with an application-class RISC-V processor, writing an OS for it and the like, but I'm waiting on a chip that's publicly well-documented in English.
As far as I can see, the only thing that isn't documented is the DDR startup/training code, which is a binary blob in u-boot. There are a few registers that are undocumented which need to be set to start up but I think the rest is well documented.
SiFive has pretty good documentation for their cores and chips -- they are more PC/Server class (some lowspeed peripherals plus PCIE and Ethernet) than SoC style. The databook does not have register level docs for PCIE and Ethernet but both look like off-the-shelf IP (hopefully documented somewhere -- I haven't investigated) but otherwise seems pretty thorough.
In addition to a documented RV64 SoC, it'd be cool to see some RV32 MCUs that are a little beefier -- more competitive with the mid-range Cortex M4 and M7 stuff (more peripherals, more SRAM, etc) -- instead of the existing stuff that looks similar to very tiny M0/M3 devices.
In addition to all that, is the GPU documented? Clicking "Request technical specs" on the Imagination website brings me to a page asking me for my business name, business email, business...
Last time I wanted rs-232 specs of a solar inverter, took me months to contact them and after some persuasion, a guy emailed me an NDA I had to physically print, sign, scan and send them back before they gave me a copy.
Obviously I was feeling funny so I signed Johnathan doe and they send me the file.
Turns out, that file was readily available online in forums because others had done the same thing.
I was looking at an import inverter that advertised CAN and rs485 support both on the website and in the manual's specs section with zero further mention. I emailed the vendor and the manufacturer at least 4 times requesting documentation with zero response. Seems to be status quo for cheap import junk. Meanwhile outback power systems offers protocol documentation in the form of manuals freely downloadable. Incredible stupidity.
on the contrary, in my case it was phocos.com which seems to be germany based and sells in many countries so this isn't just your rando junk but they still insist on stupid stuff
I've been very disappointed with the rollout of their most recent board, Beagleplay. There are all of these self-congratulatory videos of Jason Kridner at trade shows talking about they're making Embedded Linux more accessible/simple. Yet 4 months after release, the quickstart guides are mostly notes to future quickstart guide editors, or otherwise describe workflows that don't actually work.
Yeah, I had the same experience with the BeagleBone AI-64. Their documentation is extremely lacking. To make it worse, the whole point of the board is TI's ML inference accelerator, and TI's documentation and sample code for it are completely useless.
The Beagle hardware is great but it seems to me they just don't have the resources or focus to support the hardware they release.
I believe the 64 variant is the newer part. The older one is a 32 bit architecture IIRC.
Jetson has a big edge in software and documentation, no doubt. Poor documentation and SDKs seems to be the norm for a lot of embedded processors, especially for the AI acceleration piece.
I’m curious for this new beagle board if there’s enough documentation / software to use the AI accelerator.
I had similar frustrations a while ago when using their BeagleBone Black. Being new to embedded linux, it took me weeks to try and figure out how to get fast I/O pin access using their PRU. It took sifting through countless tutorials that were out of date and didn't work
Having random people reverse-engineer your hardware in order to document it seems... a lot less ideal than having the people who actually built it in the first place reveal some of the information that they must already know and probably have written about it.
My response to people who assume "if you have enough time to complain about it, you must have the time to fix it yourself" is typically that if you have enough time to tell someone to do it themself, why don't you?
I have a few Beaglebone Blacks kicking around the house and they're great. I've always felt the Beagle boards were superior to Raspberry Pis, and that the RPi mostly succeeded because of better marketing and outreach efforts.
I'd also say it's that the RPis are generally much cheaper and also offer (subjectively) better I/O.
For example, A BeaglePlay costs about twice what a Pi 4 Model B/4GB does in my local market. The BeaglePlay has half the ram, only one USB 2 port to the Pi's two, none of the Pi's USB 3 connectors, way fewer GPIOs, only one HDMI, no audio, etc. I do like that BeagleBoards have onboard flash though.
BeaglePlay also has sub-1Ghz wireless, (along with 2.4Ghz programmable wireless), a PRU (essentially a built-in microprocessor suitable for realtime I/O work). The core processor supports CAN, and a bunch of other features, but I'm not sure if these are broken out in a way that is usable.
Beagleboards are just different than RPis. They aren't really trying to be the same thing. RPis are small computers with simple GPIO meant for turning on and off things, Beagleboards are computer/microprocessor hybrids with GPIO meant for doing realtime I/O.
> RPis are small computers with simple GPIO meant for turning on and off things,
Maybe you didn't mean this in a way to diminish how handy Raspberry Pis are, but I've used it in tons of situations that are more interesting than turning LEDs on and off. It being a usable computer is icing on the cake. I have RPis for all kinds of things: Home Assistant using the Bluetooth module (+ external Z-wave/Zigbee controller via USB), OpenJVS for running arcade I/O emulation (GPIO for serial communication), I doubt I need to explain how useful it is to have a FlashROM setup, I've gotten a Pi to drive a Commodore SID...
I can see based on the RPi Pico which seems to have similar functionality to the Beagleboard in terms of I/O that in fact there is so much more that COULD be done, and I'm glad that we have these now. That said, I don't want people to think that RPi is a toy! Having a moderately powerful small form factor computer connected to all of this I/O lets you do things that you couldn't even when GPIO is involved. Not to mention, you can bitbang the GPIO really fast on a Raspberry Pi, which can come in handy.
Yeah agreed, and I don't think I communicated that in my comment above. It's not that the Pi is universally better in all cases, but it is better suited for many common consumer applications... Which logically leads to it being the higher selling device.
The soc on the original Black had two 200MHz PRUs which ran independently of the main processor and could be used for signalling and sensing tasks that require tight timing guarantees, and can then trigger interrupts on the main CPU.
The PRUs are simple single-issue in-order CPUs designed to make cycle-counting easy. They are more than an accidentally turing complete useful combination of a down-counter and shift-register. Don't get me wrong the RP2040 PIO is a very flexible, powerful peripheral for a sub-$1 MCU. A single PRU is probably larger than the whole RP2040.
The 2040's PIO is indeed similar but the PRU has features the PIO doesn't like IOs directly wired to CPU register bits so the result of an instruction is immediately available on IO lines.
edit: also Ti's PRU has been around waaaay longer than the RP2040 so the PRU is likely an inspiration for the PIO.
I think if they had invested in a beginner-friendly toolchain for the PRU (maybe something like an Arduino core with a virtual serial port to pass data back and forth without forcing people to implement ring buffers in shared memory), they could've carved out a much larger niche for the Beaglebone.
Nowadays, there are fast hobbyist-accessible microcontrollers with USB or wifi support that can fill a lot of the same niches, so I think they sorta missed the boat.
> I'd also say it's that the RPis are generally much cheaper
IF you can actually get one. That's a REALLY big IF.
RPis have been subsidized for a long time. The fact that the subsidy is gone means that they don't seem to be willing to release them to we plebians very much anymore. They're fine releasing them to T-Mobile, though.
Anybody not a pure hobbyist left the RPi space long ago.
> Anybody not a pure hobbyist left the RPi space long ago.
Actually, the constrained supply is because during COVID and aftermath they decided to support industrial customers to the detriment of hobbyist supply.
They're currently cranking out a million units per month and supply is returning to retail. https://rpilocator.com/ was completely bare a few weeks ago, and now there's a lot of retailers with stock (though it's still not where it should be).
Restocks have shot through the roof, and buying restrictions are being lifted here and there. I found Pi 4 and Pi Zero in stock both times I visited Micro Center this month, and when I needed one a couple weeks ago I saw it was available at PiShop.us too...
I think this month it really shifted from "trickling availability" to full deluge. Right now people like me who've wanted one but have been holding off are finally making our purchases. Once that appetite is filled, I can imagine we'll just see some places with steady stock.
Still waiting on CM4 though. Those are still backordered and out of stock most places.
> Anybody not a pure hobbyist left the RPi space long ago.
I suspect a lot of hobbyists have left too, and that's why there's so many not-quite-knockoff SBCs on the market (ranging from the respectable OrangePis to weird fly-by-night stuff on AliExpress made by a company that's already out of business before your order arrives).
But I don't know how many people are using alternatives because they want to use alternatives. Raspberry Pis have been like hen's teeth for a couple of years now. If you have a NIB Pi4, until recently you could sell that sucker and probably by 3 OrangePis instead.
But if RPis were the same price? I think they'd sell like hotcakes just like they did a few years ago, and you'd see them in every random project on Youtube. I don't know of any SBC (other than very high-end industrial embedded modules) that are as well-documented as the Pis.
I'm not sure the Pico and Pico W are going to make as much of a splash as the original did (it's harder for people to get started with an overgrown microcontroller than it is a tiny PC), but I expect them to sell very well, too. Maybe they won't show up in every disposable pregnancy test and lightbulb like the ESPs and Nordics, but I suspect we'll see them in some commercial products too.
It depends on the application. BBBs come in industrial variants (the Pis don't, so good luck using them in certain contexts), and have more UARTs, i2c and SPI buses, not to mention the PRUs...
I guess... but if industrial is really their market, I think they need to up their game in terms of documentation. "Real" industrial embedded modules tend to come with reams of documentation covering almost down to the silicon. You pay for that, of course, because writing documentation costs money, but so is having your engineers spend time twiddling bits and poking at undocumented registers, trying to figure out why your sample code works and theirs doesn't.
That said, I've seen some neat shoestring-budget prototype projects done on BB hardware, so there's some market there. But it seems like their stuff is a bit expensive for low-end learners and hobbyists and missing some of the niceties you get if you convince your boss to buy a ComExpress-based industrial module, or (if you really twist their arm) something like the Arnouse BioDigital SBCs.
PRU aside, BeagleBoards/Bones mount eMMC memory which offers much higher reliability compared to microSD cards. RPis are great for tinkering and prototyping, but I wouldn't feel safe employing them where uptime is important.
Agreed there, I've seen horrible reliability on (micro)SD cards for these little project boards. For RPi, usually use SSD over USB for primary boot, there are some nice case options for this, if you don't mind the space.
Over the pandemic, started using more of the mini intel boxes in the sub-$300 space, just because of availability and price gouging.
I’ve heard Beaglebone Blacks are great (never used them), but have to say the experience with Blue was awful. I had a hardware defect that’s apparently commonplace. It gave me the feeling (maybe unjustified) that there’s a low bar for slapping the Beaglebone label on a product. In contrast, none of my several RPi’s have had any hardware issues, and I’m pretty brutal with them.
The linux image on the beagleboard site for the Black is three years old. Is it possible to just boot generic ARM linux on the Black now? Is there another site for official images?
I'm always looking out for a nice single board computer (SBC), but my phase when I looked at all those (on paper) nice sounding SBCs through rose-tinted glasses is long gone, the only question I want to have answered when checking one out now is:
Does it have Linux kernel support in the mainline? I.e., not some weird semi-proprietary patch blob on some GitHub account basing of the 3.18 kernel or so..
If it doesn't, I can close the tab immediately and know for sure that I won't miss out. If it posted patches to the LKML, maybe even in an advanced revision integrating review comments then it might be worth looking at it later.
I've been down this road and while it was certainly an interesting learning experience in some of the mechanics of the kernel build process, module dependencies, etc. etc., it was not necessarily productive in moving the projects forward that I wanted to do with the temptingly-cheap Chinese SBCs that I couldn't resist buying.
Having learned that lesson, now I won't order something unless it's formally supported by someone like the Armbian project (or Debian, or OpenWRT, etc.). And as interesting as some of the niche SBCs are, sticking to boards that have a broad userbase saves a lot of time when you run into weird errors.
I used to scoff at PowerVR GPUs as being unsupportable & worthless, but progress has been quite good lately. Only 3 SoC supported & not this but porting should go relatively smoothly now.
Price feels high.
Elephant in the room: what the heck is that USB micro 3.0 connector doing there? Yikes! What an ugly relic. And that's the only USB on the board.
Yeah, that is my comment as well. It looks like it's also not enough to power it, you need to use the barrel jack.
On the original beaglebone and beaglebone black, a nice feature is you can connect it by microusb, and this provides power to the board but also bridges your internet connection. So with one cable you get power, ssh into the device, and an internet connection on the device.
I wonder if the amazing software support is still as good. The Beaglebone set th highest imaginable watermark for what an SBC experience was out of the box. You plug it in to a computer, boom, there's a networking port available. Accept & immediately the Beaglebone sends a DNS-SD/ZeroConf discovery message out for it's http server. The http server loads a code editor for the device, with some neat embedded samples. Within 10s of unboxing, you're looking at code & live programming the device. Unparalleled experience, to this day, far as I can tell.
I like both of those options myself, after much time spent learning & gaining confidence in how I could use uboot. Great because it leaves so many options open. I forget but I think Beaglebone might have those as well.
It is however way way way lower level than VisionFive 2. Beaglebone was an embedded system you didn't even have to know cli to be able to use. Self hosting a networking gadget + whole web based ide for itself, either back at launch in 2008 or even today, was an amazingly friendly feat.
What's true is VisionFive2 is from StarFive, and so is the JH7110, and they seem to care about and understand the value of the software ecosystem, which is why VF2 exists at all.
$150-$180 seems expensive for 4gb ram and 16gb flash when you can get an sbc with the same soc, the sipeed licheepi 4a with 16gb of ram and 128gb flash for $180, or $120 for 8gb ram and 8gb flash, or $135 for 8gb ram and 32gb flash
As someone who's bought many RPi-like boards and clones let me tell you: Minor differences in price/performance are unimportant. There's another factor that's so much more important it makes boards like the Beaglebone and RPi seem like ultra high performance bargains in comparison: Software/kernel support.
Every goddamned RPi-like SBC seems to require a very, very specific version of the Linux kernel that has been patched to hell and back. Almost always bundled with binary blobs/firmware that only work with that very specific version of the kernel.
None of these patches get upstreamed and the binary blobs/ultra proprietary who-knows-wtf-its-doing required firmware never get updated after the release. This means that you'll be stuck with whatever version of the kernel that shipped with the device forever. Complete with all the bugs and vulnerabilities that get discovered later.
Never again! Either the vendor needs a history of staying on top of things or they need to make some serious promises about upstreaming kernel patches and drivers.
Example of a terrible SBC vendor you should never buy from: Orange. All the OrangePi SBCs are exactly as I described. You can expect any bug or security issue that exists at release to be a problem with that board forever. They will never get fixed. They might release an update or two within a few months of release (if it's real bad) but that's all you'll ever get.
The VisionFive 2 developers are working on getting things upstreamed/open-sourced for their board. IIRC the kernel has already mainlined many (if not all) of the patches.
Some of the real issues are as follows:
1) Most companies use Debian as a base. Debian has a notoriously slow release cycle. This means it takes loads of time to submit patches -> get approval -> get merged in a merge window -> wait for debian to use new kernel with new code.
2) The GPU situation is a mess. No decent (compatible) vendors with open source GPU drivers exist. Imagination is said to be working on open source drivers, but with no real release date, we are stuck using closed source blobs. Once drivers and Mesa get updated, we then have to wait for a new release of Debian to pick these up.
3) Far fewer people use these boards over a Raspberry Pi. This means community support takes longer to develop. The VF2 has other distros like Arch and Ubuntu, for example, but no real active community behind them. Last I checked, hardware GPU acceleration was not working in these distros.
As someone that has actually shipped RPi-like boards and clones, I'll tell you that it's just part of the job description.
They ALL suck, some just suck less than others. Broadcom, Renesas? The worst. ST, NXP, TI? Slightly better than fully sucking. Look to the chipmaker (ST, NXP) and not the board maker (Orange) for a guide in how well things go.
But the RPi is broadcom and arguably the best supported. Obviously this is special.
From experience I agree with you, the chipmakers suck because they utterly fail to be open source when they're one of the groups that needs it the most. It is to the extent that I would advocate for laws in the theme of right-to-repair to force chip vendors to provide source for necessary code to use their products to consumers. (in this case open source in the narrowest definition, they can keep their copyrights but would be required to distribute source to end users in a form and with a license that makes them usable)
If the question is "are any of the SBCs worth the trouble?" and the default answer is no unless I have a really good reason and want to dedicate the time to building the janky software stack (I don't), or they're from a small list of vendors I'd trust won't be a mess (RPi, nvidia, beagle, ... that's it off the top of my head)
There is some sort of close relationship between Broadcom and the raspberry pi foundation which is not entirely clear, they are a bit more than just customers although companies use the “partnership” label to mean just about anything.
The relationship is very clear: Upton was a Broadcom FAE that started the RPi Foundation. The secondary story was that he found a use for an orphaned SoC and embarked on an 'educational' quest to make small computers for classrooms.
The real question is if Broadcom is devoting internal software resources to improving the ecosystem, or if it's coming from the devoted users. I don't track commits on kernel.org enough to know what's what.
Please excuse my ignorance here, but are you saying that the board makers have no say on what chip they want to incorporate into their board? And those chips firmware are not open or at least accessible to the board makers?
Board support packages very rarely get updated and usually target a very specific kernel version.
You move off that kernel version, no BSP, no boot. sad times.
This is one reason why you don't get android phones supported past the android release shipped.
You're completely at the mercy of the SoC provider. Promises of 'n' years support are quite often quietly dropped after 18 months, when they realise all the engineers have moved to working madly to get the latest SoC's BSP out of the door.
What I'm saying is treat the board as a development harness to get your project going. If you have issues with the processor don't take it up with the board maker because they're usually just as clueless. The exception would be boards like RPi or Beagle where the designers are tight with or owned by the chipmakers themselves.
But the fundamental difference here is that most people buying SBCs are treating them as self-contained COTS compute modules.
As someone that has worked with these EVKs for decades, you never treated them as part of your final product. But with the advent of Beagle and RPI, that's where we are now.
But when you buy an RPi or Beaglebone as the core of your industrial smelter and expect support for that module comparable to, say, a module from Kontron? You're going to be disappointed.
Are these vendor kernels good enough to run some sort of hypervisor and pass through devices at the lowest possible level to (updatable) guest kernel(s)?
The idea here would be to run things like the TCP stack, USB from the lowest proxy-able level the in USB stack, etc in the guest kernel(s), as well as the entire application level, so as to reduce exposure to vendor kernel bugs and feature freeze leaving it only with minimal SOC-specific nitty gritty. For GPIO the vendor kernel could be used as a PRU of sort, passing messages to the guest kernel for actual processing.
Then the vendor kernel is just treated as a BIOS/blob getting in the way as little as practicable, it's very ugly but would allow using all these boards, also same method could possibly be used to recycle obsolete android phones.
Wait, I used OrangePi's with Allwinner chips before precisely cause of their cheap price and mainline linux support. At the time (~5 years ago) Rpi was worse, foss-wise. Here is a wiki documenting the efforts: https://linux-sunxi.org/Linux_mainlining_effort
What am i missing?
i use orangepi prime boards in production as remote NIDS. i used Armbian (a great debian porting project that does what the maker should have done ) until orange released their Debian 10 img. I put an endurance rated sdcard in those pis and they run like the little pink bunny! Love these little orangepis. I have tried a handful of other boards ( beagle, raspberry, banana , have a whole stack. too many to remember) but the oranges are solid. On a lot of these little SoCs, you can use the raspberry pi gpio software since many of these boards follow the same gpio standard & plug in/out.
I agree with everything except I don't think I would have called out OrangePi as the worst of the lot -- at least not anymore.
They seem to have basically outsourced their software maintenance to Armbian, and if that relationship holds it's probably a win-win. Armbian's build system is really nice, IMO.
FriendlyElec are borderline; they make nice hardware but definitely seem to take a "here's a kernel we got to boot once, good luck!" attitude towards software support. Some of their boards are supported by Armbian but often without key features due to lack of documentation or binary blobs.
Below that is a vast sea of largely-anonymous Chinese-based hardware companies who drop a design (sometimes really neat) into the world, then disappear without a trace. Mostly I think these are designs whipped up quickly to use up spare parts, or originally designed for embedded use in a particular product and being sold on the side. (I've definitely seen 'development boards' that were clearly designed for security cameras or TV decoder boxes, f.ex.) But you are buying yourself a new hobby if you decide to get one.
yes, especially because there is an industrial variant that works down to -40 C. We use them in our detectors in Greenland. rpi's sometimes work at low temperatures, but are not spec'd for it (plus they use tons of power compared to the BBB).
Yes, for the application I used them in, we were concerned about both the upper and lower limits (heat from operation + cold when turned off in the winter). Outdoor installation, with hundreds of units per site.
Every time I opted for cheaper clone of beagleboard or RPi I ended up regretting it when I inevitably had to spend hours building custom kernel patches and struggling to get it working reliabily. The more expensive boards usually work out of the box with mainline kernel.
well, if the soc is the same, thus same cpu, gpu, and npu, kernel and userspace support should be also roughly equal, tho the device tree will differ between the two devices. i do agree that many of these sbc computers have poor initial support and many end up remaining that way. perhaps we should be requiring that mainline linux support, and working drm drivers, for gpu, exist before the product is released.
If it is just device tree that should be less painful, and probably also faster to upstream.
I'm just hesitant to buy one of those without having some 3rd party confirm everything works well out of the box, and the more obscure the device the harder to find such accounts.
Sure there are GPIOs -- didn't you see the "cape" connector?
The SoC had quad C910 OoO cores (similar to A72) as the application processors. There is also a simple E902 (in-order, 2 pipe stages, RV32EMC ... basically Cortex M0 equiv) in the Always-On subsystem and a C906 (64 bit in-order, 5 pipe stages, used as main applications processor in numerous AllWinner D1, Bouffalo BL808 etc boards) in the "audio" subsystem.
I don't know what machine you're referring to. The BeagleBone, or some other SBC?
Looks like this board (if you mean https://linuxgizmos.com/dev-kit-debuts-risc-v-xuantie-c910-s... or something like it) runs Linux (android or debian). With the BB, you could at least program the PRUs to handle these problems directly in hardware. With the ESP32 you're writing code that runs in an RTOS. Most SBCs I've seen make you use userspace to access GPIOs. unfortunately for my use case, I have about a 100 nanoseconds to move a signal from one GPIO to another, and if I drop an interrupt, it means part of my data ends up missing.
I'm referring to the subject of this post, the BeagleV "Ahead", of course.
Why would I be talking about the RVB-ICE? They use the same main CPU cores, but a totally different SoC.
The TH1520 has, as I wrote in my last post, two secondary RISC-V CPUs that are not managed by Linux, and which can be used for real-time tasks.
Of course you don't HAVE to run Linux in the first place if you don't want to. RISC-V chips are very standardised and easy to program bare-metal. The only tough part is usually DRAM and clocks initialisation. You can use the board's standard U-Boot SPL for that if you want, then either replace the Linux kernel by your own code, or also replace the higher level part of U-Boot.
Is there documentation on how to program real-time on the TH1520 (specifically, running Linux on the main app processor and some interrupt handlers on the secondary CPUs?
I don't think this one does, but the other models such as beaglebone black have 2, 200Mhz microprocessor cores that can access GPIO and shared memory in realtime (without an RTOS). It's a killer feature, you can have the best of both worlds. For example, a python program running in userspace, interacting with a microcontroller doing GPIO stuff quickly and in realtime.
I known the BB can do this. T he question is if any of those SBCs do realtime gpios. Raspi SBCs have gpios but you can't trivially write an interrupt handler than runs in kernel space
I came here to say exactly that. Right now ARM SBCs (especially the RK3588 ones) are pretty competitive -- but, ironically, so are Intel 5xxx and N100 mini-PCs.
Sure you'd like RVV 1.0, but there is currently zero shipping RVV 1.0 hardware.
You might see poor price/performance EVBs with RVV 1.0 in 2024, e.g. $500-$1000+ with similar specs to this.
I don't think you're going to see anything like a quad core 2.0 GHz OoO (with 2 OoO vector pipelines) board with RVV 1.0 for $150 until 2026 at the earliest.
Note that there are currently no consumer rvv 1.0 cores out there. You also can't expect much support for pre ratification rvv. I needed to patch vector support into the ubuntu build for my MangoPi MQ pro board, and use an old toolchain to be able to compile and test my rvv 0.7.1 code.
For a lot of applications this is really not competitive. You can get an Intel/AMD mini PC on Amazon for a little over $100 these days, running fully supported Linux.
Do you understand that these boards are the size of a credit card? Those mini PCs are far larger than these. I can take a Raspberry Pi and stick it inside a picture frame, for instance. I actually built an e-reader using a Raspberry Pi Zero 2 W. Even a full size Raspberry Pi would have fit in the case...an x86 'mini-PC' would not. Sure, I could probably get something x86 that would, but I'd have to spend a ton of money (like hundreds of thousands or millions)
If you rip the motherboard out of a NUC you'll probably end up with a board of a very similar size. The laptop style cooler takes up more space than the board.
The dimensions are different (more square, more USB ports, no GPIO) but they're not as big as you may think. A NUC is about twice the size of a Beaglebone with much better performance and software support, plus the advantage of being able to pick your own RAM and storage options.
For something like a picture frame you can easily use a NUC. For an e-reader you'd run into form factor issues for the cooler, but for something that low spec an ESP32 would be even more compact without sacrificing much.
But the void has been already filled if by Minisforum and many others.
I just got an N100, Dual NIC, 8GRam, 256G mSata SSD with a 9W TDP for AUD $270.
I have quite a few NUCs, and they are awesome. It's a shame Intel is getting out of the platform. But, for the money this one I got last week is incredible.
It's surprisingly fast and runs on the smallest plugpack I ever saw for a full PC (and it's probably hollow).
Running Linux of course. Installed Bookwork and everything works.
That's why I said "for a lot of applications" instead of "all applications". Many people buy these ARM boards for regular computing roles, such as file server, game emulation etc. And even in embedded roles, sometimes the application can accommodate the slightly increased size, with the MASSIVE advantage of using widely available builds and commodity PC hardware.
That depends, something like this 'GMKTec'[1] is Intel, and not really any bigger than an RPi 4 in a case? Obviously you can get smaller with an RPi Zero W, but in a case it'd still be half as big.
At the moment I have no plan to acquire yet another beagleboard, i.e. this BeagleV, a bit pricey for potential projects at scale, and I don't need those media related ports, though the AI NPU seems nice for edge AI.
If I may ask (I'm pretty bad with hardware, but learning):
What does "RISC-V" is royalty free mean? Does that make an RPi more expensive because they have to pay ARM?
What do the H.265/H.264 encoder/decoders do? Is that important when connecting a USB camera (converting from whatever the camera provides to H.265/H.264)? And then is it the same thing, i.e. that an RPi is more expensive because it has to pay to use H.265/H.264?
More than the royalties, shouldn't we care about binary blobs? The more open the hardware is, the easier it is for the community to maintain it, right?
> What does "RISC-V" is royalty free mean? Does that make an RPi more expensive because they have to pay ARM?
The RISC-V foundation published the specs for RISC-V and the extensions. These are available royalty-free and can be implemented by anyone. There are various chip designers that create RISC-V compatible CPU cores, and you would pay one of these companies to incorporate that design onto your own chip. Or you could adapt one of the open-source CPU designs, but those are not very high-performance. Or you could design your own, like Western Digital has.
For an ARM design, you pay a license fee to ARM Ltd, even if you design your own core.
So what really matters is how much you are paying to license the CPU core, if you don't design it yourself.
> More than the royalties, shouldn't we care about binary blobs? The more open the hardware is, the easier it is for the community to maintain it, right?
Yes, but the chip vendor needs to publish full documentation for the hardware too. Without that, it is harder to write your own device driver software.
I look at all the chip features like video encoding and video decoding and I think "that is super cool, pity the software will never fully enable the potential of the hardware".
Then I return to the ordinary Intel world where stuff works.
I've been quite happy with the documentation for the AM335x processors on the standard, ARM-based Beaglebone Black.
But the readme at [1] is exactly why I'm reluctant to pick this board:
> Tracking mainline u-boot/kernel with T-Head patches as needed
> Additional SoC details (Chinese language is good) - pointers to licensed IP is fine
> Clear legal path to usage:
>> Verify the IP in the SoC is licensed for use
>> Verify the IP user documentation can be public [emphasis original, why not the developer documentation?]
>> Signed 3P agreement
> SDK source required to test board
> Documentation needs to launch:
>> Additional SoC details (Chinese language is good) - pointers to licensed IP is fine
You'll pay more for an NXP, TI, or ST-branded SOC than for an Allwinner, Rockchip, or "T-head" one, but even if all you're paying for is documentation it's well worth it IMO.
Edit: It's great that the processor core is an "XuanTie C910 open-source RTL RISC-V". Open-source RTL, wow! The Verilog is up on GitHub [2]! You'll never get that from TI! But the processor core is only a small part of the SOC, there's a ton of other peripherals and other closed-source, closed-documentation IP to run them.
Note that OpenC910 isn't the same core as the shipped one on this device. OSS version doesn't have RVV where the closed one that is actually shipped has RVV 0.7.1 for example.
Agreed. And in addition to these development feasibility, sustainability, and open source concerns/requirements, some applications will also have to look at provenance.
It's a typo. The BXM-4-64 is advertised by Imagination as doing 4 pixels per clock, and 64 FP32 per clock. At 50 GFLOPS, that's roughly 3Gpixel/s, not 3Mpixel/s.
I got 7.64 SPECint2006 on my Lichee Pi 4A @ 1.85 GHz (same processor, different board). Raspberry Pi 4B @ 1.5 GHz gets 9.22 with the same compiler version and flags.
In fairness, the Cortex-A72 in the Raspberry Pi is the nth iteration of Arm cores whereas the C910 is essentially the 1st generation (the C906 is completely different and in-order). I wouldn't make too many conclusions based on this about the future of RISC-V and its implementations, but I'm looking forward to the next wave of higher performing cores coming to market.
C910 has claimed 6.11/GHz SPECint2006, which at 1.85 GHz would make it 11.3.
You might not have the optimal settings.
It's also possible that the TH1520 doesn't have enough cache for SPECint.
In my own testing building riscv-gnu-toolchain on both I've found the SG2042 EVB with -j4 to be 1.55x the speed of the LicheePi4A. The SG2042 had the same C910 cores but a lot of L2 and L3 cache (and 64 cores, but I limited it to 4 of them for this test).
Scaling your 7.64 SPECint by 1.55x gives 11.8, so that's the same ballpark.
My VisionFive 2 does the same build 1.13x faster than the LiCheePi4A. That's using the same src&build trees on the same Samsung 2 TB USB3 external SSD.
The TH1520 has 64k L1 icache and 64k L1 dcache, plus 1 MB shared L2 cache.
The JH7110 in the VF2 has only 32k each L1 icache and dcache, but 2 MB shared L2 cache.
The SG2042 has 64k each L1 icache and dcache, 1 MB shared L2 cache per 4 cores (so far, the same as TH1520), 4 MB of local L3 cache per 4 core cluster, and 60 MB of L3 cache on the other 15 clusters that is also usable at about 2/3 the bandwidth (twice faster than RAM).
The Pi4 also seems to have only 1 MB L2 cache. Which makes me wonder ... was your code compiled 32 bit or 64 bit?
More likely they are using compilers that support their private extensions. I call BS on all vendor supplied benchmark results, that includes SiFive, as they don't really represent results users are likely to get without extensive tuning.
ADD: it's unlikely the amount of cache and more likely their quite long L2 hit latency which is a lot longer (in wall-time) than, say a Cortex-A72.
L2 size, L2 speed, whatever, they're both down to the goodness of the SoC design, not the ISA.
For that matter, the 20% difference you found could be compiler maturity. And it's small enough that it's hard to notice without sitting two machines doing the same thing next to each other, or using a stopwatch.
But yeah, could well be that TH1520 has a duff L2 cache design in some way.
Much more shocking to me than the Pi 4 beating the TH1520 by 20% is the in-order dual-issue, 20% slower clock speed JH7110 beating it by 13% on a GNU toolchain build.
Many, since it's been out in the LicheePi4A for a while. Similar to Pi 4.
On my primes benchmark it comes in (at 1.848 GHz) at 10.43 seconds vs 12.1 for a Pi 4 running A64 code.
The other common RISC-V SoC right now, the JH7110, which is on quite a bit cheaper boards such as the VisionFive 2 and Pine64 Star64 and Milk-V Mars, comes in at 14.9 seconds. That's more or less an A55 equivalent.
You try coming up with something that you can run on an AVR and an i9!!
I submit that it is no worse than Dhrystone or Coremark, and correlates well with those while being a lot less code. It is better than those at being impervious to tricky compiler or library optimisations -- I have seen for example libc string function implementations that unroll a loop processing 32 bit words 5 times, not 4 or 8. Why? Well, Dhrystone just happens to call that function with an 18 byte string. Every time. Ugh.
They all exercise just the CPU core (load/store, arithmetic, branching) and L1 caches or SRAM. Which is not a full-system test, but is valuable information.
I'd love to see a RISC-V SoC (not just a dinky little MCU) that has real / complete documentation. So far I have yet to find any for any of the various RISC-V based SBCs that have shipped.