New Fedora images for Starlight/VisionFive


I wanted to check when the newer fedora images for Starlight/VisionFive will be released? The last fedora image was dated at 26/12/2021. It’s been more than 2 months the newer images are out.


For current version, there is no update plan yet. If there is an update, we will release and post it on the forum as soon as possible.

It seems that things compiled with this image rely on mesa and/or the llvm-libs even when using plain GCC and removing clang/llvm.
Those binaries then crash consistently with:
WARNING: This target JIT is not designed for the host you are running.

LLVM ERROR: Cannot select: 0x2b070e4ca0: ch = store<(store 4 into
A easy-to-compile example (depends only on sdl2) could be scummvm.
It compiled and ran out of the box on all RV64 images I tried for the Unmatched board, so it is not necessarily an issue of RiscV per se but rather (I merely suspect) the LLVM-libs and their JIT.

1 Like

To my knowledge, Mesa always relies on LLVMpipe as a JIT for CPU workloads. This should be no different on other RISC-V boards, or really on anything platform.

Having said that, this looks like a bug in the RISC-V support within Mesa or possibly LLVM. You probably don’t encounter it on other boards because they use GPU accerelation instead of the software rasteriser.

1 Like

Yes, that sounds plausible to me. I only wonder how to fix that, or simply wait for updates on LLVM. Also I wonder why this is so little reported as it seems to affect ALOT of things. Maybe most people use the VisionFive headless…?

1 Like

I don’t expect LLVMpipe to be of much practical use without vectorisation (and without GPGPU). I honestly don’t know what is the state of RISC-V vectorisation support in LLVM, but I’d guess that it is somewhere between nonexistent and very early prototype.

The question is moot anyhow given that the VisionFive supports neither V nor P extensions.

Personally, I’ve used DRM/KMS to render directly so that, in effect, the monitor takes care of colour space and hopefully soon also upscaling. That is not literally headless, but it still still avoids the display server and GL.

hello, i’ve just observed that type of LLVM error trying to compile a simple program linking to SDL2 library installed through Fedora package manager. That same program (and 2 other) was running fine on the Unmatched so it is specific to this board/setup. Unfortunately i don’t know so much about MESA things, so i’ll wait and hope for some fix.

1 Like

From 04 May, the main branch of github LLVM-project is containing the fix to the unmanaged “generic” RISCV CPU type (considering valid only ‘generic-rv32’ or ‘generic-64’ type). I’m currently compiling it on the VisionFive, and will try to use this LLVM when building MESA and SDL2 later, to give a try.

1 Like