StarFive VisionFive 2

This will be a long article with lots of information compiled from various sources as well as my experience tinkering with the StarFive VisionFive 2. This SBC is a RISC-V (in)development board, and if you’re looking for a one-click solution to play Cyberpunk 2077 and brag to your Discord friends, this ain’t it, homey.

Very important note: this article is work in progress!

Overview

RISC-V architecture

RISC-V is an open standard instruction set architecture (ISA) based on established reduced instruction set computer (RISC) principles. Unlike most other ISA designs, RISC-V is provided under royalty-free open-source licenses. A number of companies are offering or have announced RISC-V hardware, open source operating systems with RISC-V support are available, and the instruction set is supported in several popular software toolchains.

The project started in 2010 at the University of California, Berkeley along with volunteer contributors not affiliated with the university. To give the project stability and make it attractive to commercial users, a formal RISC-V Foundation was incorporated to own, maintain and publish the RISC-V definition. It was recently renamed RISC-V International, incorporated in Switzerland.

The main idea is that while ARM, the most known RISC architecture, is proprietary and needs licensing by chipmakers, RISC-V is meant to be royalty-free and, in general, free to use for everyone.

StarFive VisionFive 2

VisionFive 2 is the world’s first high-performance RISC-V single board computer (SBC) with an integrated GPU. Compared with its last generation, VisionFive 2 has been fully upgraded with significant improvements in the processor work frequency, multimedia processing capabilities, scalability, etc. Its superior performance and reasonable price make VisionFive 2 the best affordable RISC-V development board ever.

VisionFive 2 boasts a quad-core 64-bit SoC with RV64GC ISA, running up to 1.5 GHz, and integrated with IMG BXE-4-32 MC1, supporting OpenCL 3.0, OpenGL ES 3.2, and Vulkan 1.2. Available with 2/4/8 GB LPDDR4 RAM options, VisionFive 2 provides rich I/O peripherals such as M.2 connector, eMMC socket, USB 3.0 ports, a 40-pin GPIO header, Gigabit Ethernet ports, a TF card slot, and many more. It has onboard audio and video processing capabilities and has MIPI-CSI and MIPI-DSI connectors as multimedia peripherals. The open source SBC also provides wide software compatibility including support for Debian. StarFive

Specifications

StarFive JH7110 SoC

The StarFive JH7110 SoC has six RISC-V cores, of which four 64-bit RISC-V cores run the main OS, plus a 64-bit RISC-V monitoring core, and a 32-bit RISC-V real-time core. Also, there are two 1-lane PCIe 2.0 interfaces up to 5 Gbps each.

• CPU
  • Quad-core 64-bit RISC-V SiFive U74 (RV64GC) processor @ up to 1.5 GHz with 32KB D-Cache, 32KB I-cache.
  • Single-core 64-bit RISC-V SiFive S76 (RV64IMAC) monitor core with 16KB I-cache, 8KB DTIM.
  • Single-core 32-bit RISC-V SiFive E24 (RV32IMFC) real-time control core with 16KB I-cache.
  • Up to 2MB L2 cache.
• GPU
  • Imagination BXE-4-32 GPU with support for OpenCL 1.2, OpenGL ES 3.2, Vulkan 1.2.

Let’s play with it

I ordered the VisionFive 2 (8 GB RAM variant) straight from the horse’s mouth (if the horse would be China) and the delivery to Turdistan took two weeks. Price was ~$100 including delivery.

I have two goals in mind for this SBC: first to familiarize myself with the RISC-V architecture (therefore transforming the board into a full-featured computer with proper accessories, operating system, etc) and second to port Hoshi to RISC-V.

If you want to use the SBC for something and not just look at it (though I have to admit it’s a handsome board), you will need some things:

• 1 × VisionFive 2 SBC, obviously.
• 1 × Micro SD card (32 GB or more), I had a 128 GB one lying around.
• a computer with Linux/Windows/macOS, Debian in my case.
• USB to Serial Converter.
• Ethernet cable.
• Power adapter.
• USB Type-C Cable.

After updating the board and actually booting into a full-featured OS, you will need some more stuff:

• HDMI to HDMI cable.
• an external display.
• keyboard and mouse, doh.

Serial console

You will need a USB-to-Serial converter (like Sparkfun FTDI Basic 3.3V) and to connect 3 pins from the VisionFive 2 40-Pin GPIO header the the USB-to-Serial board.

