I find RISC-V an interesting architecture as a truly open hardware platform. Maybe at some point in the future this platform might run on our desktop and server systems. For RISC-V as a non-microcontroller, i.e. a “real computer”, it’s still early days and I wanted to get started with testing openSUSE on it. So recently I purchased a Milk-V CM to get started. Unfortunately there are no builds for this board yet and my first attempts to get it running turned out unsuccessful. So, I decided to step half a step back and purchase one of the current de-factor reference platforms for Linux RISC-V development: The StarFive VisionFive 2.
The VisionFive 2 is awesome. It comes with decent memory options (2/4/8 GB), a SD card slot (makes it easy to quickly test an image), a M.2 slot (M-key), two network ports, an okay-ish CPU speed for development and a nicely looking metal case, because of the heck of it. Hardware-wise I think this board could become part of my homelab once we’re out of the early first steps. It’s also a bit pricy for the performance you get, but it’s a development board so I find it fair.
To start, there are some Debian-based builds for the VisionFive 2, as there are for the MilkV CM. My journey was however to get openSUSE running there without any non-upstreamed additional pathes coming from the vendor. Just to get the scope of this post right.
So let’s get this show on the road: Getting Tumbleweed running on a StarFive VisionFive 2.
Getting Tumbleweed running on a StarFive VisionFive 2
For the unpatient, here first the caveats and difficulties that I encountered while being on this journey:
- I needed to update the bootloader to get GRUB working
- HDMI doesn’t work yet, you need a UART connection
- Some builds were broken, I needed a couple of attempts until it finally worked
The process is relatively straight-forward, once you know what to do about them. We will address and solve all of one of them, one by one in the following.
Getting the image and prepare the SD card
openSUSE provides custom images for the VisionFive 2 boards. See https://en.opensuse.org/HCL:VisionFive2 for the link or go to the repostiory directly. You can flash this image directly to an SD card, insert it into the board and it should boot.
$ xzcat openSUSE-Tumbleweed-RISC-V-JeOS-starfivevisionfive2.riscv64-2024.01.16-Build23.10.raw.xz | sudo dd of=/dev/mmcblk0 bs=4M iflag=fullblock =flag=sync status=progress
Bit first you might need to update the bootloader.
Update the bootloader
I took the easy path and updated the bootloader from a running system on the board itself. I used the official release, booted into the Debian and then followed the update procedure (the link looks not really robust, I keep it here but don’t be surprised if it won’t work in the future anymore)
First, transfer the most recent u-boot-spl.bin.normal.out and visionfive2_fw_payload.img files to the board. Then, list the partition table to figure out where to flash what
# cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00001000 "spl"
mtd1: 00010000 00001000 "uboot-env"
mtd2: 00300000 00001000 "uboot"
mtd3: 00100000 00001000 "data"
Here, the u-boot-spl.bin.normal.out file needs to go to /dev/mtd0 (“spl”) and the visionfive2_fw_payload.img file to /dev/mtd2 (“uboot”). We use the flashcp tool to flash the corresponding partitions
# apt install mtd-utils
# flashcp -v u-boot-spl.bin.normal.out /dev/mtd0
# flashcp -v visionfive2_fw_payload.img /dev/mtd2
Do a reboot and you should be good to go!
Booting into Tumbleweed
From here, the system should just boot from the SD card.
The next difficulty was to realize, that the HDMI is not yet working. So I didn’t got any signal and assumed the build was broken. It isn’t - you simply don’t get any video output. But you get a serial terminal via UART.
So, what I did is to use a USB-TTL UART module and connected it to the board. The pin layout is the following:
Pin 6 GND
Pin 8 TX (connect RX)
Pin 10 RX (connect TX)
+---------------------------------------------------------------------- ... --+
| 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 30 |
| 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 |
| |
| |
. .
. .
. .
|
+---------------------------------------------------------------------- ... --+
I typically use picocom to interact with my UART module
# picocom /dev/ttyUSB0
This worked, I saw the booting messages and was happy. Until I run into the next issues.
Broken builds
So, I saw GRUB in the UART, could select Tumbleweed and was already excited. That didn’t last long however
[ 31.223179][ C2] Unable to handle kernel paging request at virtual address ffffffa279fcc200
[ 31.231813][ C2] Oops [#1]
[ 31.234791][ C2] Modules linked in: xhci_pci xhci_pci_renesas xhci_hcd usbcore nvme nvme_core mmc_block usb_common nvme_auth t10_pi axp20x_regulator dw_mmc_starfive dw_mmc_pltfm axp20x_i2c axp20x dw_mmc mfd_core regmap_i2c spidev mmc_core jh7110_crypto dw_axi_dmac_platform crypto_engine pcie_starfive clk_starfive_jh7110_aon starfive_wdt virt_dma phy_jh7110_dphy_rx spi_cadence_quadspi pinctrl_starfive_jh7110_aon pinctrl_starfive_jh7110_sys spi_pl022 sfctemp phy_jh7110_pcie clk_starfive_jh7110_stg phy_jh7110_usb btrfs blake2b_generic xor raid6_pq libcrc32c dm_mirror dm_region_hash dm_log dm_mod efivarfs
[ 31.288608][ C2] CPU: 2 PID: 29 Comm: ksoftirqd/2 Not tainted 6.7.0-rc8-73-default #1 openSUSE Tumbleweed (unreleased) 46e9439e13f0d6e63af16b21017504b41e41385c
[ 31.303129][ C2] Hardware name: StarFive VisionFive 2 v1.3B (DT)
[ 31.309402][ C2] epc : put_css_set_locked+0xae/0x250
[ 31.314654][ C2] ra : put_css_set_locked+0x8e/0x250
[ 31.319895][ C2] epc : ffffffff83adbac4 ra : ffffffff83adbaa4 sp : ffffffc80011bc10
[ 31.327817][ C2] gp : ffffffff859605a0 tp : ffffffd8c02a3a00 t0 : 0000000000000000
[ 31.335739][ C2] t1 : 0000000000ff0000 t2 : ffffffff84c00d48 s0 : ffffffc80011bc60
[ 31.343006][ T72] usb 1-1: new high-speed USB device number 2 using xhci_hcd
[ 31.343659][ C2] s1 : ffffffd8c1c75560 a0 : ffffffd8c02a3a00 a1 : 0000000200000022
[ 31.358794][ C2] a2 : ffffffda7970c000 a3 : 0000000200000020 a4 : 0000000000000000
[ 31.366720][ C2] a5 : ffffffa279fcc200 a6 : 0000000000ff0000 a7 : ffffffff8017000f
[ 31.374642][ C2] s2 : ffffffd8c1c75448 s3 : ffffffd8c1c75400 s4 : ffffffd8c1c755b0
[ 31.382563][ C2] s5 : 0000000000000122 s6 : 0000000000000100 s7 : ffffffff85d2d6c8
[ 31.390486][ C2] s8 : ffffffd8c0e4dc40 s9 : 0000000000000001 s10: ffffffff83aa21e0
[ 31.398407][ C2] s11: ffffffff858f1518 t3 : 0000000000000001 t4 : 0000000000000001
[ 31.406328][ C2] t5 : 00000000f5257d14 t6 : 0000000000702bb7
[ 31.412339][ C2] status: 0000000200000100 badaddr: ffffffa279fcc200 cause: 000000000000000d
[ 31.420957][ C2] [<ffffffff83adbac4>] put_css_set_locked+0xae/0x250
[ 31.427504][ C2] [<ffffffff83ae1848>] cgroup_free+0x3a/0x56
[ 31.433355][ C2] [<ffffffff83a1a31a>] __put_task_struct+0x36/0x138
[ 31.439817][ C2] [<ffffffff83a21cbe>] delayed_put_task_struct+0xbc/0xde
[ 31.446710][ C2] [<ffffffff83aa20ce>] rcu_do_batch+0x120/0x3ea
[ 31.452820][ C2] [<ffffffff83aa5c0e>] rcu_core+0x160/0x3ac
[ 31.458583][ C2] [<ffffffff83aa60d4>] rcu_core_si+0xc/0x14
[ 31.464345][ C2] [<ffffffff84391498>] __do_softirq+0x178/0x36a
[ 31.470459][ C2] [<ffffffff83a25030>] run_ksoftirqd+0x3a/0x4e
[ 31.476483][ C2] [<ffffffff83a47042>] smpboot_thread_fn+0x142/0x1c2
[ 31.483025][ C2] [<ffffffff83a41dd8>] kthread+0xca/0xe6
[ 31.488526][ C2] [<ffffffff84391256>] ret_from_fork+0xe/0x1c
[ 31.494476][ C2] Code: 76f3 1001 2703 0202 070e 975e 6310 f713 0026 97b2 (6394) 16fd
[ 31.502292][ T72] usb 1-1: New USB device found, idVendor=2109, idProduct=3431, bcdDevice= 4.20
[ 31.502573][ C2] ---[ end trace 0000000000000000 ]---
[ 31.511486][ T72] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 31.516742][ C2] Kernel panic - not syncing: Fatal exception in interrupt
[ 31.516752][ C2] SMP: stopping secondary CPUs
[ 31.516797][ C2] Kernel Offset: 0x3a00000 from 0xffffffff80000000
Boom. Ok, I thought the kernel simply doesn’t support this hardware. There’s an upstream plan however that shows the opposite, so it might be that this is just a kernel regression. Later on I realized that the image contains pre-release kernels, so expect some difficulties when dealing with those images. We don’t have openQA setup yet, so those builds are not being validated. They come fresh out of the Factory.
It took me two more builds until it finally worked with the openSUSE-Tumbleweed-RISC-V-JeOS-starfivevisionfive2.riscv64-2024.01.16-Build23.10.raw.xz build. The login credentials as the same as with any other JeOS image - user root password linux. Please change the password ASAP because this super secure password (TM) is already taken by someone else /s.
Take home message: If you run into kernel issues/panic, it might be that the current build contains a broken kernel (or any other component). Be patient, and wait for a new build with a newer kernel that (hopefully) fixes your issues. There is no QA yet - but that’s exactly the reason why I perform this stunt.
Welcome to the Future!
But when it boots it feels nice :-)
...... root@archon.home
.,cdxxxoc,. .:kKMMMNWMMMNk:. ----------------
cKMMN0OOOKWMMXo. A ;0MWk:' ':OMMk. OS: openSUSE Tumbleweed riscv64
;WMK;' 'lKMMNM, :NMK' 'OMW; Host: StarFive VisionFive 2 v1.3B
cMW; WMMMN ,XMK' oMM. Kernel: 6.8.0-rc5-84-default
.MMc ''^*~l. xMN: KM0 Uptime: 12 hours, 26 mins
'MM. .NMO oMM Packages: 980 (rpm)
.MM, .kMMl xMN Shell: bash 5.2.26
KM0 .kMM0' .dl>~,. .WMd Terminal: /dev/pts/1
'XM0. ,OMMK' OMMM7' .XMK CPU: (4) @ 1.500GHz
*WMO:. .;xNMMk' NNNMKl. .xWMx Memory: 196MiB / 7922MiB
^ONMMNXMMMKx; V 'xNMWKkxllox0NMWk'
''''' ':dOOXXKOxl'
I’m running nginx now on it for the sake of running it.
Expect still issues on this board. e.g. mariadb doesn’t work yet due to a nasty SIGILL. But that’s why I do it - it’s time to test and improve the support on RISC-V so that this can become an awesome hardware platform in the future. A truly open CPU and firmware.