I had triple luck: 1. a case bought last August came with a replacement screw, 2. I found the screw and 3. the screw fitted.
But I wonder if it is good to put the weight of the following cooler on this small screw. 
2 Likes
NVME Kingston 128GB, M.2 2280
om8pdp3128b-ab1
#lspci
0001:01:00.0 Non-Volatile memory controller: Kingston Technology Company, Inc. OM3PDP3 NVMe SSD (rev 01)
The SSD has never run so hot as it does on the VisionFive2.
The 7110 is also running hot.
Is the AXP15060 setup correctly ?
Could StarFive have an active heatsink option when a board is purchased ?
The mounting holes aren’t a standard footprint.
Can you make explicit, what you mean with “hot”? The worst i had was a 54°C nvme while passively cooling the cpu. My impression was, that the nvme follows the temperature of the cpu by an offset of -10°C in my setting.
2 Likes
53.8C with X disabled
62.0C with X running apt install, + thunar
big heatsink on cpu, down to 45.7C
heatsink off straight back to 60.4C
38.8C X disabled, heatsink, thermal paste
Since the heat sink on your cpu plays a role, too, i see my suspicion confirmed, that the SSD’s temperature is mainly driven by the closely mounted CPU. Unfortunately, a heat sink or fan is obligatory to actually run the device even under small loads as yours. I’m using a 4x4x2cm heat sink with a termal pad and have an idle base line (no X) of CPU: 45.8°C, SSD: 42°C.
Hmm, i wouldn’t call this “hot”. By the rule of the thumb, when it hurts, touching it, its hot. Mine still feels only warm. I doubt, that the device is aging much faster at this temperature, so cooling down to 40°C or below is not really necessary, imo. But i might be wrong about that.
I remember times, where Intel cpus dissipated more heat per square size than a cooking plate without delivering the speed that we get with this device now. If i read the findings in VisionFive 2 performance and power consumption benchmarks right, the device has a comparatively good energy efficient, but i’m not an expert in this.
My passive heatsink is a piece of Al bar 50x50x20mm and thermal compound.
Have ordered a raspberry pi stick-on heatsink w 5v fan and passive SSD 2280 heatsink.
If all else fails I have a giant Zalman Cube.
I worked with early 1802 cmos processors which were cold compared to nmos and ttl devices.
All I’ve read riscv comes out better than other processors,
but it depends how many subsystems are active and sucking juice simultaneously.
I’m with you in your disappointment that cooling seems to be mandatory with this chip, although my grievance is mainly aesthetic. That beautiful little chip is literally buried under a heat sink. But the fact, that the system can still be passively cooled is practically enough for me.
Now I have an aversion to fans specifically and prefer a passive heat sink even for my workstation. Comparing the size of the heat sinks and the performance of both systems gives a satisfactory overall result for me. Clearly, certain applications, like using the device in a smartphone, are excluded by the current cooling requirements.
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?
1 Like
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.
1 Like
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
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.
2 Likes
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.
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.
1 Like
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
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.
that sounds good,
so the firmware is doing the right thing
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.
2 Likes
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.)
2 Likes
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…
3 Likes