For the Sparkfun FTDI Basic 3.3V board, the connection is done like this:

Connect the USB-to-Serial board to a free USB port of your computer, and install minicom.

$ sudo apt update && sudo apt install minicom

Figure out which of the connected serial devices is your USB-to-Serial converter:

$ sudo dmesg | grep tty
[  1085.850537] usb 2-1: FTDI USB Serial Device converter now attached to ttyUSB0

Start minicom and connect it to your serial device (make sure hardware flow control is off):

$ sudo minicom -D /dev/ttyUSB0 -b 115200

Power on the VisionFive 2 SBC and you will get serial output from the board.

Updating firmware

Before installing Debian (or any other supported Linux distro) we need to update the SPL and U-boot, and we’ll do that using the last version of the minimal Linux image (sdcard.img) provided by StarFive, [direct link to .img]. Download balenaEtcher and select the sdcard.img file that you just downloaded, and a SD card that’s already inserted somewhere in your computer (hopefully in a SD card slot). Press Flash button.

Alternatively, use dd to write the disk image to the proper SD card.

$ sudo dd if=sdcard.img of=/dev/sdb bs=4M status=progress conv=fdatasync

When balenaEtcher (or dd) finished writing, eject the SD card and pop it inside the SD card slot of your VisionFive 2. Insert the USB-C power cable into the SBC (or press the Reset button if the cable is already connected) and give it some time to boot.

When you see the buildroot login: prompt, enter:

username: root
password: starfive

Make sure your VisionFive 2 is connected to the network, check with ifconfig and look at eth0 or eth1, depending on where your network cable is inserted.

Download the latest (v3.0.4 as of now) SPL and U-boot from GitHub: visionfive2_fw_payload.img, u-boot-spl.bin.normal.out on your computer and send them to the VisionFive 2 using scp. 192.168.1.4 is the IP of the SBC, check yours with ipconfig on the SBC.

$ scp visionfive2_fw_payload.img root@192.168.1.4:~
$ scp u-boot-spl.bin.normal.out root@192.168.1.4:~

Alternatively, you can copy the two files to an USB stick and insert it into the VisionFive SBC.

Back to the VisionFive board and check the partitions layout:

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00001000 "spl"
mtd1: 00300000 00001000 "uboot"
mtd2: 00100000 00001000 "data"

Now we can update SPL (to the correct partition, /dev/mtd0):

# flashcp -v u-boot-spl.bin.normal.out /dev/mtd0
Erasing blocks: 32/32 (100%)
Writing data: 127k/127k (100%)
Verifying data: 127k/127k (100%)

And update U-boot to /dev/mtd1:

# flashcp -v visionfive2_fw_payload.img /dev/mtd1
Erasing blocks: 683/683 (100%)
Writing data: 2731k/2731k (100%)
Verifying data: 2731k/2731k (100%)

AFTER flashcp finished erasing, writing and verifying, power down the VisionFive 2:

# shutdown -h now

Installing Debian

Remove the SD card from the SBC and pop it back into your main computer, now it’s time to write the Debian image on it. Download the latest image from either Baidu or Google, extract the .bz2 file and write the resulting .img file to the same SD card using balenaEtcher.

Alternatively, you can dd the image file old-school style but be aware of the destination, you wouldn’t want to overwrite something that shouldn’t be overwritten.

$ sudo dd if=starfive-jh7110-VF2-SD-wayland.img of=/dev/sdb bs=4M status=progress conv=fdatasync

When it’s done, pop it back into the VisionFive 2 and press the Reset button to power it up. At this stage you want to have a keyboard, mouse (maybe), HDMI cable, display, etc. The first boot takes a while (about 3 minutes) but the subsequent ones take less.

Login with:

username: user
password: starfive

Extending partition(s)

You will need to use fdisk to extend the partition on the SD card first:

$ fdisk /dev/mmcblk1

Delete partition number 4 and recreate it (d -> 4 followed by n -> 4). Type w to write the partition info and now you can resize the filesystem of the partition number 4:

$ resize2fs /dev/mmcblk1p4

