With losetup and some parameter, you get subdevices for each partition. I mounted and took what I needed from /boot, and used the official root tarball from the arch risc-v port website.
Disk images are the problem. Just use tarballs instead.
There is no build script, I did everything manually as described in this post.
Unfortunately, the corruption of the DTB file is something beyond my control. I recently discovered that the file was being overwritten by the u-Boot. I hope Starfive will address this issue in future releases of their Debian image.
I am currently waiting for the delivery of the revision B board so that I can test my image on both revisions. Until then, I do not plan on releasing any new images.
I have early work on package of the IMG_GPU driver userspace (GLES, Vulkan, OpenCL).
From the starfive-tech/soft_3rdpart repo.
It comes with some testing tools as well. rgx_triangle_test can draw some spinning triangles using DRI/KMS.
It comes with testing tools that work and use the GPU.
I think anything using opencl should work.
What doesn’t
The libvulkan is missing some some symbols so even basic things like vkcube don’t work.
It’s just GLES no OpenGL
Wayland compositors have decencies that conflict. Eg: weston explicitly depends on mesa which conflicts.
There’s no EGL not sure what’s up with that.
There’s no libgbm. Which would make KMS hard.
I haven’t tested GLES yet.
The bundled libvulkan could probably be replaced with the normal vulkan-icd and likewise for opencl. That might fix the linking issues for vkcube.
I didn’t bundle the provided headers. Again I think the standard ones should probably suffice for that. (eg vulkan-headers can be installed with this to compile vulkan programs)
I think it would be a good idea to let the package depend on ocl-icd, vulkan-icd-loader, libglvnd and opencl-headers, to supply proper versions of those libraries (and their respective headers).
At least that is how I did it for my install locally and it seems to work alright (albeit I only tested OpenCL and some Vulkan)
By using this approach there is no conflict with mesa or the like either. Those libraries should be pretty much vendor agnostic, the juicy part is the firmware binary.
Thanks for providing this; it seems to work for me (and I finally have a basic perf, even though it’s missing all the DTB PMU entries for full U74 support, sigh).
(deleted nonsense)
My problems with packages were resolved after I updated with sudo pacman -Sy.
fbdev fails to start for me. I’m trying to figure out what driver would work with this. I might have to compare with the debian image. As far as I know the debain image has make installed all its x11 stuff which makes it annoying to figure out what it’s doing.
I think you are talking about VK_KHR_swapchain, which is a Vulkan extension, should be provided by Imagination-patched Mesa.
Provided by Imagination-patched Mesa.
Provided by Imagination-patched Mesa.
I wrote a note about VisionFive 2 GPU in Chinese. I would translate it to English later, but now I’m preparing for examinations, so you might have to use machine translation. You can also reference to attached PKGBUILDs, including the one I used to build patched Mesa.
Wow thanks that basically answered all the things I was trying to figure out.
I used google translate and I think I understood it. I’m trying your PKGBUILD’s now to see if they work for me.
I installed your aur package (via yay) and all its optional dependencies, and copied starfive’s debian xorg.conf (from /usr/local), getting modesetting to work.
However, vulkan nor opengl work, and X is extremely slow as 2d rendering seems to go through glamor, which in turn goes through softpipe.
Do you actually have acceleration working? If so, what am I missing?
First of all, many thanks for providing this Arch image. While not being a foremost Arch Linux user, this is the first image that actually let’s me do the things I want with my set of of Vision 2’s. Eagerly awaiting the arrival of an Ubuntu image to standardize ARM/RISCV64 and AMD64.
For now on question; I have it running/booting from SD. It is possible to have it boot from EMMC and what steps should I take for it?
For both the emmc and nvme TO BOOT, I heard there needs to be more work done with regards to supporting pcie within the earlier boot stage components. not linux modules. We’re talking uboot and opensbi. WIP. Not done yet.
I believe you can still chroot /mnt the emmc if you want once linux is booted from the sdcard, linux supports the emmc/nvme. I’m chroot’ing to /mnt my nvme and it’s working well.