The VisionFive 2 desktop experience (long post)

[Jackson Huff]

I got my VF2 board a couple weeks ago for a project using it, so I wanted to give a quick update regarding it. My project was to figure out if RISC-V boards were ready to be used as a simple desktop PC yet.

The first step to this project was to get the board set up with something, anything, running on it. Surprisingly, the starter kit was almost overkill here because it came with a fancy-schmancy acrylic case, a heatsink (with a fan that's totally unnecessary) with a thermal pad already applied, a power brick, a WiFi module, and an eMMC module. I assembled the case and got everything else set up. Unfortunately, I couldn't make the eMMC work even after flashing multiple images and a firmware update, so I just left that for later. Fortunately, I did have a spare microSD laying around so I used that instead. Finally, something I did later related to this was install a Samsung 970 EVO Plus NVMe SSD (512GB) but I haven't been able to boot from it or do anything else other than just mount it.

The second step? Get the desktop going. I downloaded the development Debian Wayland image from the Starfive page and loaded it onto the microSD after upgrading the firmware. After some waiting, I got an image on the super cheap 42" TV I had nothing else to use for. I logged in and after a few hours of figuring out how to get software without upgrading the specially patched packages from Starfive, I finally got Firefox and a few other useful programs loaded up.

To summarize a few more days of messing around, I'm now at the point where I can run a game launcher (Prism for Minecraft), compile special Java libraries just for that game (using JIT for native speed), listen to lossless music without any crackles, and browse webpages shockingly comfortably.

Here's the issues I've come into so far. The Minecraft launcher has not been specifically made for RISC-V (yet) so I have to compile these special libraries even though the launcher itself works without any extra effort other than manually compiling. During the first couple days, I couldn't get high quality audio working AT ALL because although the HDMI audio through the super cheap TV worked, there was zero bass (likely an RC filter messup?). I tried the built in headphone jack on the VF2 but nothing came out but loud static. Finally, two different USB audio devices (a Scarlett Solo and a Soundblaster Play dongle) worked great at first but after 30 seconds froze the entire system for what seems to be a buffer underflow. This isn't actually an issue now (as implied earlier) because those two devices somehow fixed themselves today and I can't reproduce the same issue even though no packages got upgraded. Something else I tried was to run Alacritty and Kitty because they're GPU accelerated. I couldn't get these to work, however, because it looks like the PowerVR drivers don't support the right EGL configs yet for either of the two. Finally, the last issue I have is with Firefox. Firefox can't play FLAC files for some reason (it complains about "no decoders") and from reading issues on Github, it seems to be missing packages but I wasn't able to fix that. Either way, VLC works just fine and is in fact perfect with zero crackling or other audible issues. 

To sum it up, I would say RISC-V is nearly ready for desktop usage because there are zero large blockers other than the obvious native library support for games (I haven't tried Box64 yet) and little nitpicks that may not even be an issue of RISC-V but rather bad builds. Unfortunately, for these actual RISC-V issues that remain, I'm not sure I can actually contribute to upstream for two reasons. First, for the GPU drivers, since nobody outside Imagination has the source code to them yet, this remains unfixable. Second, for the open source projects that I could contribute to, I get the impression that this kind of work for RISC-V is "frivolous" because the maintainers have said that they only support these specifically enumerated platforms, of which RISC-V isn't one of them. And when I suggested adding RISC-V nightly builds to one (probably a single line change) I got met with a refusal to attempt it.

So, to put all of that in one sentence, all RISC-V needs to be desktop ready is faster hardware, less closed-source code, and open-minded open source maintainers.

[Jackson Huff]

P.S. I accidentally posted this using my other personal email (because people often misspell it), so I'm still the same person.

[Adriaan de Groot]

Chiming in on Jackson's post,

On Thursday, 1 June 2023 23:17:46 CEST Jackson Huff wrote:
> I got my VF2 board a couple weeks ago for a project using it, so I wanted
> to give a quick update regarding it. My project was to figure out if RISC-V
> boards were ready to be used as a simple desktop PC yet.

We (wearing my "KDE community" hat here) got one to check out specifically KDE
Plasma Desktop support on the VF2 board -- so that's roughly the same project
as yours, but with a specific tech stack (FreeDesktop + Qt + KDE Plasma,
probably Wayland rather than X11) as target. That lifts everyone's boat as we
get a broader ecosystem and improved infrastructure (at the FreeDesktop level
and things on top of that).

> [image: Screenshot from 2023-06-01 20-40-55.png]
> The first step to this project was to get the board set up with something,
> anything, running on it. Surprisingly, the starter kit was almost overkill
> here because it came with a fancy-schmancy acrylic case, a heatsink (with a
> fan that's totally unnecessary) with a thermal pad already applied, a power
> brick, a WiFi module, and an eMMC module.

Agreed, that acrylic case *is* fancy-schmancy (and looks nice and I appreciate
the thought put into the posts and assembly of the thing).

> Unfortunately, I couldn't make the eMMC work even
> after flashing multiple images and a firmware update, so I just left that
> for later.

I mostly bumped into it being a 16GB eMMC module, and the "image 69"
recommended default Debian distro unpacking to 16GB+a smidgen. Since it did
not fit, I switched to micro-SD as well.

> Finally, something I did later related to this was install a
> Samsung 970 EVO Plus NVMe SSD (512GB) but I haven't been able to boot from
> it or do anything else other than just mount it.

My only spare was a 1TB 980 PRO, so it feels like a ridiculous amount of
overkill. Was there a suitable nvme 2280 retention screw included in the
package? If so, I didn't spot it.

Anyway, I have not tried booting from it, but it is identified and is writable
by the "image 69" kernel without any issues:

nvme0n1 259:0 0 931.5G 0 disk
`-nvme0n1p1 259:1 0 64G 0 part /mnt/tmp


So at this point my goal is to kick off builds (starting with the KDE Qt patch
collection, rather than the somewhat dated Qt5 available via that Debian
image) and to see how far we get.

[ade]

[Stewart “X” Addison]

Having seen a VF2 without a heatsink/fan I'm pleasantly reassured by having the fan present, although it is a bit louder than I'd like and isn't speed controlled. I also really like having the case :-)

One other thing to note is that if anyone tries the Ubuntu 23.04 image you can't use the USB ports or the M.2 slot for an NVME SSD (Known issue) so the board will work via UART console+ethernet but clearly not if you plan to attach it to a screen :-) I'm a little surprised that Ubuntu shipped with USB not working, but hopefully they'll get that resolved fairly soon.

I'm also booting off an SD card and keeping the (much faster!) eMMC as my "data" drive for running builds etc. and it's working well.

[Robert Lipe]

On Tue, Jun 6, 2023 at 7:13 AM Stewart “X” Addison <s...@redhat.com> wrote:

Having seen a VF2 without a heatsink/fan I'm pleasantly reassured by having the fan present, although it is a bit louder than I'd like and isn't speed controlled. I also really like having the case :-)

IMO, and I haven't measured temps or read that part of the data ships, if the chip/board maker thought the board needed a fan, one would be included or HIGHLY recommended just to reduce warranty costs and failures. I get that MOST people won't be running all four cores full tilt, so maybe it's only the highest portion users that need to bother. {shrug}
 

One other thing to note is that if anyone tries the Ubuntu 23.04 image you can't use the USB ports or the M.2 slot for an NVME SSD (Known issue) so the board will work via UART console+ethernet but clearly not if you plan to attach it to a screen :-) I'm a little surprised that Ubuntu shipped with USB not working, but hopefully they'll get that resolved fairly soon.

I bought an Early Board and Ubuntu 23.04 on it basically useless.  USB and M2 don't work and on the early boards, you have to upgrade firmware manually because they blew the compatibility between the board firmware and the OS, even if you DO fiddle with the DTB files as mentioned (added for me...) in the release notes.

All three of these fixes: 

• USB (broken on all boards) 
• M.2 (broken on on all boards)
• The firmware updater that would ensure the board and the firmware were in sync (broken on EarlyBirds), rendering Ethernet dead, so even the optional WiFi board can't be used.

were available for a long time before Canonical cut this image. (I know there's lead time and testing time and ... While it's great that Canonical is increasingly committed to RISC-V, it's just pretty sad that Canonical chose to ship something that was so close to totally broken. It wasn't a great first showing.

There's a way to reflash the PROMSs manually. I just haven't done it yet. It's a pretty ridiculous expectation, even for early adopters. I figure in the time I can do that, I can probably install either other Debian derivatives (I love DietPi on my smaller headless SoC's...) that move fast and may have updated to newer kernels and included updaters in about that time.

I haven't tried it, but going to VisionFive's own image might be an option.
https://github.com/starfive-tech/VisionFive2/releases
mentinoes NVM boot, WiFi, and USB

I was Fedora years ago, then did time in Ubuntu, but I don't think either DietPi or the VisionFive image looks too culture-shocky to at least try. I'll report back (it may be a few weeks) unless someone else here does first.

probably Wayland rather than X11) as target. That lifts everyone's boat as wez

Are Wayland and X working now, or is changing that the goal?

I mostly bumped into it being a 16GB eMMC module, and the "image 69"
recommended default Debian distro unpacking to 16GB+a smidgen. Since it did
not fit, I switched to micro-SD as well.

Be sure your logging and swap aren't on SD. They tyically have a low number of write cycles and a development-class machine can tear up both logs and swap actions, potentially leaving you with a slightly broken card. (A completely dead one is MUCH easier to recognize and diagnose.)

Definitely keep copies of your work trees elsewhere, even if that's on NFS.

None of this is unique to StarFive - that's just operating systems on SD. Disabling swap is the norm, but we dno't normaly have an eMMC or SSD to outsource it to.

 

overkill. Was there a suitable nvme 2280 retention screw included in the
package? If so, I didn't spot it.

Not in either of my RISC-V boards with such sockets. My card is short anyway, so, embarrassingly,  it's kept in control by two rubber bands, for redundancy.

 

So at this point my goal is to kick off builds (starting with the KDE Qt patch
collection, rather than the somewhat dated Qt5 available via that Debian
image) and to see how far we get.

As a Qt dev, the positively ancient Qt that's available on the Linuxen really holds them back for me. The hacked up QWebView on one of them (still using WebKit instead of Chrome's own Clang is a BIG problem) keeps my project years behind there compared to the others... But that's beyond the scope of this group.

RJL

[Fishwaldo1]

Hi All,

Apologies in advance if outsiders should not be posting to this group, but I was passed a link and told that you all might be interested in my work.

I have been working on the Kernel, uboot, and a Yocto Image for the Star64 and upcoming PineTab-V from Pine64. These are based on the JH7110 SOC which is the same as the VisionFive2.

With this Yocto Image, I have taken the "vendor" patches from StarFive and existing contributions to the meta-riscv yocto layer on Github and built a KDE Plasma Image that is leveraging both the GPU and VPU for graphics/video acceleration. As far as I am aware, outside of the Debian Snapshot that Starfive provide, no other images or distributions currently support GPU or VPU acceleration on the JH7110. The Yocto Recipes I have should also be able to build for the VisionFive2, although i'm unable to test as I don't have a VF2, but happy to help anyone who wants to try it out.

In addition, I've taken the list of all the apps that fall under the "KDE Gear" banner (close to 300 apps/libraries etc) and created a Yocto Layer for this, that provides a complete KDE Plasma Desktop. I've spent a lot of time on the KDE side packing the apps and in some cases, simple patches for RiscV (or yocto) support. As I understand from looking over this group, there are a number of people working on similar "desktop" related work with the JH7110 SOC and I thought there might be a opportunity to collaborate on this together (I'm not a member of the Dev Board Program though... so if there are other preferred channels, please let me know)

The main github repo for this work is at https://github.com/Fishwaldo/meta-pine64 (but if you are familar with the Yocto "layers" - A lot of different layers, and thus, patches lives in different repositories under my Username - I"m hoping to upstream these changes where possible soon)

At the very least, I hope some of the work I've done so far could help people here with their efforts on desktop support on more "mainstream" distributions such as Ubuntu/Fedora/Gentoo/Arch etc.

Adrian,

In addition, I would like to contribute back all my work on the KDE Yocto Layers I've updated/changed... maybe you can ping me off list on this with your KDE community hat, or point me to someone that I can collaborate with there? This is using the latest releases of Plasma, KF5 and KDE Gear Apps, and is at least a version or two ahead of the existing yocto recipes hosted on invent.kde.org

(this work is far from over in case i gave that impression. I'm still battling with qtwebengine/chromium porting to riscv, and the VPU acceleration with ffmpeg/gstreamer is pretty unstable as well)

Thanks

Justin