Check with df if the partition 4 occupies the rest of the SD card, its size depending on the size of your SD card, of example on a 128 GB card:

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            3.7G     0  3.7G   0% /dev
tmpfs           793M  3.1M  790M   1% /run
/dev/mmcblk1p4  118G  2.4G  115G   3% /
tmpfs           3.9G     0  3.9G   0% /dev/shm
tmpfs           5.0M   12K  5.0M   1% /run/lock
/dev/mmcblk1p3  100M   23M   78M  23% /boot
tmpfs           793M   32K  793M   1% /run/user/110
tmpfs           793M   24K  793M   1% /run/user/1000

To fix the pink screen overlay you will need to run /opt/disable_monitor_color.sh and reboot, you need to rerun it when using a different monitor as it ties to the monitor device ID.

Install optional packages

Install the optional Debian packages:

cd ~/Downloads
wget https://github.com/starfive-tech/Debian/releases/download/v0.7.1-engineering-release-wayland/install_package_and_dependencies.sh
chmod +x install_package_and_dependencies.sh
sudo ./install_package_and_dependencies.sh

If you want to monitor core temperature, install the lm-sensors package:

$ sudo apt install lm-sensors
$ sensors
x.tmon-isa-0000
Adapter: ISA adapter
temp1: 		+65.3°C

To dump a list of USB or/and PCI devices you will need to install the required packages:

$ sudo apt install pciutils usbutils
$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundations 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundations 2.0 root hub
$ lspci
0000:00:00.0 PCI bridge: PLDA XpressRich-AXI Reg Design (rev 02)
0000:01:00.0 USB controller: VIA Technologies, Inc VL805/806 xHCI USB 3.0 Controller (rev 01)
0000:00:00.0 PCI bridge: PLDA XpressRich-AXI Reg Design (rev 02)

I’ve seen people complaining that writing an image to a SD card, updating the SPL flash is soooo complicated and that a MacBook Pro M2 is more powerful. Yes, it’s true, if you’re the kind of person that compares a $65 board with a $3000 laptop.

Flashing is pretty simple and even if you do something wrong, you will still be able to recover your board.

Do not use apt upgrade or apt dist-upgrade because you will lose all the StarFive patches, until they land into the kernel upstream!

Setup NVMe SSD

As of StarFive’s 3.0.4 firmware release, NVMe boot is supported out of the box, so you don’t need to bootstrap a Debian environment anymore. Just update the SPL and U-Boot to v3.0.4, write the starfive-jh7110-VF2-SD-wayland.img to nvme0n1, replace all occurencies of /dev/mmcblk1p3 and /dev/mmcblk1p4 inside /etc/fstab/ and /boot/extlinux/extlinux.conf with /dev/nvme0n1p3 and /dev/nvme0n1p4 and resize the last partition.

Here is how:

$ sudo dd if=starfive-jh7110-VF2-SD-wayland.img of=/dev/nvme0n1 bs=4M status=progress conv=fdatasync
$ sudo mkdir nvme-boot && sudo mount /dev/nvme0n1p3 nvme-boot
$ sudo sed -i 's/mmcblk1p3/nvme0n1p3/g' nvme-boot/boot/extlinux/extlinux.conf
$ sudo sed -i 's/mmcblk1p4/nvme0n1p4/g' nvme-boot/boot/extlinux/extlinux.conf
$ sudo umount nvme-boot
$ sudo mkdir nvme-root && sudo mount /dev/nvme0n1p4 nvme-root
$ sudo sed -i 's/mmcblk1p3/nvme0n1p3/g' nvme-root/etc/fstab
$ sudo sed -i 's/mmcblk1p4/nvme0n1p4/g' nvme-root/etc/fstab
$ sudo umount nvme-root
$ sudo shutdown now

Make sure the Boot Mode is set to 1-bit QSPI Nor Flash.

After restarting the SBC, resize the user partition but replace /dev/mmcblk1 with /dev/nvme0n1, partition numbers stay the same.

I’ll leave the rest of the section for historical reasons but as I said before, it’s obsolete now.

Pop the SSD inside the slot on the back of your VisionFive 2 SBC and install the nvme-cli package to make sure your SSD is correctly detected:

$ sudo apt install nvme-cli
$ sudo nvme list
Node                  Generic               SN                   Model                                    Namespace Usage                      Format           FW Rev  
--------------------- --------------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1          /dev/ng0n1            [REDACTED]           KINGSTON SNV2S1000G                      1           1.00  TB /   1.00  TB    512   B +  0 B   SBM02103

