Chinaunix首页 | 论坛 | 博客
  • 博客访问: 822358
  • 博文数量: 124
  • 博客积分: 1927
  • 博客等级: 上尉
  • 技术积分: 932
  • 用 户 组: 普通用户
  • 注册时间: 2010-08-31 14:06
文章分类

全部博文(124)

文章存档

2018年(5)

2017年(2)

2016年(6)

2015年(4)

2014年(24)

2013年(7)

2012年(11)

2011年(13)

2010年(52)

我的朋友

分类: LINUX

2010-09-30 14:00:04

linux 2.6.20
??
??关于mtd驱动的一些东西:
??
??驱动必须调用register_mtd_chip_driver(struct mtd_chip_driver *drv)
??将自己的驱动注册到驱动列表chip_drvs_list中,这样在接下来physmap_flash_probe-->
??do_map_probe-->get_mtd_chip_driver中才能返回正确的struct mtd_chip_driver类型值,
??才能在do_map_probe中的drv->probe中调用正确的probe函数
??
??SST39VF6401B的ID是0x236d,而datasheet上说的是0x236b
??
??因为读的话是和ram一样的,写和擦的话因为符合cfi或者jedec规范,因此内核应该自己
??就实现了,不需要自己实验.
??
??/*
?? 摘自网上
?? * nor flash的MTD驱动中,驱动作者需要定义自己的map_info结构体,并且为read/write
?? * 函数分量赋值。在write函数的实现中,大多使用__raw_writew来实现。但是向
?? * nor flash写入数据是要经过program的过程的,不能像写内存一样写入。而且nor flash
?? * 的底层读写函数实际上是在cfi_cmdset_0001/2.c中实现的,并且被赋给mtd_info的
?? * read/write分量。
?? */
??
??因为在启动linux的时候,从启动信息中发现了nor flash并没有被检测到,说明linux里面
??并没有对这个块at91rm9200的板子进行nor flash的驱动进行移植。因此,以下为我浏览内
??核中的nor flash中的一些心得。整个过程一直prink,然后编译内核......
??
??1,首先,根据板子上的nor flash 芯片SST39VF6401B来配置好board-dk.c里面的相应的宏,
?? #define DK_FLASH_BASE AT91_CHIPSELECT_0
?? #define DK_FLASH_SIZE 0x800000 //8MB的flash
?? 可以在这个文件看到定义的 struct resource dk_flash_resource,表明了nor flash在
?? 内核里的设备资源结构体;struct physmap_flash_data dk_flash_data,表明了这里是
?? 将nor flash看成physmap_flash来对待的,与nand flash不同,nand_flash的被当成了
?? struct at91_nand_data __initdata dk_nand_data,该结构体传递给
?? at91rm9200_devices.c中的at91_add_device_nand()作为参数,放在了 struct
?? platform_device at91rm9200_nand_device结构体中,而nor flash的 platform_device
?? 的相应的变量定义在board-dk.c中,为 struct platform_device dk_flash,该结构体
?? 包括了resource结构体(设备资源)、name(设备名字)和platform_data = dk_flash_data
?? (类型为 struct physmap_flash,为nor flash的一个配置)。
??
??2,接着在board-dk.c里面的板子初始化函数里面就调用了
?? platform_device_register(&dk_flash); 将该设备的platform_device结构体添加到了内
?? 核的设备列表中了;
??
??3,nor flash在内核中的驱动有两种,一个是cfi_chipdrv,一个是jedec_chipdrv。两种驱动
?? 在我的配置中都在系统时加载了,分别可以在 drivers/mtd/chips/cfi_probe.c 中的
?? int __init cfi_probe_init()和drivers/mtd/chips/jedec_probe.c 中的
?? int __init jedec_probe_init()中发现,都调用了
?? register_mtd_chip_driver(struct mtd_chip_driver *) 在内核中注册了这两个驱动。
??
??4,而真正与nor flash的platform_device对应的platform_driver是定义在
?? drivers/mtd/maps/physmap.c中,为 struct platform_driver physmap_flash_driver。
?? 该结构体中定义了驱动的名字(name),该变量应该与先前已经通过调用
?? platform_device_register()注册到内核设备列表中的nor flash设备的那个
?? struct platform_device dk_flash中的名字一样,这样physmap驱动才能在内核设备列表
?? 中找到相应的设备以获得设备的资源等信息;同时该结构体中有定义了probe函数,该函数
?? 会在platform_driver_register()中被调用,来侦测硬件设备。该驱动在系统启动时被加
?? 载,驱动模块的初始化函数为 int __init physmap_init(),该函数中调用
?? platform_driver_register(struct platform_drier *)来注册驱动。
??
??5,在 platform_driver_register()注册过程中,会调用参数结构体中的probe函数来侦测
?? 硬件设备,这里为physmap.c中的
?? int physmap_flash_probe(struct platform_device *dev),其中函数的参数为在该
?? probe函数被调用前,在platform_driver_register()中通过platform_driver结构体中的
?? name变量与内核设备列表中已注册了的platform_device的结构体中的name进行匹配,从
?? 而得到的platfor_device。因此,如果platform_device和platform_driver中的name不
?? 一致的话,驱动是不会可能加载成功的。
??
??6,在驱动的侦测函数physmap_flash_probe()中,比较重要的结构体为physmap_flash_info
?? 结构体和physmap_flash_data结构体。其中physmap_flash_info中包含了很重要的信息,
?? 包括了: struct mtd_info *, struct map_info, struct resource,如果有分区的话,
?? 还有 struct mtd_partition *。首先先根据得到的platform_device结构体,将设备
?? 硬件信息设置到驱动结构体中去,即初始化physmap_flash_info中的各个成员。然后,
?? 调用 do_map_probe(char *name, struct map_info *map)来进行实质性的侦测。其中的
?? 参数 name 来自physmap.c中的字符串数组 char *rom_probe_types[]; 这里有三个成员,
?? 表示三种类型的nor flash,分别为"cfi_probe", "jedec_probe"和"map_rom",数组以
?? NULL表示结束。其实已经知道我们的nor flash SST39VF6401B为jedec类型的了,那么
?? 接下来就直接讲解jedec类型的侦测了,虽然前面有进行了cfi类型的侦测。另一个参数
?? struct map_info *map则是此前根据硬件信息初始化好的结构体,该结构体在mtd体系
?? 中扮演着十分重要的角色。
??
??7,do_map_probe()定义在drivers/mtd/chips/chipreg.c中,看名字有知道是和芯片注册
?? 相关的一个函数。该函数中有两个主要的结构体: struct mtd_chip_driver *,
?? struct mtd_info *,都是mtd体系中的重要角色。首先,函数调用get_mtd_chip_driver
?? 函数来取得mtd_chip_driver的指针,而name参数则是上面rom_probe_types中的成员,
?? 这里就以"jedec_probe"来说明。其实和platform_device和platform_driver这中
?? platform系的驱动一样,也是通过name匹配来找到彼此的。这里就通过"jedec_probe"
?? 这个名字找到了mtd_chip_driver类型的驱动。而这个驱动是在"3"中说明了的,已经在
?? 系统启动时已经通过调用register_mtd_chip_driver()在内核中注册好了的
?? jedec_chipdrv。
??
??8,在得到了jedec_chipdrv这个驱动结构体指针之后,随即调用该驱动的probe函数,这个
?? probe函数定义了driver/mtd/chips/jedec_probe.c中,为
?? struct mtd_info *jedec_probe(struct map_info *map),这个是在驱动结构体里的
?? probe变量中指定了的。这个函数很干脆,直接就调用了.../gen_probe.c中定义的通
?? 用的侦测函数 struct mtd_info *mtd_do_chip_probe(struct map_info *map,
?? struct chip_probe *cp),至于原因,注释上说了。
??
??9,在通用的mtd_do_chip_probe()中,有一个比较重要的结构体 struct cfi_private *cfi,
?? 这个结构体在后面的具体的侦测中有用。该函数为了分配这个结构体首先调用
?? struct cfi_private *genprobe_ident_chips(struct map_info *map,
?? struct chip_probe *cp),genprobe_ident_chips()中调用
?? int genprobe_new_chip(struct map_info *, struct chip_probe *,
?? struct cfi_private *);该函数为了配置cfi,又调用了 struct chip_probe *cp的成员
?? probe_chip来真正的侦测芯片,看看软件内的配置是否与硬件上的配置一致。这个
?? struct chip_probe *cp呢,又是在遥远的jedec_probe()函数中被传进来的参数
?? jedec_chip_probe的指针,参看"8"。这个结构体定义在jedec_probe.c中,结构体的
?? probe_chip成员指定给了 int jedec_probe_chip(struct map_info *, __u32,
?? unsigned long *, struct cfi_private *);
??
??10,这个jedec_probe_chip()函数就以符合jedec规格的侦测方法来侦测硬件了。
?? 其中base参数为nor flash的基地址,为0。首先是通过函数cfi_send_gen_cmd()将查询
?? software ID的Data 和 Addr传输给flash,然后通过jedec_read_mfr()和
?? jedec_read_id()取得了芯片的制造商代号和芯片id。然后调用jedec_match()测试是否
?? 与已有的芯片符合。这个"已有的芯片"指的是该文件内定义的超长的数组
?? struct amd_flash_info jedec_table[]。该数组的类型结构体定义了各个制造商的各种
?? 芯片。(唉,AMD和Intel就搞两个标准,烦)。因为内核源码中没有定义这个板子上用的
?? SST39VF6401B,所以要按照格式(有这么多呢)将参数添加进一个数组成员。如下:
?? }, {
?? .mfr_id = MANUFACTURER_SST,
?? .dev_id = SST39VF6401,
?? .name = "SST 39VF6401",
?? .uaddr = {
?? [0] = MTD_UADDR_0x5555_0x2AAA,
?? [1] = MTD_UADDR_0x5555_0x2AAA
?? },
?? .DevSize = SIZE_8MiB,
?? .CmdSet = P_ID_AMD_STD,
?? .NumEraseRegions= 1,
?? .regions = {
?? ERASEINFO(0x1000, 2048)
?? }
?? 同时,要在一堆的宏定义里面找到 SST的里面添上宏:
?? #define SST39VF6401 0x236d
?? 这个0x236d即为芯片的id,从datasheet中可以知道,同时会在侦测中与从芯片里得到的
?? id进行匹配。但是datasheet看到的是0x236b,不是这个,不知道为什么。
??
??11,在jedec_match()中将从硬件得到的mfc和id与那个巨大的数组内的各个成员进行匹配
?? 以及进行一些测试。符合要求之后返回之后,就算找到了硬件了,之后进行的东西就是
?? 在内核里面设置好合适的结构体了,然后玩成了physmap这个驱动的注册。完成注册后,
?? 应该就完成了mtd系统中的相关设置(我不确定),关于后面如何使用驱动这个就暂不讲了。
??
??plus: 在"11"里面,完成硬件侦测之后,会在gen_probe.c中调用check_cmd_set(),该函数
?? 中再根据条件调用不同的函数来设置mtd_info结构体里的各种函数,包括read,
?? write, erase等成员。这里的转到了cfi_cmdset_0002.c里面的cfi_cmdset_0002()函
?? 数,再调用cfi_amdstd_setup。
??
?? /* 可能底层的读写函数定义在map.h */
?? 可能是inline_map_read, inline_map_write
?? mtd的write, read完成时序,比如cfi_amdstd_write_words,并且在该过程中调用
?? map的read, write完成总线送数据,比如map_read。
阅读(2285) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~