转载_linux中at91rm9200板子nor flash驱动添加及心得

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。