What kind of SSD can be used?

Supply is 5V (usb power monitor reads 5.001V).

When attached to VF2, it immediately becomes 12V (~11.87V).


Good to know, thanks. My USB power monitor is in a package which hasn’t left China yet, so it’s hard to get a reading on my system…

Thinking for a bit about what easytarget suggested - possibly, when Linux boots and the USB drivers start up, the board is going through a USB-client reset or enumeration process which touches the USB C port. This might cause the upstream USB host (charger or supply in this case) to reset its USB PD or QC logic, dropping back to 5 volts of output. It might take a while for the supply and the board’s CH224D (or whatever) to go back through the PD negotiation process and switch back up to 12 volts - and perhaps this doesn’t always happen properly, or at all?

Even if it does happen, the step-down to 5 volts might be occurring at just the worst possible time… when the core CPUs are running at full speed trying to bring up the kernel, and when the NVMe is going through its own link negotiation and training (which might be a high-power moment if it tries to use a high clock rate on the interface). I could easily see a momentary brown-out occurring under these circumstances… and that might account for both the NVMe failure-to-train, and the “USB overcurrent” warning (which might really mean “under-voltage detected on the downstream USB power pins”?).

It would be interesting looking at the VBus DC voltage on the board, between the USB C jack and the buck regulator, and see if it bobbles during the boot process. The schematics indicate a test point, somewhere thereabouts… I wonder if it’s actually accessible and safe to tack a test lead to…


Well, I think I just ruled out that hypothesis (or at least the simplest version of it).

I haven’t found the test point for Vbus, but I found that the incoming power is present on one pad of R9127 - the large SMD resistor closest to the USB-C jack. With my 45-watt supply connected, this pad is sitting up right around 9 volts, with a small amount of what looks like switching noise (reduced for a moment when I reset the board). (I’m not sure why this charger isn’t negotiating 12 volts - need to wait for my PD analyzer to arrive.)

I held a scope probe on this pad, with the scope set to trigger on a falling edge at 8 volts. I then ran the board through half-a-dozen reset-and-boot cycles. In several of these cycles, the NVMe was not seen, and the “USB over-current” diagnostic was printed.

The 9-volt supply voltage was rock-solid throughout. The only time the scope triggered was when I removed the probe from the pad. There was no indication that the supply was dropping DC down below 8 volts.

I then switched to my UGreen 100-watt USB PD supply, with Anker 60-watt cable, and repeated the test sequence.

Voltage at the resistor was 12 volts. I set the scope trigger to falling edge, 11 volts. After half a dozen reboot cycles, the NVMe was seen 3-4 times and absent the others (with the USB over-current condition being reported in the latter). The scope didn’t trigger until I removed the probe at the end of the test. No drop down to 5 volts, not even a significant sagging below 11.

So, my friends… whatever’s causing the NVMe detection failure, and the USB over-current condition warnings, can occur even when the incoming voltage is in the 9-12 volt range, and isn’t dropping out by even a volt. At this point I don’t see evidence of USB PD (or QC) being directly involved.

I guess that’s good news, in a sense, as it seems to remove one big variable (USB supply negotiation protocol / quirks) from the equation.


I have now watched the video several times at reduced speed (0.25). I wanted to know when exactly the drop to 5V happens. Quite directly after the message “reboot: Restarting system” and quite a long time before “U-Boot SPL …”.

I have switched both my power monitors to protocol display mode, so I know that they both always convert PD at the input to QC 3.0 at the output. @rvalles can you please also display the current protocol on your power monitor? I assume your device uses the protocol of the input for the output. With my PD power supply units without power monitor, I had no problems with the SSD.

I am now sure we both have different problems that we should not lump together. I think I read that you use different PD power supplies, which I have no problems with. My problems only occur in connection with QC 3.0 and only the successor QC 4.0 is compatible with PD (or is supposed to be compatible).

USB-C is an “egg laying wool and milk sow”, as we say in Germany, and can be hell for developers, manufacturers and consumers.
All About USB-C: Manufacturer Sins


can you please also display the current protocol on your power monitor? I assume your device uses the protocol of the input for the output. With my PD power supply units without power monitor, I had no problems with the SSD.

Unfortunately, my power meter does not provide information about the protocol used. It just monitors voltage and current passively.

The power supply I use does not claim to support anything else than USB-PD, and its spec reads 3A@5V, 2.22A@9V, 1.67A@12V.


To start we are powered from USB-C 5.0V into the NB679 buck supply. (needs 5.5V)
Looking through the powerup sequence,
everything gets turned on in sequence,
last reset goes high,
code starts running from QSPI NOR? EMMC? SSD? (switch selected)
then the USB-C negotiates 12V via JH7110 usb2 port.
Looks like an unstable power supply for turn on.
When I get home I’l put a CRO on it and see what the timing looks like.
Once powered from 12v, using the reset switch might not send USB-C back to 5V.


I took the time to track it down, TP180, it’s on the underside of the board near the eMMC connector (directly under the power converter circuitry), here is a somewhat crudely cropped/scaled/edited fragment of the bottom silkscreen:


Well, I have another data point to add.

I purchased a Patriot P300, based on the recommendation by rvalles, and installed it in place of the Mushkin I’d been using. Success!

I’ve reset-and-booted more than a dozen times, and the VisionFive 2 has recognized the Patriot P300 100% of the time. I’m still seeing the two USB over-current warnings, but the NVME hasn’t failed once. I’m using my intermediate-size (45-watt) USB C power supply… which seemed to be running in its 9-volt/3-amp configuration when I tested it last week.

