Linux下读写FLASH驱动——MTD设备分析

转载 2013年12月04日 16:36:41
Linux下读写FLASH驱动——MTD设备分析
 

       最近在学习驱动读写flash的代码部分。经历了可笑的过程:开始我知道flash用通过spi口来读写。所以就到了driver/spi 下面看相关代码。发现有个spidev.c里面有read/write/ioctl等函数。而且还有一个davinci_spi_master.以为调用spi驱动的时候会首先调用到这里,于是就想怎么在上层应用里将spidev.c里open调用到就可以了。最后修改了一些地方就在应用的地方打开了这个字符设备驱动。在dev下面生成了dev/spidev0.0目录。于是打开它还调用到了spidev.c里的相关函数。甚是窃喜,但突然发现这个跟我要读写的flash又有什么关系呢?flash芯片型号是:m25p40。知道了又怎么样?我该如何读写它呢。后来突然在网上看了这么一段话MTD(memory technology device内存技术设备)是用于访问memory设备(ROM、flash)的Linux的子系统。MTD的主要目的是为了使新的memory设备的驱动更加简单,为此它在硬件和上层之间提供了一个抽象的接口。MTD的所有源代码在/drivers/mtd子目录下。我将CFI接口的MTD设备分为四层(从设备节点直到底层硬件驱动),这四层从上到下依次是:设备节点、MTD设备层、MTD原始设备层和硬件驱动层。(http://blog.csdn.net/binghuiliang/archive/2008/01/23/2060794.aspx)郁闷之余看到了这样的信息,发现原来flash不是要注册一个什么spi设备,而是要通过mtd设备来读取后来在dev/mtd/devices文件夹里看到了m25p80.c这个代码。打开发现里面是对这一类flash驱动的支持代码。天哪怎么回事,后来就又看了里面的函数有read/write/probe函数但是没有发现open函数,甚是烦恼。不知道open函数哪里去了。是不是probe代替了呢??同时也没有发现ops这样的文件操作结构体。问题出现了。


       参看高手说在应用里要 system("flash_eraseall /dev/mtd4");spi_fd =open("/dev/mtd4",O_RDWR, 0);
这么调用,而mtd4在哪里注册的我就不知道了。现在还在寻找中。read和write都是调用到了m25p80.c里函数。下面具体说一下如何添加m25p80.c驱动吧。

步骤如下:
1、make menuconfig里选择MTD/下相应的选项。内核已经配好了。
2、修改arch/arm/mach-davinci下面的davinci_spi_platform.c 在里面加入
static struct flash_platform_data davinci_m25P40_info =
{
   .name = "m25p80",
   .parts = NULL,
   .nr_parts = 0,
   .type = "m25p40",
};
static struct spi_board_info dm6467_spi_board_info[] = {
{
   // SPI FLash
   .modalias = "m25p80",
   .platform_data = &davinci_m25P40_info,
   .mode = SPI_MODE_0,
   .irq = 0,
   .max_speed_hz = 4 * 1000 * 1000, /*4MHZ*/
   .bus_num = 0,
   .chip_select = 0, // device number on bus (0-based)
},

};


然后编译重新编译内核之后就可以发现在dev目录下多了一个dev/mtd4设备节点。这里面有很多奇怪的地方。不知道这个mtd4是怎么生成的。像那个spidev0.0设备节点是因为在文件spidev.c里有赋值给主设备和从设备的地方,而这个在m25p80.c里并没有发现任何迹象,只是看到在probe里加进了add_mtd_partitions()函数,还有这样的语句:
flash->mtd.erase = m25p80_erase;
flash->mtd.read = m25p80_read;
flash->mtd.write = m25p80_write;
然后继续查找probe最后到了那里:
static struct spi_driver m25p80_driver = {
.driver = {
   .name = "m25p80",
   .bus = &spi_bus_type,
   .owner = THIS_MODULE,
},
.probe = m25p_probe,
.remove = __devexit_p(m25p_remove),
};
貌似这里又用probe来注册了spi_driver结构体。而最后的init和exit函数都用了spi注册。晕倒!那怎么最后是open设备mtd4呢。这中间到底发生了什么?
这里只能说mtd设备利用了spi总线来达到注册自己设备的目的。而这个mtd设备在本质上是一个字符设备。
在板子登陆的内核信息里截获到以下信息:
call video_register_device() in file videodev.c
call video_register_device() in file videodev.c
call adv7343_initialize()
ad9889_i2c_init() OK!
i2c /dev entries driver
nand_davinci nand_davinci.0: Using soft ECC
info->emifregs = 0xc8008000,EMIF_A1CR = 0x3ffffffc
info->emifregs = 0xc8008000,EMIF_A1CR = 0x88442a8
/*****************************************************************************/
mtd->writesize(pagesize)=2048
mtd->oobsize=64
mtd->erasesize(blocksize)=0x20000
/*****************************************************************************/
NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 3,3V 8-bit)
Scanning device for bad blocks
chip_delay = 30
Creating 4 MTD partitions on "nand_davinci.0":
0x00000000-0x000e0000 : "bootloader"
0x000e0000-0x00100000 : "params"
0x00100000-0x004a0000 : "kernel"
0x004a0000-0x08000000 : "filesystem"
nand_davinci nand_davinci.0: hardware revision: 2.2
Enter into m25p_probe
m25p80 spi0.0: m25p40 (512 Kbytes)
dm_spi.0: davinci SPI Controller driver at 0xc8002800 (irq = 43) use_dma=1
pcf8563 0-0051: chip found, driver version 0.4.2
上面的Enter into m25p_probe 是在m25p80.c里probe函数打印出来的。这么早就打印了而不是open时候才调用probe是在内核加载时就调用了。
可见这块板子是用的nandflash并把它分成四部分:bootloader、代码、内核、文件系统。而m25p80 spi0.0: m25p40 (512 Kbytes)这一句更是
经典,是说生成了m25p80 spi0.0的一个设备m25p40吧,猜的呵呵。

       现在发现mtd字符设备都在mtd/mtdchar.c里注册,于是就怀疑是不是open调用到了这里呢,于是打印验证后发现open("/dev/mtd4",O_RDWR, 0);调用到mtdchar.c程序里open函数,那为什么read和write却是调用到m25p80.c呢,这里的read有没有调用到呢?这就更奇怪了,是不是mtd自己有一套机制让打开字符设备的语句直接去打开mtdchar.c的open然后再具体针对某个设备来读写。这也不对呀,open返回的是mtd4的设备号啊。
       哈哈,测试了一下原来同样会调用到mtdchar里read和write。m25p80.c里的read和mtdchar.c里的read函数,这个逻辑是怎么回事?
       为了查找这个根据我看了:mtdchar.c里mtd_read函数,最后终于明白了:
