BeagleV-Ahead RISC-V board(beagleboard.org)
beagleboard.org
BeagleV-Ahead RISC-V board
https://beagleboard.org/beaglev-ahead
161 comments
This is a Wujian 600 from Alibaba (!). To my knowledge there is currently no publicly available documentation from the chip manufacturer.
Was the idea of an open ISA leading to an open SoC was just wishful thinking?
Was the idea of an open ISA leading to an open SoC was just wishful thinking?
Not entirely, but the process is very slow.
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 (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 source RTL for the roughly Arm A72-equivalent cores used in this were open-sourced several years ago.
https://github.com/T-head-Semi/openc910
The same cores are used in the 64 core SG2042 workstation/server SoC.
https://github.com/T-head-Semi/openc910
The same cores are used in the 64 core SG2042 workstation/server SoC.
Open ISA is necessary but not sufficent. One step on a long journey.
That is my point exactly.
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.
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:
- https://www.openhwgroup.org/
- https://www.chipsalliance.org/
- https://opentitan.org/
There are many more.
> That is not much different from MIPS which opensourced some CPUs 10-15 years ago.
Its very different because you were not allowed to use those MIPS chips or built products with it. The only one that was as open was SPARC 32-bit.
What we don't have is cheap mass produced SoC that are well documented. But that a general problem of the industry not just RISC-V.
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:
- https://www.openhwgroup.org/
- https://www.chipsalliance.org/
- https://opentitan.org/
There are many more.
> That is not much different from MIPS which opensourced some CPUs 10-15 years ago.
Its very different because you were not allowed to use those MIPS chips or built products with it. The only one that was as open was SPARC 32-bit.
What we don't have is cheap mass produced SoC that are well documented. But that a general problem of the industry not just RISC-V.
The link they liisted to the SoC is also broken: https://t-head.cn/TBD
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.
>Was the idea of an open ISA leading to an open SoC was just wishful thinking?
The boot process for RISC V is standardised. There are going to be far more RISC-V SBCs that support uefi than ARM SBCs.
The boot process for RISC V is standardised. There are going to be far more RISC-V SBCs that support uefi than ARM SBCs.
The boot sequence is standardised on all CPU architectures. But is the boot firmware (and specially the M-mode fw) open on all devices?
ARM addressed this by creating ATF which most companies now use:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/
ARM addressed this by creating ATF which most companies now use:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/
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.
If I had to wait for documentation in my native language, I would never work on any modern chips, period.
The more mature VisionFive 2 and its SoC, JH7110, have some documentation[0].
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...
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...
Agreed, the best I have found so far is the SiFive Unmatched: https://www.sifive.com/boards/hifive-unmatched which is a full mini-itx motherboard. It's not a SoC though.
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.
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.
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.
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.
The more mature VisionFive 2 and its SoC, JH7110, have some documentation[0].
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...
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...
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...
Haha.
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
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
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
Imagination is trying to opensource their GPU drivers.
To be more exact, they've contracted the services of a third party company to write a new mesa3d driver.
Their proprietary driver will stay closed, but hopefully they'll be able to deprecate it at some point.
Their proprietary driver will stay closed, but hopefully they'll be able to deprecate it at some point.
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.
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 think the newer AI board from beagleboard is "BeagleBone AI" without the "64"?
Anyway I was thinking about buying it, but ended up with buying Nvidia's Jetson instead, due to software and documentation difference.
Anyway I was thinking about buying it, but ended up with buying Nvidia's Jetson instead, due to software and documentation difference.
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.
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
Great opportunity to contribute
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.
It's nice to see the project still chugging along
It's nice to see the project still chugging along
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.
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.
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.
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.
> Beagleboards are just different than RPis.
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.
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.
Are PRUs their version of the RP 2040's Programmable IO (PIO)?
PRU stands for Programmable Real-time Unit.
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 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.
so yes, then.
It's kind of a middle ground, it looks more like a barebones MCU.
RP2040's PIO is extremely limited with only 9 available instructions, this looks a bit more involved, but functionally it's very similar.
RP2040's PIO is extremely limited with only 9 available instructions, this looks a bit more involved, but functionally it's very similar.
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.
edit: also Ti's PRU has been around waaaay longer than the RP2040 so the PRU is likely an inspiration for the PIO.
CAN is likely doable via the PRU's.
My favorite part of the BeagleBoard are the PRU's: two little 200Mhz realtime coprocessors. [1]
[1] https://beagleboard.org/pru
[1] https://beagleboard.org/pru
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.
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.
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).
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.
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.
Digikey has CM4's right now-- 270 in stock.
> 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.
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.
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.
sure, there are better options, but we don't have "engineers" and instead "grad students" :).
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.
You can get CM4s with eMMC memory now, but if I was doing a CM4, might as well just use an nvme ssd.
Yeah, NVMe prices have dropped so much you can get hundreds of GB for like 15€.
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.
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?
Robert C Nelson's OMAP Image Builder is excellent. You can use it to build Debian or Ubuntu images for the Ti AM335/OMAP (e.g. BeagleBone Black) SoM:
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!
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!
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.
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.
Yes, a hundred times yes.
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'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.
The Vision Five 2 supports uefi and is going for upstream kernel support. https://forum.rvspace.org/t/linux-kernel-6-3/2648/2
It'd be more accurate to say that it'll eventually support UEFI and that there's already a proof of concept available.
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.
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.
Overall nice looking board.
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.
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.
Agree,
Any reason why is the Type-C not used?
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.
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.
With a serial console and knowledge of how u-boot works, VisionFive 2 is about as good.
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.
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.
Yet another TH1520 board.
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
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
> I would still recommend VisionFive2 or Star64 to most people, due to its maturity and much better upstream support
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
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
I do not own a Beaglebone either, can't say.
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.
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.
I do not understand why VisionFive2 being from StarFive is important. What is VF2? "github.com/starfive-tech/VisionFive2"?
Starfive is working on upstreaming their SoC's support.
Whereas VisionFive2 is a means for Starfive to leverage the community to accelerate support, while at the same time giving them a compelling SBC.
Whereas VisionFive2 is a means for Starfive to leverage the community to accelerate support, while at the same time giving them a compelling SBC.
$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.
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.
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.
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)
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)
Were the kernel and BSP improvements and ongoing support for RPi produced by Broadcom, or by the user community?
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.
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.
Rinse and repeat.
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.
Rinse and repeat.
This problem wouldn’t exist if linux had a stable ABI.
Hopefully Fuchsia’s stable ABI promises pan out and companies start releasing drivers for it.
Hopefully Fuchsia’s stable ABI promises pan out and companies start releasing drivers for it.
Haiku is already working on the board, although you need to build your own, as there's no public builds for it.
Haiku remarkably does have proper driver APIs and stable ABIs.
Linux is and will remain painful, on all platforms, until it is finally deprecated, and for a while longer after that.
Haiku remarkably does have proper driver APIs and stable ABIs.
Linux is and will remain painful, on all platforms, until it is finally deprecated, and for a while longer after that.
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.
Right, which is what GP was saying: stick to those that are able to support longer than zero time horizon.
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.
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.
Support is the S in IOT.
I thought that.... oh, Security is the other S. Got it!
Identity is the Id in IdIoT.
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.
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.
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.
i agree, that is a problem, mainline linux and working drm, that is direct rendering manager, drivers should exist before release of the product.
Beaglebone Black is used in industrial applications. At scale, those price differences add up.
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.
I keep saying, the first cheap Chinese manufacturer that ships a SystemReady board is going to slaughter the competition.
> There's another factor that's so much more important [...]: Software/kernel support.
Vision Five 2 it is then
Vision Five 2 it is then
How's the software support for sipeed stuff?
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.
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.
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.
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.
Who should require it? And how will it be enforced?
do those SBCs have digital IO (GPIOs) and a realtime operating system?
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 reason I'd buy a Beagle (well, really an ESP32) isn't the price, it's the convenience of havng real time GPIOs.
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.
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.
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.
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.
"2GHz quad-core RISC-V 64GCV Xuantie C910 central processing unit (CPU)"
The datasheet doesn't mention Vector (V) extension support. Is this an error on the Beagleboard page?
The datasheet doesn't mention Vector (V) extension support. Is this an error on the Beagleboard page?
No, unfortunately not - the TH1520 SoC comes with some Vector extension support - but rev 0.7 (IIRC), not 1.0 which one would rather want.
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.
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.
Maybe it's because the C910 + V is now sometimes called C920, I think they changed their branding on that.
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.
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.
NUC is goneburger. Discontinued. Dead.
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.
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.
Also, check this out: https://www.amazon.com/GMKtec-Nucbox5-Desktop-Computer-Windo...
Also, check this out: https://www.amazon.com/GMKtec-Nucbox5-Desktop-Computer-Windo...
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.
1: https://www.amazon.com/GMKtec-Nucbox5-Desktop-Computer-Windo...
1: https://www.amazon.com/GMKtec-Nucbox5-Desktop-Computer-Windo...
Here is Beagle board list:
https://www.arrow.com/en/research-and-events/videos/comparin...
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.
https://www.arrow.com/en/research-and-events/videos/comparin...
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.
64bits RISC-V: yes yes yes.
H.265/H.264: Where is AV1? Coze risc-v is worldwide royalty free, not h.265/h264.
HDMI: same issue than H.265/H.264, I should see a dedicated display usb-c connector (displayport).
But I am being excessive, it is going in the right direction, the next step is to remove H.265/H.264 and HDMI royalties.
That said, has the GPU a lean, plain and simple C written, vulkan3D open source driver?
H.265/H.264: Where is AV1? Coze risc-v is worldwide royalty free, not h.265/h264.
HDMI: same issue than H.265/H.264, I should see a dedicated display usb-c connector (displayport).
But I am being excessive, it is going in the right direction, the next step is to remove H.265/H.264 and HDMI royalties.
That said, has the GPU a lean, plain and simple C written, vulkan3D open source driver?
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?
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.
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.
No USB-C port.
No NVME port.
Price tag is too high.
Shame because the rest of the H/W looks nice.
No NVME port.
Price tag is too high.
Shame because the rest of the H/W looks nice.
Look at the Lichee Pi 4A instead. Same SoC, but USB-C, and cheaper.
Ah Beagleboard, what everyone was reaching for, before Arduino and Raspberry Pi got famous.
What's up with their pricing? It's way too expensive compared to the competition
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.
Then I return to the ordinary Intel world where stuff works.
> System on chip: Alibaba T-Head TH1520
Why is this not a TI SoC?
Why is this not a TI SoC?
TI does not make any RISC-V processors.
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.
[1]: https://git.beagleboard.org/beaglev-ahead/beaglev-ahead/-/bl...
[2]: https://github.com/T-head-Semi/openc910/blob/main/C910_RTL_F...
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.
[1]: https://git.beagleboard.org/beaglev-ahead/beaglev-ahead/-/bl...
[2]: https://github.com/T-head-Semi/openc910/blob/main/C910_RTL_F...
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.
The situation is better[0] with JH7110, which has been around for a few months already in VisionFive2 and Star64 boards.
0. https://rvspace.org/en/project/JH7110_Upstream_Plan
0. https://rvspace.org/en/project/JH7110_Upstream_Plan
TI doesn't make RISCV anything.
It's why they called it the BeagleV ;)
It's why they called it the BeagleV ;)
Surely this:
50GFLOPS, 3Mpixel/s Imagination BXM-4-64 graphics processing unit (GPU)
Has got to be a typo? 3 million pixels per second is not very impressive, to understate things a bit.
Edit: also, in Sweden Digi-Key want almost $180 for this which was more than I expected. Wow.
50GFLOPS, 3Mpixel/s Imagination BXM-4-64 graphics processing unit (GPU)
Has got to be a typo? 3 million pixels per second is not very impressive, to understate things a bit.
Edit: also, in Sweden Digi-Key want almost $180 for this which was more than I expected. Wow.
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.
Nitpicking but they really need to have someone proofread their copy.
They just want you to know you're not paying for anything except engineering. :)
I like very much the BBB, but here the price point is way too excessive. Around 135€. It is the price range of a NUC.
Wow $235 CAD. Why is this board so insanely expensive?
Any benchmarks of the CPU?
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.
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?
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.
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.
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.
https://hoult.org/primes.txt
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.
https://hoult.org/primes.txt
Your benchmark is near useless but I appreciate that you have benchmarked a variety of systems. Thanks.
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 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.