RISC-V SBC VisionFive 2 Officially Shipped(starfivetech.com)
starfivetech.com
RISC-V SBC VisionFive 2 Officially Shipped
https://www.starfivetech.com/en/site/new_details/976
104 comments
Their date format not being the standard yyyy-mm-dd gets on my nerves.
I received mine weeks ago.
There are several desktop images but various issues reported from no display output, to only 1080p supported. To this image or that one working.
Important note, the later images require an updated to uboot and SPL, either with the bootrom or a serial connection.
It's a mess at the moment!
There are several desktop images but various issues reported from no display output, to only 1080p supported. To this image or that one working.
Important note, the later images require an updated to uboot and SPL, either with the bootrom or a serial connection.
It's a mess at the moment!
> It's a mess at the moment!
from my cursory testing it seems gui performance is much better than hifive unmatched (window manager, apps, web browser)
[edit] add geekbench
https://browser.geekbench.com/v5/cpu/compare/17159543?baseli...
> 1 Processor, 1 Core, 4 Threads
Any idea why StarFive went with this choice for an SBC? I remember POWER7 also having 4 SMT, but it felt right for a superscalar multi-core CPU.
Any idea why StarFive went with this choice for an SBC? I remember POWER7 also having 4 SMT, but it felt right for a superscalar multi-core CPU.
The link in the GP comment is wrong - both SoCs have 4 cores, each with a single thread.
The reason why this SoC is faster than HiFive Unmatched seems to be down to architectural improvements.
The reason why this SoC is faster than HiFive Unmatched seems to be down to architectural improvements.
They both use U74, but different versions.
The one in JH7110 is the 2021Q1 version, AIUI.
Besides faster, it also added B extension.
The one in JH7110 is the 2021Q1 version, AIUI.
Besides faster, it also added B extension.
No. VisionFive2's RISC-V CPU does not have the B extension. I confirmed it on the actual device.
$ cat /proc/cpuinfo processor : 0 hart : 2 isa : rv64imafdc mmu : sv39 uarch : sifive,u74-mc
$ cat /proc/cpuinfo processor : 0 hart : 2 isa : rv64imafdc mmu : sv39 uarch : sifive,u74-mc
As you say this, I realize I can't find anywhere that it does.
I do not know why I thought it did. Possibly as U74-MC[0] supports that option.
Interestingly, I also took a look at RVA22[1], and found it requires Zbb but not the whole B.
Your /proc/cpuinfo isn't listing Z* extensions. Maybe lscpu output would be more detailed?
0. https://www.sifive.com/cores/u74-mc
1. https://github.com/riscv/riscv-profiles/blob/main/profiles.a...
I do not know why I thought it did. Possibly as U74-MC[0] supports that option.
Interestingly, I also took a look at RVA22[1], and found it requires Zbb but not the whole B.
Your /proc/cpuinfo isn't listing Z* extensions. Maybe lscpu output would be more detailed?
0. https://www.sifive.com/cores/u74-mc
1. https://github.com/riscv/riscv-profiles/blob/main/profiles.a...
Ah, makes much more sense. Thanks!
Embarrassingly I thought I had a Quad-Core based on `lscpu`.
I have been meaning to make use of it but so far just as a vnc server which works well loading XFCE on the minimal desktop image.
Edit: can see below that it is indeed a quad core... Embarrassed I took an internet strangers off the cuff remark as gospel
I have been meaning to make use of it but so far just as a vnc server which works well loading XFCE on the minimal desktop image.
Edit: can see below that it is indeed a quad core... Embarrassed I took an internet strangers off the cuff remark as gospel
It gets more complicated :D
Quad-core 64-bit RISC-V SiFive U74 (RV64GC) processor @ up to 1.5 GHz with 32KB D-Cache, 32KB I-cache
Single-core 64-bit RISC-V SiFive S7 (RV64IMAC) monitor core with 16KB I-cache, 8KB DTIM
Single-core 32-bit RISC-V SiFive E24 (RV32IMFC) real-time control core with 16KB I-cache
Quad-core 64-bit RISC-V SiFive U74 (RV64GC) processor @ up to 1.5 GHz with 32KB D-Cache, 32KB I-cache
Single-core 64-bit RISC-V SiFive S7 (RV64IMAC) monitor core with 16KB I-cache, 8KB DTIM
Single-core 32-bit RISC-V SiFive E24 (RV32IMFC) real-time control core with 16KB I-cache
It has 4 cores with 1 thread each, rather than 1 core with 4 thread
sadly, just half of the speed of the 3 years old raspberry PI 4 ...
Hah, reminds me of my disappointment with the original Pi. Here's hoping they sort it out as fast as they did for ARM!
Likewise. I believe mine arrived about the 29th.
Haven't broke the shrink wrap yet.
Does is have UEFI boot support? I guess through u-boot?
AIUI it doesn't, but there's nothing in the way of it, other than some board-specific porting work.
I believe by the standard boot process, opensbi would jump into uefi instead of u-boot.
I believe by the standard boot process, opensbi would jump into uefi instead of u-boot.
SDK：https://github.com/starfive-tech/VisionFive2
Docs: https://doc-en.rvspace.org/Doc_Center/visionfive_2.html
Docs: https://doc-en.rvspace.org/Doc_Center/visionfive_2.html
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.
SiFive does provide docs for the core complex (processors, cache, irq controller, etc), but that doesn't cover any SoC-specific peripherals.
Agreed. But I feel like that is still a step ahead of RPi where you get random firmware blobs for the GPU without which it won't even boot.
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 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.
I think it will push to upstream ASAP.
Explaining Computers "StarFive VisionFive 2 RISC-V SBC review, including a demo of an engineering release of Debian, and of Python GPIO control"
https://www.youtube.com/watch?v=ykKnc86UtXg
https://www.youtube.com/watch?v=ykKnc86UtXg
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 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.
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 understand it is just a usb dongle, shipped together.
>> it's sad how 'being able to actually use GPIO pins in software' is an achievement for an SBC
Yeah, but with an OS and MMU you don't get to just write to a port or other registers. The plumbing has to be in place.
Yeah, but with an OS and MMU you don't get to just write to a port or other registers. The plumbing has to be in place.
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.
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.
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.
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.
HN is tanking the RVSpace forum too.
Just go here and buy one instead: https://www.waveshare.com/visionfive2.htm?sku=23875
Just go here and buy one instead: https://www.waveshare.com/visionfive2.htm?sku=23875
I have a sifive "unmatched" board sitting here collecting dust, cost me $700 then.
Most projects turned out ARM based after I bought it.
The site is not working, any price of this board? What's its market, e.g. ip camera? I'm still interested in lower cost ready to go risc-v boards.
Most projects turned out ARM based after I bought it.
The site is not working, any price of this board? What's its market, e.g. ip camera? I'm still interested in lower cost ready to go risc-v boards.
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.
$55/$65/$85 for 2GB, 4GB, 8GB plus shipping
Amazon pricing is inflated... best to buy from one of the other sources listed on the main site.
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.
Please let me know if you’re interested in selling me yours.
Any performance comparisons with Raspberry Pi boards? How does this RISC-V CPU stack up against them?
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:
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
>the mad performance per watt of the 4.
More like bad than mad.
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.
More like bad than mad.
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.
We'll see, if you need a heatsink for this here is one I bought which should fit: http://www.enzotech.com/cnb_s1l.htm
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)
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)
If the SoC in rpi4 was any good, it wouldn't need a huge heatsink to not throttle.
The reality is that it draws around 10w more often than not.
The reality is that it draws around 10w more often than not.
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.)!
The future belong to those that compile!
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.)!
The future belong to those that compile!
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.
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.
Do you have a URL for those 3.xW and 4.4W claims?
For longevity 60C is better. I'm talking multiple decades at constant permanent full blast here.
For longevity 60C is better. I'm talking multiple decades at constant permanent full blast here.
https://www.design-reuse.com/news/52544/starfive-risc-v-jh71...
The interesting part goes:
>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.
The interesting part goes:
>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:
http://www.enzotech.com/cnb_s1l.htm
I received it now and it's great (if it fits) well worth the expensive price!
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:
http://www.enzotech.com/cnb_s1l.htm
I received it now and it's great (if it fits) well worth the expensive price!
>does that imply GPU is 100% loaded?
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.
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.
Faster than a 3 but slower than a 4 by raw clock speed but ymmv with real world usage
Not great; VisionFive appears to be significantly less performant.
https://browser.geekbench.com/v5/cpu/compare/17159543?baseli...
https://browser.geekbench.com/v5/cpu/compare/17159543?baseli...
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)
U74-MC performance is not an unknown, and they can do much better than that.
Of course, there's a lot of software factors holding it back, such as quality or lack of drivers.
Benchmarks will be worth re-running in a few months, once some level of ecosystem is in place.
Of course, there's a lot of software factors holding it back, such as quality or lack of drivers.
Benchmarks will be worth re-running in a few months, once some level of ecosystem is in place.
There are a few where it does win though -- I wonder what characteristics favor VisionFive in those?
afaict rbpi cpu has vector instructions?
if so, i wonder how much that contributes to the difference...?
if so, i wonder how much that contributes to the difference...?
a lot.
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.
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.
A board that you can buy will perform better than one that is unavailable.
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.
Where is the CPU hardware manual that tells me the CPU's memory map and registers?
This is why so much hardware ends up in landfills. No thanks to undocumented junk.
This is why so much hardware ends up in landfills. No thanks to undocumented junk.
The CPU itself (Core Complex, including cache, irq controller, etc) is documented by SiFive:
https://www.sifive.com/cores/u74-mc
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:
https://doc-en.rvspace.org/Doc_Center/jh7110.html
https://www.sifive.com/cores/u74-mc
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:
https://doc-en.rvspace.org/Doc_Center/jh7110.html
> 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.
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.
~ 10% $ of Xilinx demo boards.
Curious: Is there a "Ferrari" general RISC-V ISA shorthand or CPU implementation with more extensions including Q B V K H & S ?
Curious: Is there a "Ferrari" general RISC-V ISA shorthand or CPU implementation with more extensions including Q B V K H & S ?
How well are Linux and the BSDs supported?
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.
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.
Interesting. I see that NetBSD can now boot on riscv also:
https://mail-index.netbsd.org/port-riscv/
https://mail-index.netbsd.org/port-riscv/
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.
My answer was, however, specific to systems that run on VisionFive 2.
The situation should improve dramatically once proper documentation is available.
Not this board, but a $$ RISC-V from Xilinx's PolarFire does:
- Yocto Linux BSP
- Buildroot Linux BSP
- Embedded Linux from Siemens Embedded
- FreeBSD (coming soon)
https://www.microchip.com/en-us/products/fpgas-and-plds/syst...
- Yocto Linux BSP
- Buildroot Linux BSP
- Embedded Linux from Siemens Embedded
- FreeBSD (coming soon)
https://www.microchip.com/en-us/products/fpgas-and-plds/syst...
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.
To me, at least.
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.
To me, at least.
I meant MicroChip. Take a chill pill.
Good luck using it with docker, many images don't support ARM, let alone RISC-V
Do we know what instruction-set profile it implements? Any?
I understand it's RV64GCB + a few Z extensions.
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.
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.
Thank you. Guessing the Z extensions are AES operations? Supervisor ops?
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.
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.
Update: B extension is apparently not actually enabled. Alas.
As usual. Sigh. Just Zpopcnt would go a long way.
It might have popcnt. It might have Za and Zb.
It just doesn't claim to have B (the whole package).
It just doesn't claim to have B (the whole package).
Looks like Zbb is where the "CPOP" and related instructions (popcount, count leading/trailing zeroes) live.
Zba ("and-not" etc.) and Zbs (single-bit) are more obscure and less important. Zbc (carry-less multiply) is interesting.
Zba ("and-not" etc.) and Zbs (single-bit) are more obscure and less important. Zbc (carry-less multiply) is interesting.
more like generic tweaks rather than large swathes of stuff
$ cat /proc/cpuinfo
processor : 0
hart : 2
isa : rv64imafdc
mmu : sv39
uarch : sifive,u74-mc
Any clue on Zbb? Zk* and Zbk*?
Can you do regular Linux without S?
Can you do regular Linux without S?
I am waiting to get mine.
Imagination Technologies GPU = no thanks
If your only sell is open hardware, I'm going to wait until the hardware is open to waste my time with it.
If your only sell is open hardware, I'm going to wait until the hardware is open to waste my time with it.
Don't let your out of date[0] knowledge of imatech hold you back.
0. https://www.phoronix.com/news/Open-Source-PowerVR-Vulkan
0. https://www.phoronix.com/news/Open-Source-PowerVR-Vulkan
Don't buy from this company. They can't even keep their website up from the strain of a few HN readers.
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.