这个函数的基本功能是:


格式:static ssize_t mtd_read(struct file *file, char *buf, size_t count,loff_t *ppos)

功能:MTD字符设备的读操作

说明:

      count>0{

             裁减本次操作大小lenmin(MAX_KMALLOC_SIZE,count)

             申请一块大小为MAX_KMALLOC_SIZE的内核空间kbuf

             调用mtd_info->readMTD设备中的数据读入kbuf

             kbuf中的数据拷贝到用户空间buf

              count自减

             释放kbuf

       }

参数:

file:系统给MTD字符设备驱动程序用于传递参数的file结构,此函数通过file得到下

层的MTD设备

       buf:用户空间的指针,用于存放读取的数据

       count:被读数据的长度

       ppos:被读数据在MTD设备中的位置

返回:

      成功:返回实际读取数据的长度

      失败:返回错误码

调用:

       mtd_info->read()用于从MTD设备中读取数据

被调用:

      被注册进mtd_fops结构

源代码:
static ssize_t mtd_read(struct file *file, char __user *buf, size_t count,loff_t *ppos)
{
struct mtd_file_info *mfi = file->private_data;
struct mtd_info *mtd = mfi->mtd;
size_t retlen=0;
size_t total_retlen=0;
int ret=0;
int len;
char *kbuf;

DEBUG(MTD_DEBUG_LEVEL0,"MTD_read\n");

if (*ppos + count > mtd->size)
   count = mtd->size - *ppos;

if (!count)
   return 0;

/* FIXME: Use kiovec in 2.5 to lock down the user's buffers
    and pass them directly to the MTD functions */

if (count > MAX_KMALLOC_SIZE)
   kbuf=kmalloc(MAX_KMALLOC_SIZE, GFP_KERNEL);
else
   kbuf=kmalloc(count, GFP_KERNEL);

if (!kbuf)
   return -ENOMEM;

   printk("mtd_read called!!000000000000000\n");
while (count) {

   if (count > MAX_KMALLOC_SIZE)
    len = MAX_KMALLOC_SIZE;
   else
    len = count;

   switch (mfi->mode) {
   case MTD_MODE_OTP_FACTORY:
    ret = mtd->read_fact_prot_reg(mtd, *ppos, len, &retlen, kbuf);
    break;
   case MTD_MODE_OTP_USER:
    ret = mtd->read_user_prot_reg(mtd, *ppos, len, &retlen, kbuf);
    break;
   case MTD_MODE_RAW:
   {
    struct mtd_oob_ops ops;

    ops.mode = MTD_OOB_RAW;
    ops.datbuf = kbuf;
    ops.oobbuf = NULL;
    ops.len = len;

    ret = mtd->read_oob(mtd, *ppos, &ops);
    retlen = ops.retlen;
    break;
   }
   default:
    printk("mtd_read called!!111111111111\n");
    ret = mtd->read(mtd, *ppos, len, &retlen, kbuf);
   }
   /* Nand returns -EBADMSG on ecc errors, but it returns
   * the data. For our userspace tools it is important
   * to dump areas with ecc errors !
   * For kernel internal usage it also might return -EUCLEAN
   * to signal the caller that a bitflip has occured and has
   * been corrected by the ECC algorithm.
   * Userspace software which accesses NAND this way
   * must be aware of the fact that it deals with NAND
   */
   if (!ret || (ret == -EUCLEAN) || (ret == -EBADMSG)) {
    *ppos += retlen;
    if (copy_to_user(buf, kbuf, retlen)) {
     kfree(kbuf);
     return -EFAULT;
    }
    else
     total_retlen += retlen;

    count -= retlen;
    buf += retlen;
    if (retlen == 0)
     count = 0;
   }
   else {
    kfree(kbuf);
    return ret;
   }

}
        printk("mtd_read called!!2222222222222222\n");
kfree(kbuf);
return total_retlen;
} /* mtd_read */
注意到里面这一句:ret = mtd->read(mtd, *ppos, len, &retlen, kbuf);这个是调用MTD原始设备层的mtd.read函数了。
而我们再回头看看m25p80.c里probe函数里语句:
flash->mtd.erase = m25p80_erase;
flash->mtd.read = m25p80_read;
flash->mtd.write = m25p80_write;
这个就是给mtd结构体赋初值的地方。原来是这么联系起来的。晕倒!
从上面的解释可以看到这个函数
1、先申请一块大小为MAX_KMALLOC_SIZE的内核空间kbuf,

