VisionFive 2 kickstarter, $49 4 GB 64 bit quad core 1.5 GHz RISC-V - Page 1
Forum section: electronics / general

author: brucehoult
author_rank: Super Contributor
timestamp: August 23, 2022, 09:49:53 am
content: https://www.kickstarter.com/projects/starfive/visionfive-24 GB board in November, 2 GB and 8 GB in February. My total charge for the 4 GB super early bird board including shipping to New Zealand is SG$80 (US$57.27, NZ$92.74, AU$83.35, £48/69, €57.75)Imagination Tech BXE-4-32 GPU. They've been promising open source drivers. Hopefully that happens. Imagination have also announced their own RISC-V cores, so they're serious about supporting RISC-V and may have really turned over a new leaf after getting dumped by Apple.Officially announced with Debian and Fedora support. Ubuntu are already supporting the (dual core, 1.0 GHz, no GPU) VisionFive 1, so I'm sure they'll be in, and others too.Between Pi 3 and Pi 4 performance, except this generation of RISC-V doesn't yet have SIMD/Vector or crypto (SHA, AES) acceleration. Next year's SoCs will.Has Micro SD, SPI flash, eMMC, M.2 M-key for SSD (or WIFI if you prefer). Dual gig ethernet, HDMI 2.0 (4k x30), 2 USB2, 2 USB 3. Pi-compatible GPIO. All that camera and LCD display stuff...Note: the Pine64 "Star64" using the same SoC but on a larger board with a PCIe x4 slot is expected to be a similar price (not yet announced) and available to order within weeks.Several other RISC-V SoCs with up to 2x Pi 4 performance (similar to ARM-based RK3588, while this board's SoC is similar to RK3566) are expected to be announced soon, with boards in maybe mid 2023. This tech is not going to stand still in the next few years.

author: FlyingDutch
author_rank: Regular Contributor
timestamp: September 06, 2022, 04:54:15 pm
content: Hi @brucehoultIt seems the Chinese learned their conclusions from the first version of this board. The RISC-V CPU in the first version could not have any GPU, which caused the CPU to saturate (while moving the mouse). On the other hand, the Chinese should be thanked for such a quick introduction of changes "in silicon".Best regards

author: Nominal Animal
author_rank: Super Contributor
timestamp: September 06, 2022, 08:26:33 pm
content: Quote from: brucehoult on August 23, 2022, 09:49:53 amI've been bitten by closed source blobs and forked kernel trees in Linux SBCs enough times to wait until the support is upstreamed to the vanilla Linux kernel tree. The instability and maintenance hassle and being dependent on the vendor is just not worth it.Other than that, it definitely looks interesting. Except..QuoteYeah, nah.

author: brucehoult
author_rank: Super Contributor
timestamp: September 06, 2022, 11:55:05 pm
content: Quote from: FlyingDutch on September 06, 2022, 04:54:15 pmThe JH7110 was always the "real" version of the chip. It was originally supposed to have shipped in the BeagleV "StarLight" in September 2021. They made a limited number of JH7100 -- about 300, on a "shuttle run" -- and distributed them to developers for free as the BeagleV "Starlight" Beta board in May 2021.The JH7100 was never intended for volume production. I was surprised when they announced the VisionFive v1 with it at the end of 2021. I don't know how many chips they made, or whether they actually made production masks for it or just ran the MPW masks a few more times. Given that the VisionFive v1 was sold for three times the price of the VisionFive 2, with the rest of the board almost identical, I strongly suspect that they continued to use (expensive) shuttle run chips for it.

author: brucehoult
author_rank: Super Contributor
timestamp: September 07, 2022, 12:03:33 am
content: Quote from: Nominal Animal on September 06, 2022, 08:26:33 pmThat is THE most recent LTS kernel, used in e.g. the current (and supported) Ubuntu 22.04 LTS.The CPU cores and everything out to L2 cache and the buses are straight SiFive U74-MC, with kernel support long since upstreamed. Things such as initialising the DRAM and console UART are the job of U-Boot and OpenSBI, not the Linux kernel.

