平台:mini2440 128M的板子
UBOOT：论坛置顶中支持128M mini2440的U-boot现已发布(感谢Tekkaman  Ninja提供)提供的U-BOOT-2009.08补丁做成.


首先说明一下,在用这个UBOOT下的nand write.yaffs命令烧写几次都失败的情况下，我只好将板子设置到NOR启动，用官方的SURPERVIVI中的Y选项下载YAFFS根文件系统。
下载后，可以正常的加载mount上。

下面是UBOOT下烧写时的串口信息：
[u-boot@MINI2440]# tftp 0x31000000 root_ser.bin
dm9000 i/o: 0x20000300, id: 0x90000a46
DM9000: running in 16 bit mode
MAC: 08:08:11:18:12:27
operating at 100M full duplex mode
Using dm9000 device
TFTP from server 192.168.0.1; our IP address is 192.168.0.2
Filename 'root_ser.bin'.
Load address: 0x31000000
Loading: *T #################################################################
     #################################################################
     #################################################################
     #################################################################
     #################################################################
     #################################################################
     ###########################################
done
Bytes transferred = 6350784 (60e7c0 hex)
[u-boot@MINI2440]# nand erase 0x260000 0x800000
NAND erase: device 0 offset 0x260000, size 0x800000

Erasing at 0x26000000000008 --   0% complete.
Erasing at 0x28000000000008 --   0% complete.
Erasing at 0x2a000000000008 --   0% complete.
Erasing at 0x2c000000000008 --   0% complete.
Erasing at 0x2e000000000008 --   0% complete.
Erasing at 0x30000000000008 --   0% complete.
Erasing at 0x32000000000008 --   0% complete.
Erasing at 0x34000000000008 --   0% complete.
Erasing at 0x36000000000008 --   0% complete.
Erasing at 0x38000000000008 --   0% complete.
Erasing at 0x3a000000000008 --   0% complete.
Erasing at 0x3c000000000008 --   0% complete.
Erasing at 0x3e000000000008 --   0% complete.
Erasing at 0x40000000000008 --   0% complete.
Erasing at 0x42000000000008 --   0% complete.
Erasing at 0x44000000000008 --   0% complete.
Erasing at 0x46000000000008 --   0% complete.
Erasing at 0x48000000000008 --   0% complete.
Erasing at 0x4a000000000008 --   0% complete.
Erasing at 0x4c000000000008 --   0% complete.
Erasing at 0x4e000000000008 --   0% complete.
Erasing at 0x50000000000008 --   0% complete.
Erasing at 0x52000000000008 --   0% complete.
Erasing at 0x54000000000008 --   0% complete.
Erasing at 0x56000000000008 --   0% complete.
Erasing at 0x58000000000008 --   0% complete.
Erasing at 0x5a000000000008 --   0% complete.
Erasing at 0x5c000000000008 --   0% complete.
Erasing at 0x5e000000000008 --   0% complete.
Erasing at 0x60000000000008 --   0% complete.
Erasing at 0x62000000000008 --   0% complete.
Erasing at 0x64000000000008 --   0% complete.
Erasing at 0x66000000000008 --   0% complete.
Erasing at 0x68000000000008 --   0% complete.
Erasing at 0x6a000000000008 --   0% complete.
Erasing at 0x6c000000000008 --   0% complete.
Erasing at 0x6e000000000008 --   0% complete.
Erasing at 0x70000000000008 --   0% complete.
Erasing at 0x72000000000008 --   0% complete.
Erasing at 0x74000000000008 --   0% complete.
Erasing at 0x76000000000008 --   0% complete.
Erasing at 0x78000000000008 --   0% complete.
Erasing at 0x7a000000000008 --   0% complete.
Erasing at 0x7c000000000008 --   0% complete.
Erasing at 0x7e000000000008 --   0% complete.
Erasing at 0x80000000000008 --   0% complete.
Erasing at 0x82000000000008 --   0% complete.
Erasing at 0x84000000000008 --   0% complete.
Erasing at 0x86000000000008 --   0% complete.
Erasing at 0x88000000000008 --   0% complete.
Erasing at 0x8a000000000008 --   0% complete.
Erasing at 0x8c000000000008 --   0% complete.
Erasing at 0x8e000000000008 --   0% complete.
Erasing at 0x90000000000008 --   0% complete.
Erasing at 0x92000000000008 --   0% complete.
Erasing at 0x94000000000008 --   0% complete.
Erasing at 0x96000000000008 --   0% complete.
Erasing at 0x98000000000008 --   0% complete.
Erasing at 0x9a000000000008 --   0% complete.
Erasing at 0x9c000000000008 --   0% complete.
Erasing at 0x9e000000000008 --   0% complete.
Erasing at 0xa0000000000008 --   0% complete.
Erasing at 0xa2000000000008 --   0% complete.
Erasing at 0xa4000000000008 --   0% complete.
OK

