I thought visionfive2-img-gpu was just the firmware. I set it as a dependency of mine. I might need to have a closer look.
Mine cribs heavily from meta-riscv/recipes-graphics/mesa/mesa-pvr at master · riscv/meta-riscv · GitHub, I thought visionfive2-img-gpu was just the firmware portion - but you’re right it looks like there are some Mesa .so’s in there so that might cause issues. Or maybe my package just overwrites them. I can have a closer look later tonight or tomorrow.
yeah, the visionfive2-img-gpu contains a lot of blob or precompiled binary files from GitHub - starfive-tech/soft_3rdpart. Both of our packages provide opengl-driver and vulkan-driver.
Yeah I’ll have to fix that I guess. I’ll make an equivalent of meta-riscv/recipes-kernel/firmware/linux-firmware-visionfive2-imggpu.bb at master · riscv/meta-riscv · GitHub (which is what I thought visionfive2-img-gpu was)
Could you check if your package already provides (or overwrites) all binary files and libraries included in visionfive2-img-gpu? If that’s the case, I think I can split just the GPU firmware to a separate package, and then you can make it a dependency in your package. Finally, we can remove the blob from StarFive.
1 Like
I’ll check tomorrow. Btw the vulkan driver seems a bit broken - I mentioned here Vulkan Driver Broken? VK_KHR_SURFACE unsupported
1 Like
My package functions independently of visionfive2-img-gpu looks like. So I removed the dependency. And also I reproduced the weston issue @stronnag saw, but sway is working so 
Maybe an issue with the weston package - unsure.
Edit: Argh I was fooled by llvmpipe. So there is some piece of the firmware we need from the img gpu files. Should I make a new package for those blobs? Sounds like @cwt was up to the task as well. Whoever gets to it first I suppose.
1 Like
Do you just need this part of the visionfive2-img-gpu?
# Firmware files
install -Dm644 lib/firmware/rgx.fw.36.50.54.182 "${pkgdir}/usr/lib/firmware/rgx.fw.36.50.54.182"
install -Dm644 lib/firmware/rgx.sh.36.50.54.182 "${pkgdir}/usr/lib/firmware/rgx.sh.36.50.54.182"
install -Dm644 $srcdir/img-gpu-firmware-mkinitcpio.conf "${pkgdir}/etc/mkinitcpio.conf.d/${pkgname}.conf"
Great news! Thanks for this, even tho it looks like this PKGBUILD isn’t quite there yet. I thought those es2gears results were low for having a supposedly working mesa driver. llvmpipe deceives again!
I’ve got the next couple of weeks off work so putting together a PKGBUILD for the PVR mesa driver was near the top of things I was going to be doing but you narrowly beat me to it, which I don’t mind at all! I may or may not wait for you to fix up the firmware issue before I give it a go.
I’m pretty shocked by the lack of interest in the GPU and video decoding etc on here. I thought the open source, (potentially when the drivers are more complete) better than the Rpi GPU driver of the VF2 was the long awaited killer feature on a SBC but… crickets!
HW video decoding next!
1 Like
I think we need a bit more than just the pure firmware. The visionfive2-img-gpu provides hardware OpenCL functionality that is not supplied by mesa, but I am not quite sure which files are needed for that (Haven’t tested it).
At the very least we should need:
/etc/OpenCL/vendors/IMG.icd
/usr/lib/libPVROCL.so
/usr/lib/libPVROCL.so.1
/usr/lib/libPVROCL.so.1.17.6210866
Looking at it, we might need some vulkan stuff aswell, but I haven’t played with vulkan yet
1 Like
packaged kernel release cwt13 3.0.4-2 fails to initialise the GPU:
[Wed Jun 14 10:27:13 2023] PVR_K:(Error): 1: PVRSRVDeviceFinalise: Failed to set device (____ptrval____) power state to 'on' (PVRSRV_ERROR_TIMEOUT) [2466]
[Wed Jun 14 10:27:13 2023] PVR_K:(Error): 1: PVRSRVDeviceFinalise() failed (PVRSRV_ERROR_TIMEOUT) in PVRSRVCommonDeviceInitialise() [2170]
[Wed Jun 14 10:27:13 2023] [drm:pvr_drm_load] *ERROR* device (____ptrval____) initialisation failed (err=-19)
cwt13 extracted from the SD image initialises the GPU without error.
Did you add the gpu firmware files to the initramfs generated by the kernel?
FILES=(/lib/firmware/rgx.fw.36.50.54.182 /lib/firmware/rgx.sh.36.50.54.182)
Yes. It’s the default. And demonstrated by dmesg and lsinitcpio
could you dmesg |grep -ie pvr_k -ie rgx -ie drm ?
mine looks like this:
$ uname -a
Linux VF2-A 5.15.2-cwt-3.0.4-2 #1 SMP PREEMPT Wed Jun 14 01:20:40 +07 2023 riscv64 GNU/Linux
$ dmesg |grep -ie pvr_k -ie rgx -ie drm
[ 0.646801] PVR_K: 1: Read BVNC 36.50.54.182 from HW device registers
[ 0.646874] PVR_K: 1: RGX Device registered BVNC 36.50.54.182 with 1 core in the system
[ 0.792378] PVR_K: 1: RGX Firmware image 'rgx.fw.36.50.54.182' loaded
[ 0.796462] PVR_K: 1: Shader binary image 'rgx.sh.36.50.54.182' loaded
[ 0.798833] [drm] Initialized pvr 1.17.6210866 20170530 for 18000000.gpu on minor 0
[ 2.782652] innohdmi-starfive 29590000.hdmi: [drm:inno_hdmi_i2c_adapter] registered Inno HDMI I2C bus driver success
[ 2.783884] [drm] Initialized starfive 1.0.0 20191101 for soc:display-subsystem on minor 1
[ 3.284002] starfive soc:display-subsystem: [drm] Cannot find any crtc or sizes
[ 3.784230] starfive soc:display-subsystem: [drm] Cannot find any crtc or sizes
[ 4.284388] starfive soc:display-subsystem: [drm] Cannot find any crtc or sizes
[ 9.419763] systemd[1]: Starting Load Kernel Module drm...
[ 9.586787] systemd[1]: modprobe@drm.service: Deactivated successfully.
[ 9.587524] systemd[1]: Finished Load Kernel Module drm.
[ 39.085943] starfive soc:display-subsystem: [drm] fb0: starfive frame buffer device
Sure, first the working cwt13:
[ 0.650446] PVR_K: 1: Read BVNC 36.50.54.182 from HW device registers
[ 0.650512] PVR_K: 1: RGX Device registered BVNC 36.50.54.182 with 1 core in the system
[ 0.652006] PVR_K: 1: RGX Firmware image 'rgx.fw.36.50.54.182' loaded
[ 0.655880] PVR_K: 1: Shader binary image 'rgx.sh.36.50.54.182' loaded
[ 0.658189] [drm] Initialized pvr 1.17.6210866 20170530 for 18000000.gpu on minor 0
[ 2.643433] innohdmi-starfive 29590000.hdmi: [drm:inno_hdmi_i2c_adapter] registered Inno HDMI I2C bus driver success
[ 2.645553] [drm] Initialized starfive 1.0.0 20191101 for soc:display-subsystem on minor 1
[ 3.993865] starfive soc:display-subsystem: [drm] fb0: starfive frame buffer device
[ 9.329240] systemd[1]: Starting Load Kernel Module drm...
[ 9.513265] systemd[1]: modprobe@drm.service: Deactivated successfully.
[ 9.517520] systemd[1]: Finished Load Kernel Module drm.
And the failing packaged kernel as an attachment, as it’s somewhat bigger.
cwt-pkg.txt (15.7 KB)
Hmm… that is super weird and unexpected!
I feel like you board didn’t load the corrected dtb. Do you put both SD and NVMe together?
The boot partition is common (listed to max-depth 2):
/boot
/boot/dtbs
/boot/dtbs/5.15.2-cwt13
/boot/dtbs/sifive
/boot/dtbs/starfive
/boot/extlinux
/boot/extlinux/extlinux.conf
/boot/initramfs-linux.img
/boot/initrd.img-5.15.2-cwt13
/boot/uEnv.txt
/boot/vmlinuz
/boot/vmlinuz-5.15.2-cwt13
boot is from SD, root is on NVME (u-boot doesn’t appear to recognise the NVME, but that’s a different problem …).
The latest firmware files are identical on /dev/mtdX, and the SD/NMVE partitions 1 & 2 are imaged from the cwt13 image.
I agree that it smells like a dtb issue, just don’t see where it comes from.
I have just built an experimental real-time kernel using instructions and patches from Analysis of Running Real-Time Linux on VisionFive 2.
If you really want to try, the kernel packages are here: Release cwt13-rt 3.0.4-2 · cwt/pkgbuild-linux-cwt-starfive-visionfive2 · GitHub
2 Likes
Did the firmware packaging issues get resolved to allow easier installation of the open source PVR driver?