My u-boot log → u-boot - Pastebin.com
My speedtest for my sd-card
root@starfive:/# dd if=/dev/zero of=sd.img bs=1M count=4096 conv=fdatasync
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 215.98 s, 19.9 MB/s
My sd-card
I think it’s a bit slow 
The only “SanDisk Extreme microSDXC UHS-I 64GB U3 A2” I could find results for online was here (~82% faster on a RPi4B):
Card Make/Model hdparm buffered dd write 4K rand read 4K rand write
SanDisk Extreme U3 V30 A2 64GB 43.73 MB/s 36.3 MB/s 7.35 MB/s 3.70 MB/s
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):
A quick lookup of what to expect from a Class 10, U3, V30 gives a sequential writing speed of 30 MB/s.
And 19.9 MB/sec is not 30MB/sec write rate, but it is not an order of magnitude slower either.
Thanks for the infos. On my main pc with usb adapter i can see
[frank-ms72 root]# dd if=/dev/zero of=sd.img bs=1M count=4096 conv=fdatasync
4096+0 Datensätze ein
4096+0 Datensätze aus
4294967296 Bytes (4,3 GB, 4,0 GiB) kopiert, 68,8811 s, 62,4 MB/s
I’m kind of curious what the performance would be on the VF2 with the USB adapter. So that you were comparing like with like.
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
/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.
Since system rootfs also inside sd card, I think speed might be affected since system also have to read/write the card and causes lower test results…
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.
Edit: Confirmed SD card won’t report mmc clock change info while testing IO speed.
user@starfive:~$ sudo hdparm --direct -t /dev/mmcblk1
/dev/mmcblk1:
Timing O_DIRECT disk reads: 64 MB in 3.01 seconds = 21.29 MB/sec
tested with my emmc module(FORESEE 64GB chip)… seems some low-power mode causes this?
[ 162.732463] mmc_host mmc0: Bus speed (slot 0) = 198000000Hz (slot req 400000Hz, actual 399193HZ div = 248)
[ 163.001433] mmc_host mmc0: Bus speed (slot 0) = 198000000Hz (slot req 100000000Hz, actual 99000000HZ div = 1)
[ 164.152473] mmc_host mmc0: Bus speed (slot 0) = 198000000Hz (slot req 400000Hz, actual 399193HZ div = 248)
[ 164.421576] mmc_host mmc0: Bus speed (slot 0) = 198000000Hz (slot req 100000000Hz, actual 99000000HZ div = 1)
user@starfive:~$ sudo hdparm --direct -t /dev/mmcblk0
/dev/mmcblk0:
Timing O_DIRECT disk reads: 24 MB in 3.95 seconds = 6.08 MB/sec
FWIW, eMMC is a different device from SD. Same peripheral capabilities, but slightly different and unique configuration. Fixes for one may be replicated for the other.
I’m working on fixing SD right now.
SD/EMMC are using the same controller IP and driver, so they share same problems…
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.
Again I am working on fixing SD right now.
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.
Thank you for this informative reply.
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
/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?
Edit: after dumping default register config from PMIC under U-Boot, seems eMMC’s power rail already set to 1.8v by default. So the speed issue is becoming more intreresting…
Edit 2: Whatever I change device tree config to, none of them could get a faster read speed than 20M/s… Even kernel reports a MMC clock over 90Mhz
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…
Edit: Haven’t tested yet, but seems that function implementation is only a simple GPIO edit, might only applicable to their internal EVB. Seems I’m wrong again.
OK, I think I found out the true reason for why eMMC stays at that extremely low speed:
In this commit, they removed dwmci driver’s voltage switch function since SD card doesn’t have a 1.8V power rail as mentioned here. But they forgot that eMMC slot has a proper 1.8V rail. Their upstream version driver also forgot that…
I will test if adding back voltage switch function really helps.