According to JEDEC eMMC and experience, it is painstakingly organized, original protection, and reprinting is prohibited .
Homepage " Meta Storage - CSDN Blog "
Full text 15000 words, main content
eMMC initialization in Linux
Linux eMMC debugging toolMMC-utils
mmc-utils function
mmc-utils consumer
Linux/Android eMMC performance testing tool
DD tes
FIO test
IOZone test
Kernal mmc_test
The content of this article is based on practical clues, and it cannot be fully explained for each Tool. Readers don't need to memorize it by rote, just save it and use it as a reference book.
As for the tool, just choose the one you like, there is no best one, only the most suitable one. If it is relatively simple to use, just use MMC-utils and keneral mmc_test. If you are more in-depth, use MMC-utils, DD test and FIO Test. DD is easy to get started, and FIO is relatively professional, but of course it will be more complicated to use.
Primer
In this article, Linux is used to illustrate, because Android is based on the Linux kernel, so the method in this article is also applicable to Android.
eMMC initialization in Linux
Because SD, SDIO and MMC are very similar, how does Linux recognize MMC? The identification process during device initialization is as follows:
- When initializing, first send cmd0 to make the card enter the idle state;
- Then send cmd8 to check whether the card is SD2.0. SD1.1 does not support cmd8, so if there is no response when sending cmd8, the card is SD1.1, otherwise it is SD2.0;
- mmc_attach_sdio sends cmd5 to read the OCR register to determine whether it is sdio, and if so, bind the sdio bus;
- mmc_attach_sd sends commands acmd55 and cmd41 to make the card enter the working state. If it passes, it is considered to be an sd card and bound to the sd bus. The mmc card does not support acmd55, and cmd41, so if there is no response, the card is considered to be an mmc card;
- Send cmd1 in mmc_attach_mmc to judge whether it is an mmc card, and if it responds, bind the mmc bus. If there is no response from cmd1, it is not the mmc card.
Linux eMMC debugging toolMMC -utils
[3] MMC debugging tools for mmc-utils, maintained by Ulf Hansson , you can find it in the following public git repository:
https://git.kernel.org/pub/scm/utils/mmc/mmc-utils .git
This open source tool is used in a Linux environment. The core of Android is also Linux, and this tool can also be used. Because the difference between eMMC and MMC is that one is welded and the other is plug-in. This tool is applicable to both eMMC and MMC.
Let's take a look at the functions first. You don't need to remember how to use each function, just know what you can use it for.
mmc-utils function
The mmc-utils tool can do the following:
- Print and parse extcsd data.
- Determine the eMMC write protection status.
- Set eMMC write protection status.
- Set the eMMC data sector size to 4KB by disabling emulation.
- Create a GPAP general partition.
- Enable Enhance Area (enhanced user area).
- Enables write reliability for each partition.
- Print the response to STATUS_SEND (CMD13).
- Enable the Boot (boot) partition.
- Set bootstrap bus conditions.
- Enable eMMC BKOPS feature.
- Permanently enable eMMC H/W Reset function.
- Permanently disable eMMC H/W Reset function.
- Send the Sanitize command.
- The device's program authentication key ( authentication key , used in RPMB ).
- The counter values of the RPMB partition will be read to the standard output device (such as the screen).
- Read from RPMB device to output.
- Write to RPMB device from data file .
- Enable eMMC Cache (caching) feature.
- Disable eMMC Cache (caching) feature.
- Print and parse CID data.
- Print and parse CSD data.
- Print and parse SCR data.
How to use MMC-utils
You can view the usage through mmc without parameters
Usage:
mmc extcsd read <device>
Print extcsd data from <device>.
mmc writeprotect get <device>
Determine the eMMC writeprotect status of <device>.
mmc writeprotect set <device>
Set the eMMC writeprotect status of <device>.
This sets the eMMC to be write-protected until next boot.
mmc disable 512B emulation <device>
Set the eMMC data sector size to 4KB by disabling emulation on
<device>.
mmc enh_area set <-y|-n> <start KiB> <length KiB> <device>
Enable the enhanced user area for the <device>.
Dry-run only unless -y is passed.
NOTE! This is a one-time programmable (unreversible) change.
mmc write_reliability set <-y|-n> <partition> <device>
Enable write reliability per partition for the <device>.
Dry-run only unless -y is passed.
NOTE! This is a one-time programmable (unreversible) change.
mmc status get <device>
Print the response to STATUS_SEND (CMD13).
mmc bootpart enable <boot_partition> <send_ack> <device>
Enable the boot partition for the <device>.
To receive acknowledgment of boot from the card set <send_ack>
to 1, else set it to 0.
mmc bkops enable <device>
Enable the eMMC BKOPS feature on <device>.
NOTE! This is a one-time programmable (unreversible) change.
mmc hwreset enable <device>
Permanently enable the eMMC H/W Reset feature on <device>.
NOTE! This is a one-time programmable (unreversible) change.
mmc hwreset disable <device>
Permanently disable the eMMC H/W Reset feature on <device>.
NOTE! This is a one-time programmable (unreversible) change.
mmc sanitize <device>
Send Sanitize command to the <device>.
This will delete the unmapped memory region of the device.
mmc help|--help|-h
Show the help.
mmc <cmd> --help
Show detailed help for a command or subset of commands.
0.1usage example
mmc extcsd read /dev/mmc0
Linux/Android eMMC performance testing tool
There are mainly 4 tools for linux emmc performance testing :
- DD
- FIO
- IOZone
- General mmc_test
Which one is better? People have different opinions, since I put DD first, you will know which one I like^^
DD test
write performance test
We divide into two cases to test
write to block device
The cache partition is generally used to store the OTA upgrade package. Under normal conditions, the failure of the mount will not affect the normal operation of the system, so we use the cache partition for the write test, first find the block device file corresponding to the cache
1 2 3 |
KKHi3751V810:/ #ls -l /dev/block/platform/soc/f9830000.emmc/by-name/cache < lrwxrwxrwx 1 root root 21 1970-01-01 08:00 /dev/block/platform/soc/f9830000.emmc/by-name/cache -> /dev/block/mmcblk0p18 KKHi3751V810:/ # |
The block device file of the cache partition is /dev/block/mmcblk0p18.
Write a test:
1 2 3 4 5 6 |
KKHi3751V810:/ # echo 1 > /proc/sys/vm/drop_caches KKHi3751V810:/ # busybox dd if=/dev/zero of=/dev/block/mmcblk0p18 bs=1M count=1024 conv=fsync 1024+0 records in 1024+0 records out 1073741824 bytes (1.0GB) copied, 24.122624 seconds, 42.4MB/s KKHi3751V810:/ # |
The input file is /dev/zero, which is a virtual device. We can think that the reading speed of this device is infinite, that is, the reading speed will not affect the writing speed.
bs=1M: write 1M at a time
count=1024: write 1024 times, that is, the total amount of data written is 1G
conv=fsync: before the end of dd, synchronize the data to emmc, if this parameter is not added, the data may Still in cache. In order to ensure the accuracy of the data, this parameter must be added.
Repeat the test several times, the speed is basically around 42M/s.
write to file
1 2 3 4 5 6 |
KKHi3751V810:/ # echo 1 > /proc/sys/vm/drop_caches KKHi3751V810:/ # busybox dd if=/dev/zero of=/data/ddtest.bin bs=1M count=1024 conv=fsync < 1024+0 records in 1024+0 records out 1073741824 bytes (1.0GB) copied, 30.607905 seconds, 33.5MB/s KKHi3751V810:/ # |
Repeat the test several times, the speed is basically around 33M/s. Compared with directly writing block device files, it is about 10M/s slower. This may be an effect of the file system.
read test
read block device
Just use the example we introduced above to clear the cache, so I won’t repeat it here.
The data obtained from the above example is about 203M/s.
read file
1 2 3 4 5 6 |
KKHi3751V810:/ # echo 1 > /proc/sys/vm/drop_caches KKHi3751V810:/ # busybox dd if=/data/ddtest.bin of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.0GB) copied, 4.915286 seconds, 208.3MB/s KKHi3751V810:/ # |
Take the file generated when testing the writing speed directly, repeat the test several times, and the speed is basically around 208MB/s.
FIO test
Reprinted from: linux emmc test - Zhihu
You can get iops, read and write bandwidth rate and other information.
The reading and writing speed is closely related to the queue depth, block size, number of threads, etc., which is related to the working principle of ssd
1. Random read (Random read)
fio -filename=/tmp/test_randread -direct=1 -iodepth 1 -thread -rw=randread -ioengine=psync -bs=16k -size=30G -numjobs=10 -runtime=600 -group_reporting -name=mytest
When 10 threads
Run status group 0 (all jobs):
READ: io=51200MB, aggrb=257806KB/s, minb=257806KB/s, maxb=257806KB/s, mint=203365msec, maxt=203365msec
when a thread
Run status group 0 (all jobs):
READ: io=1024.0MB, aggrb=27522KB/s, minb=27522KB/s, maxb=27522KB/s, mint=38099msec, maxt=38099msec
When 2 threads
Run status group 0 (all jobs):
READ: io=2048.0MB, aggrb=48400KB/s, minb=48400KB/s, maxb=48400KB/s, mint=43329msec, maxt=43329msec
Random write
fio -filename=./test_randread -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=psync -bs=16k -size=1G -numjobs=10 -runtime=600 -group_reporting -name=mytest
Run status group 0 (all jobs):
WRITE: io=10240MB, aggrb=66959KB/s, minb=66959KB/s, maxb=66959KB/s, mint=156599msec, maxt=156599msec
Disk stats (read/write):
sda: ios=1/655282, merge=0/86, ticks=0/135704, in_queue=135652, util=86.80%
Sequential read
fio -filename=./test_randread -direct=1 -iodepth 1 -thread -rw=read -ioengine=psync -bs=16k -size=1G -numjobs=5 -runtime=600 -group_reporting -name=mytest
Run status group 0 (all jobs):
READ: io=5120.0MB, aggrb=45658KB/s, minb=45658KB/s, maxb=45658KB/s, mint=114829msec, maxt=114829msec
Sequential write
fio -filename=./test_randread -direct=1 -iodepth 1 -thread -rw=write -ioengine=psync -bs=16k -size=1G -numjobs=5 -runtime=600 -group_reporting -name=mytest
Run status group 0 (all jobs):
WRITE: io=2048.0MB, aggrb=15644KB/s, minb=15644KB/s, maxb=15644KB/s, mint=134053msec, maxt=134053msec
About fio running problems
Run fio on the android platform and find that fio cannot run normally for two reasons
- The imported fio executable program is 32-bit, but the current cpu is 64-bit, and the running kernel lacks 32-bit related libraries, including /system/bin/linker, system/lib/libc.so lbc++. so .. . and other dynamic linkers, shared libraries, etc. required for 32-bit programs to run; here it should be explained that 64-bit cpu and linux support running 32-bit programs in EL0, provided that they are enabled in the kernel and the relevant 32-bit programs are run library import;
- fio can be compiled into a static program, so the library that fio needs to depend on must also be static.a
- Regarding the selection of the compiler used to compile fio, because it runs in the linux environment that supports android, the compiler uses the aarch-linux-android-gcc version, because the library functions in the kernel are also compiled using this compiler, and the application layer and The kernel compiler needs to be consistent.
FIO Test in Action
write file speed
KKHi3751V810:/ # echo 1 > /proc/sys/vm/drop_caches
KKHi3751V810:/ # fio -filename=/dev/block/mmcblk0p18 -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=psync -bs=1m -size=1G -numjobs=4 -runtime=60 -group_reporting -name=rand_write_1m
rand_write_1m: (g=0): rw=randwrite, bs=1M-1M/1M-1M/1M-1M, ioengine=psync, iodepth=1
...
fio-2.2.6
Starting 4 threads
Jobs: 3 (f=3): [w(3),_(1)] [98.1% done] [0KB/80734KB/0KB /s] [0/78/0 iops] [eta 00m:01s]
rand_write_1m: (groupid=0, jobs=4): err= 0: pid=8316: Wed Feb 12 21:03:34 2020
write: io=4096.0MB, bw=83067KB/s, iops=81, runt= 50493msec
clat (msec): min=10, max=1361, avg=48.60, stdev=44.45
lat (msec): min=10, max=1361, avg=48.86, stdev=44.44
clat percentiles (msec):
| 1.00th=[ 18], 5.00th=[ 22], 10.00th=[ 23], 20.00th=[ 26],
| 30.00th=[ 34], 40.00th=[ 37], 50.00th=[ 46], 60.00th=[ 48],
| 70.00th=[ 58], 80.00th=[ 65], 90.00th=[ 76], 95.00th=[ 87],
| 99.00th=[ 104], 99.50th=[ 114], 99.90th=[ 758], 99.95th=[ 1123],
| 99.99th=[ 1369]
bw (KB /s): min= 1343, max=41353, per=25.49%, avg=21171.93, stdev=4637.55
lat (msec) : 20=1.51%, 50=60.52%, 100=36.40%, 250=1.37%, 500=0.02%
lat (msec) : 750=0.05%, 1000=0.05%, 2000=0.07%
cpu : usr=0.43%, sys=1.13%, ctx=10620, majf=0, minf=6
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued : total=r=0/w=4096/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: io=4096.0MB, aggrb=83067KB/s, minb=83067KB/s, maxb=83067KB/s, mint=50493msec, maxt=50493msec
Disk stats (read/write):
mmcblk0: ios=54/8332, merge=5/888, ticks=60872/378355, in_queue=439181, util=100.00%
KKHi3751V810:/ #
The average writing speed of 4 threads is bw=83067KB/s, which is about 80M/s, which is more than twice as fast as dd.
read file speed
KKHi3751V810:/ # echo 1 > /proc/sys/vm/drop_caches
KKHi3751V810:/ # fio -filename=/dev/block/mmcblk0 -direct=1 -iodepth 1 -thread -rw=randread -ioengine=psync -bs=1m -size=1G -numjobs=4 -runtime=60 -group_reporting -name=rand_read_1m
rand_read_1m: (g=0): rw=randread, bs=1M-1M/1M-1M/1M-1M, ioengine=psync, iodepth=1
...
fio-2.2.6
Starting 4 threads
Jobs: 1 (f=1): [_(3),r(1)] [96.2% done] [148.5MB/0KB/0KB /s] [148/0/0 iops] [eta 00m:01s]
rand_read_1m: (groupid=0, jobs=4): err= 0: pid=7889: Wed Feb 12 20:56:21 2020
read : io=4096.0MB, bw=171813KB/s, iops=167, runt= 24412msec
clat (msec): min=4, max=9350, avg=19.50, stdev=215.06
lat (msec): min=4, max=9350, avg=19.50, stdev=215.06
clat percentiles (msec):
| 1.00th=[ 7], 5.00th=[ 8], 10.00th=[ 8], 20.00th=[ 11],
| 30.00th=[ 11], 40.00th=[ 11], 50.00th=[ 11], 60.00th=[ 14],
| 70.00th=[ 14], 80.00th=[ 14], 90.00th=[ 14], 95.00th=[ 14],
| 99.00th=[ 16], 99.50th=[ 30], 99.90th=[ 2638], 99.95th=[ 4113],
| 99.99th=[ 9372]
bw (KB /s): min= 964, max=145420, per=46.41%, avg=79740.53, stdev=25495.41
lat (msec) : 10=13.77%, 20=85.55%, 50=0.29%, 100=0.12%, 500=0.05%
lat (msec) : 750=0.05%, 2000=0.05%, >=2000=0.12%
cpu : usr=0.22%, sys=3.16%, ctx=9195, majf=0, minf=1030
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued : total=r=4096/w=0/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
READ: io=4096.0MB, aggrb=171813KB/s, minb=171813KB/s, maxb=171813KB/s, mint=24412msec, maxt=24412msec
Disk stats (read/write):
mmcblk0: ios=8365/46, merge=15/47, ticks=633927/61332, in_queue=695214, util=99.20%
KKHi3751V810:/ #
The average reading speed of 4 threads is bw=171813KB/s, which is about 170M/s.
IOZone test
There is no iozone in the Android system source code, we have to download and compile it from the official website. The latest version when I downloaded it is iozone3_489. This version already has Android.mk in the code, just put the source code in the Android system source code and mm.
Random read and write test:
KKHi3751V810:/ # echo 1 > /proc/sys/vm/drop_caches
KKHi3751V810:/ # iozone -azecI -+n -L64 -S32 -r1m -s1024m -i0 -i2 -w -f /data/iozonetest.bin
Iozone: Performance Test of File I/O
Version $Revision: 3.489 $
Compiled for 64 bit mode.
Build: linux-arm
Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
Al Slater, Scott Rhine, Mike Wisner, Ken Goss
Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
Vangel Bojaxhi, Ben England, Vikentsi Lapa,
Alexey Skidanov, Sudhir Kumar.
Run began: Wed Feb 12 20:47:58 2020
Auto Mode
Cross over of record size disabled.
Include fsync in write timing
Include close in write timing
O_DIRECT feature enabled
No retest option selected
Record Size 1024 kB
File size set to 1048576 kB
Setting no_unlink
Command line used: iozone -azecI -+n -L64 -S32 -r1m -s1024m -i0 -i2 -w -f /data/iozonetest.bin
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 32 kBytes.
Processor cache line size set to 64 bytes.
File stride size set to 17 * record size.
random random bkwd record stride
kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread
1048576 1024 74782 0 199299 71520
iozone test complete.
KKHi3751V810:/ #
From the results, the random read speed is 199299 kB/s, which is about 200M/s. The random write speed is 71520 kB/s, which is about 70M/s.
Repeat the test several times, the result is similar, and the reading speed is basically the same as that of dd. Writing is nearly twice as fast as dd.
Kernal mmc_test
Reprinted from: Linux kernel mmc framework description, including how to use mmc_test_operation and maintenance_kivy_xian's blog-CSDN blog
Use the mmc_test.ko that comes with the linux kernel to perform the functional test of mmc, including speed setting, bus width setting, multiple operation, trim operation, command and basic data read and write and other characteristic tests. You can follow the steps below:
1. CONFIG_MMC_BLOCK=n, CONFIG_MMC_TEST=y. Or CONFIG_MMC_BLOCK=y, CONFIG_MMC_TEST=y. If you choose the latter configuration, you need to manually bind and unbind in the bus driver after the system is up, see later;
2. CONFIG_DEBUG_FS=y, CONFIG_DEBUG_KERNEL=y, these two items have been configured in the defconfig of the kernel of our project, so there is no need to make changes;
3. mount -t debugfs none /sys/kernel/debug, this has been mounted in our project, no need to change;
After completing the above three items, start the system. If CONFIG_MMC_BLOCK=y in step 1, you need to perform the following operations first:
etau:/ # ls sys/bus/mmc/devices/
mmc0:aaaa
etau:/sys/bus/mmc/drivers # ls
mmc_test/ mmcblk/
etau:/sys/bus/mmc/drivers # cd mmcblk/
etau:/sys/bus/mmc/drivers/mmcblk # ls -al
total 0
drwxr-xr-x 2 root root 0 2000-01-01 01:27 .
drwxr-xr-x 4 root root 0 2000-01-01 01:27 ..
--w------- 1 root root 4096 2000-01-01 01:28bind
lrwxrwxrwx 1 root root 0 2000-01-01 01:28 mmc0:aaaa ->../../../../devices/soc0/20a50000.rda-mmc0/mmc_host/mmc0/mmc0:aaaa
--w------- 1 root root 4096 2000-01-01 01:28uevent
--w------- 1 root root 4096 2000-01-01 01:28unbind
etau : / sys / bus / mmc / drivers / mmcblk # echo – n mmc0 : aaaa > unbind
etau:/sys/bus/mmc/drivers # cdmmc_test/
etau:/sys/bus/mmc/drivers/mmc_test # ls
bind uevent unbind
etau : / sys / bus / mmc / drivers / mmc_test # echo – n mmc0 : aaaa > bind
After completing the above operations, the binding of mmc0:aaaa and mmc_test driver is completed. The subsequent steps are exactly the same, as follows:
etau:/sys/kernel/debug/mmc0/mmc0:aaaa# cat testlist
1: Basic write (no data verification)
2: Basic read (no data verification)
3: Basic write (with data verification)
4: Basic read (with data verification)
5: Multi-block write
6: Multi-block read
7: Power of two block writes
8: Power of two block reads
9: Weird sized block writes
10: Weird sized block reads
11: Badly aligned write
12: Badly aligned read
13: Badly aligned multi-block write
14: Badly aligned multi-block read
15: Correct xfer_size at write (start failure)
16: Correct xfer_size at read (start failure)
17: Correct xfer_size at write (midway failure)
18: Correct xfer_size at read (midway failure)
19: Highmem write
20: Highmem read
21: Multi-block highmem write
22: Multi-block highmem read
23: Best-case read performance
24: Best-case write performance
25: Best-case read performance into scattered pages
26: Best-case write performance from scatteredpages
27: Single read performance by transfer size
28: Single write performance by transfer size
29: Single trim performance by transfer size
30: Consecutive read performance by transfer size
31: Consecutive write performance by transfer size
32: Consecutive trim performance by transfer size
33: Random read performance by transfer size
34: Random write performance by transfer size
35: Large sequential read into scattered pages
36: Large sequential write from scattered pages
37: Write performance with blocking req 4k to 4MB
38: Write performance with non-blocking req 4k to 4MB
39: Read performance with blocking req 4k to 4MB
40: Read performance with non-blocking req 4k to 4MB
41: Write performance blocking req 1 to 512 sg elems
42: Write performance non-blocking req 1 to 512 sg elems
43: Read performance blocking req 1 to 512 sg elems
44: Read performance non-blocking req 1 to 512 sg elems
45: Reset testThen execute etau:/sys/kernel/debug/mmc0/mmc0:aaaa# echo 1 > test to see the test results:
[314034.644348] mmc0: Starting tests of cardmmc0:aaaa...
[314034.645080] mmc0: Test case 1. Basicwrite (no data verification)...
[314034.647583] mmc0: Result: OK
[314034.647827] mmc0: Tests completed.
reference
[2] linux emmc test - Zhihu
[3] MMC tools introduction — The Linux Kernel documentation
Disclaimer :
This article is organized based on public information and aims to introduce more storage knowledge. The articles contained in the article are only the author's opinion and do not constitute investment or commercial advice. This article is only for learning and communication, not for commercial use. If you have any questions or infringements, please contact the author.