What kind of SSD can be used?

[DavidPlatt]

I’m having difficulty with my VisionFive 2 and a Mushkin Tempest 256-gig M.2 SSD (MKNSSDTS256GB-D8) I purchased for the project.

The SSD is only recognized by the Linux kernel about half the time, when I boot (the boot image comes from the TF card, of course). When it works, it works very well indeed - good speed, fully reliable. I was able to transfer the current Debian image over from the TF card and run with the appropriate NVMe partition as the root filesystem. When it doesn’t work, the boot hangs at the “waiting for root filesystem” stage, and eventually times out.

I though that the problem might be one of intermittent contacts between the SSD and the M.2 socket. I’ve re-seated the module repeatedly, played around with its exact angle, position of the hold-down screw, and so forth, and this hasn’t helped.

In my latest experiment I left the board and module in exactly the same positions, rebooted repeatedly using the board’s RESET button, and making no other changes between trials. The success rate was approximately 50% - on half of the boot attempts the system came up fine, and on the others the console log didn’t show the PCIe interface coming up and the NVMe wasn’t seen.

I’ve tried a couple of different USB power supplies, including a 4-amp 5-volt supply, and a PD-capable charger. The results are the same for both.

At this point it’s feeling like some sort of PCIe link-training problem between the board and the module when Linux tries to bring up PCIe.

Since the current boot code doesn’t have NVME support compiled in, I can’t tell whether the problem is specific to the Linux kernel, or whether it’s a hardware incompatibility, or whether I have broken hardware.

Any hints for further debugging?

[tommythorn]

All I’ve read riscv comes out better than other processors,

There’s nothing about the RISC-V ISA that inherently makes chips any colder or hotter than an equivalent Arm64 chip - the difference is much too trivial. It’s all a function of the architecture, implementation, voltage, and frequency, process, etc. However, power is proportional to c × V² × f (capacitance (c) is a function of the number of transistors/area), and frequency (f) goes up with V as well so you get diminishing performance benefit from more power. According to older StarFive documents, the JH7110 is designed for 1.8 GHz. I assume they are using 1.5 GHz to get better yield = lower cost.

[coltree]

Looks like it’s set for on-demand clock, but basically idle running graphic desktop - 1500000 full speed, 45degC
change to multiuser still on-demand, 1500000, temperature quickly drops ~ 3degC.
haven’t checked which peripherals are active, clocked and drawing power,
but not using graphics saves some power.
It is currently setup to run whatever is thrown at it, but I’m only using 1 serial port & 1 ethernet

[coltree]

When I ran my board from an under power USB charger it wouldn’t recognise the SSD. Changed to a 45W USB-C supply sorted out all my problems. The USB-C ups the voltage for higher power draw, the input switch mode supply (NB679) supports 5->24V input, more than just a 5v 4amp supply (15W). The usb cable is also critical.

USB hardware | USB Power Delivery

[rvalles]

As an update, the M2 6mm screws arrived, and the Patriot P300 is now secured in place by one of these.

So far, no issues with the SSD. It was fine hanging from the slot for weeks, too.

[DavidPlatt]

Hmmm. The problem may very well be power-related, but I don’t think it’s as simple as one might hope.

I’ve tried two additional USB-PD supplies/cables. The first is a 45-watt supply with an integral cable (I believe it was originally for a Chromebook). The second is a 100-watt UGreen supply, with a new Anker USB cable spec’ed for 60 watts of power delivery.

The results with these supplies is the same as before: the system will recognize the NVMe about one time in three. Whether I soft-reboot, button-reboot, or power-cycle the board between attempts doesn’t appear to matter.

Now, the interesting thing I’ve noticed is this. On the successful attempt, both PCIe bridges come up (the USB subsystem is behind the first, and the NVMe is behind the second), and there are no complaints in the dmesg log.

On the unsuccessful attempts, only the first PCIe bridge comes up. The second reports “link down”, and neither the bridge nor the NVMe behind it is enumerated. AND (this is the interesting part) the boot log shows “USB overcurrent condition” at right about the same time… and there’s nothing at all connected to any of the USB interfaces!

So, something seems to be going wonky with power… but it beats me what it is. It could be a bad board, or a bad NVMe that’s somehow dragging down power across the board (but with a 60-watt cable/supply combination that seems odd) or something else amiss.

