RISC-V Business: Testing StarFive's VisionFive 2 SBC | Hacker News Reader

RISC-V Business: Testing StarFive's VisionFive 2 SBC

jeffgeerling.com

126 pointsmikece31 comments

This is a decent review of VisionFive 2 as it is right now (early days).

I noticed a few mistakes/omissions. From the top of my mind:

- There's mention of bad cryptography performance. But there is a cryptography acceleration engine. This is not enabled in the current test kernels, but yet patch is being reviewed by Linux upstream. In contrast, the Broadcom SoCs in the other boards VF2 was compared against have no such hardware.

- There's mention of unusably slow youtube, but again, there's a hardware video decode block that's still not usable, yet it is considerably more capable than the one in the Broadcom SoCs.

- Related, Firefox is very slow because JS is interpreted. A RISC-V JIT implementation landed recently and will be present in the 111 release due in a few weeks.

- The SoC GPU is glossed over, but it did deserve more attention. Claimed to be 4x the performance of RPi4's SoC, Imagination Technologies is working on an open driver. This is a public effort as of early 2022, with some code already in Mesa3d upstream.

I am happy that the author did stress that this is early days, and that if the review/benchmarks were to be repeated in the future, the results would be very different.

Get this board (I love mine) if you're curious about and want to play with RISC-V. There's currently nothing faster than the VF2 available at any price, and yet VF2 is available at ~$100.

I wouldn't consider these mistakes or omissions. He's reviewing the board as is and not assuming future progress that may or may not take place in some undetermined time. If I'm looking for a relatively cheep single board computer to play with and am not focused on specific RISC-V development I want to buy a board for what it can do now not what it will be able to do with kernel updates that are not guaranteed.

>He's reviewing the board as is and not assuming future progress that may or may not take place in some undetermined time.

Absolutely, but he does (for the cryptography example) mention that future chips will do better in this regard.

Why would he do this, and not mention the cryptography engine present in this very SoC?

What's most likely is he managed to overlook this SoC has this hardware.

>I want to buy a board for what it can do now

This board clearly isn't for you.

>kernel updates that are not guaranteed.

Having kernel patches already sent upstream for review[0] is a much better situation than potentially having nothing.

0. https://rvspace.org/en/project/JH7110_Upstream_Plan

> I want to buy a board for what it can do now not what it will be able to do

Then buy something else.

My VF2 boards (one 8 GB and one 4 GB) were very clearly sold as "Early Bird" and "Super Early Bird", respectively, and Jeff's will have been too.

They are for early adopters and for developers to use to fill in the missing software support. It is not practically possible to do this without a board in your hands.

It is NOT for the average user right now. In 3 or 6 months it will be.

Does this board have virtualisation technology?

Yes and no.

No, as in not having the hypervisor extension.

Yes, as in the modes it does have (M,S,U) being sufficient for the implementation of efficient virtual machines.

I'm a little surprised that Amazon hasn't made (or commissioned) a small SBC computer to compete directly with the Raspberry Pi but one that is certified for and pre-loaded with software for AWS IoT applications (including Greengrass) and selling for about $99. At that price point you could sell both to AWS customers looking for inexpensive IoT systems for experimentation (or deployment!) as well as the general enthusiast market who could replace the AWS IoT bits (probably based on Fedora?) and put whatever distro they want on it. This would be a win-win for Amazon since the general enthusiast market could enable volume sales to keep the price of entry for AWS IoT experimenters low enough to try out (creating yet another sales funnel for AWS services).

I wonder if Amazon would consider using a RISC-V CPU for such a device?

They do have something like this, an ESP32 based system for IoT using FreeRTOS.

https://devices.amazonaws.com/detail/a3G0h000007djMLEAY/M5St...

I am not sure of the exact relationship AWS has with FeeRTOS, but the FAQ says they have ‘taken stewardship’ of the open source project.

https://www.freertos.org/FAQ_Amazon.html

The maintainer works for Amazon, I think

LOL, MIT open source license. That’s what happens - the developer sells out.

It’s not GPL, so it’s open to embrace, extend, extinguish. We shall see.

For that matter a scaled down version of the chipsets their arm cloud servers use. Where you can build/test in-house and deploy to AWS. I know there's the "why not just build/test in AWS?" as a question, and the answer is sometimes you want to self-host or at least start that way. Or you want to do more than just the web side, but still want to be compatible.

They sorta already do, it's called Echo. I'm not convinced there's a market for what you're describing, or at least not one that's necessarily worth the cost. A lot of the cheap Chinese IoT devices generally available already go through AWS. People with the skills and desire to do that type of thing themselves are both a small market, and less likely to use AWS for the types of projects they'd be building with said device.

I wonder how much of the performance will improve when compilers get better at RISC-V.

It's been a long time since I could beat the compiler at optimizing assembly on x86, yet in the end merely unrolling a loop and keeping an eye on write-read stalls I managed to get a simple "multiply array by const" about 56% less time (more than twice as fast):

