I partitioned and unpacked arch’s risc-v tarball using starfive’s debian image, then chrooted into it and updated it.
Then I copied and set up cwt’s kernel.
However, my usual encrypted swap setup doesn’t work:
Feb 09 12:51:40 StarFive systemd[1]: Starting Cryptography Setup for swap...
Feb 09 12:51:40 StarFive systemd-cryptsetup[279]: Cannot initialize device-mapper. Is dm_mod kernel module loaded?
Feb 09 12:51:40 StarFive systemd-cryptsetup[279]: Set cipher aes, mode cbc-essiv:sha256, key size 256 bits for device /dev/nvme0n1p1.
Feb 09 12:51:40 StarFive systemd-cryptsetup[279]: Cannot initialize device-mapper. Is dm_mod kernel module loaded?
Feb 09 12:51:40 StarFive systemd-cryptsetup[279]: Cannot use device swap, name is invalid or still in use.
Feb 09 12:51:40 StarFive systemd-cryptsetup[279]: Failed to activate with key file '/dev/urandom': Operation not supported
Feb 09 12:51:40 StarFive systemd[1]: systemd-cryptsetup@swap.service: Main process exited, code=exited, status=1/FAILURE
Feb 09 12:51:40 StarFive systemd[1]: systemd-cryptsetup@swap.service: Failed with result 'exit-code'.
Feb 09 12:51:40 StarFive systemd[1]: Failed to start Cryptography Setup for swap.
The kernel seems to have been built w/o device manager support (or something related is broken), and thus I can have no encrypted swap (or encrypted anything).
I did get weston working on wayland. I never tried X. I don’t think it will working out of the box without Starfive patches. It may required binary blob too, which I don’t expected it to work because the glibc on Arch is newer than Debian.
@rvalles I just uploaded an experimental kernel that I’ve been working on. It’s quite stable and I’ve been using it as my daily driver for a week now (24x7). DM, DM_CRYPT, and other DM_* modules are enabled.
The kernel was built with LLVM:
$ make -j4 LLVM=1 CC="clang -mcpu=sifive-u74 -mtune=sifive-7-series"
So if you want to build any external module or driver, please add LLVM=1 to your make command.
@cwt The latest image ArchLinux-VF2_515_v2.8.0-cwt6.1.img (not experimental image) has two flaws…
The extracted image is 15GB. Even though most of it is empty, dd will still write additional 12-ish GBs to the disk and cause extra wear and tear. It is also very time consuming. Please trim the image down, 15 GB is too much. I guess you can get away with 1200MB only
The device tree is still being corrupted somehow… The reboot +0 command does not work. I can see on UART that the board is stuck and the last kernel message is: reboot: Restarting system with command '+0'. Edit: The reset button doesn’t work either
Can you share your build scripts? Maybe I can chip in, I too prefer Arch over Debian
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.