author: Nominal Animal
author_rank: Super Contributor
timestamp: September 07, 2022, 07:23:13 am
content: Quote from: brucehoult on September 07, 2022, 12:03:33 amAnd yet, they still insist on forking the kernel and providing their own? I don't want vendor forks, they always die before the hardware does. And it's a pain to deal with, unless you run their preferred distro with their preferred packages. I rarely do.I'm only saying that I'm very suspicious of any SBC nowadays that cannot run vanilla kernels, and require one to use vendor trees. Doubly so, when they claim the kernel sources "will be released". This stuff is not something you work on in private, and not something I am willing to take on a vague promise, no matter how interesting the hardware seems to be.Have you ever had to look at Linux-based routers' source trees? Aside from OpenWRT, those arehorribleconcoctions glued together with spit and bubblegum. Linux systems integration is not that difficult, just don't hire high-schoolers or Windows enthusiasts to do it (like most router manufacturers seem to do, especially Asus).

author: Nominal Animal
author_rank: Super Contributor
timestamp: September 07, 2022, 08:21:57 am
content: All that said, if they do sort out the software side in a sensible manner, so that one can run a Debian derivative with a vanilla Linux kernel without closed-source blobs, this would be a great board for many use cases. I do love the idea of RISC-V SBCs running Linux, and do want one myself.Do note that my gripes are exacerbated by the fact that RISC-V is an open design; it annoys me to no end when the same approach is not taken throughout, and is stopped mid-way because of no actual reason –– especially when it would not be that much effort to do it right all the way. Like brucehoult mentioned, the base RISC-V support is already in the Linux kernel, so pushing any board-specific stuff (device tree, and driver quirks if any) to the vanilla kernel should be the default, not an optional end goal. Similarly, if you push all needed support (u-boot et cetera) upstream, you can concentrate on maintenance and testing and improvements, instead of wasting your time in packaging. Too many vendors do their own integration in private,and fail at it, already.Vendors providing their own forks of open source projects as SDKs is a stupid, wasteful way of supporting SBCs. We can do better.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 07, 2022, 06:49:42 pm
content: Quote from: Nominal Animal on September 07, 2022, 08:21:57 amI do not disagree with this, although I personally still don't know how to leverage open-source in a healthy business model.

