VisionFive 2 Debian Image 202306 Released

[jiangtao9999]

If “additional packages” is build from mesa-9999.0 , they can install and version is 9999.0 too .
Others rely on hand-written deps.

[thefossguy]

@Michael.Zhu can you please add a tag on GitHub for u-boot and kernel? I maintain a separate image of my own

[LivingLinux]

Here is my video review of the release:

202306 Debian Update VisionFive2 RISC-V SBC

[crash1013]

I have written the starfive-jh7110-202306-nvme-minimal-desktop.img to an nvme ssd and installed it in my VF2. I selected QSPI boot mode both switches low. No boot that I can see after a considerable time. What am I doing wrong?

[mzs]

@crash1013

What am I doing wrong?

I did not hear you say that you updated the onboard SPI NOR flash to the very latest SPL+U-Boot (u-boot-spl.bin.normal.out) and U-Boot+OpenSPI (visionfive2_fw_payload.img).

[coltree]

dd command default block size 512 bytes
try with bs=4M
my dd was swift with bs=4M
nvme SSDs block size 4096 bytes
minimum bs=4K
nvme does block write, multiple ‘writes’ to one block is wasteful
each access it rewrites the whole 4k block
so 512 bytes = 8 repeated writes for each block

[omac777]

Perhaps you would like to try compressing with orz. The encode times are impressive and the decode time is respectable as well. All these requests are in the hopes to make image creation and checksum’ing iterations fasters: b3sum and orz make a good team at this point.

git clone https://github.com/richox/orz.git
cd orz/
cargo build --release

Here’s the encode result with vf2 nvme image:

time /home/davidm/rustplay/orz/target/release/orz encode starfive-jh7110-202306-nvme-minimal-desktop.img starfive-jh7110-202306-nvme-minimal-desktop.img.orz
[INFO] statistics:
[INFO]   size:  3145728000 bytes => 741275542 bytes
[INFO]   ratio: 23.56%
[INFO]   speed: 15.592 MB/s
[INFO]   time:  201.750 sec

Here’s the decode time for the same vf2 nvme image:

time /home/davidm/rustplay/orz/target/release/orz decode starfive-jh7110-202306-nvme-minimal-desktop.img.orz starfive-jh7110-202306-nvme-minimal-desktop.img.2
[INFO] statistics:
[INFO]   size:  3145728000 bytes => 741275542 bytes
[INFO]   ratio: 23.56%
[INFO]   speed: 57.865 MB/s
[INFO]   time:  54.364 sec

[crash1013]

Yes, that was the problem. I was not sure where to get the latest. I was not sure about using cpflash because of the instruction wording was confusing; “only supports versions equal to or later than VF2_v2.5.0.” I did not understand the version. However cpflash worked perfectly. I just booted and extended the partition…

[ycat3]

Wrong Japanese keyboard layout .
Such as
" → @, & → ^, ’ → &, ( → *
When I modify /etc/default/keyboard file
XKBMODEL=pc105
XKBLAYOUT=jp
XKBVARIANT=
XKBOPTIONS=
VisioFive2 Debian Image 202303 worked fine.
I feel Image 202306 does not reflect /etc/default/keboard

Image 202306 is working both SD and nvme image.

[marv]

In google drive not found, in my case baidu not is possible into…

[LivingLinux]

@marv

In google drive not found

They switched to MS OneDrive. I just checked and the files are listed.
Did you start from https://debian.starfivetech.com/ ?

[KenDickey]

Thanks much for the work here!
I was able to build and test Gambit Scheme compiler.
Also the Cuis Smalltalk IDE running on OpenSmalltalk VM, on both Wayland and in Framebuffer (libevent + libfbdev).

[marv]

Thanks, installed and function…

[Fishwaldo]

@Michael.Zhu where can we find the patches/sources for the packages that starfive have modified? it all seems out of sync with the old Debian repository etc.
eg, mesa 22, chromium, gst, vlc etc

[ioasiodf]

