Sorry for the late reply. I didn’t find the time to implement everything into our image OOTB, but the needed changes to the bootloader environment have been done since StarFive’s U-Boot/software v3.x.x release already. Here is how to enable 8 GiB support: RISC-V and VisionFive 2 testing · Issue #6212 · MichaIng/DietPi · GitHub
Similarly Ethernet for the 1.2A revision can be enabled/fixed: RISC-V and VisionFive 2 testing · Issue #6212 · MichaIng/DietPi · GitHub
Hi, is there a guide on installing the GPU drivers?
Not really. Here is the last research I made in this regards: RISC-V and VisionFive 2 testing · Issue #6212 · MichaIng/DietPi · GitHub
However, we aim to migrate to mainline Linux, after which, maybe plain Mesa supports the GPU. I hope to finish this until DietPi v9.11 release.
UEFI BOOT DietPi 10.5.2(USB)
Thanks, any chance you can provide the log lines above the kernel panic? Was this when the init system was loaded already?
Our Trixie and Forky images both ship with identical kernel and setup, only the Debian repo, hence e.g. systemd version, is different.
QSPI → NVME(grub) → USB(Ubuntu240404)
Does this apply to all your tests? The GRUB EFI bootloader in the SPI flash, GRUB configs with boot menu on the NVMe? Was this installed via grub-efi-riscv64 from a Debian system on the NVMe? DietPi Trixie and Forky tested with the same USB stick? And how did you generate the boot menu entries? I wonder e.g. how it knows e.g. the device tree to load, and the cmdline, whether GRUB detects and parses /boot/extlinux/extlinux.conf automatically or so.
I am an end user in China. I am not familiar with development and I don’t English, so I will try to keep my answers brief.
This is the boot error message after selecting the grub menu. I don’t know how to find the log records.
yes.The system with “uefi boot XXX” is always like this.
The grub configuration file is automatically generated by update-grub.
YES, The official version of debian13 is installed on /dev/nvme0n1p8. /dev/nvme0n1p1 is /boot/efi.
I’m not sure if it’s the same USB stick. I used two for testing. I will use the same USB stick to retest the two DietPIs in a few days and then inform you of the results.
grub will not modify /boot/extlinux/extlinux.conf。
After constructing the menu in grub, I corrupted extlinux.conf, resulting in a failed boot process.
I guess, QSPI → efi → grub → uboot, so most systems that were originally booted by uboot, can now be booted by grub.
I have modified /boot/extlinux/extlinux.conf and /etc/fstab on nvme.
So, if my nvme capacity is large enough, I can install various system images that were originally booted on uboot onto nvme and boot them through grub.
The menu of Grub not be displayed on the monitor, but I can modify the default startup value of Grub to boot the required OS.
Great, thanks for the info. As far as I understand, GRUB EFI is a secondary bootloader in this case:
QSPI (U-Boot) => EFI (GRUB primary) => /dev/nvme0n1p8 (GRUB boot menu) => selected distro
And update-grub most likely invokes os-prober to check for available distros on all drives and partitions.
I do not have a VisionFive 2 here, but a Star64, which has the same SoC, shares the same kernel (with some added onboard WiFi driver), and boots with the same StarFive U-Boot. It does not have an M.2 NVMe slot, but I try to replicate the setup as close as possible with an SD card and USB stick, when I find time.
YES. 
Use SD card and USB stick good. There seems to be an issue with debian’s uboot. The grub startup sequence on nvme should take priority over TF and USB stick; TF and USB stick can only boot when there is no grub on nvme.
The boot priority is usually set via boot_targets variable. You could check in DietPi via fw_printenv command whether there is a persistent environment stored on the QSPI, or whether it just prints our defaults from /etc/u-boot-initial-env. In that case, U-Boot takes its internal/embedded defaults.
We do set boot_targets=mmc1 usb0 nvme0 mmc0 dhcp in our environment, hence SD card > USB > NVMe > eMMC > DHCP. If there is an environment present on the QSPI device (exposed as /dev/mtd1 on DietPi), then you can you can just edit it from DietPi with this command:
fw_setenv boot_targets 'mmc1 usb0 nvme0 mmc0 dhcp'
If there is no persistent environment stored, you can view, change, and store it from the U-Boot console:
env print boot_targets
setenv boot_targets "mmc1 usb0 nvme0 mmc0 dhcp"
env save
Great, so something is wrong with the other USB stick, or the board/bootloader/kernel is a bit picky/prone regarding USB slot connectivity/power or something.
Awesome to see the new DietPi OS detection as ASCII logo from fastfetch 
: fastfetch/src/logo/ascii/d/dietpi.txt at dev · fastfetch-cli/fastfetch · GitHub
The first option in the grub menu must be a kernel created by r0b0, otherwise other operating systems will not start properly.
The kernel won’t be relevant, but the EFI/GRUB on the first bootable partition detected by the QSPI.
Reminds me to rebase our JH7110 kernel builds to latest 6.12.y as well.
7.0-7.1
powerVR
Great to see some upstreaming work for the GPU driver. This, along with general HDMI/DRM/KMS support is the missing piece which prevents us from switching to mainline Linux. But according to Debian, it is still too slow to be practically usable.
There is an issue about this on the VF2 GitHub repo as well: JH7110 IMG BXE-4-32 GPU: bare-metal measurements and upstream enablement questions · Issue #119 · starfive-tech/VisionFive2 · GitHub
