最近比较闲,准备玩玩xilinx的SoC,但又由于预算不够,买不起ZedBoard,所以最后入手了Z-Turn这块板子。它是米尔科技设计的,板子整体是蛮漂亮的,就是软资源不足——不能很好地玩转啊,这是个硬伤。过年在家,闲的无聊,就准备研究一下以前 一直想了解的linux中块设备的驱动架构,好吧扯了很多废话,让我们进入正题吧。
z-turn这块板子上,系统可以从SPI flash或者TF卡中启动,我们来看一下它的uboot env中与从tf卡启动的相关的部分(此处省去不相关的东西):root=/dev/mmcblk0p2。从此我们知道系统是从编号为0的块设备的part2区域去加载linux的根文件系统的,很多人可能理解为什么是编号为0的块设备,但可能会对为什么会是part2区域产生一定的疑惑。
对此,我是这样理解的:TF卡和电脑的硬盘一样,可以分成几个parTIons(C盘、D盘......)。在linux里面识别为 mmcblkxpy,其中x是mmc设备的编号,y是parTIon的编号。比如插入一块tf卡,识别为0号,就是mmcblk0。在本系统中具体分区如下图所示:
图1.1
可以看出TF卡分成了2个分区,第一个是fat32格式的文件系统分区,linux会识别为mmcblk0p1,第二个是ext4文件系统的分区,linux会识别为mmcblk0p2。一般来说没有特殊的软件支持,windows系统只识别第一个分区,不信话你可以吧TF通过读卡器,插到电脑上试试,是可以识别fat32的分区,也就是说,你是可以拷贝来更新uboot、linux等文件的。当然你如果使用专用的软件,你也可以去更新ext4文件系统,在本系统中ext4里面就是ubuntu。
好了,前戏结束了,让我们进一步跟进,开始讨论这个mmcblk0是怎么在内核中被注册。首先我们当然想到了函数(省去了具体代码):
int register_blkdev(unsigned int major, const char *name)
{
1. 从全局变量数组major_names找到一个是NULL(空闲)的成员
2. 通过参数major和那么,构造并初始化一个blk_major_name类型的对象p
3. 检查major_name中是否有major相同的,如果有就挑选出来,并把对象p填充到该数组中
}
大家可能发现了,注册了不也是什么功能都实现不了吗?对啊,很多注册函数本来就是这个样子,为了混个脸熟,占个位子嘛!
我们打开设备树文件linux-xlnx/arch/arm/boot/dts/zynq-7000.dtsi。通过搜索关键词sdhci,可以搜索到TF卡的设备驱动的节点部分,源码如下:
sdhci0: sdhci@e0100000 {
compaTIble = "arasan,sdhci-8.9a";
status = "disabled";
clock-names = "clk_xin", "clk_ahb";
clocks = , ;
interrupt-parent = ;
interrupts = ;
reg = ;
};
我们都知道,linux启动以后,系统过通过dts去生成各个设备驱动,并通过这些设备驱动去probe平台驱动,此处也是一样,它肯定对应了一个平台驱动,源码位于:linux-xlnx/drivers/mmc/host/sdhci-of-arasan.c。大家可能会疑问为什么是arasan,而不是xilinx呢?我查看了下,arasan这是一家可以提供各种SDIO、SPI等可以连接MMC/eMMC存储设备的接口的IP核的公司,xilixn估计就是用的它的IP核,毕竟方便易用好移植吗。
通过不停得追踪,发现此处注册一个设备驱动有如下的函数滴啊用关系:sdhci_arasan_probe->sdhci_add_host->mmc_add_host->device_add,顺利地把这个设备注册到了系统中。device_add?为什么不是device_register,该设备驱动驱动是在哪里被构造的?好回去继续找吧!函数调用关系如下:sdhci_arasan_probe->sdhci_pltfm_init->sdhci_alloc_host->mmc_alloc_host,就是这个函数里面构造了这个设备驱动;大家阅读的时候可能发现了,设备的是名字是"mmc%d",转换出来就是"mmc0","mmc1"......和设备"mmcblk0p2"有一毛钱关系啊,突然感觉失去了线索。但是想想我们这里也只是注册了一个mmc驱动,和block驱动还是很大的区别的吧!所以呢我觉得这应该就是个设备驱动,需要通过总线(应该就是MMC总线了)去match正真的驱动——块设备驱动。
在文件linux-xlnx/drivers/mmc/card/block.c中我找了函数mmc_blk_init,该函数被module_init引用,应该是驱动入口函数了,我们看看它具体是干嘛的。先通过register_blkdev(MMC_BLOCK_MAJOR, "mmc")注册了一个名字是mmc的块设备;接着通过mmc_register_driver(&mmc_driver)这个mmc设备驱动,这是里面最重要的函数。
int mmc_register_driver(struct mmc_driver *drv)
{
drv->drv.bus = &mmc_bus_type;
return driver_register(&drv->drv);
}
主要就是吧该驱动注册到mmc总线上面去。再次通过层层追踪,发现mmc_blk_probe->mmc_blk_alloc->mmc_blk_alloc_req->snprintf(md->disk->disk_name, sizeof(md->disk->disk_name), "mmcblk%d%s", md->name_idx, subname ? subname : "")将某设备的名字配置成了"mmcblk%d%s",终于找到它了。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)