关于u-boot移植时的NAND FLASH问题

    遇到的问题是这样：u-boot无法对nand flash正常读写，总是识别出各种坏块，几乎把整块nand都当作坏块了，最明显的就是保存环境变量时，使用saveenv命令，提示擦除时遇到坏块。

    各种找原因，刚开始以为是底层驱动函数没有写好，然后就研究底层驱动开始，一点一点的理解。。。

    在这里普及一下NAND的基本知识吧，刚开始我也稀里糊涂的。

    NAND flash以页为单位读写数据，而以块为单位擦除数据。按照这样的组织方式可以形成所谓的三类地址：
　　Column Address：Starting Address of the Register. 翻成中文为列地址，地址的低8位
　　Page Address ：页地址
　　Block Address ：块地址
　　对于NAND Flash来讲，地址和命令只能在I/O[7:0]上传递，数据宽度是8位。

    我的用吧，一页有2112Bytes(2048byte(Main Area)+64byte(Spare Area))，每64个page形成一个Block，然后具体有多少个块，就视你的nand容量大小喽。。。（注意NAND FLASH在出厂时就别允许具有少量坏块）

    基本知识搞定，然后是写代码。。。根据电路原理图，写吖写，这里就不写出来了。

    可悲的是发现没有任何问题。。。

    裸奔程序能完美的操作NAND FLASH读写擦除各种HIGH。。。

    最后，只能回归研究u-boot代码了。。。

    再然后的然后，我知道了。。。

在drivers/nand目录下的nand_ids.c文件里，列出了各种NAND的属性列表。。。然后把

  {"NAND 512MiB 3,3V 8-bit",  0xDC, 512, 512, 0x4000, 0},
   改为

   {"NAND 512MiB 3,3V 8-bit", 0xDC, 0, 512, 0, 0},

   就这样改一句就把我纠结那么久的问题解决了。。。识别俺的NAND出问题了。。。

   在看代码的过程中，注意到了一点，就是每当程序运行到nand初始化的时候，都要花费非常久的时间，这直接导致u-boot启动时间大大延长，这就和我们的电脑一样，如果BIOS在引导windows时花费了很长时间，任谁都抓狂。

   刚开始我以为这些时间是花费在检测NAND的容量上，但是通过读代码，最终发现，在nand_base.c里有个函数为nand_scan()，其最后为

                    return this->scan_bbt (mtd);

   就是这个scan_bbt(mtd)，占用了这么长时间。。。然后百度了一下BBT，记录坏块的一个东东，然后我就把他抛弃了，然后这个返回变为return 0;....呱呱，启动只需一瞬间，或许我的电脑启动那么慢也是做很多无聊的事吧。。。呵呵，开个玩笑，建立BBT是非常有好处滴，自己百度吧。