MMC分区流程分析

Chipset: msm8926 
OS: Android4.4 
Kernel: 3.4.0

在N久之前的会议上留下了两个问题： 
1. 内核在加载emmc驱动时是如何知道当前有几个分区的? 
2. 如何知道/dev/mmcblkXpX对应的是哪个分区呢?

读取分区

加载sd/emmc驱动的时候，有如下流程： 

来看看Check_partition(): 

核心的部分是check_part这个结构体，里面放的都是对应的解析分区的算法： 

算法不是我们需要关注的，解析哪一块区域等小弟看了partition再给大家解释吧。 
解析完成之后放到struct parsed_partitions也就是这里的state变量的parts元素里： 

然后通过add_partition()将这些part信息添加到disk里去。

有多少分区可以从开机Log看到： 
 
确实我们在8926平台上定义的分区个数是34个： 
[non_hlos\common\build\partition_f5.xml] 

分区对应label

其实Linux已经在/dev/block下提供了查看方法： 

从本质上来说，这些信息是从解析出来的struct parsed_partitions中的info变量获取的： 

emmc分区初始化

emmc卡检测到后先从mmc_init_card得到并构建card参数，如向mmc控制器获取boot0 boot1 rpmb物理节点分区再通过mmc_part_add加入card中，card->nr_parts显示有几块物理分区(emmc 出厂就有的）

1. [ 0.612375] <3>.(0)[6:kworker/u8:0]mmcblk0: mmc0:0001 M62704 3.53 GiB

2. [ 0.612631] <3>.(0)[6:kworker/u8:0]mmcblk0boot0: mmc0:0001 M62704 partition 1 2.00 MiB

3. [ 0.612896] <3>.(0)[6:kworker/u8:0]mmcblk0boot1: mmc0:0001 M62704 partition 2 2.00 MiB

4. [ 0.613142] <3>.(0)[6:kworker/u8:0]mmcblk0rpmb: mmc0:0001 M62704 partition 3

再通过读取 userdata区的MBR分区表（软件分区表）****rescan_partitions得到软件的分区信息（用户自己定义，加入软件分区表这里为efi_partition，调用流程如下

[    0.615795] <3>.(1)[6:kworker/u8:0] mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10

1. 0.745744] <1>-(1)[6:kworker/u8:0]Call trace:

2. [ 0.746312] <1>-(1)[6:kworker/u8:0][<ffffff800808a3b0>] dump_backtrace+0x0/0x158

3. [ 0.747244] <1>-(1)[6:kworker/u8:0][<ffffff800808a51c>] show_stack+0x14/0x20

4. [ 0.748132] <1>-(1)[6:kworker/u8:0][<ffffff800835f878>] dump_stack+0x90/0xb0

5. [ 0.749022] <1>-(1)[6:kworker/u8:0][<ffffff800809f2e8>] warn_slowpath_common+0x98/0xd0

6. [ 0.750019] <1>-(1)[6:kworker/u8:0][<ffffff800809f3c8>] warn_slowpath_null+0x18/0x20

7. [ 0.750994] <1>-(1)[6:kworker/u8:0][<ffffff80083573c4>] efi_partition+0x494/0x5f8

8. [ 0.751937] <1>-(1)[6:kworker/u8:0][<ffffff8008355f68>] check_partition+0xf8/0x210

9. [ 0.752890] <1>-(1)[6:kworker/u8:0][<ffffff80083554c0>] rescan_partitions+0xc8/0x2d0

10. [ 0.753866] <1>-(1)[6:kworker/u8:0][<ffffff80081f41e4>] __blkdev_get+0x214/0x310

11. [ 0.754798] <1>-(1)[6:kworker/u8:0][<ffffff80081f4d28>] blkdev_get+0xf8/0x340

12. [ 0.755697] <1>-(1)[6:kworker/u8:0][<ffffff8008352e08>] add_disk+0x338/0x440

13. [ 0.756586] <1>-(1)[6:kworker/u8:0][<ffffff8008684a0c>] mmc_add_disk+0x24/0x110

14. [ 0.757507] <1>-(1)[6:kworker/u8:0][<ffffff8008684ffc>] mmc_blk_probe+0x1d4/0x2b0

15. [ 0.758451] <1>-(1)[6:kworker/u8:0][<ffffff80086779a4>] mmc_bus_probe+0x1c/0x28

16. [ 0.759373] <1>-(1)[6:kworker/u8:0][<ffffff800840c79c>] driver_probe_device+0x1fc/0x348

17. [ 0.760381] <1>-(1)[6:kworker/u8:0][<ffffff800840ca18>] __device_attach_driver+0x90/0xd8

18. [ 0.761400] <1>-(1)[6:kworker/u8:0][<ffffff800840a990>] bus_for_each_drv+0x58/0x98

19. [ 0.762353] <1>-(1)[6:kworker/u8:0][<ffffff800840c4e4>] __device_attach+0xc4/0x148

20. [ 0.763306] <1>-(1)[6:kworker/u8:0][<ffffff800840cab0>] device_initial_probe+0x10/0x18

21. [ 0.764302] <1>-(1)[6:kworker/u8:0][<ffffff800840b98c>] bus_probe_device+0x94/0xa0

22. [ 0.765255] <1>-(1)[6:kworker/u8:0][<ffffff8008409904>] device_add+0x354/0x548

23. [ 0.766164] <1>-(1)[6:kworker/u8:0][<ffffff8008677e8c>] mmc_add_card+0xdc/0x278

24. [ 0.767086] <1>-(1)[6:kworker/u8:0][<ffffff800867b5f0>] mmc_attach_mmc+0xb0/0x170

25. [ 0.768029] <1>-(1)[6:kworker/u8:0][<ffffff8008677514>] mmc_rescan+0x2a4/0x2f8

26. [ 0.768941] <1>-(1)[6:kworker/u8:0][<ffffff80080b8550>] process_one_work+0x1e0/0x478

27. [ 0.769916] <1>-(1)[6:kworker/u8:0][<ffffff80080b891c>] worker_thread+0x134/0x4f0

28. [ 0.770860] <1>-(1)[6:kworker/u8:0][<ffffff80080be800>] kthread+0xd0/0xe8

29. [ 0.771717] <1>-(1)[6:kworker/u8:0][<ffffff8008085f90>] ret_from_fork+0x10/0x40

30. [ 0.772648] <1>.(1)[6:kworker/u8:0]---[ end trace 30179c718ee802dd ]--

转自：https://blog.csdn.net/gnnulzy/article/details/86167062