author: Nominal Animal
author_rank: Super Contributor
timestamp: September 07, 2022, 09:42:49 pm
content: Quote from: SiliconWizard on September 07, 2022, 06:49:42 pmWith Linux SBCs, we can assume profits come from the hardware sales, so the target (for the vendor) should be to minimize maintenance cost while maximizing the user demand. Forking a kernel and/or a distribution maximizes maintenance cost (since you'll be doing it all yourself), with the only vendor benefit being that the vendor can hopefully force users to upgrade to another SBC when the support ends. Problem is, those users won't have any incentive to pick that vendor again, especially if the vendor uses a shorter product cycle than the users prefer (which is always, because users want BOTH the old stuff maintained forever AND the new stuff also).An appliance baseboard vendor could push the component support upstream, and generate documentation on how to do the systems integration properly, achieving vanilla kernel and typical userspace support from the get go. The inertia there is the proprietary give-us-the-SDK model you need to overturn first; it can be a bit of a fight to get the Cxx bigwigs to understand that this is better than the old proprietary way.SoC vendors like Samsung and Amlogic are already doing this; similarly for the RISC-V support itself (by RISC-V foundation and companies like SiFive).What is still lacking is the documentation on how to do it properly and efficiently without wasting money, I guess.I might sound like a zealot, but that's a misunderstanding. For example, I do not mind that appliance providers have their own userspace applications and services and daemons that are proprietary, as long as they use the same kernel APIs as everything else. As a systems integrator myself –– I like to put together my own "distros" for dedicated devices and appliances –– binary kernel blobs mean that I cannot reliably debug the kernel; vendor kernel trees mean I have to backport any later changes from vanilla kernels to the vendor tree (unless the tree is so mangled, like on many Asus routers, that it is impossible to do); and so on. Basically, binary blobs and vendor trees tie my hands in a way that makes it less than worth the necessary effort for me.It annoys me more, because I do firmly believe that getting the support upstreamed is, for the vendor, for the entire product lifetime,cheaperthan having someone maintain the forks and packaging. You may have to hire an actual professional instead of random highschoolers, though. Smaller overall cost-benefit ratio, in other words.For hobbyists who just use the SBCs according to guides and videos, having binary OS images one can use from the get go is more important, sure.But is an SBC targeting only the hobbyists and rejecting the integrators and open source developers actuallyviable? RPI does it, but the foundation pays quite a few people to do the integration and maintenance stuff for them; actual profit-seeking companies without SoC vendor patrons with deep pockets are hard-pressed to duplicate that. The Pi "clone" manufacturers seem to thrive by pushing a new model out at least once a year –– except for the ones who do push the support upstream.If a fully working system is achievable with packages only from the Debian repositories (no vendor-specific packages or software needed), basically all my worries and objections here are voided.(And if that happens, I want one of these, too. Especially if it can boot of M.2 SSD without an initrd on an SD-card or USB memory stick.)What Ifearis what I have seen many times before, and the "Debian" support is actually a Debianforkprovided by the vendor; a specific version snapshot, that the vendor "promises" to maintain for a short while, with kernel sources "coming soon" (and when available, cannot reproduce the distributed binaries). Debian itself will grow and fix bugs, but those won't affect the vendor fork, unless actively backported by the vendor.Maybe not an issue for pure end users, I dunno, but definitely an issue for integrators and system/appliance developers like myself.So, why am I whining here, bothering a thread about crowd funded projects? Because this project is already so close, but at high risk of making the same old fatal flaws as other SBC projects have done before. I'm hoping that if people point it out, the flaws could be avoided. Perhaps not for this kickstarter, but by the next model; I'd be happy with that, too. If this feels like I'm slighting the Kickstarter project or anyone else, I apologize; not my intent.

author: brucehoult
author_rank: Super Contributor
timestamp: September 07, 2022, 10:07:56 pm
content: Quote from: Nominal Animal on September 07, 2022, 08:21:57 amNote that many projects DO NOT allow you to upstream code for unreleased products.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 10, 2022, 12:56:27 am
content: Quote from: Nominal Animal on September 07, 2022, 09:42:49 pmWell, for this particular market, I agree completely. Actually those boards are 100% useless without proper software support, all the more that they usually come with no to very little hardware documentation and writing your own support is often not even doable.Without Linux, they wouldn't sell a single board. So they are leveraging it and they definitely need to give back in the most open way possible.

author: brucehoult
author_rank: Super Contributor
timestamp: September 10, 2022, 02:30:08 am
content: I'm in contact with a developer in China who has a prerelease Pine64 Star64 with the same JH7110 SoC. It came running at 1.25 GHz but they've yesterday bumped it to 1.75 GHz and it happily ran stress test overnight, reaching 43 C in a room that was around 30 C. They do have a heatsink with fan on it at present, but plan to try without after the weekend.The data sheet gives Theta-JA as 8.1 ºC/W (on the 1 cu foot box JESD51-2 still air test procedure, I assume), 5 W maximum consumption at 1.5 GHz, and 125 C maximum junction temperature, so it should be absolutely fine without a heatsink at all in a domestic/office environment.This SoC is looking like being the 2nd properly-engineered RISC-V applications processor after the Allwinner D1. But the D1 is single core single-issue at 1.0 GHz, while this is quad core dual-issue (~1.6 IPC in practice) at 1.5 GHz, so up to maybe 9 times faster in aggregate.The only slightly annoying thing is it uses the 21G1 U74 core release, which is at least a nice upgrade from the early 2019 core using in the JH7100 test chip in the VisionFive v1 (and earlier BeagleV beta board). But the 21G3 U74 core release (U74-MC coreplex really) got a 4 channel DRAM stream predictor / prefetcher. The lack of a prefetcher means the JH7110 is only doing 450 MB/s on standard memcpy while the slower CPU core D1, which has a prefetcher, does 1100 MB/s. However the JH7110 has 2 MB L2 cache, which is considerably faster than the D1's DRAM. The D1 doesn't have an L2 cache.

author: 5U4GB
author_rank: Super Contributor
timestamp: March 10, 2023, 05:52:30 am
content: I've got a VF2 and it's perfectly fine for development work, if you're not doing kernel development or needing to support obscure bits of hardware but just want to test your stuff on Risc-V it's quite adequate. The main concern with this is whether it'll be like every single other Risc-V Linux SBC ever, about six months of fixer-upper DIY install and update, six months of mostly-works but increasingly infrequent updates, and then it's abandonware as the next-big-thing SBC is prepared for release and the cycle repeats.But if all you want to do is make sure your existing code runs on a new architecture it's good enough.