DietPi OS for VisionFive 2

Linux Distros
, ,
1

DietPi logo

DietPi is one of the lightest Debian based Linux distributions, optimised for minimal CPU, RAM and disk usage.

A set of bash scripts with whiptail based dialogues allow a quick and easy ready-to-run installation of about 200 server/cloud/media/home automation/… applications, with all necessary setup and configuration steps included.

Our VisionFive 2 image uses a kernel based on StarFive’s sources, but rebased onto latest upstream Linux 5.15.y (5.15.103 at time of writing). A few patches were applied to e.g. enable the HDMI text console. The kernel configuration has been adjusted to enable additional features, like WireGuard, OpenVPN, NFS+SMB server+client, F2FS, Btrfs, zswap, zram, and others. Find our kernel repository here: GitHub - MichaIng/linux

It ships without U-Boot and without initramfs. It boots with the default StarFive SPI U-Boot and has kernel + extlinux configured to not require an initramfs. But you can create one, of course, if needed.

Userland is, of course, Debian ports Sid, no snapshot, all upgrades enabled. We aim to test and in case report and/or fix issues with Debian RISC-V support and packages, so testing latest packages instead of a prepared frozen snapshot is intended. So if you have no experience with rolling-release model distros, just be careful with apt upgrade and especially apt full-upgrade, as breaking changes are possible and expected at any time.

To get started: DietPi on RISC-V StarFive VisionFive 2 SBC – DietPi Blog

General info about DietPi:

Thanks to:

5 Likes
2

Thanks, I’ve used Dietpi on numerous SBCs.
Boot from flash,
Wifi isn’t working yet, but the Dietpi ‘experience’ is good.
Straight up on HDMI, logged in with serial console.

2 Likes
3

Thanks for your feedback. Good point about WiFi, we tested everything with an Ethernet cable attached so far. Should be done with some kernel config additions, as long as the WiFi chip has mainline Linux support. I’ll probably be able to do this tomorrow.

4

[EDIT]
don’t know if it’s in Sid ??
eswin_6600u (USB)

(translated)
6600U (USB) transparent version compilation instructions The 6600U slave side uses the 6600U transparent version under the 6600U repository, and the host driver compilation command is as follows: sudo make product=6600u (no need to take os parameters, 6600U with CEVA_OS by default) The 6600U host ko load command looks like this: sudo insmod wlan_ecr6600u_usb.ko (6600U host ko will download firmware by default when loading, the default loading firmware name is: ECR6600U_transport.bin, if firmware download is not required use dl_fw=0, if you want to customize the download firmware name use: fw_name=“filename.bin”); The firmware uses firmware/ECR6600U_transport.bin

cfg file usage instructions Copy the wifi_ecr6600u.cfg to the /lib/firmware path, modify the parameter values in the cfg file, you can modify the relevant parameters of host and slave, and after the modification is completed, reload and load ko to take effect; The following parameters are currently supported: DRIVER_LOG_LEVEL=0x10800f //host driver log level, the value is a decimal 16 number of 32bits, each bit represents a class of debug types, the debug type is as follows, you can set the corresponding bit to 1 to open the debug function of the corresponding module;

FW_LOG_LEVEL=2 //slave log level, the value range is 0-4 FW_LOG_TYPE=0 // slave log output mode, 0 is output through the slave serial port; 1 is saved via host debugfs; 2 is saved via the host side file;

the driver is in your image
the firmware isn’t in your image
the firmware in eswin_6600u loads but fails
the firmware in starfive-jh7110-202302-SD-minimal-desktop.img works.

2 Likes
5

Ah right, the WiFi 6 dongle shipped for VisionFive 2 bakers. Does the firmware binary from eswin sources work?

curl -sSfo /lib/firmware/ECR6600U_transport.bin 'https://raw.githubusercontent.com/eswincomputing/eswin_6600u/master/firmware/ECR6600U_transport.bin'
modprobe wlan_ecr6600u_usb
ip l l wlan0
6

