Results from 25+ microSD Benchmarks on the VisionFive 2


I recently tested 25+ microSD cards in the VisionFive 2 to see how the performance fared and which were the best options. Sadly there was no out-and-out winner, but I thought it may still be useful to some of you. Let me know if you have any questions!



I haven’t started it yet, but I now know what to buy.
Thank you, Bret.

I disagree!
Your NVMe was the clear winner :stuck_out_tongue:

I guess the very similar results from all the fast cards indicates that the bottleneck is the VF2 card slot, not the cards themselves.

I’m seriously wondering what would happen if someone were to cut the SD slot 3.3v line and hack in a 1.8v converter for it. Being unemployed and with only one VF2 board, I’m not going to risk it…


Hah, well if you look at it that way…

Yup, definitely the board/slot/configuration in this case as the same cards push 90MB/s in other boards. As I mention in the piece, the closest comparison is the Raspberry Pi 3 in this case. Not great, though given it has eMMC connectors and an M.2 slot there, I don’t think it’s the end of the world. It’s still a solid option for quick and easy storage expansion that can be useful in certain cases!

1 Like

From what I understand, the SD controller should be capable of higher speeds. It’s currently configured for high speed mode as the highest supported speed, limiting peak speed to ~25MB/s (slightly less in practice). I’ve tried exposing higher speed modes in the device tree but it just results in an unusable device. Haven’t debugged further, but likely need to configure the peripheral controller appropriately before doing this. The datasheets available are lacking so I don’t know where to look to try enabling this.

And re: NVMe, I was initially planning to use this device with NVMe storage but I may instead try external GPU as built in GPU is in terrible shape. If microSD wasn’t as slow as it currently is, I could probably accept it and use it. As it stands now, I’ll likely need to use eMMC or USB root. For some workloads, having faster microSD would be easiest and possibly cheapest.

For SD, higher speed cannot be reached since necessary 1.8V input isn’t possible due to PMIC lacks enough power rails for a dedicated source for SD. Emmc speed problem is more weird and is being digged by official.

1 Like

I don’t know, but the availability and price on the market, of the different multi-channel PMIC, may possibly have led to the use of this model and perhaps represents a compromise.

Sorry, you are right: I thought lower speed UHS-I worked at 3v3, but looking around (not reading the spec, not sure if it’s available freely, perhaps it is?) I guess lower speed is not. I wouldn’t expect SDR104 to work at 3v3 anyway.

I wonder if this will be an issue too on the Star64.

Since both boards use the same PMIC (AXP15060), I wouldn’t be surprised.

page 21

page 19

1 Like

The choice of pmic isn’t the issue, it’s the circuitry. Is a switchable 3.3 → 1.8 supply provided to the slot?

However, this is not an issue. This is not a PI, and is not really intended to be run from the SD card when used as a SBC.

These boards have NVMe, eMMC and USB3 ports. Once the firmware/uboot/SBI work matures it will be possible to boot directly via flash into them. No SD card will be needed, except as a recovery option. And also as an option for embedded systems where performance isn’t an issue.


No, this isn’t a Pi… but it’s a fairly slow yet still fastest currently available RV SBC on the market. It’s primarily an early adopter / initial development machine, where faster storage would come in handy. m.2 makes sense in this platform.

But not everyone uses the computer in the same way. For me, even with this development and testing mindset, slow microSD is an issue.

Re: Star64, keep in mind the schematics posted are over 8 months old. Things may have changed. We’ll know soon.


It should be much faster than a RPi at 1080p @ 30 fps H.265 encoding (hardware acceleration, but the RPi does not) and much slower than the RPi at 1080p @ ~53-60 fps H.264 encoding (no hardware acceleration, but the RPi does).

It should be faster than a RPi at AES (encryption and decryption) with a key length of 64/128/192/256 bits (hardware acceleration, but the RPi does not). And slower at AES with a key length higher than 256 bits than the RPi (if only CPU’s are used, but in theory some of that could be offloaded to OpenCL and then it may be much faster!).

It should run circles around the RPi in terms of GPU performance.

And it has OpenCL so it’s GPU OpenCL should easily beat the CPU only OpenCL performance of the RPI4B.

People keep on saying that the VF2 is worse, but it wins in a lot of areas (provided you only pick the areas where it will do better).

And there are two basically unused CPU’s in the VF2, which could boost performance by offloading some tasks in the future.