DietPi OS for VisionFive 2

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:

2 Likes

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

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.

[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

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

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

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.

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

Enable 5G

export CONFIG_ECRNX_5G=n

1 Like

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 ?

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: 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
pw_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 pw_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 pw_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