VisionFive 2 Debian Image 202306 Released

Thanks, installed and function…

@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


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.

1 Like

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
  1. Execute the following command to check:
modetest -M starfive -c

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

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.


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.

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).

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.


What kind of power supply do you use? I found that after switched to USB Type C PD, the problems are solved mostly if not all.


I’ve tried a couple, with no difference. Currently I’m using supply capable of delivering 45 watts (if up at 20 volts). My USB-C power monitor says it’s delivering 9 volts to the VisionFive 2 (it’ll provide 3 amps at that voltage).

I also tried a high-end USB PD supply rated at 100 watts. No better results.

Before I bought this Patriot M.2, I tried a Mushkin as these seemed to have a good overall reputation. The Mushkin wouldn’t enumerate more than half the time, no matter what power supply I used.

I do suspect that this board design has M.2-slot power regulation problems. The schematics and design suggest that it should work - there’s a dedicated step-down regulator for the slot, powered pretty directly from the USB C jack. Possibly the PC-board traces simply aren’t heavy enough to deliver the proper amount of current to the slot, when a high-performance NVME card tries to draw a big power-on surge? It sounds as if other folks have had the same sorts of issues I ran into, and that switching to a high-power PD supply isn’t necessarily a reliable fix for everybody.

If these I/O timeouts were being caused by power brownouts, I’d sorta expect to see the NVME device reporting something relevant in its error log - extra power-off/power-on cycles, or unsafe shutdowns, or etc. - and I’m not seeing that.


SD card works great, but nvme complains with “Main section boot fail, use backup section”. Could this be a power issue?

I loaded the 202306 image to a Samsung NVME using belena etcher on an external USB-NVME adapter, it didn’t work then MZS pointed to the latest latest SPL+U-Boot (u-boot-spl.bin.normal.out) and U-Boot+OpenSPI (visionfive2_fw_payload.img). I installed them using flashCP. Now I have no issues. I boot from the NVME I have never seen the timeout you refer to. It just works. It is not the best performance for an NVME, on a Gen2 PCIe with 2 lanes it should be much faster than 250MB/s but it is what it is, 1TB of relatively fast storage for development purposes.

1 Like

Only 1 lane is available to the M.2 socket on the vf2, so halve your expectations…

did you change the boot mode back to QSPI flash? as the JH7110(bootrom code) does not support to boot from PCIe directly


Did you update the onboard QSPI NOR FLASH to the latest firmwares ?


after updating uboot and spi and putting the image on my nvme ssd it started immediately on the first try. so thanks Michael for the work done since the last release.

I must say that the GUI is not usable due to the slowness, even to change the background image I get the warnings that the window is not responding and after several times that I click on wait then I display the window correctly.

too bad, the XFCE release was much more responsive.

I await further updates


I prefer XFCE as well, but then again I will have always chosen speed over fancy eye candy.

My most loved DM (Desktop Manager) of all time was OLVWM (OPEN LOOK Virtual Window Manager) where I could have 5x5 (or more) full desktop windows on a machine and swap between any two desktops full of applications with at most only eight key presses in less than half a second.

I thought I had but went ahead and flashed them again, toggled boot back to qspi and all worked! Thanks for the advice.


Yep, reflashed and toggled back to QSPI and all works now. Thanks!


yup, new tag/release was released. Release VisionFive2 Software v3.1.5 · starfive-tech/VisionFive2 · GitHub

There are no other big update points other than the ddk version of the GPU(1.17 -->1.19), just sync with Debian 202306 image’s kernel.

1 Like