StarFive VisionFive 2 quad-core RISC-V SBC _crowdfund_ launched

CNX Software – Embedded Systems News link

SoC – StarFive JH7110 quad-core 64-bit RISC-V (SiFive U74 – RV64GC) processor @ up to 1.5 GHz
System Memory – 2GB, 4GB, or 8GB LPDDR4
Networking – 2x Gigabit Ethernet RJ45 ports

More details at the link.

I have no idea if the cpu is powerful enough to traffic shape at full GigE speeds and/or run a firewall, but if it is, it could be an interesting device.

Given this is the start of a crowdfunding campaign, I don't know if it'll ever become a reality, but if it does, it might be a worthwhile target.

The link to the Kickstarter page is: https://www.kickstarter.com/projects/starfive/visionfive-2

For any SBC I've found the most important question is distro availability. Will there be enough public information available to make porting easy, or will it only work with a bespoke custom kernel that's too difficult for anyone to keep updated so everyone gets stuck on an ancient version forever?

After having some bad experiences with SBCs that I've paid money for: I now value this software support side of things much more than other factors like raw computing performance, because if it doesn't work then I can't even enjoy those features anyway :slight_smile:

It looks like on the released predecessor VisionFive 1 things are not too crazily bad. They publish their patchset with a checkbox list of what hardware features work and the Debian wiki guide doesn't seem as complicated as some that I have seen, but I can't be certain without trying (and seeing how portable these patches are to newer kernels). Otherwise if you want pre-built images then I think you're stuck with their bespoke Fedora builds, I can't see anything else.

I can't find any model numbers for the gigabit chipsets. I tried going through their related links, but nothing more detailed than "2xRJ45" or "2xgigbit ethernet" seems to appear. Maybe I'm missing something. I'll presume they're Realtek parts, that's likely a safe bet.

I presume the M.2 slot is SATA-only (not PCIE) given that it's only labelled for SSDs, but I could be wrong. They probably have some PCIE on this board for the gigabit ethernet chipsets. Alas if they exposed PCIE on the M.2 connector then they'd probably sing proudly about it, because people can get extension cables to turn those into full mechanical size PCIE slots. Maybe.

2 Likes

Thank you for sharing your knowledge and experience of SBCs.

My search for a cost-effective OpenWrt device* that can handle traffic shaping and firewall duties on a Gigabit connection continues.

*Power-hungry x86-64 devices are not in the running. For something drawing power 'permanently', every watt saved is worth it, especially at current electricity prices where I live. It also means less fan noise, preferably zero. It could well be that there is a minimum power draw needed for handling Gigabit connections so my wish for a silent low power-consumption device is impossible, but the search is interesting.

Thank you for sharing your knowledge and experience of SBCs.

I've only bought a few, other people may have had better experiences :slight_smile:

every watt saved is worth it,

Agreed. In many places its only looking to get worse. I think I'm currently around $2 per wattyear, so a 40W idling x86 box would still cost most of $100 per year.

Some x86_64 devices can actually be really power efficient, eg laptops. Sadly they have other problems (like only having one ethernet port) or are just plain expensive.

I spent the $$$ on an APU2 from pcengines a while back. It was more expensive than I'd normally be comfortable paying, but compared to running a old Core 2 Duo box it was more economical (and quieter). Nowadays sadly they're completely out of stock (and have been for a while), but some people here occasionally report finding rebadged versions on eBay.

My search for a cost-effective OpenWrt device* that can handle traffic shaping and firewall duties on a Gigabit connection continues.

I would recommend steering clear of any "new" devices then (especially unreleased ones). Don't buy anything that has not been out on the market for at least a year OR somehow otherwise is known to have really good software support and reliability. Many new SBCs are more experimental than you expect (broken features, unstable, etc) and even some old ones have weird problems (but at least they are known before you buy).

Don't worry about missing out by choosing "older" technology, the age of the silicon manufacture processes and the chip current/voltage configurations vary wildly. eg I vaguely recall some OrangePi boards being stuck at their highest Vcore voltage on a lot of distros, running them hotter and limiting their performance.

1 Like

where's here ?

You can easily find the sw302da (or sw301da, if you don't mind the USB2 ports) on US eBay, but the prices are ridiculous.

Here = the forum.

I saw some that were not ridiculously priced, but their shipping to me (in restoftheworldistan) was. EDIT: Which is weird, as sometimes shipping from the US to Australia is cheaper than shipping from within Australia to Australia.

I'm up at roughly 4 USD per wattyear, and that is likely to rise. It's why I'm willing to pay extra for power efficiency.

Eek. My $2 was 2AUD, not USD. That's nasty. I need to find our last power bill and double check (but it's probably too old to see the newest fluctuations).

