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.
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'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 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.
> 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.
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...
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.
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.
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 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.
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.
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 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 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.
Readit News
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.
Was the idea of an open ISA leading to an open SoC was just wishful thinking?
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.
The boot process for RISC V is standardised. There are going to be far more RISC-V SBCs that support uefi than ARM SBCs.
I find the most useful there is the JH7110 TRM specifically.
There's links to a bunch more over here[1].
0. https://doc-en.rvspace.org/
1. https://forum.rvspace.org/t/visionfive-2-faq-quick-links/137...
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.
https://www.sifive.com/documentation
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.
I find the most useful there is the JH7110 TRM specifically.
There's links to a bunch more over here[1].
0. https://doc-en.rvspace.org/
1. https://forum.rvspace.org/t/visionfive-2-faq-quick-links/137...
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.
So much for NDA. Sigh
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.
Anyway I was thinking about buying it, but ended up with buying Nvidia's Jetson instead, due to software and documentation difference.
It's nice to see the project still chugging along
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.
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.
[1] https://beagleboard.org/pru
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.
Over the pandemic, started using more of the mini intel boxes in the sub-$300 space, just because of availability and price gouging.
https://github.com/RobertCNelson/omap-image-builder
I believe Robert is an applications engineer with Digikey; he does stellar work on this, thank you RCN!
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.
In any event, VF2 is the best option currently, if you wish for a board that cares about upstream support and, in general, just works.
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.
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.
Note there's several, by different vendors, with different connectivity (e.g. PCIe, M2, wifi/bt) and RAM (4-16GB range).
The CPU is a XuanTie C910, which is somewhat faster than SiFive U74 used in the JH7110 (VisionFive2), and adds pre-spec vector extension (0.7.1).
I would still recommend VisionFive2 or Star64 to most people, due to its maturity and much better upstream support[0].
0. https://rvspace.org/en/project/JH7110_Upstream_Plan
Is there any confidence to be had from the well established nature of Beagle Bone (whoever the corporate master is).
I am entirely unfamiliar with Beagle Bone, so a genuine question
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.
Whereas Beaglebone is not involved in TH1520.
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.
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.
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.
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.
Vision Five 2 it is then
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.
For some that can be worth the extra $50.
The reason I'd buy a Beagle (well, really an ESP32) isn't the price, it's the convenience of havng real time GPIOs.
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.
The datasheet doesn't mention Vector (V) extension support. Is this an error on the Beagleboard page?
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.