StarFive Tech. have been upstreaming on kernel, OpenSBI and U-Boot from several weeks now. Of course this is still weeks/months away (if not more, for all the features) from landing in stable releases. Even more for distributions to pick those up.
Looks pretty good opensource-wise, right? Some linux fork with ton of patches but hopefully most of that will get upstreamed, and except that I found no weird blobs or proprietary crap.
Still no sign of an actual Technical Reference Manual or any other detailed documentation on the SoC (registers, peripherals, etc). A big pile of Linux patches, while better than nothing, is a poor substitute for actual documentation.
SiFive does provide docs for the core complex (processors, cache, irq controller, etc), but that doesn't cover any SoC-specific peripherals.
It's definitely nicer to have source than a bunch of opaque binaries. (Is there source for the full boot path? Sounds like they have patches for OpenSBI and u-boot -- didn't see if there was source or docs for the on-die boot rom.)
I just find the "all you need is Linux patches" approach annoying. There are BSD variants and little experimental and homebrew OSes out there that would be fun to run on a capable RISC-V SBC and even if you are using Linux it's still nice to have some documentation to refer to beyond whatever the silicon vendor implemented in various driver patches.
I haven't looked at the v2 but they seemed to be doing an alright job at getting things upstreamed with the v1. the only thing i remember seeing that wasn't very good in that regard was the neural net stuff that they had and that seemed more from just issues getting the hardware working than any nda or lack of desire to do it. I'd hope that the v2 is similarly worked through even if it needs some non-upstream patches at the start just because it's new hardware and it takes time.
It seems like many SoCs (also in ARM space) advertise '2 TOPS' or however many TOPS neural processors integrated in the silicon... but the actual number of SoCs where those coprocessors can be used in Linux seems to be very low.
yea it's a shame that it seems to be the normal state of things still. Based on the fact that so many of them have the exact same specs I think it's probably all the same (or only a few) vendors that make that part of the silicon/IP and everyone is just copying it without ever planning much around the support.
It's sad how 'being able to actually use GPIO pins in software' is an achievement for an SBC. But I do applaud StarFive for actually seeming to throw some support behind their boards.
We have been spoiled with Raspberry Pi the past few years prior to the shortages. I wish another vendor could get close to Pi's position to give more competition in terms of support and documentation.
We should remind ourselves that Raspberry Pis are in abundance, just not in the hobbyist channel. Current situation is not unlike the graphics card shortage when crypto miners were on garaunteed purchase contracts
This board has so much going for it. The native M.2 is a highly desireable feature. The only knock is the lack of wifi/bluetooth which can at least be solved with a dongle.
The no-wifi seems to just be the kickstarter. When I ordered mine a little while back, they had an option for wifi (extra $8-$10, as I recall). I haven't received it yet...so not sure if it actually does.
I don’t know much about this stuff. But Khadas has some stuff. They provide quite a lot of docs. Even cad model so you can design cases for their stuff.
I just got an Edge 2. Damn so much faster than my pi4. The downside is I think it’s hard/impossible to get an OS on it other than the ones they provide. ubuntu/android.
Does anyone know if this SBC contains RISC-V Worldguard capabilities (https://www.sifive.com/technology/shield-soc-security)? I've been looking for a RISC-V SBC with a way to protect asymmetric keys. The new ESP32 has a dedicated key storage.
The SoC docs indicate:
• 512 × 32-bit (2 KB) of OTP for key data on-die storage
But, that sounds like it's for the likes of secureboot.
No, and there aren't any (public) cores deployed with Worldguard support that I'm aware of, at least none with user-controllable software, nor am I aware of any alternative implementations to Worldguard e.g. FPGA designs for prototyping. Seems like a fairly involved product.
If you just want some kind of trusted key storage/signing inside a secure enclave style design, to keep things secure from the OS/hypervisor, something like Keystone may be more your speed. It largely just re-uses the existing M-mode privilege level to enforce separation from the OS and userspace stack. It isn't 1-to-1 with Worldguard, but it's a start, and in theory you can "just" patch the SBI implementation to support it: http://docs.keystone-enclave.org/en/latest/Getting-Started/H...
Anything implemented today is probably going to be missing some key features of a complete stack, but the parts are all mostly there, and still moving.
The Unmatched board is great, a real workhorse for building Fedora packages. It was very expensive at release (as was Unleashed) because of the small run, so we hope the VF2 with better performance far lower price will drive more adoption.
I’m looking to buy these boards; recently I bought one on eBay. I plan on using them to add to FOSS projects’ buildfarms. The first one I got from eBay is now running Postgres buildfarm.
Please let me know if you’re interested in selling me yours.
Any reason why it's collecting dust? I have a few RISC-V boards and I haven't had any issues with them other than having to compile almost everything from source.
CPU slower than 4 as said, but even Jetson Nano is slower that the mad performance per watt of the 4.
BUT the GPU is apparently better which would make this THE SBC.
I will test my 3D MMO engine and give exactly what is what once I receive mine, should be a couple of days.
The Raspberry GPU has a serious cache problem, it can't render a triangle at 60FPS in 1080p!!!
But 100 non-instanced animated characters (each with a unique weapon in hand) at 60FPS and low res (800x600).
Jetson (1/2 Nintendo Switch GPU) does 300 at 60 FPS in 1080p.
If the Visionfive 2 is either:
- 100+ at 60 FPS and 1080p
- 200+ at 60 FPS and 800x600
I'm going ALL IN on Risc-V (my own VM for scripting the engine) and StarFive (buy a few to use as demo for the MMO instead of Raspberry 4/Jetson Nano).
This SoC is far more efficient, using just 4.4w on full load and achieving some 80% of rpi4's cpu performance at a much lower power, with no need for a heatsink.
Not going to debate the gflops/w yet, but Raspberry 4 cores are also around 1W each and they kick ass compared to even M1 (much worse OFC, but per $/openess they still win imo)
I know what 10W feels like because the Jetson Nano draws that, and Raspberry 4 is 7W with GPU+4 cores saturated.
You will need a heatsink on the Visionfive if the GPU does what I hope it does.
The Raspberry 4 GPU is only 1W vs. 5W on the Jetson Nano!
I'm hoping for a 2-3W GPU on the Visionfive and then you'll need a heatsink for MMO gameplay no question about it.
Longevity is now crucial as hardware peaks, heat kills electronics slowly but oh so surely!
Edit: Do you have a URL for those 3.xW and 4.4W claims... Then I think we wont see 100+ but cache can still be larger so you can have 100 at 1080p and that is enough for mainsteam adoption and replacing all other computers (Switch, PS4, XBOX, phones and pads etc.)!
4.4 W is the figure given for the SoC on full load.
They also give a lower figure that's 3.x W for full load with the GPU off.
It won't need a heatsink, because with its power draw it won't get above 70C even on full load, while the chip is built for industrial temperature range in operation.
>As for power consumption, JH7110 is separated into 8 independent power domains. CPU frequency can be configured through software. To achieve a balanced PPA, customers can set the most optimum SoC frequency based on their application scenarios and performance requirements. In sleep mode, the static power consumption of JH7110 is 120 mW. When working on an SBC, with all the main modules under full load, the dynamic power consumption of JH7110 is 4,100 mW. In the application scenarios of soft routers and NAS, where you don’t need GPU and video processing, but only require the dual Ethernet port operation, you can configure the modules on/off through software. And the actual power consumption decreases to 3,300 mW.
So, to summarize:
* 120mW when completely idle.
* 4100mW on full load.
* 3300mW on full load w/o GPU or video processing modules.
This is, I have to say, crazy good relative to rpi4.
>For longevity 60C is better. I'm talking multiple decades at constant permanent full blast here.
Yes, I will at least put a stick-on passive heatsink on mine.
"with all the main modules under full load" does that imply GPU is 100% loaded?
I hope not, and then if I'm right and the GPU is more powerful than the Raspberry 4 one this board will run at 6W or something and then a stick-on heatsink wont do it...
Look at my link to the full copper one if I'm right:
What I gather from the text is that it's a calculated (from design libraries), rather than measured, full load power draw. Which would make these numbers the upper bound, and thus very good.
I might be wrong.
Either way, as these boards are reaching people, it shouldn't take long until we see measured power draw and temperatures.
We're still in the early days of risc-v availability. Arm has been widely deployed and the compilers optimised by both individuals and companies. I expect this comparison to look better in a year (not better than rpi4, just a smaller gap)
Fortunately, at least for video codecs, there's a hardware acceleration block, and it is significantly stronger than the one rpi4's SoC has.
Unfortunately, there's no drivers in the current images, and it'll take time to have proper open drivers and integration with common APIs such as vdpau.
For what it's worth, I managed to get an RPi4 at retail price within a few days by setting the appropriate filters on https://rpilocator.com and keeping a watch on it with an Android app called "Web Alert". I've used the same trick to buy out-of-stock cameras and laptops too, works a treat.
Unfortunately there appears to be no detailed documentation at all (unless you count a pile of Linux and bootloader patches, which I don't) for the peripherals, etc, outside of the core complex on the SoC:
> unless you count a pile of Linux and bootloader patches, which I don't
This is what drives me crazy. Vendor claims "open source" which means an outdated linux image and the source code is wrapped up inside of a megalith build monstrosity like penguintronix or yocto. Utter junk these things are.
Linux works somewhat, with some duct taped drivers.
Freebsd boots, but that's it.
Of course, as this board is the first large production run, decent spec'd and reasonably compliant <$100 RISC-V SBC, this is expected to improve quickly as they reach developers and quickstart the ecosystem. That's the true intent of this board.
This is an order of magnitude more boards than accumulated RISC-V development boards distributed to date.
Good to hear. There are other interesting systems, such as xv6 (which abandoned x86 for RISC-V) or Haiku (which RISC-V support has working desktop from about a year ago, unlike aarch64 which doesn't yet).
My answer was, however, specific to systems that run on VisionFive 2.
The situation should improve dramatically once proper documentation is available.
Polarfire FPGAs are not Xilinx! Which means you can't use things like https://f4pga.readthedocs.io ATM, or tools from Xilinx. Instead being chained to whichever proprietary stuff Microchip decides to deliver for dealing with the FPGA-part.
I've looked at the board, and don't see the appeal in price, for only mediocre CPU-parts, not enough RAM, altough good enough I/O-options. Makes no sense if you don't want to meddle with FPGAs, and just look for a fast SBC with Risc-V.
As RVA22 is not done (although almost there), we can't know whether it's compliant, but we will once it is. Expectation is yes.
Otherwise, most stuff out there will be RVA20 compliant once that's ratified, as that reflects what was already common back in chips designed in 2020, what most have been calling RV64GC.
The cores are SiFive U74-MC, the version is, I believe, 21G1.
These are documented.
But that design is configurable. We know B extension (optional) is enabled. I have no idea about every other setting this core can be synthesized with.
StarFive Tech. have been upstreaming on kernel, OpenSBI and U-Boot from several weeks now. Of course this is still weeks/months away (if not more, for all the features) from landing in stable releases. Even more for distributions to pick those up.