https://github.com/gnuradio/volk/pull/619

And that's with hardware that doesn't even have vector instructions! I'd understand GCC not supporting that yet.

Some other quickstart docs and hot takes from me on this hardware: https://blog.habets.se/2023/01/VisionFive-2-quickstart.html

Edit: Oh yeah, if you can decipher my tables then you can compare some performance ray tracing with pov-ray here: https://qpov.retrofitta.se/stats

>(link) It doesn’t have AES instructions, so be deliberate in how you compare this benchmark to anything, but here’s openssl speed:

Beware the CPU does not have the scalar or vector cryptographic extensions, but the SoC has a cryptography acceleration module.

It is not supported in the current image's kernel, but the patch to support it is being reviewed upstream for merging.

I really wish someone would make a framework-laptop compatible board layout for a RISC-V chip. Even if it's not high performance it'd let us treat it like a daily-driver and really contribute to getting the desktop linux experience in better shape for RISC-V

Or if not framework, like the Pine 64. I believe Pine64's laptop is pretty much a laptop shell that houses one of their boards. Make a laptop shell that you can drop in any reasonably dimension-ed SBC and hook it up.

I think this review is either coming from a place of misunderstanding, or to help others not misunderstand what it is.

The VF2 board is a development board. The Raspberry Pi is "small computer".

Is a development board also a computer? Yes, but they are not for the same purpose.

This is a test fire, to get hardware to developers and get the hardware-software cycle started.

RISC-V has to start somewhere, I would say, and since the "markets" are already busy, I don't expect them to improve as fast as the others.

But no toxic IP on the ISA is the way to go (and it seems the ISA has CPU internal design simplicity in mind, of course there will be trade off).

Hope RISC-V is a success.

>(and it seems the ISA has CPU internal design simplicity in mind, of course there will be trade off)

There's no such trade-off. The ISA is designed to scale from the smallest embedded microcontrollers to the top supercomputers.

It has the advantage of being designed from a clean slate, decades after the incumbent ISAs, with careful consideration put into every decision made and the hindsight of every other ISA to draw from.

The (relatively cheap) book "RISC-V Reader" presents a good introduction to the ISA and its design, with chapters covering each extension and comparing with incumbent ISAs.

The incumbent ISAs end up looking very bad. Note that the book is written by the main architects of the ISA, so it is of course very biased. They do however manage to keep it reasonably objective and to make really good points.

> It has the advantage of being designed from a clean slate, decades after the incumbent ISAs,

Unless it was designed in 2030 - which would be an impressive feat given we are in 2023 - it was not designed decades after current incumbent ISAs.

I purchased a DE10-nano last year with the plan to try some FPGA RISC-V based development... but got lost in the number of extensions and versions of RISC-V kicking around. Has anyone tried this? I'd also be interested how it compares performance wise to the above, and Pi4, see if it worth the effort. Anyway at least it got some good use with MiSTer :) I kinda hope Raspberry adopts RISC-V on their next SBC, but hopefully with more open hardware.

The repo below has support for building a 32bit RISC-V CPU for de10nano. It also includes information about booting Linux.

https://github.com/litex-hub/linux-on-litex-vexriscv

The CPU will likely have a clock speed around 100Mhz, far slower than the 1.5Ghz 64bit cores on the VisionFive 2 or Pi4. The FPGA might still be useful if you want to customize the CPU or integrate other custom hardware.

Open source tool chain and open source cores, wow, nice progress since I last looked into this.

Yeah unfortunately there isn't really a great place that lists all the extensions with links and ratification status.

But anyway there is a sort of standard set of extensions that "application processors" (I guess CPUs that want to run precompiled code) should support:

https://github.com/riscv/riscv-profiles/blob/main/profiles.a...

The 22 indicates the year.

>Yeah unfortunately there isn't really a great place that lists all the extensions with links and ratification status.

RISC-V's wiki specification status page[0] is about as good as it gets.

0. https://wiki.riscv.org/display/HOME/Specification+Status

thanks, so for something like the reviewed board above, how would RV64GC map into one of those profiles, or set of supported instructions?

RV64GC expands into RV64I + M + A + F + D + C. The CPU in this board also has the Zba and Zbb extensions (which together with a couple of others make up what was originally envisioned as the "B" extension, but it was decided to split it up).

What's the supply chain of these look like? I'd be very scared to use these for anything, even just small projects, on my network.

This is not the first riscv board and they have had plenty of time to learn from all the sbcs out there. This experience sounds horrible.

>This is not the first riscv board

It isn't, but it is the first one that's made at scale.

>This experience sounds horrible.

Barely launched, it's a much better experience than the average ARM SBC, and the review makes a point to stress this fact.

> Barely launched, it's a much better experience than the average ARM SBC, and the review makes a point to stress this fact.

That's a very generous interpretation of what he said.

He stressed out that the documentation is much better, yes, but the user experience is currently much much worse.

Reply on news.ycombinator.com