To compare to the above result, you should probably use the same command that they used:
dd if=/dev/zero of=~/test bs=8k count=50k conv=fsync
But even then two different filesystem parameters could have been tuned for better (or worse) write performance. CPU load can also effect results, as can RAM speed and kernel parameters when writing to a filesystem instead of the underlying raw device. And the age of the card, the more a card is written to the slower they become, the advertised/marketing numbers are always for a new device that has never been written to, not even once. Oh and different filesystems, with default parameters, pretty much all have different read and write performance!
Your result is no where near the Western Digital claimed marketing numbers, but since the JH7110 can at most support UHSI_SDR104 (104MB/sec) I would never expect that (Western Digital may be implying that the very best you could hope for would be 39MB/sec write without their proprietary technology, but it is not clearly stated):
I’m wondering how fair, or representative, a test that is, the first test mentioned wrote 4GB continuously which you’re pretty unlikely to do under Linux on a SBC device. If you’re going to use this somewhat artificial test you need to get video speed class SD cards which are designed to take this, but even then they’re designed for a certain grade of video, e.g. your V30, which is at the lower end of the scale of video grades, is for standard HD video.
So you can get bigger numbers by using a V60 or V90 SD card, but does that really mean anything when used with a VF2?
I do not see anything wrong with it, all testing is artificial and not fair. But it does help with performance tuning. Ideally you want to fully isolate the hardware under test from everything that could possibly reduce performance (no filesystem, no multitasking, no dynamic CPU frequency throttling/underclocking, no powersaving, no …), and get a number that represents the very maximum that the hardware could achieve. Then incrementally bring back in reality, seeing where all the bottlenecks are and how much performance is lost in each. And once identified and measured, checking to see if there are any parameters that can be tuned to reduce losses in performance. But it is nearly always a balancing act, like squeezing a balloon, if it gets smaller in one place it is getting bigger somewhere else. With synthetic benchmarks you are basically attempting to find the upper limit, the maximum that could be possible, but which would never be achieved under typical real world conditions.
My bandwidth test result, using 256GB Samsung Evo Select U3 A2 V30:
# hdparm --direct -t /dev/mmcblk1
Timing O_DIRECT disk reads: 64 MB in 3.02 seconds = 21.20 MB/sec
With an external reader, I get ~75MB/s read and ~60MB/s write.
I haven’t tested latency or random access yet.
Poor result, but similar to what others are getting. Hopefully this can be fixed.
edit: The likely reason for the slower speed is that capabilities for higher speeds on sdio1 are not in the device tree. The fastest capability exposed is cap-sd-highspeed, which is limited to 50MHz. 50MHz x 4pins = ~25Mbyte/s peak theoretical. So it makes sense why we are seeing only ~19-22Mbyte/s on microSD. I’m working on this now.
If you are referring to my test, the system is console mode and is otherwise an idle Gentoo install. Also, others are reporting the same results. System use of the SD card is not impacting these results, as there is either minimal or no system use during the test.
It is the same controller IP and driver, but still two separate peripherals and each has different and unique configuration in the device tree. Also, eMMC attributes are not always the same as SD attributes.
I’ve tried setting the UHS flags for sdio1, but it doesn’t appear to be as simple as that. Setting any of them causes the microSD to fail to boot. dtb I generate without the flags boot fine. Don’t have uboot console on the serial port for some reason, so have not looked further. Without a TRM, it’s waiting on the vendor to support higher speeds on the SD interfaces.
For sdcard, on this board it doesn’t support 1.8v io mode for hs200/400 speed mode…
For emmc, some software work need to be done to enable 1.8v supply for it.
(Thanks to neggles from Pine64 community to find out this)
Edit: current discovery is based on v1.2A board schematic, since there are some big changes on v1.3B pcb, we might need to check that version of schematic to confirm if this design problem still exists.
I have Samsung Pro Plus 128gb microsd card (Model MB-MD128KA/KR).
On the x86_64 computer I can get stable speeds about 80-90 Mb/s using Kingston MobileLite G4 (FCR-MLG4) card reader.
But on VF2 the card is detected as SDR50 with 50MHz clock and runs at only ~20 Mb/s (hdparm -t /dev/mmcblk1) - see below:
# dmesg | grep -i mmc
[ 0.000000] Kernel command line: root=/dev/mmcblk1p4 rw console=tty0 console=ttyS0,115200 earlycon rootwait stmmaceth=chain_mode:1 selinux=0
[ 4.294062] dwmmc_starfive 16010000.sdio0: IDMAC supports 32-bit address mode.
[ 4.301403] dwmmc_starfive 16010000.sdio0: Using internal DMA controller.
[ 4.309897] dwmmc_starfive 16020000.sdio1: IDMAC supports 32-bit address mode.
[ 4.316055] dwmmc_starfive 16010000.sdio0: Version ID is 290a
[ 4.316101] dwmmc_starfive 16010000.sdio0: DW MMC controller at irq 29,32 bit host data width,32 deep fifo
[ 4.323337] dwmmc_starfive 16020000.sdio1: Using internal DMA controller.
[ 4.329187] mmc_host mmc0: card is non-removable.
[ 4.338797] dwmmc_starfive 16020000.sdio1: Version ID is 290a
[ 4.338847] dwmmc_starfive 16020000.sdio1: DW MMC controller at irq 30,32 bit host data width,32 deep fifo
[ 4.350473] mmc_host mmc1: card is polling.
[ 4.565739] mmc_host mmc0: Bus speed (slot 0) = 198000000Hz (slot req 400000Hz, actual 399193HZ div = 248)
[ 4.575737] mmc_host mmc1: Bus speed (slot 0) = 198000000Hz (slot req 400000Hz, actual 399193HZ div = 248)
[ 4.827956] mmc_host mmc1: Bus speed (slot 0) = 198000000Hz (slot req 50000000Hz, actual 49500000HZ div = 2)
[ 4.838835] mmc1: new high speed SDXC card at address 59b4
[ 4.846238] mmcblk1: mmc1:59b4 FD4Q5 119 GiB
[ 4.861335] mmcblk1: p1 p2 p3 p4
[ 5.015819] mmc_host mmc0: Bus speed (slot 0) = 198000000Hz (slot req 300000Hz, actual 300000HZ div = 330)
[ 5.455782] mmc_host mmc0: Bus speed (slot 0) = 198000000Hz (slot req 200000Hz, actual 200000HZ div = 495)
[ 5.905840] mmc_host mmc0: Bus speed (slot 0) = 198000000Hz (slot req 100000Hz, actual 100000HZ div = 990)
[ 7.671822] EXT4-fs (mmcblk1p4): mounted filesystem with ordered data mode. Opts: (null). Quota mode: disabled.
# hdparm -t /dev/mmcblk1
Timing buffered disk reads: 66 MB in 3.05 seconds = 21.66 MB/sec
Is it possible to get at least SDR104 mode in U-boot and then in the system on VF2 rev. V1.2a PCB?
For sd card, it’s power rail is shared between multiple devices due to PMIC on board lacks rails and is set to 3.3V, causing it cannot reach higher speed mode which uses 1.8V mode.
However on-board emmc slot has a dedicated power rail from PMIC, so it’s possible to make it reach maximum speed mode, but current PMIC driver doesn’t support that.
To solve this problem,I’m working on a new driver which could be upstreamed: GitHub - Headcrabed/linux at axp15060
This driver currently lacks GPIO support, and not tested yet. But I’m busy these days to finish this driver…