[u-boot@MINI2440]# nand write.yaffs 0x31000000 0x260000 0x60e7c0

NAND write: device 0 offset 0x260000, size 0x60e7c0
Skip the first good block 26000000020000

Writing at 0x28000000020000 --

到这里不动了,等几秒钟,板子自动重启.

计算了一下,YAFFS根文件系统境像的大小也是符合2112的整数倍要求的.Bytes transferred = 6350784 (60e7c0 hex)

有哪位朋友知道这是什么情况么?个人感觉nand erase那步有点怪异，为啥全是提示0%complete呢？
难道这个uboot-2009.08的PACTH中，nand FLASH驱动部分还是有问题？还没具体的看过，我后面也会具体的看下的，有结果了也会贴出来。
有知道原因的朋友，也麻烦告诉下。。谢谢了！

我是一下就重启

我的也是同样情况啊。差不多一秒的样子，马上上重启了。。

为什么不看一眼你打的补丁呢？很明显，这段u-boot-2009.08_yaffsimg.patch里的代码只适用于512 page size +16 oob size的NAND Flash.在2048 page size + 64 oob size的NAND Flash上会因为oobtemp[16]溢出而出现crash。

复制代码 diff -uaNr u-boot-2009.08/drivers/mtd/nand/nand_base.c u-boot-2009.08_tekkaman/drivers/mtd/nand/nand_base.c --- u-boot-2009.08/drivers/mtd/nand/nand_base.c    2009-09-01 01:57:42.000000000 +0800 +++ u-boot-2009.08_tekkaman/drivers/mtd/nand/nand_base.c    2009-10-28 21:19:23.000000000 +0800 @@ -1958,7 +1958,30 @@ {      struct nand_chip *chip = mtd->priv;      int ret; - +#if defined(ENABLE_CMD_NAND_YAFFS) +    /*Thanks for hugerat's code!*/ +    // +    int oldopsmode = 0; +    if(mtd->rw_oob==1)    { +        size_t oobsize = mtd->oobsize;  // +        size_t datasize = mtd->writesize; +        int i = 0; +        uint8_t oobtemp[16]; +        int datapages = 0; +        datapages = len/(datasize); // +        for(i=0;i<(datapages);i++)    { +            memcpy((void *)oobtemp, +                (void *)(buf+datasize*(i+1)), +                oobsize); +            memmove((void *)(buf+datasize*(i+1)), +                (void *)(buf+datasize*(i+1)+oobsize), +                (datapages-(i+1))*(datasize)+(datapages-1)*oobsize); +            memcpy((void *)(buf+(datapages)*(datasize+oobsize)-oobsize), +                (void *)(oobtemp), +                oobsize); +        } +    } +#endif      /* Do not allow reads past end of device */      if ((to + len) > mtd->size)          return -EINVAL;

我的是64M的板子

kasim大侠说得很对...昨晚我也用beyond compare比较了一下.开始以为是mtd->oobsize这个参数传递有问题,后来跟踪了一下代码,第一次用uboot对这个结构很不熟悉,有些慢.. 后面发现这些参数都是根据分析FLASH型号而得出的,而那部分代码并没有被修改,所以应该没问题.  不好意思啊,kasim大侠,这样的问题,细心一些,应该能发现的..sorry!!!  
tekkman 大侠把这个uint8_t oobtemp[16];定义成uint8_t oobtemp[mtd->oobsize];的话,就更有结构性了.

既然已经发现问题了，写个补丁解决它吧，也算是为Open Source社区做点贡献，谢谢了！^_^

刚到家,把代码修改了一下,下到板子上跑了试试,没问题了.
+    if(mtd->rw_oob==1)    {
+        size_t oobsize = mtd->oobsize;  //
+        size_t datasize = mtd->writesize;
+        int i = 0;
+        uint8_t oobtemp[16];
+        int datapages = 0;
+        datapages = len/(datasize); //
+        for(i=0;i<(datapages);i++)    {
+            memcpy((void *)oobtemp,
+                (void *)(buf+datasize*(i+1)),
+                oobsize);
就改了kasim大侠提到的那一行，
uint8_t oobtemp[16];
改成了：
uint8_t oobtemp[oobsize];就OK了。。。。
至于补丁嘛，由于tekkman对这个u-boot-2009.08后面又出了几个添加了新功能的补丁，我这里就不出了。
另外我也告诉他了，他说很快会出新的补丁来修正的。
等不及的朋友，可以先按我说的手动修改这一处，也很快捷。