碎碎念android eMMC【轉】
本文轉載自：https://blog.csdn.net/Fybon/article/details/44242549
一、/dev/block
[email protected]:/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
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
[email protected]:/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
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
十、eMMC HS200 & HS400
AP CPU 和 eMMC 同時支援HS400 ，HS400 performance才能發揮出來！否則還是HS200 .
十一、eMMC cache
cache對emmc write performance影響很大，使能它。
十二、 eMMC Cmd Queue
選擇支援Cmd Queue功能的eMMC極大地提供隨機讀寫能力。