I’ve tried a couple, with no difference. Currently I’m using supply capable of delivering 45 watts (if up at 20 volts). My USB-C power monitor says it’s delivering 9 volts to the VisionFive 2 (it’ll provide 3 amps at that voltage).
I also tried a high-end USB PD supply rated at 100 watts. No better results.
Before I bought this Patriot M.2, I tried a Mushkin as these seemed to have a good overall reputation. The Mushkin wouldn’t enumerate more than half the time, no matter what power supply I used.
I do suspect that this board design has M.2-slot power regulation problems. The schematics and design suggest that it should work - there’s a dedicated step-down regulator for the slot, powered pretty directly from the USB C jack. Possibly the PC-board traces simply aren’t heavy enough to deliver the proper amount of current to the slot, when a high-performance NVME card tries to draw a big power-on surge? It sounds as if other folks have had the same sorts of issues I ran into, and that switching to a high-power PD supply isn’t necessarily a reliable fix for everybody.
If these I/O timeouts were being caused by power brownouts, I’d sorta expect to see the NVME device reporting something relevant in its error log - extra power-off/power-on cycles, or unsafe shutdowns, or etc. - and I’m not seeing that.
I loaded the 202306 image to a Samsung NVME using belena etcher on an external USB-NVME adapter, it didn’t work then MZS pointed to the latest latest SPL+U-Boot (u-boot-spl.bin.normal.out) and U-Boot+OpenSPI (visionfive2_fw_payload.img). I installed them using flashCP. Now I have no issues. I boot from the NVME I have never seen the timeout you refer to. It just works. It is not the best performance for an NVME, on a Gen2 PCIe with 2 lanes it should be much faster than 250MB/s but it is what it is, 1TB of relatively fast storage for development purposes.
after updating uboot and spi and putting the image on my nvme ssd it started immediately on the first try. so thanks Michael for the work done since the last release.
I must say that the GUI is not usable due to the slowness, even to change the background image I get the warnings that the window is not responding and after several times that I click on wait then I display the window correctly.
too bad, the XFCE release was much more responsive.
I prefer XFCE as well, but then again I will have always chosen speed over fancy eye candy.
My most loved DM (Desktop Manager) of all time was OLVWM (OPEN LOOK Virtual Window Manager) where I could have 5x5 (or more) full desktop windows on a machine and swap between any two desktops full of applications with at most only eight key presses in less than half a second.
Well, I wasn’t impressed with the performance of watching a simple video with VLC, so I rather wait for the next image.
glxinfo -B shows me Device: softpipe, so we still don’t have full hardware acceleration.
The GPU should be able to decode VP9, once we have a proper driver. Not sure if Chromium will work with that. Otherwise we might have to wait for Firefox with V4L2 M2M support.
I know I’m a bit pedantic here, but the GPU is not used for Video Decoding, but what is used is a video decoder.
It just happen that in the PC world, often GPU also have video encoder/decoder embedded in them, but in the embedded world they are more often different and unrelated blocks.
The main issue isn’t even accelerated video codecs, but the fact that we don’t have accelerated OpenGL or Vulkan. It’s disappointing that Imagination won’t properly support their GPU.
The main issue with accelerated video is that its not possible to build the wave511/vdec kernel module under Debian yet. As pointed out already, even when we can build and install wave511 this won’t improve playback under browsers unless you use a plugin to use ffmpeg for video playback instead of using the browsers native video playback code. It will also very likely mean full video screen playback only for hw accelerated decoding, I expect.