NAND坏块的处理.docVIP

自己从第一次接触Nandflash到现在也有将近两年的时间了，从刚开始的无从下手到现在的略知一二。 回过头来看自己的学习历程，积累了很多无论你如何Google和泡坛子都学习不到的经验。现在拿出来分享给大伙，算是对集体智慧的一种回馈吧。 首先说一下Nandflash本身的一些缺陷和优势： 优势： 1，速度快。这个貌似没啥可说的，对于现在动辄上G的芯片容量，速度是必要的基础。 2，便宜。虽然赶不上硬盘，但是在嵌入式设备里面绝对是性价比杠杠的。 3，没了。除了傻快傻便宜，真没嘛优势。 劣势： 1，可靠性不高。这里所说的可靠性分为两个方面，第一是芯片出厂的时候就伴随着一定概率的缺陷。你们懂得，我说的是坏块。这个缺陷会令很多初入此行的孩纸们丢掉工作，后面会详细说。第二个是芯片使用过程中的不稳定，当然还是在说会产生坏块的问题。。。 2，不能片上运行程序。由于无法直接寻址，所以就不可能做到片上运行程序。这是很多网络上文章经常提到的一点，实际上对生活影响不大。因为现在内存便宜的很，一般的家用嵌入式设备对内存没有这么苛刻的要求。 3，芯片操作复杂。不同于norflash，nandflash没有这么容易操作。我说的操作主要是指不通过驱动程序直接靠编程完成对于flash的存取。但是我还是要说上面的话：实际上对于生活影响不大。因为目前大部分的民用嵌入式设备都有操作系统，一般为linux。linux为flash设备提供了mtd驱动层，我们对于flash的操作都被抽象成了统一的接口甚至是设备符号，无需关心底层实现。 ? 下面来说说实际使用时候的一些心得体会： ? 一，什么样nandflash分区大小是合理的？ 考虑到业务的需要，一般我们不会将整个芯片完全当作一个整体来使用。就如同你使用电脑的时候不会只给硬盘分一个区一样。主要是为了防止对分区进行改动或者重新烧录的时候会丢失全部的数据。 而如何分区才是合理的呢？我归纳主要有以下几点需要注意： 1，任意一个分区的大小不要超过操作系统所能操作内存的2/3。比如你有128M内存，linux可以支配其中的96M，那请不要将nandflash的分区设计为大于64M。 这样的考虑主要是因为，如果未来你需要升级这个分区，尤其是通过网络升级这个分区。如果你的升级方式不是增量式的，那么你必须有一段与flash分区大小一致内存空间用来存放镜像。这个时候假设你的flash分区为96M，那么你将不可能完成更新。因为你没有足够的内存空间。除非实时解压缩实时烧录，风险很高。 ? 2，分区一定要给坏块留出足够的空间。我最早接触到nandflash的时候就犯了这个错误，uboot大小200k，我给它划分的空间为256k，结果遭遇坏块，上下移动都没有空间，非常杯具。 拿目前嵌入式系统比较常用的128M nandflash，他没产生一个坏块，空间损失128k。也就是说，如果你设计分区大小为512k，遭遇两个坏块，实际空间只有256k了。 通过大量设备生产后所统计出来的结果，一般nandflash出厂的坏块基本不会超过4块。位置不固定。所以我的推荐是，如果你的某些分区容量较小，比如设计使用容量为512k，请划分该分区为1M以避免坏块。如果分区容量较大，比如60M，请划分64M。这样比较合理。 ? 3，如果被划分的分区将会使用文件系统，比如Yaffs之类，请不要划分的过小。比如你有一个分区用来存储配置文件，你认为只需要3M就可以解决问题。但实际上你会发现，这个分区只要一mount上，就已经被占用了2M，因为文件系统自己会规划出来一部分区域。你自己能操作的空间只剩下1M了，与设计目标产生巨大的冲突。请适当调整大小，并同时参考2号建议。 ? 二，如何对nandflash分区进行合理的规划？ 这里所说的规划指flash要如何进行逻辑上的区分，比如要分几个区等。 这个问题说起来比较复杂，因为不同的应用有不同的设计目标。有些提供可能简单的分两个区甚至不分区就能解决问题，而有些可能会很复杂。 这里我拿我所经手的项目举例子： 项目为iptv机顶盒，使用linux操作系统，使用uboot作为引导程序。 我的分区如下： 1M,uboot 1M,uboot-config 3M,kernel 32M,rootfs 16M,backup-rootfs 64M,apps 5M,config ? uboot如果升级失败，将会带来灾难性的后果。但是有些uboot启动的参数需要被动态的更改，所以必须要把uboot存储参数的部分与uboot分离。所以uboot被分为两个区分别存储。 ? kernel无需多说，由于附带的驱动较多3M是一个合理的数值。 ? rootfs指linux所依赖的根文件系统。包括busybox以及实现最小系统所必须的文件。 ? rootfs-backup为备