2、调用mtd->read将MTD设备中的数据读入kbuf,

3、将kbuf中的数据拷贝到用户空间buf


       可以看到,原来如此mtd是通过这些层次关系来调用底层mtd设备(m25p80.c)的数据来的。这又让我想起了视频video驱动里v4l2层次了。原来复杂的内核哪里都少不了这种层次的调用。这样的话m25p80.c没有open和ops结构体也正常了,因为在mtdchar.c里都已经做好了啊。同样在mtdchar.c里mtd_write()函数也看到了
           ret = (*(mtd->write))(mtd, *ppos, len, &retlen, kbuf);
这样的语句就是调用m25p80.c的m25p80_write函数的语句。现在情况就一目了然了。



小结:原来我们要对flash读取的时候就是要给它完成底层MTD原始设备(本例中的m25p40芯片)的加入(包括配置内核kconfig、makefile及davinci_spi_platform.c 改写),然后这个底层设备就会通过probe函数注册自己的mtd结构体,(struct mtd_file_info *mfi = file->private_data;struct mtd_info *mtd = mfi->mtd;)。然后中间的mtd设备层才能够调用这个底层设备的数据,诸如:mtdchar.c里的read、write调用。最终完成擦写具体flash的目的。上层的应用程序要继续研究。而设备节点代表了具体的一个mtd设备我们加载了m25p80.c以后在dev目录下就出现了mtd4这个设备。(至于为什么是mtd4就需要继续学习了)。