$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
mtdblock0    31:0    0   256K  0 disk 
mtdblock1    31:1    0     3M  0 disk 
mtdblock2    31:2    0     1M  0 disk 
mmcblk1     179:0    0 119.4G  0 disk 
├─mmcblk1p1 179:1    0     2M  0 part 
├─mmcblk1p2 179:2    0     4M  0 part 
├─mmcblk1p3 179:3    0   100M  0 part /boot
└─mmcblk1p4 179:4    0 119.3G  0 part /
nvme0n1     259:0    0 931.5G  0 disk 

Partition and format the NVMe disk:

$ parted /dev/nvme0n1
GNU Parted 3.5
Using /dev/nvme0n1
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mklabel gpt
(parted) mkpart
Partition name?  []? /boot/efi
File system type?  [ext2]? fat32
Start? 100M
End? 700M
(parted) mkpart
Partition name?  []? /boot
File system type?  [ext2]? ext4
Start? 798M
End? 2048M
(parted) mkpart
Partition name?  []? /
File system type?  [ext2]? ext4
Start? 2056M
End? 1T
(parted) print
Model: KINGSTON SNV2S1000G (nvme)
Disk /dev/nvme0n1: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name       Flags
 1      99.6MB  700MB   601MB                /boot/efi  msftdata
 2      798MB   2048MB  1250MB  ext4         /boot
 3      2056MB  1000GB  998GB   ext4         /

(parted) quit
Information: You may need to update /etc/fstab.

$ sudo mkfs.vfat /dev/nvme0n1p1
$ sudo mkfs.ext4 /dev/nvme0n1p2
$ sudo mkfs.ext4 /dev/nvme0n1p3
$ sudo sync

Check if everything is ok:

$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
mtdblock0    31:0    0   256K  0 disk 
mtdblock1    31:1    0     3M  0 disk 
mtdblock2    31:2    0     1M  0 disk 
mmcblk1     179:0    0 119.4G  0 disk 
├─mmcblk1p1 179:1    0     2M  0 part 
├─mmcblk1p2 179:2    0     4M  0 part 
├─mmcblk1p3 179:3    0   100M  0 part /boot
└─mmcblk1p4 179:4    0 119.3G  0 part /
nvme0n1     259:0    0 931.5G  0 disk 
├─nvme0n1p1 259:4    0   573M  0 part 
├─nvme0n1p2 259:5    0   1.2G  0 part 
└─nvme0n1p3 259:6    0 929.6G  0 part 

And now you can use debootstrap and setup a chroot on the new NVMe disk.

Testing disk reads with hdparm yields the following results:

$ sudo hdparm --direct -t /dev/mmcblk1
/dev/mmcblk1:
 TIMING O_DIRECT disk reads: 64MB in 3.01 seconds = 21.23 MB/sec
$ sudo hdparm --direct -t /dev/nvme0m1
/dev/nvme0m1:
 TIMING O_DIRECT disk reads: 584MB in 3.00 seconds = 194.34 MB/sec

/dev/mmcblk1 is a 128GB Samsung EVO+ SD card and /dev/nvme0m1 is a 1TB Kingston SNV2S1000G NVMe. I don’t have an eMMC module to test its speed.

Others

• There are two hardware versions of the SBC, Rev 1.2A and Rev 1.3B. Rev 1.3B has dual Gigabit Ethernet ports.
• JH7110 SoC doesn’t have V extension (Vector Operations).
• JH7110 SoC doesn’t have H extension (Hypervisor).
• The extensions available for the JH7110 cores are:
  • U74 - RV64IMAFDC_Zicsr_Zifencei_Zba_Zbb_Sscofpmf (rv64imafdczbb0p93_zba0p93_zicsr_zifencei_sscofpmf)
  • S76 - RV64IMAC_Zicsr_Zifencei_Zba_Zbb_Sscofpmf (rv64imaczbb0p93_zba0p93_zicsr_zifencei_sscofpmf)
  • E24 - RV32IMFC_Zicsr (?)
• The S76 and the E24 cores are not used for now (the E24 core is not even enabled in the Linux DTS file).

RISC-V extensions

When identifying the RISC-V ISA standard and extensions for the target device, the following table may be useful:

