Arch Linux Image for VisionFive 2

sajattack · July 23, 2023, 4:59am

mesa-pvr-vf2-22.1.3-1-riscv64.pkg.tar.zst (9.3 MB)
Mesa 22.1.3 supporting DDK 1.19

https://aur.archlinux.org/packages/mesa-pvr-vf2

Tested to work with

weston
sway
hyprland
wayfire

stronnag · July 23, 2023, 6:41pm

Thanks, GTK4 applications now fail to crash. Excellent.

cwt · July 24, 2023, 6:27am

I’m not quite a fan of GUI on SBC or embedded system, but here’s the Window Maker on VF2

danboid · July 29, 2023, 2:40pm

Your gist guide still recommends mesa-pvr-vf2-21.2.5-1-riscv64.pkg.tar.zst. Would you now recommend mesa-pvr-vf2-22.1.3-1-riscv64.pkg.tar.zst?

I’ve not tried your guide or cwt14 yet. I wonder if hw video decoding works?

stronnag · July 29, 2023, 4:44pm

Thanks, I will update the notes.

cwt · August 9, 2023, 6:03am

Just release the cwt15 image.

stronnag · August 9, 2023, 6:19pm

Thank you again.
Will there be a kernel package (otherwise, I don’t mind scraping the image; qemu-nbd makes this painless) ?

Update: OK, I discovered them in the image.

cwt · August 9, 2023, 9:19pm

You can download the latest packages from the release pages from these repo:

Kernel from GitHub - cwt/pkgbuild-linux-cwt-starfive-visionfive2: PKGBUILD for Linux kernel (-cwt) Image on StarFive VisionFive 2
GPU driver from GitHub - cwt/aur-visionfive2-img-gpu: IMG_GPU driver AUR package for VisionFive2
Mesa from GitHub - cwt/aur-mesa-pvr-vf2: Clone of https://aur.archlinux.org/mesa-pvr-vf2.git to host the binary package

I’m learning on how to make them available together on a single GitHub repo and be able to upgrade them just by pacman -Syu command.

rvalles · August 28, 2023, 10:59pm

Irrespective to the binary packages, why not put the three PKGBUILDs in the aur?

cwt · August 29, 2023, 3:51am

The GPU stuff is already in AUR under @trissylegs’ ownership, but she hasn’t merged my pull request for the last two releases. So, I went ahead and updated it myself and put up the binary package on GitHub.

Mesa is also on AUR, but I’m just hosting the binary package on GitHub.

As for the original kernel package in AUR owned by @saeziae, my patches and building method are quite different from the original one. I’ve always considered it highly experimental, so I’m not sure if it’s a good fit for AUR (though that might just be my gut feeling).

Or may be I should give them all a rebrand and list them on AUR with my unique names? However, I have a feeling (again) that it is against the AUR recommendation.

leuc · August 31, 2023, 3:03am

I looked into packing the hardware decoding / encoding stack for Arch.

The Debian build script and the provided patch files are the best reference so far.

https://github.com/starfive-tech/Debian/blob/20221225T084846Z/multimedia/build.sh

wave420l does compile on Arch with the patches
w4_enc_test does encode yuv to x265

ffmpeg -f lavfi -i yuvtestsrc -t 1 -r 30 -s 1920x1080 -f rawvideo -pix_fmt yuv420p wave420l/code/yuv/mix_1920x1080_8b_9frm.yuv

sudo wave420l/code/script/enc_1920x1080_8b.sh

wave511 builds on Arch with patches
omx-il builds on Arch with patches
gst-omx builds on Arch with patches but only v1.18.5, nothing above

So far partial decoding support in gstreamer.

gst-inspect-1.0 omx
Plugin Details:
  Name                     omx
  Description              GStreamer OpenMAX Plug-ins
  Filename                 /home/user/repos/soft_3rdpart/target/usr/lib/gstreamer-1.0/libgstomx.so
  Version                  1.18.5
  License                  LGPL
  Source module            gst-omx
  Source release date      2021-09-08
  Binary package           GStreamer OpenMAX Plug-ins
  Origin URL               Unknown package origin

  omxh264dec: OpenMAX H.264 Video Decoder
  omxmp3dec: OpenMAX MP3 Audio Decoder
  omxmpeg2dec: OpenMAX MPEG2 Video Decoder

