I look another, rather hacky, approach, something like:
mesa to replace mesa-pvr-vf2
llvm15-libs
mesa-pvr-vf2 package to depend on llvm15-libs (vice llvm-libs=15.07)mesa-pvr-vf2, removing mesa.wayfire is working as well as before …
gst-omx v1.22.5 gstreamer plugin for hardware video encoding / decoding with patches from StarFive
Binary Release build with clang 15 and PKGBUILD provided
https://github.com/leuc/gst-omx-starfive-aur/releases
Patch Source
https://github.com/starfive-tech/Debian/tree/20221225T084846Z/multimedia/patch/gstreamer1/sf-gst-omx
Verify Usage Example
gst-inspect-1.0 omx
[...]
Filename /usr/lib/gstreamer-1.0/libgstomx.so
Version 1.22.5
gst-play-1.0 -v --videosink='kmssink driver-name=starfive' video.mp4
Look for GstOMXH265Dec
These lines in the PKGBUILD make it pretty hard to maintain the package on rolling-based distro like Arch.
I hope/wish the whole llvm 16 and clang 16 packages are available soon.
I would not set a hard compiler dependency, unless it ONLY compiles with one specific compiler or version. Leave it to the builder and whatever makepkg config they have?
And the rm -r _build should already be accomplished by running makepkg -C ?
https://wiki.archlinux.org/title/Meson_package_guidelines was helpful too for meson builds. Worked great for gst-omx.
Should we upstream these pkg builds together in a group=(starfive) ?
@cwt can you add a provides=() line for all .ko files, so I can add them as dependency on the user space libs. It’s not fixed to a specific kernel, but any package that provides venc.ko and co.
I think in the future there will be visionfive 3 and 4 like Raspberry Pi. So how about group=(starfive-vf2) or something like that?
We may need to standardize the name of our packages. I always feel the name of my kernel packages are too long, and the name of other packages like mesa, img-gpu didn’t get along too.
I hope that, by then, VisionFive2 won’t need a special kernel nor special mesa3d.
For the latter, we depend on that Imatech open source driver actually supporting our GPUs.
The initial development board probably exists already. And at a guess a very high percentage of the current source code for the JH7110 SoC can be reused on the new chip. Once StarFive state that the solution to problems in the current silicon (JH7110) will be the StarFive next generation SoC (The errata sheet calls it the “JH-8100”), you know it is on the way. Probably 6 months to a year away from holding one in your hands (for most people), unless you are adding value. e.g. By developing software that is beneficial to RISC-V or working on a popular Linux distribution.
For now I would not expect any official announcements from StarFive to avoid the Osborne effect.
The only way that I’ve been able to successfully update the u-boot and firmware on my VF2 previously was by using arch. The commands for doing this used to be included in the top post of this thread but you seem to have got rid of those instructions. Why? Is it no longer possible to update the VF2 u-boot or firmware from Arch? flashcp is still included.
If using flashcp from Arch still works, what are the commands we’d run to update all the things under Arch? There are new versions of the starfive Debian image since I last tried updating the firmware using sf Debian so maybe it’ll work for me now following the quickstart instructions.
Last time I had to do this I had to use a different mtd device to flash the firmware to than the one given in the Updating SPL and U-Boot section of the quickstart guide.
The method I documented here:
Has yet to fail me.
Since the image was constructed using a script with minimal (or zero) manual intervention, and prior to cwt16, the SPL and U-Boot were written to partitions 1 and 2 of the SD image. Therefore, if you boot the board in SD mode, it should load the correct firmware from those partitions. Hence, there is no longer a need to flash the firmware to the board.
However, with the latest firmware 3.6.1 (possibly 3.4.5 as well?), there has been a change that writes the SPL and U-Boot directly to the SD image, resulting in an unbootable image in SD mode. I had to extract partitions 1 and 2 from the official Debian-202308 and then use them in my SD image to enable booting in SD mode. By the way, this poses another issue.
The point I want to emphasize is that if you can boot the board from the Arch SD, then you can follow the official firmware flashing instructions, which I believe would be redundant if included here. I apologize if this causes any confusion, and perhaps I should consider adding a link to the official document with some explanation.
Thanks for explaining where we’re up to cwt. I go away for a few months and everything has changed again but this is only to be expected with such new hardware.
I nearly always boot off NVMe. The only time I can see myself wanting to boot off SD would be in a recovery scenario. It seems I’ve got little to gain in upgrading my u-boot and SPL so I’ll just update my firmware using the quickstart guide command.
@leuc @stronnag et. al. I just rebuilt the mesa-pvr-vf2 against llvm15-libs instead of llvm-libs, so now you should be able to upgrade the whole system with pacman -Syu.
$ ldd /usr/lib/dri/pvr_dri.so |grep LLVM
libLLVM-15.so => /usr/lib/libLLVM-15.so (0x0000003f91663000)
I successfully updated to the latest firmware under arch using the same command and device used in the SF QSG ie
flashcp -v visionfive2_fw_payload.img /dev/mtd1
I’ve had a quick go with the SF 202308 Debian image. I was happy to see that they included all four of the packages that I had requested they add to the minimum image. Thanks StarFive!
mpv seemed to be working better than under 202306 and it does a great job of playing 60 fps 4K hevc video files on a 1080p display. I was able to get some YT videos to play when I was using my 4k display but mpv cannot output video at 4k yet. Does mpv under Arch fare any better with 4k displays?
I am going away for the weekend so I won’t get to try arch again until early next week.
I would expect mpv on arch is worse because we haven’t made packages for the gstreamer and ffmpeg using the vdec yet (as far as I know).
https://github.com/leuc/vf2-soft_3rdpart-aur/releases
https://github.com/leuc/ffmpeg-omx-aur/releases
https://github.com/leuc/gst-omx-starfive-aur/releases
i might look into packaging vlc, mpv and kodi build against the ffmpeg with omx patches, if nobody else does.
Oh sweet, nice job. I’ve been out of touch for a while. I started some similar PKGBUILDs months ago but didn’t have time to finish the project. Glad someone else stepped up 
pacman -S xf86-video-fbdev
The debian image is using mode setting for x11, not fbdev. Config is in /usr/local/etc