RISC-V defines the order that must be used to define the ISA subset:
RV[32, 64, 128] I, M, A, F, D, G, Q, L, C, B, J, T, P, V, N.

For example, RV32IMAFDQC is legal, whereas RV32IMAFDCQ is not. In the case of the VisionFive 2, the following identifiers are both valid however the first is more descriptive: rv64imafdc, rv64gc. Also, we have some additional extensions to take into account:

• zicsr (Control and Status Register [CSR] Instructions); implied by the F extension
• Bitmanip extensions Zba (address generation) and Zbb (Basic bit manipulation)

This results in the following being the descriptive and shorthand flags for the VisionFive2 board respectively: rv64imafdc_zicsr_zba_zbb, rv64gc_zba_zbb.

Operating systems

Currently the VisionFive 2 SBC works under multiple operating systems, with various stages of support:

Binary blob status

I’ll just quote Nicole Faerber from Purism:

Even though the RISC-V ISA is free and many many things around RISC-V are also pretty open and free this does not guarantee a blob free software ecosystem. I just mention it here for the sake a completeness. The JH7110 seems, as far as I know, very promising for being very close to blob free, yes, but not fully. Still the LPDDR4 PHY firmware is needed (included in UBoot) and I think we will not see a free replacement for this any time soon.

We had this discussion about firmware and blobs a couple of times already and my take on this is less strict as the RYF. Yes, of course in an ideal world we want to have everything free and open. But we are not living in this ideal world so we have to cope with reality somehow and come up with a reasonable middleground that will not cut us off from hardware supplies for our software development and in the end our work needs - I am not doing all this work just for the sake of enjoying development but to create something that I and other people can actually do work with.

Nevertheless, the JH7110 is very promising in this regard too, not 100% blob free but pretty close and the parts that are not free I am not very concerned about. I would be concerned about blobs that are running in kernel space, closed source libraries in user space or proprietary firmware running on peripherals that have very low level access to private data, i.e. peripherals directly attached to the memory bus without IOMMU. But this is not the case here.

My biggest concerns with blobs are about freedom and security. […] Let’s take the DDR4 PHY as a first example. The DDR4 PHY is a very tiny logic part of the SOC. Yes, it sits directly attached to the RAM, quite naturally, but the PHY’s only function is to do the physical attachment of the SOC to the DDR4 RAM, controlling signal strength, impedance etc. but it does not understand the data getting pushed through that afterwards and also has no means to run complicated intelligence operations on the data. The PHY firmware only gets executed once after initial power on reset to tune the signal lines to the DDR4, that’s it. I do not know 100% for sure since this would require a really in depth research, but I am fairly sure that there is little to no security risk in it. As for the freedom part it is a tiny piece of hex dump firmware that usually gets rolled into UBoot, downloaded and triggered for execution only once after power on.

It is not what I and all freedom lovers would ideally like to have, but I am OK with that. Better having it this way than not being able to use the hardware at all.

Boot mode settings

Boot Mode	RGPIO_1	RGPIO_0	Picture
1-bit QSPI Nor Flash	0 (Low)	0 (Low)
SDIO3.0	0 (Low)	1 (High)
eMMC	1 (High)	0 (Low)
UART	1 (High)	1 (High)

GPIO 40-Pin header

All GPIOs can be switched (multiplexed) to support different functions including but not limited to SDIO, Audio, DMIC, SPI, I2C, UART, PWM, and CAN bus.

List the GPIO chips:

$ ls -l /dev/gpiochip* 
crw-------    1 root     root      254,   0 Jan  1 00:00 /dev/gpiochip0
crw-------    1 root     root      254,   1 Jan  1 00:00 /dev/gpiochip1

To configure the GPIO pin 44 (pin 40 on the 40-Pin GPIO header):

$ cd /sys/class/gpio
$ echo 44 > export
$ cd gpio44

Configure the GPIO pin as out or in:

$ echo out > direction
$ echo in > direction

Configure the voltage level of the GPIO pin as high or low:

$ echo 1 > value
$ echo 0 > value

I2C

To connect something to I2C (for example a sensor), you will need pin 1 (for +3.3V) or pin 2 (for +5V), pin 9 (GND), pin 3 (GPIO58 I2C SDA) and pin 5 (GPIO57 I2C SCL).

Install the i2c-tools package and insert the module:

$ sudo apt install i2c-tools
$ sudo modprobe i2c_dev