So… it looks as if one of two things may be true. Either the Mushkin NVME I bought is flaky, or it’s just incompatible with the VisionFive 2 board for some reason.

I looked up the specs for the buck regulators used on the VisionFive 2. In theory, both the input-side 5-volt regulator, and the dedicated 3.3-volt regulator for the M.2 slot, are capable of delivering more than enough current to meet the needs of a standard NVMe. Maybe the Mushkin tries to draw more current at peak than the spec allows, or maybe the VisionFive board itself has some issues (too-small traces on the PCB?).

In any case, it looks as if selecting a lower-operating-power NVMe for this board may be necessary, even if it costs some performance.


Thank you for the feedback :wink:
I did the same, I needed a card for this machine and the P300 was also pretty much the cheapest card to easily get online here in the Netherlands.

Since I doubt if it is even possible to buy an NVMe with fewer than 2xPCIe lanes these days we should always get good peak speeds (cough, firmware!, cough).

But the P300 and others in it’s price range do not have the DRAM caching that higher speed drives have, which certainly helps with power draw, but makes them a bit less responsive to random reads and writes (for a given value of ‘a bit’).


I have a San Disk A400 NVMe 512 GB drive that I attached to my VF2. However the NVMe drive is not recognized. lsblk -f shows mtdblock0, mtdblook2, mmcblk1 with its partitions 1, 2, 3, and 4.
ls /dev/disk/by-path lists platform-160020000.sdio1 and its part 1,2,3 and 4. /usr/sbin/nvme list
doesn’t show the drive just a bunch of dashes. dmesg | grep -i nvme gives the following info:
nvme nvme0: pci function 0001:001:00.0
nvme 0001:01:00.0 enabling device (000 → 0002)
nvme nvme0 Device not ready aborting initialization CSTS = 0x0
nvme nvme0 Removing after failure status -19.

Hi there, StarFive has provided a compatibility list of JH7110 for each module, which includes SSD.

You can see the following site for more info:


Nice to have this list, but doesn’t help. I found a similar problem in the Pine64 forum NVME problems. the solution was to use another SPI.
I am using uboot-spi.bin.normal.out 132.2 kB March 26. dmesg | grep -i spi shows spi-nor spi0.0 gd25lq128d (16385 Kbytes) if this is helpful. I am using VF2.11.5 starfive-jh7110-VF2-SD-wayland.img

I notice you are confusing u-boot SPL (first non-rom boot loader, primary function is to set up RAM then load the next stage) with the SPI interface.

I understand the difference between spl in the boot loader and and spi interface. Howerver my 78 year old eyes and small Ubuntu fonts sometimes make it difficult to see the difference between “l” and “i”. The problem remains. I have tried various options to get my VF2 to recognize my SanDisk A400 NVMe drive without success. I have tried to follow the advice in NVME boot using VisionFive2 Software 2.11.5 but can’t get sdcard.img to recognize the NVMe drive. The drive is recognized under Ubuntu 22.40 and Windows 10 and has been formated. I may swap out the SanDisk for a Samsung MZVLW256 HDHP-000L7 drive on my ThinkPad to see if that works better.

1 Like


I was going to ask about your power supply, non USB-PD supplies are known to cause issues with some NVMe’s.

I decided to look at the power requirements in the specs, but I can’t find anything definitive for ‘SanDisk A400 NVMe’.

OTOH I think I found the real problem, none of the listings I found mention anything other than SATA interfaces for these NVMe’s… they do not say this card supports PCIe at all.

If true, then this card cannot work on the VF2 since that only supports PCIe drives. A search based on the manufacturers model number from your drive’s label should be able to confirm this for sure.

1 Like

The power supply is a Samsung Super Fast Charger that put out 5V 3A, 9V 3A, 15V 3A, 20V 2.25A. that is 45 watts should be enough for the VF 2 and NVME drive. The SanDisk A-400 SSD’s were make for Dell in both SATA and NVME interfaces. The SSD specifically says SanDisk A-400 NVMEe on the label. I have pictures of it. Also I put it my desktop in place of a Crucial NVMe 1TB drive and it was recognized as an NVMe drive with Windows 10 and Dell support files. It formatted with the linux command nvme. There are several mentions of this NVMe drive on the Dell support web site.

What is the fastest read speed anyone has managed on the VF2 with a NVMe SSD?

Going off this thread alone, the 256 GB Transcent SSD TS256GMTE110S @ 230 MB/s would seem to be about the fastest anyone has reported.

I’ve tried a 500 GB SAMSUNG 980 PRO wit my VF2 but I only average about 155 MB/s so its no good for the VF2.

Has anyone seen faster than 230 MB/s? If you’re using hdparm, just use the -t option instead of / without -T.


Please do as sugested and find the correct datasheet/specs for your specific make and model.
Then look really hard at the interfaces listed in those specs. If you do not see ‘PCIe 2.x’ listed there, it will not work.

Not sure about the fastest, but I got this on a 1Tb Kingston SNV2S1000G NVMe.

hdparm --direct -t /dev/nvme0m1
 TIMING O_DIRECT disk reads: 584MB in 3.00 seconds = 194.34 MB/sec
1 Like

Thanks @typedef . 200MB/s seems to be about the average transfer rate currently. Hopefully this will improve as VF2 support in the kernel matures, we should be getting about double that speed unless the hardware is at fault.