i got one of these things and sort of managed to get openwrt running on it
well, pretty much everything works, though it seems the onboard lan ports have some limitations like:

[48889.626002] starfive-eth-plat 16040000.ethernet eth1: Only single VLAN ID supported
[49063.485183] starfive-eth-plat 16030000.ethernet eth0: Only single VLAN ID supported

however, the USB ports work so i'm using a USB network adapter currently

it actually seems quite stable and runs wireguard fine at least up to 100mbits/s which is as fast as my internet will go

Linux version 5.15.102 (alarm@alarm) (riscv64-openwrt-linux-gnu-gcc (OpenWrt GCC 12.2.0 r22273+40-bf261073dc) 12.2.0, GNU ld (GNU Binutils) 2.40.0) #0 SMP Tue Mar 14 00:45:42 2023

[    6.851960] device-mapper: ioctl: 4.45.0-ioctl (2021-03-22) initialised: dm-devel@redhat.com
[    7.033122] raid6: int64x8  gen()   872 MB/s
[    7.203122] raid6: int64x8  xor()   524 MB/s
[    7.373128] raid6: int64x4  gen()  1444 MB/s
[    7.543135] raid6: int64x4  xor()   690 MB/s
[    7.713123] raid6: int64x2  gen()  1350 MB/s
[    7.883130] raid6: int64x2  xor()   720 MB/s
[    8.053121] raid6: int64x1  gen()  1216 MB/s
[    8.223134] raid6: int64x1  xor()   622 MB/s
[    8.227397] raid6: using algorithm int64x4 gen() 1444 MB/s
[    8.232874] raid6: .... xor() 690 MB/s, rmw enabled
[    8.237751] raid6: using intx1 recovery algorithm
[    8.242819] xor: measuring software checksum speed
[    8.252459]    8regs           :  2032 MB/sec
[    8.261757]    8regs_prefetch  :  1989 MB/sec
[    8.268902]    32regs          :  3526 MB/sec
[    8.276061]    32regs_prefetch :  3509 MB/sec
[    8.280410] xor: using function: 32regs (3526 MB/sec)

It looks like crypto acceleration isn't working, but this is an idea of the raw performance, looks like there are some optimizations to go there:

root@Rashemen:~# openssl speed aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 4693504 aes-128-cbc's in 2.99s
Doing aes-128-cbc for 3s on 64 size blocks: 1551624 aes-128-cbc's in 2.99s
Doing aes-128-cbc for 3s on 256 size blocks: 422794 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 108176 aes-128-cbc's in 2.99s
Doing aes-128-cbc for 3s on 8192 size blocks: 13606 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 16384 size blocks: 6785 aes-128-cbc's in 2.98s
version: 3.0.8
built on: Tue Mar 14 00:45:42 2023 UTC
options: bn(64,64)
compiler: riscv64-openwrt-linux-gnu-gcc -fPIC -pthread -Wall -O3 -pipe -march=rv64gc_zba_zbb -mtune=sifive-u74 -mabi=lp64d -fno-caller-saves -fno-plt -fhonour-copts -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -O3 -DPIC -fpic -ffunction-sections -fdata-sections -znow -zrelro -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -DOPENSSL_PREFER_CHACHA_OVER_GCM
CPUINFO: N/A
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-cbc      25115.74k    33212.02k    36078.42k    37047.57k    37153.45k    37303.84k
root@Rashemen:/# cat /proc/cpuinfo 
processor       : 0
hart            : 3
isa             : rv64imafdc
mmu             : sv39
isa-ext         : 
uarch           : sifive,u74-mc

processor       : 1
hart            : 1
isa             : rv64imafdc
mmu             : sv39
isa-ext         : 
uarch           : sifive,u74-mc

processor       : 2
hart            : 2
isa             : rv64imafdc
mmu             : sv39
isa-ext         : 
uarch           : sifive,u74-mc

processor       : 3
hart            : 4
isa             : rv64imafdc
mmu             : sv39
isa-ext         : 
uarch           : sifive,u74-mc
root@Rashemen:/# cat /sys/bus/cpu/devices/cpu0/cpufreq/scaling_available_frequen
cies 
375000 500000 750000 1500000
lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
    |__ Port 2: Dev 2, If 0, Class=, Driver=r8152, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M

Hi Wilson,

I am a StarFive marketing staff. We are actively looking for cooperation in porting operating systems like OpenWRT to our VisionFive 2 board. Do you mind sending me your contact method so we can give you a hand using our technical support resources.

Thanks,

Allen

1 Like

Does the GPU work in OpenWRT? (For instance for Frigate)

There are no graphics drivers in OpenWrt at all, except for basic text output capabilities (typically found in SBCs and x86 type setups). So, no, it wouldn't work.

1 Like