Start by scanning the bus:

$ sudo i2cdetect -l
i2c-0   i2c             Synopsys DesignWare I2C adapter         I2C adapter
i2c-2   i2c             Synopsys DesignWare I2C adapter         I2C adapter
i2c-5   i2c             Synopsys DesignWare I2C adapter         I2C adapter
i2c-6   i2c             Synopsys DesignWare I2C adapter         I2C adapter
i2c-7   i2c             Inno HDMI                               I2C adapter

Scan I2C bus 0:

$ sudo i2cdetect -y -r 0

JTAG

From StarFive’s U-boot source we can see the SoC JTAG lines are multiplexed to the GPIO pins 35, 36, 37, 38 and 40, as follows:

static void jh7110_jtag_init(void)
{
	/*jtag*/
	SYS_IOMUX_DOEN(36, HIGH);
	SYS_IOMUX_DIN(36, 4);
	SYS_IOMUX_DOEN(61, HIGH);
	SYS_IOMUX_DIN(61, 19);
	SYS_IOMUX_DOEN(63, HIGH);
	SYS_IOMUX_DIN(63, 20);
	SYS_IOMUX_DOEN(60, HIGH);
	SYS_IOMUX_DIN(60, 29);
	SYS_IOMUX_DOEN(44, 8);
	SYS_IOMUX_DOUT(44, 22);
}

And you can use a SEGGER J-Link probe to connect to the SoC.

Photos

Click on one of the images for a higher resolution photo.

System info

• View the bootlog (no SD card, no eMMC, no NVME, no network)
• View the bootlog (v2.11.5, minimal SD image, no network)
• View the bootlog (v2.11.5, Debian Image-202303, no network)

$ sf probe
SF: Detected gd25lq128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB

$ cpu list
  0: cpu@0      rv64imacu
  1: cpu@1      rv64imafdcbsux
  2: cpu@2      rv64imafdcbsux
  3: cpu@3      rv64imafdcbsux
  4: cpu@4      rv64imafdcbsux

$ cat /proc/cpuinfo
processor       : 0
hart            : 1
isa             : rv64imafdc
mmu             : sv39
isa-ext         : 
uarch           : sifive,u74-mc

processor       : 1
hart            : 2
isa             : rv64imafdc
mmu             : sv39
isa-ext         : 
uarch           : sifive,u74-mc

processor       : 2
hart            : 3
isa             : rv64imafdc
mmu             : sv39
isa-ext         : 
uarch           : sifive,u74-mc

processor       : 3
hart            : 4
isa             : rv64imafdc
mmu             : sv39
isa-ext         : 
uarch           : sifive,u74-mc

$ cat /proc/cmdline
root=/dev/mmcblk1p4 root=/dev/mmcblk1p4 rw console=tty0 console=ttyS0,115200 earlycon rootwait stmmaceth=chain_mode:1 selinux=0

$ uname -a
Linux starfive 5.15.0-starfive #1 SMP Sun Mar 26 12:29:48 EDT 2023 riscv64 GNU/Linux

$ cat /proc/partitions
major minor  #blocks  name

  31        0        256 mtdblock0
  31        1       3072 mtdblock1
  31        2       1024 mtdblock2
 179        0  125173760 mmcblk1
 179        1       2048 mmcblk1p1
 179        2       4096 mmcblk1p2
 179        3     102400 mmcblk1p3
 179        4  125062144 mmcblk1p4

$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
mtdblock0    31:0    0   256K  0 disk 
mtdblock1    31:1    0     3M  0 disk 
mtdblock2    31:2    0     1M  0 disk 
mmcblk1     179:0    0 119.4G  0 disk 
|-mmcblk1p1 179:1    0     2M  0 part 
|-mmcblk1p2 179:2    0     4M  0 part 
|-mmcblk1p3 179:3    0   100M  0 part 
`-mmcblk1p4 179:4    0 119.3G  0 part /

Documentation

Official documentation for VisionFive 2 components, provided by StarFive, mirrored here, all PDF downloads.

Additional links

• StarFive GitHub organization
• VisionFive 2 firmware images
• RVspace
• RVspace VisionFive 2 forum
• RVspace documentation center
• StarFive VisionFive 2 on Ubuntu Wiki
• VisionFive 2 Debian images
• RVspace Application Center
• JH7110 Upstream plan