old GitHub - eswincomputing/eswin_6600u firmware loads, but then fails
the firmware in 202302-SD-minimal-desktop works
and when we say WiFi 6, is that new generation faster/better ???
looks like it is still 2.4G old school wifi
it is possible to enable 5G when compiling the module,
I’ll try that next with the working firmware.
eswincomputing has updated their firmware, but that seems to still fail.

1 Like
7

Based on the version string and date, this is not the old firmware, but the newest one. I however recognised that the driver sources differs quite significantly from the ones in StarFive’s (and hence our) kernel source tree, so probably the firmware needs to match as well. Can you check whether their initial commit matches your binary?

cd tmp
curl -sSfO 'https://raw.githubusercontent.com/eswincomputing/eswin_6600u/4a5b1c9/firmware/ECR6600U_transport.bin'
diff ECR6600U_transport.bin /lib/firmware/ECR6600U_transport.bin
rm ECR6600U_transport.bin

A problem is that I cannot find a download source for the firmware blob used by StarFive, which I could update together with the kernel source tree, when required. However, for now I can just copy the one from their Debian image and host it elsewhere for builds, but I don’t like such way of adding blobs from no clear origin.

Don’t ask me, but generally WiFi 6 supports the 5 GHz band, as long as your router/AP supports it. Not sure what you mean by “compiling the module”, as it is already compiled in our kernel.

The problem might be indeed that the drivers do not match. StarFive declares its version as V1.1.0B04P06. Eswin declared its initial commit as V1.1.0B03P06 and then after another large commit V1.1.0B05P06. But there are differences between StarFive’s and Eswin’s sources which cannot be found in the commit. So StarFive’s changes have not been merged back into Eswin’s sources, even that the version strings seem to indicate this.

8

in
/usr/src/linux/drivers/net/wireless/eswin/feature_config/6600u_config

Enable 5G

export CONFIG_ECRNX_5G=n

1 Like
9

or maybe not, translated from their website

ECR6600U series

The ECR6600U series is a single-frequency 2.4 GHz Wi-Fi 6 chip series, which is used in high-speed transparent transmission scenarios such as black home appliances, network cameras, and scanning pens.

still looking for a datasheet ?

10

I found and added the ESWIN ECR6600U firmware to our kernel package: CI | Add ESWIN ECR6600U USB WiFi adapter firmware · MichaIng/linux@eaf275b · GitHub
If this works, I’ll at least try to enable 5 GHz support with the config key you found.
EDIT: 5 GHz does not work: ECR6600U firmware

Also bumped to Linux 5.15.104.

To update the kernel:

cd /tmp
curl -O 'https://dietpi.com/downloads/binaries/linux-image-visionfive2.deb'
dpkg -i linux-image-visionfive2.deb
rm linux-image-visionfive2.deb

I also tested the fixed U-Boot env QSPI address and it works fine now:

apt install libubootenv-tool
echo '/dev/mtd2 0x00000 0x10000 0x10000' > /etc/fw_env.config
# EDIT: With Linux 6.1 it became /dev/mtd1!
fw_printenv

If the command still returns an error or nothing, the (custom) environment is still empty and the U-Boot internal defaults are used. To add the defaults to this space, abort boot via serial console, hitting CTRL+C to enter U-Boot console and run:

env save
boot

Now fw_printenv will show the whole U-Boot environment as result, which can be also stored, so it will show it even if it has been erased from SPI:

fw_printenv > /etc/u-boot-initial-env

But this is not needed to change it via fw_setenv, e.g. to generally add support for compressed kernel images:

fw_setenv kernel_comp_addr_r '0x90000000'
fw_setenv kernel_comp_size '0x10000000'
fw_printenv kernel_comp_addr_r kernel_comp_size
cd /boot
gzip vmlinuz-5.15.104
mv vmlinuz-5.15.104.gz vmlinuz-5.15.104
reboot

=>

Retrieving file: /boot/vmlinuz-5.15.104
7490517 bytes read in 323 ms (22.1 MiB/s)
append: root=PARTUUID=c3534437-01 rootfstype=ext4 rootwait earlycon=sbi console=tty1 console=ttyS0,115200 consoleblank=0 net.ifnames=0
Retrieving file: /usr/lib/linux-image-visionfive2/starfive/jh7110-visionfive-v2.dtb
47949 bytes read in 12 ms (3.8 MiB/s)
   Uncompressing Kernel Image
