I could see that initramfs is not mounted while booting from SD card (error is Waiting for root device…). I tried both the methods
→ manually loading initramfs.cpio.gz
→ auto boot with startup.nsh script
initramfs is booting fine If I use the linux.iso image which downloaded from starfive-tech repo.
I checked the difference between custom linux.iso and repo image. Lib files are missing in the custom images. Is this is the real cause of this error ?
Please find below attached logs for the issue.
Those problem are probably related to this (search for “delay”): https://lore.kernel.org/lkml/be30446c-f350-471d-bfac-b4b8dc0a75a2@starfivetech.com/
(The M.2 SSD 970 EVO Plus mentioned in the OpenBSD mailing list is a 250GB/500GB/1TB or 2TB SSD with 2GB of LPDDR4 SDRAM which supports PCIe 3.0 x4 - Idle (ASPT on) 30 mW ; Active (Avg.) Read 5.5W ; Active (Avg.) Write 6.0W - so under average usage it could potentially require 11.5 watts or at 3.3 volts nearly 3.5 amps of current, I can not find any information about peak power requirements, but that could be very high indeed for a few microseconds to milliseconds)
At a guess the very large and very fast (very higher power) NVMe devices draw so much current that they are glitching the power and clocks of the VF2, and it needs an extra delay beyond what the specification suggests for them to both stabilise before the NVMe can be accessed.
I’d call it a software compatibility workaround, instead of an actual fix, because every time a NVMe device changes from idle to active there would be a small extra delay before being able to access data simply because there is not enough power available for the device to jump from idle to maximum power usage nearly instantaneously.
I’m not even sure if a hardware bodge like a high value electric capacitor (Think of it as a temporary power reservoir, that would slowly refill when idle) placed very close to the NVMe socket would fix the problem since the highend NVMe devices just require so much power.
EDIT A better option might be to update the NVME_QUIRKS with new problematic devices. And only add the longer delays for devices that actually need it. That way all the smaller lower power devices will still achieve optimal performance. But then the assumption would be that they had QUIRKS on all systems not just the VF2, which is probably an invalid assumption.
Hi I am an openkylin community developer, I am trying to make the openkylin image support edk2 UEFI boot, please do you know how to modify the VF2 release image to make it boot with edk2 UEFI, and then repackage as an image