The run_env.sh test script also lists omxh265dec.

Haven’t tried building the patched ffmpeg or gstreamer, yet. That might be the reason why no encoders are build…

Main blockers

access to /dev/venc /dev/jpu /dev/vdec requires root
starfive-tech/soft_3rdpart really needs to be split into individual repositories for easier packaging (and PR’s). git clone --filter might be a work-around

or proper Makefiles that don’t require patches…

… to be continued

cwt · August 31, 2023, 4:08am

We should allow all to read/write them (666), right?

leuc · August 31, 2023, 4:12am

matching /dev/dri/card0 might be the best practice? Change group to video or render with 0660.

cwt · August 31, 2023, 5:58am

yeah, will change group to video with mode 660

leuc · September 1, 2023, 5:18am

WIP PKGBUILD for ‘codaj12’ ‘wave420l’ ‘wave511’ and ‘omx-il’

https://github.com/leuc/vf2-soft_3rdpart-aur

Please check if it builds with /etc/makepkg.conf settings.

rvalles · September 1, 2023, 5:33am

I cloned your repo and built the kernel.

Booting it, fstab handling for LABEL=linux-home (my /home) times out.

It is encrypted with LUKS2, and the device (via crypttab) opens correctly. But the contents of the opened device aren’t the decrypted data, but high entropy garbage i.e. encrypted data as-is or decoded with the wrong key.

This should never happen, as if LUKS2 manages to open the device, it means that the needed cryptography support is available, and the entered passphrase is correct.

└─nvme0n1p7    259:7    0 867.7G  0 part
  └─linux-home 254:1    0 867.7G  0 crypt
[root@starfive ~]# cryptsetup status linux-home
/dev/mapper/linux-home is active.
  type:    LUKS2
  cipher:  aes-xts-plain64
  keysize: 512 bits
  key location: keyring
  device:  /dev/nvme0n1p7
  sector size:  512
  offset:  32768 sectors
  size:    1819723776 sectors
  mode:    read/write
[root@starfive ~]# file /dev/mapper/linux-home
/dev/mapper/linux-home: symbolic link to ../dm-1
[root@starfive ~]# file /dev/dm-1
/dev/dm-1: block special (254/1)
[root@starfive ~]# file -s /dev/dm-1
/dev/dm-1: data
[root@starfive ~]# uname -a
Linux starfive 5.15.2-cwt-3.4.5-2 #1 SMP PREEMPT Thu Aug 31 04:18:49 UTC 2023 riscv64 GNU/Linux

u-boot and spl are from v3.6.1… as I boot from newest debian image sdcard with added extlinux.conf options for my Arch Linux. DIP switches set to use sdcard.

edit: I installed your binary package, to exclude issues specific to my build environment. It behaves the same way.

Do you have any clue what could be going on?

cwt · September 1, 2023, 5:54am

Seems like we’re both tackling the same thing at the same time. Should I go ahead and split out the building package for ‘soft3dpart’ from my PKGBUILD?

Sometime in the past, I tried to do that, but it turned out I had to provide the whole kernel source instead of just the header package. That kind of made the whole building process a bit more complicated.

Right now, the deal is that ‘soft3rdpart’ gets built alongside the kernel, and then we divide it into three separate packages. You can check out how it’s done in my PKGBUILD.

I’m up for adding the stuff I missed from your PKGBUILD too. But I have to see if I can get it to build separately first.

cwt · September 1, 2023, 5:58am

The last time I use LUKS (and it was only LUKS not LUKS2) was ages ago!

I’d love to assist, but honestly, I have no clue.

rvalles · September 1, 2023, 7:22am

All it means is that the kernel’s cryptography support is broken, at least for aes-xts-plain64. Old kernel was fine.

I’d like to try and build your kernel with gcc instead of llvm, to see if this changes anything. Is this easy to achieve?

cwt · September 1, 2023, 7:30am

In that case, just change all lines with:

LLVM=1 CC="clang -mcpu=sifive-u74 -mtune=sifive-7-series"

to:

CC="gcc -mcpu=sifive-u74 -mtune=sifive-7-series"

and then makepkg again.

By the way, which kernel was good and which kernel was bad? I want to see if there was anything related to crypto added or removed.