norflash驱动编写

首先我们来看代码: /* *参考drivers\mtd\maps\physmap.c */ #include #include #include #include #incl...
  • zuijinzhao
  • zuijinzhao
  • 2012年09月25日 10:24
  • 3065

NAND FLASH 驱动

三星的nand flash 驱动架构是相当的复杂,虽然说,对驱动的架构大致了解,就可以按照韦东山老师的视频,一步步写出nandflash的驱动,但这样虽然写出来,心中仍有点不踏实。下面就对linux-...
  • Dreaming_My_Dreams
  • Dreaming_My_Dreams
  • 2012年08月18日 20:21
  • 1652

spi flash驱动代码分析(一)

一、       spi_flash uboot驱动的一个应用实例 1.      spi应用程序在操作之前调用spi_flash_probe去初始化spi_flash 2.      初始化完毕即可...
  • gujintong1110
  • gujintong1110
  • 2015年07月17日 18:19
  • 2827

运行成功的读写MTD的测试程序

#include #include #include #include #include #include #include #include #include s...
  • melody157398
  • melody157398
  • 2012年05月28日 19:25
  • 3959

Linux移植添加norflash MTD分区

开发板上只有Nor Flash,所以为了实现层次文件系统,需要为Linux2.6.20增加Nor Flash MTD驱动支持。其实工作量并不大,因为已经有现成的程序可供参考。       MTD的...
  • shanzhizi
  • shanzhizi
  • 2014年01月23日 16:33
  • 4396

使用linux的MTD tests support测试flash性能

在嵌入式linux开发过程中,经常会使用到nor flash,nand flash等存储设备,由于flash的芯片型号和接口类型较多,性能不一,我们需要对系统中使用的flash性能进行分析,并对设备工...
  • gp_scoprius
  • gp_scoprius
  • 2016年12月02日 14:56
  • 1372

使用linux的MTD tests support测试flash性能

本文为gp_scorpius原创文章:http://blog.csdn.net/gp_scoprius/article/details/53257056 在嵌入式Linux开发过程中...
  • u010445505
  • u010445505
  • 2017年04月25日 16:08
  • 300

Linux系统中/dev/mtd与/dev/mtdblock的区别

无论以x86平台下面的grub还是ARM、MIPS下的uboot来启动内核,多需要在启动参数中设定根文件在硬盘(flash)上面的分区位置。 由于目前要对此更新openwrt上面的系统,因此就涉及到...
  • suiyuan19840208
  • suiyuan19840208
  • 2014年07月28日 19:38
  • 5379

linux 对MTD分区nand flash的烧写和读取

使用mtd-utils工具实现对flash的升级分区的烧写yaffs2 yaffs2的格式是根据所使用的nandflash来制作的,不同的nandflash,得到的yaffs2是不一样的,具体可以参...
  • liqinghan
  • liqinghan
  • 2016年06月01日 22:08
  • 2428

个人总结 - m25p80.c debug on Micron spi nor_flash.pdf

  • 2017年09月04日 15:23
  • 406KB
  • 下载
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Linux下读写FLASH驱动——MTD设备分析
举报原因:
原因补充:

(最多只允许输入30个字)