## Flattened Device Tree blob at 46000000
   Booting using the fdt blob at 0x46000000
   Using Device Tree in place at 0000000046000000, end 000000004600eb4c

Starting kernel ...

Not practicable of course, since our packages ship the kernel necessarily uncompressed, just to show the concept.

1 Like
11

Hi, @MichaIng :
Thanks for your awesome work! It’s my first time to try DietPi. I flashed the latest DietPi image and booted it successfully. However, I soon found DietPi only detected 4G ram on my VisionFive 2, while my board is a 8G ram version.

Maybe it’s device tree related? The vendor image showed 8G ram as I tried before.

1 Like
12

Thanks for your feedback.

I checked again, and indeed it is the very same issue as with JH7110A SoC revision (A1.2 and earlier) and Ethernet. In U-Boot, the device tree file is rewritten on every boot with adjusted Ethernet PHY node values and memory size. I find this very problematic, since any issue or power off during that write will break the image. I’m working on a device tree overlay for the old revision Ethernet support and will do the same for the RAM size. Those will be applied during first boot, via extlinux.conf, so the original device tree file is not touched.

But we need a way to identify the RAM size from userland, when the size in the device tree is still set to 4 GiB. For the SoC revision this was possible via serial number:

cat /proc/device-tree/serial-number

Mine is

VF7110B1-2253-D004E000-40000324

(indicating VF7110B => A1.3) while a JH7110A/A1.2 shows

VF7110A1-2250-D008E000-00000540

While the first block is about the SoC revision, probably the 3rd block is about the RAM size?

1 Like
13

Maybe your guess is right :smiley:, this is mine:

$ cat /proc/device-tree/serial-number
VF7110B1-2253-D008E000-00001551
2 Likes
14

Great, the guy with the old revision also just confirmed that it has 8 GiB. Let me write a device tree overlay to test.

1 Like
15

The following should solve it:

apt install device-tree-compiler
cat << '_EOF_' > dietpi-visionfive2-8GB.dts
/dts-v1/;
/plugin/;
/ {
	compatible = "starfive,visionfive-v2", "starfive,jh7110";
	fragment@0 {
		target-path = "/memory@40000000";
		__overlay__ {
			reg = <0x0 0x40000000 0x2 0x0>;
		};
	};
};
_EOF_
dtc -I dts -O dtb -o /boot/dietpi-visionfive2-A12.dtbo dietpi-visionfive2-8GB.dts
G_CONFIG_INJECT 'fdtoverlays[[:blank:]]' 'fdtoverlays /boot/dietpi-visionfive2-8GB.dtbo' /boot/extlinux/extlinux.conf 'fdt[[:blank:]]'

But it may not work yet, as fdtoverlays seems to require fdtoverlay_addr_r to be set, which is missing in the default U-Boot environment: Default value of fdtoverlay_addr_r · Issue #26 · starfive-tech/u-boot · GitHub

But with the newest kernel, the environment can be edited/extended via fw_setenv, as described above: DietPi OS for VisionFive 2 - #10 by MichaIng
I’ll wrap everything together, if this is indeed needed.

2 Likes
16

With next SPI bootloader update, adding the dtoverlay address to the U-Boot env won’t be required anymore: VisionFive 2: Add default device tree overlay address by MichaIng · Pull Request #44 · starfive-tech/u-boot · GitHub

3 Likes
17

Great! So if we want to see the 8G issue fix, should we reflash the SPI bootloader in the near future?

18

And, besides the dtoverly issue, will you also consider to enable cgroup, bridge, etc. in kernel, so that docker and systemd-nspawn can be used? :smiley:

19

Exactly, once there is a new release > 2.11.5 shown here: Releases · starfive-tech/VisionFive2 · GitHub
The bootloader can be updated via dietpi-config advanced options now as well, btw.

I’ll also keep you updated here once we have a kernel package with the fix included.

Yes, it is planned. I’ll see if I can identify the missing kernel modules the next days.

1 Like
20

Any Updates on getting all of the 8GB’s working?