I’d gladly upload the logs and lspci, but the forum won’t let me (yet) as I’m still a new user.

[coltree]

The VN679 is specified for 5.5V → 24V input and 5V 8A continuous output.
It is a buck regulator and doesn’t claim compliance with USB power delivery.
I have noticed requirement for a 30W supply for the VisionFive2 board, but does that include peripherals ?
I wouldn’t use an extended (>3Amp) supply (>60W) which can take you to the absolute maximum rating 28V input of the VN679.
I try to avoid absolute maximum ratings !!!
I don’t know how the 5.5V input relates to the USB 5V output ???
I have a USB-C 45W supply which seems to be running perfectly.
USB overcurrent sounds like the supply isn’t switching up voltage to keep the current <3Amp.
I would prefer a 2.1mm DC plug for power supply as found on numerous SBCs which would support 12-24VDC @ 2-3Amp. The usb-c is ???
OR use a USB specified input regulator

[rvalles]

The usb-c is ???

I own a usb power monitor. According to its display, my VF2 board seems to negotiate and run off 12v from my usb-pd power supply.

[coltree]

that sounds good,
so the firmware is doing the right thing

[SunWukong]

@DavidPlatt

Whether I soft-reboot, button-reboot, or power-cycle the board between attempts doesn’t appear to matter.

I have had the same experience with 3 different Quick Charge 3.0 power supplies and also with two different USB power monitors, both of which, even when connected to different PD power supplies, only output Quick Charge 3.0. If I connect the VF2 v1.2a directly to a PD power supply without a power monitor, this behaviour does not occur.

Quick Charge 3.0 power supplies first start at 5V, switch to 12V quite quickly, switch back down to 5V when restarted and do not switch back up to 12V afterwards.

Here is a short video that hopefully makes this behaviour clearer: Quick Charge 3.0 power supplies at VF2 SBC v1.2A

I now have a little more time and want to do a cross-check with my VF2 v1.3b and will then report back.

[DavidPlatt]

Very interesting - thank you! It’s more than slightly reassuring to know that I’m not the only person seeing this sort of issue.

It’s feeling to me at this point as if the PD power-negotiation process may very well be involved here. Perhaps the board and the supply are negotiating a switch to a different voltage level, in a way (or at a time) which causes a brief brown-out during the switchover, at a time when the NVMe is drawing more current or is more vulnerable to voltage fluctuations (e.g. during PCIe link training)?

I’m not too concerned about a high-power adapter causing an over-voltage condition… assuming that the adapter and the VisionFive are competently designed, the VisionFive’s PD chip should never request a power-profile voltage higher than the board can handle, and the supply should never send a voltage higher than is in the requested profile. (Of course, I may be assuming more than I should )

The board design documentation says that one option for powering it, is to apply a fixed voltage (between 5 and 20 VDC) on the USB C power pins. The schematic agrees, as the USB C VBUS pins are routed fairly directly (through a fusible resistor and some bypass caps) to the input of U26, the buck regulator which outputs the VCC5.0 supply.

The regulator doesn’t seem to have any control connections at all to U27, the USB C power management chip. It simply bucks down whatever incoming voltage is presented to it, to create a should-be-stable 5-volt supply.

So, completely avoiding the whole USB C PD / QC concern might make for more reliable operation. No negotiation, no supply-voltage changes, no chance for glitches during voltage changes. Wire up all four USB C bus-power contacts in parallel (ditto for the grounds) to minimize voltage drop. Might beworth sacrificing a USB-A-to-C cable to make up a supply like this.

Of course, one would have to be VERY careful in making up a supply like this for this board. You’d want to hang a big red warning sticker on the end of its dedicated cable… “VISIONFIVE 2 ONLY, WILL DESTROY OTHER DEVICES VIA OVERVOLTAGE!!”

Another possibility is that the board itself isn’t capable of delivering enough power to the M.2 slot under all conditions - i.e. it doesn’t comply with the PCIe M.2 specs. Or, perhaps, some NVMe SSDs try to pull more current than the M.2 spec allows. Compatibility is a tough issue, and sometimes when two devices each try to push right up to the spec limits, things go sour and behavior becomes intermittent.

(I ran into a problem like this latter in a previous job. A SOC processor which pushed memory-bus transaction speeds up to the limit from one side, and some DRAM chips which could just barely make the spec in the other direction, would sometimes occasionally fail to meet in the middle… causing the “atomic” read-and-exchange memory access to fail… causing the operating-system mutex() operation to allow two threads to grab the same mutex at a time. You can imaging the havoc which resulted.)

