碎碎念android eMMC【转】
本文转载自：https://blog.csdn.net/Fybon/article/details/44242549
一、/dev/block
root@:/dev/block #ls
bootdevice
mmcblk0
mmcblk0p1
mmcblk0p10
…….
mmcblk0p18
mmcblk0p19
mmcblk0p2
mmcblk0p20
……
mmcblk0p29
mmcblk0p3
mmcblk0p30
……
mmcblk0rpmb
platform
dd命令直接操作
分区的创建过程：
LK获取分区信息
smem_ptable_init()从SMEM的entry SMEM_AARM_PARTITION_TABLE中读取分区信息，保存在smem_ptable结构中(hard coded)。调用smem_add_modem_partitions()将smem_ptable中的内容解析出来保存在flash_ptable中.
将分区信息传递给kernel
Lk将分区信息打包成atag形式传递给kernel，让kernel知道分区信息。
target_atag_mem()->flash_get_ptable()
Kernelget the partition info and add partition:
blkdev_get_by_path()->blkdev_get()->__blkdev_get()->
rescan_partitions()->add_partition()
/dev/block/bootdevice/by-name/xxx，目录及后面的链接是在userspace的init进程中创建出来的，init收到增加新分区的uevent事件后，构造出以上by-name下的文件。
Code:system/core/init/devices.c
Function:parse_platform_block_device(structuevent*uevent)
二、/sys/class/mmc_host/mmc0/mmc0:0001
root@:/sys/class/mmc_host/mmc0/mmc0:0001#ls
block
cid
csd
date
driver
enhanced_area_offset
enhanced_area_size
erase_size
fwrev
hwrev
manfid
name
oemid
power
preferred_erase_size
prv
raw_rpmb_size_mult
rel_sectors
runtime_pm_timeout
serial
subsystem
type
uevent
三、/sys/block/mmcblk0
root@:/sys/block/mmcblk0 #ls
alignment_offset
bdi
bkops_check_threshold
capability
dev
device
discard_alignment
ext_range
force_ro
holders
inflight
mmcblk0p1
mmcblk0p10
……
mmcblk0p9
mmcblk0rpmb
no_pack_for_random
num_wr_reqs_to_start_packing
power
queue
range
removable
ro
Size // emmc size = Size * 512Btye
slaves
stat
subsystem
uevent
四、/proc/partitions
root@:/proc # cat partitions
major minor #blocks name
253 0 486188 zram0
179 0 15267840 mmcblk0 //emmc size,单位KB
179 1 65536 mmcblk0p1
179 2 512 mmcblk0p2
179 3 512 mmcblk0p3
179 15 16 mmcblk0p15
179 16 20480 mmcblk0p16
……
179 26 2097152 mmcblk0p26
179 27 512 mmcblk0p27
179 28 32 mmcblk0p28
179 29 65536 mmcblk0p29
179 30 268288 mmcblk0p30
179 31 12312559 mmcblk0p31
179 32 4096 mmcblk0rpmb
五、多种size规格eMMC兼容方案一：利用文件系统自身resize功能
mountdata之前，比较super block的size与block deviceszie，不一样就去resize。
六、多种size规格eMMC兼容方案之二：第一次开机format data分区
如果使用的filesystem没有resize功能，比如f2fs, fat32等。
那只能采用此种办法啦：
不下载userdata.img
mountdata之前，fs_mgrservice判断是否会第一次开机，如果是，则启动format
system/core/fs_mgr
七、存储空间保护，防止空间满导致系统启动异常
内置sd卡保护：
fuse增加保护，内置sd卡最大可写容量data total size-reserved(50MB)
Code:system/core/sdcard/sdcard.c
#define LIMIT_SDCARD_SIZE
MTP保护：
Mtpservice增加保护，PC可写的最大可写容量internalsdcardfs total size-reserved
code:frameworks/base/services/java/com/android/server/MountService.java
FileSystem保护：
Ext4文件系统增加保护，保留16MB给uid<= 10010的使用
Code：kernel/fs/ext4/balloc.c
init.{platform}.rc：exec /system/bin/tune2fs -Ohas_journal -u 10010 -r 4096 /dev/block/platform/mtk-msdc.0/by-name/userdata
resv_clusters: -r 4096=4096blocks=4096*4096=16MB
dirty_clusters: default 16M当flags有EXT4_MB_USE_RESERVED才可写
sbi->s_resuid：-u10010
sbi->s_resgid：tune2fs没有传递default0
八、eMMC workload & performance of mtk log
1.Workload是根据什么计算出来的呢？
500ms内花在io上的时间比例
/kernel/drivers/mmc/card/block.c
static intmmc_blk_issue_rw_rq(structmmc_queue *mq,struct request *rqc)
xlog_printk(ANDROID_LOG_DEBUG,"BLOCK_TAG", "mmcqd:%d Workload=%d%%, duty %lld,period %lld00, req_cnt=%d \n",mmcqd[idx],t_percent,t_usage,t_period,mmcqd_rq_count[idx]);
2.能否知道主要哪个app占得workload？
/kernel/drivers/mmc/card/block.c
static intmmc_blk_issue_rw_rq(structmmc_queue *mq,struct request *rqc)
sprintf (g_pid_logger[index].pid_buffer+i*37,"{%05d:%05d:%08d:%05d:%08d}",g_pid_logger[index].pid_logger[i],g_pid_logger[index].pid_logger_counter[i],g_pid_logger[index].pid_logger_length[i],g_pid_logger[index].pid_logger_r_counter[i],g_pid_logger[index].pid_logger_r_length[i]);
如 {26626:00000:00000000:00878:03596288}含义：pid为26626的进程500ms内read3512KB（03596288）的数据，write0KB的数据。
可以查看某段时间内，各个进程读写的情况，进而判断是哪个进程占用的worload比较高；
3. 当workload比较高的时候，log打印read、write也比较高，能否说明emmc是没有问题的？
<6>[16656.919474] (5)[142:mmcqd/0][BLOCK_TAG]mmcqd:142 Workload=63%, duty 317163907, period 500889000, req_cnt=1426
<6>[16656.919483] (5)[142:mmcqd/0][BLOCK_TAG] mmcqd:142 WriteDiversity=5553653 sectors offset, req_cnt=12, break_cnt=0, tract_cnt=0,bit_cnt=0
<6>[16656.919534] (0)[142:mmcqd/0][BLOCK_TAG] mmcqd:142 ReadDiversity=607567 sectors offset, req_cnt=1414, break_cnt=0, tract_cnt=0,bit_cnt=0
<6>[16656.919565] (0)[142:mmcqd/0][BLOCK_TAG] mmcqd:142 WriteThroughput=69222 kB/s, size: 692224 bytes, time:10 ms
<6>[16656.919617](0)[142:mmcqd/0][BLOCK_TAG] mmcqd:142 Read Throughput=93819 kB/s, size:28708864 bytes, time:306 ms
是的。从log看，eMMC的performance还可以。
workload高不一定是eMMC性能差导致，最近发现内存泄漏也可能导致workload高！
qcom 平台也有类似机制，参考：CONFIG_MMC_PERF_PROFILING
mmc debug log 需要请打开CONFIG_MMC_DEBUG
九、eMMC ext_csd
root@:/sys/kernel/debug/mmc0/mmc0:0001# catext_csd
十、eMMC HS200 & HS400
AP CPU 和 eMMC 同时支持HS400 ，HS400 performance才能发挥出来！否则还是HS200 .
十一、eMMC cache
cache对emmc write performance影响很大，使能它。
十二、 eMMC Cmd Queue
选择支持Cmd Queue功能的eMMC极大地提供随机读写能力。