I installed VisionFive 2 Debian Image 202306 in my SD card. My VF2 is connected to a 4K display and it’s a very laggy experience. I can’t switch my resolution to 1920x1080 60Hz. Can you tell me if I can change the resolution in the command line ? Or have you a better idea ? My VF2 software is latest in the flash.

[Chloe]

Hi @ioasiodf , mabye first you should check if your screen supports 1080P or not (although most of the screens can). The following is the command to check this:

1. Execute the following command to install:

apt install libdrm-tests

2. Execute the following command to check:

modetest -M starfive -c

If it still doesn’t work, hope this post can help you：

A unified reply to a question about the display of debian69

Currently there are two main phenomena： After starting debian, the screen will appear black and a mouse and the mouse cannot move. Black screen after startup, no mouse. Corresponding solutions are as follows： 4K display issues： The 4K monitor will have a black screen and mouse after starting debian, and the mouse will not move. The main reason is that there is no support for 4K monitors at the moment, if you need to use a 4K monitor you can use the following method (this method will workar…

[DavidPlatt]

I’m also getting the NVME queue timeouts, as I did on the previous releases. I’ve been looking around on the web and have found numerous reports of this sort of NVME queue timeout on many different Linux systems and with different types of NVME SSD. It doesn’t seem to be specific to the VisionFive 2.

It sorta sounds as if there’s a problem (or regression) in the NVME driver in recent versions of the Linux kernel, which causes command completions or MSIX interrupts to be dropped under certain ill-defined conditions. Feels like a timing-sensitive race condition to me, but I can’t prove it by any means.

I haven’t found a way to avoid it. The best I’ve been able to do on my VisionFive 2 is use a systemd service script to set the io_timeout for the NVME device down to 5 seconds (from the default 30), so that the timeouts and recovery happens sooner.

For now, I’ve decided not to make NVME the primary device, as even a 5-second timeout when trying to run a program is annoying. I’m booting from EMMC and using the NVME as a data-storage filesystem only.

On the up side - I can report that an EMMC compatibility problem seems to have been fixed by the new Debian image, or the latest board firmware. With the previous release, the driver would try to run the EMMC at a super-high speed of 100 MHz and kept timing out. With the new release the speed for the slot is set to 50 MHz, and everything works fine.

On the down side - the new firmware’s UBoot scripts seem to have some quirks. If I have only an EMMC (and no SD card), the FDT isn’t being loaded - the “fatbootpart” variable is hard-coded to look on the SD - and the uEnv.txt isn’t loaded either. I had to reset the uBoot environment and override a few definitions and commands to get a really clean EMMC-only boot with a modified (8 GB of RAM) DTB.

[philrandal]

Same NVME timeout issue here, with both Integral and Kingston devices.

There is an older thread on here with a suggested workaround. I’ve yet to test that on the current build.

NVMe I/O timeouts

I saw someone on twitter got the same problem as me about NVMe I/O timeouts. I added these params to the kernel and my problem is fixed. pcie_aspm.policy=performance pcie_aspm=off pcie_port_pm=off nvme_core.default_ps_max_latency_us=0 nvme_core.io_timeout=255 nvme_core.max_retries=10 nvme_core.shutdown_timeout=10 Please try it if you got the same problem.

[DavidPlatt]

Thanks for the pointers, Phil!

I’ve tried this full set of kernel options (both with and without my “shorten the queue timeout to 5 seconds” script). It doesn’t appear to have affected the frequency of the problem at all, on my system (Patriot NVME).

[DavidPlatt]

Additional data: I’ve used the “nvme” command line utility to check the smart-log in the Patriot. I can run my load test for an hour or so (triggering multiple timeouts), and I see:

• There’s no increase in the number of power cycles, or unsafe shutdowns reported by the device.

• The contents of the device error log doesn’t change

• The device temperature is reasonable (61C). The device reports 0 temperature warnings and 0 critical temperature events.

So, as far as I can tell, this issue doesn’t seem to result from (obvious) low-level physical problems such as power brownouts or excessive heat.