[easytarget]

@DavidPlatt

It’s feeling to me at this point as if the PD power-negotiation process may very well be involved here. Perhaps the board and the supply are negotiating a switch to a different voltage level, in a way (or at a time) which causes a brief brown-out during the switchover, at a time when the NVMe is drawing more current or is more vulnerable to voltage fluctuations (e.g. during PCIe link training)?

I’m inclined to agree.

I think it is worth putting this here: The USB-PD circuitry from the 1.3b schematic:

U27 is a 12V usb-pd charge controller, U29 is a usb-pd charge controller set to 12v by R91291. Both are connected to the USB-C data and cs lines. Neither is connected any further, they do not ‘charge’ anything, they exist only to do the USB-PD negotiation.

One or the other will be fitted depending on suppliers and availability, not both. This allows StarFive to work around supply-chain issues.

I’m wondering which one you have?

Edit: Also, since this process is not controlled by the firmware, I wonder if a delay to allow the voltage to switch before querying the NVMe might work around this.
Edit2: Since the USB-C data lines are connected the the JH7110 USB2.0 lines, albeit decoupled by some resistors, is it possible that the JH7110 is trying to find a USB2.0 hub or whatever and preventing the PD negotiation…

[SunWukong]

@easytarget

U28 is a usb-pd charge controller set to 12v by R91291

I have also just found that out. I found the following information on U29 CH224 (U28 is certainly a typeo of yours), which confirms what you described, i.e. permanently 12V. But this contradicts the behaviour I observed. Unfortunately, I did not save the design schematics of version 1.2a locally in time.

I have not found a working source for the CH224D (error 404), only for the CH224K.
CH224K Low-cost USB-PD Sink Controller

[easytarget]

@SunWukong I have the 1.2 schematics, I just did a quick compare and this part of the design is unchanged between 1.2 and 1.3.

I don’t think board revision should affect this (unless there are layout changes between the two that somehow matter).

I’m more interested in which PD chip is fitted and if that is a factor. Once home I’ll check my board.

[DavidPlatt]

@easytarget

I’m wondering which one you have?

On my board, there’s an unlabeled 20-pin IC located between the USB-C jack and the CSI - I’m guessing that this is U28. There’s an un-stuffed 32-pad layout nearby, and I’m guessing this is for U27. So, I believe I have the CH224.

@easytarget

Edit2: Since the USB-C data lines are now connected the the JH7110 in Rev1.3b boards, albeit decoupled by some resistors, is it possible that the JH7110 is trying to find a USB2.0 hub or whatever and preventing the PD negotiation…

Hmmm. I thought that the PD negotiation was done entirely over the USB-C CC lines, and didn’t utilize DATA. I could be wrong, though (happens often enough )

[easytarget]

I’m out and about right now, but iirc one is on the top of the board, and the other underneath…
The top and bottom silkscreens are published along with schematic. They are super useful to identify component locations.

[SunWukong]

@easytarget

the design is unchanged between 1.2 and 1.3

I have just tested it with my VF2 v1.3 (Debian Image 202302) and unfortunately I did not notice any difference. With QC 3.0, a reboot causes a switch to 5V and my (Transcend TS512GMTE220S 512GB M.2) SSD is then also no longer recognised. On a PD power supply, the SSD is also recognised after a reboot.

[DavidPlatt]

Hmmm. The EMMC socket is on the bottom, but I don’t see any other padprints down there which look suitable for either of those parts.

The silkscreen PDFs don’t render clearly enough for me to be sure about the part identifiers, alas. If I zoom them up enough to see the markings in the center of the footprints, the text is blurred to the point of being unreadable.

[coltree]

An afterthought -
at power-up what was the initial voltage coming out of your supply ? 5V, 5.5V or 6.0V ?
and how long before negotiating the switch to 12V ?

[easytarget]

My bad, they are both on the top. My pdf viewer won’t zoom in far enough either, at least in chrome. But these are vector diagrams in the PDF and I was able to extract them with inkscape+poppler.

Here is the relevant bit; cut, pasted, scaled and edited in inkscape.

…and an okay-ish picture of my board…

So I have a CH224D too, I suspect everybody is getting he same at the moment unless these parts are really low on supply…