In March, I wrote about my initial contact with the StarFive VisionFive 2 board. Since then, StarFive released a couple of new releases of their Debian-based operating system. However, these releases are still based on a Debian unstable snapshot from 2022 and a Linux 5.15.0 kernel that contains several severe vulnerabilities. Updating the image is not possible without breaking their custom fixes to mesa.
By now there are also dozens of distributions available for the board. Many of them rely on StarFive’s outdated kernel sources. Others merge those kernel sources with more recent upstream patches or selectively apply StarFive patches on up-to-date mainline kernel sources. However, looking at the current status of the upstreaming efforts for the JH7110 SoC, it shows that most parts of the SoC are supported in mainline Linux 6.6. The most important part missing is certainly the HDMI output.
As I am using the board purely headless, i.e., without any display, HDMI does not matter for me. With that, openSUSE Tumbleweed looked very interesting to me, currently coming with a stock Linux 6.6-rc3 kernel and stock u-boot 2023.10-rc4 and promising regular, rolling updates. However, it comes with several issues, namely:
- It boots up with 8 GiB of memory visible to the kernel – no matter how much memory your board has. If you have less than 8 GiB, segmentation faults will bite you.
- Lots of hardware that should work with the supplied kernel does not. For example, PCIe, USB, thermal sensors, SPI, etc…
- It feels slow, in particular when I/O on the SD card is involved.
- It does not properly shutdown. Instead, in most cases, the board freezes on shutdown and the file systems need a check on next boot.
By now I could fix most of these issues. If you are interested or affected yourself, read through the solutions / workarounds below.
Fixing the Amount of Available Memory
The VisionFive2 is available with different amounts of main memory. The current strategy to support those different variants is to configure 8 GiB of memory in the u-boot devicetree and to update this amount to the correct value at boot time based on information read from EEPROM. This feature was introduced in u-boot quite recently but it should be included in all 2023.10 release candidates. However, it does not work with the openSUSE image on my board which only contains 4 GiB.
Manually adjusting the devicetree memory node in u-boot to reflect a size of 4 GiB instead of 8 GiB did not solve the issue for me either, although the change reflected in /proc/device-tree after boot. As I am not sure if this is an upstream issue or some issue with the openSUSE image, I reported it to the openSUSE bug tracker.
A quite simple workaround for this problem is to add “mem=4G” to the list of kernel arguments in the grub configuration. This way, Linux will only use the lower 4 GiB of memory which match the memory present on a 4 GiB board.
To apply this change, modify /etc/default/grub and extend GRUB_CMDLINE_LINUX_DEFAULT by “mem=4G”:
GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 splash=silent systemd.show_status=1 console=ttyS0,115200n8 mem=4G"
Afterwards, regenerate the grub configuration:
grub2-mkconfig -o /boot/grub2/grub.cfg
Lacking Device Support and Performance
The issue of the missing hardware support is also related to devicetree handling in u-boot. The problem is that the environment variable fdtfile, which specifies which devicetree should be loaded, needs to be set correctly depending on the revision of the board (1.2A and 1.3B). This has only recently been implemented in u-boot by reading the revision from EEPROM and setting fdtfile accordingly. However, that fix is not yet included in any release candidate.
There are at least two methods to specify the correct devicetree anyway:
- Manually interrupt the boot process in u-boot by pressing a key. Then run the following sequence of commands:
Adjust “v1.3b” to “v1.2a” if you have that revision of the board. This change is only effective for a single boot though.setenv fdtfile "starfive/jh7110-starfive-visionfive-2-v1.3b.dtb" boot
- Add the following line in each grub boot entry before the “linux …” line:
Again, adjust “v1.3b” to “v1.2a” if you have that revision of the board.devicetree /boot/dtb/jh7110-starfive-visionfive-2-v1.3b.dtb
CAUTION: Your system will likely not boot anymore after those changes. The reason is that the correct devicetree requires use of a different driver for mmc which will not be part of the initramfs. Also, the devicetree will make available a crypto device whose driver is very unstable for me and crashes during each boot. Hence, I suggest the following sequence of changes:
- Boot the system without any modifications (only the “mem=4G” setting should be applied if needed).
- Regenerate the initramfs and make sure that the starfive-specific mmc driver is included:
dracut --regenerate-all -f --add-drivers dw_mmc-starfive
- Patch /etc/grub.d/10_linux as follows to include the “devicetree”-line in the auto-generated grub.cfg:
--- 10_linux.orig +++ 10_linux @@ -180,6 +180,7 @@ message="$(gettext_printf "Loading Linux %s ..." ${version})" sed "s/^/$submenu_indentation/" << EOF echo '$(echo "$message" | grub_quote)' + devicetree /boot/dtb/jh7110-starfive-visionfive-2-v1.3b.dtb linux ${rel_dirname}/${basename} ${root_device} ${args} EOF if test -n "${initrd}" ; then - Modify /etc/default/grub to add “modprobe.blacklist=jh7110_crypto” to the list of kernel arguments, blacklisting the broken crypto driver:
GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 splash=silent systemd.show_status=1 console=ttyS0,115200n8 mem=4G modprobe.blacklist=jh7110_crypto"
- Regenerate grub.cfg:
grub2-mkconfig -o /boot/grub2/grub.cfg
- Reboot.
- Regenerate the initramfs again to include all required drivers:
dracut --regenerate-all -f
- Reboot again.
Your system should now come up with all devices visible and functional that are supported by Linux 6.6. For example, this now also allows the use of many cheap Realtek Wifi dongles supported by the rtl8xxxu driver in recent kernels. This is handy as the provided ESWIN dongle is not supported in mainline.
Unfortunately, the one remaining issue which I could not fix so far is the broken shutdown/reboot. There are reports that this issue is also present in a custom 6.1 kernel that StarFive is currently working on, so I hope they will come up with a fix at some point in time.