一个朋友的问题，我们共同分析后搞定。其实以前也遇到过同样问题，时间长了，没总结。
事发：在Nand Flash上使用2.6.14的linux kernel，三星2440的板子，连续写入文件，到一定大小限制就删除，文件写入没有超过flash保留10%的空闲，应该说还差很多。
第一步，不适用syslog写，换做自己写代码写入，出现几率降低；
第二步，fwrite换成write，几率增加，很快就坏。
坏的时候提示：yaffs tragedy: no more eraased blocks !!!!!!!!! Allocator out !!!!!!!!!!!!!!!!!
重新启动，就会标出很多坏块（bad block...），当然是假的，一格式化，就好。
第三步，朋友说用2.6.34的内核，没有问题，但从14移到34，需要修改的驱动之类太多，数据结构变化太大。
第四步，我想起以前说起nand时候mtd校验和yaffs校验不能同时开启。
第五步，让在14内核上关闭yaffs软校验，开启mtd nand硬件校验，出现：mtd ecc error unfixed on chunk 26784
第六步，14内核，关闭mtd nand硬件校验，使用yaffs软校验，出现： VFS: Mounted root (cramfs filesystem) readonly. Mounted devfs on /dev Freeing init memory: 108K Error -3 while decompressing! c02ccb50(312)->c3cc0000(4096) Failed to execute /linuxrc. Attempting defaults... Kernel panic - not syncing: No init found. Try passing init= option to kernel.
然后，想了想。
34可以，14同样的配置不可以，应该是软件差异。查看14下yaffs的版本，挺老。朋友说34下的yaffs拿过去编译无法通过。
我从这边使用的18内核抠出来yaffs部分给他，这个yaffs是：
Id: yaffs_mtdif.c,v 1.22 2009/03/06 17:20:51 wookey Exp $";
编译，还是有一个头文件（linux/uaccess.h）找不到，屏蔽之，OK。
再编译，使用mtd的硬nand ecc，关闭yaffs own ecc，测试，OK，写文件OK，写入断电 OK。
总结：主要就是两种ECC冲突的事情，yaffs官网上写道：
Nand interface: For yaffs to function, it must be able to be the only code that writes to the oob area on the NAND device. The existing NAND driver in kernel 2.4.19 assumes that it will do the ecc/oob management for the host fs. For yaffs, this is quite wrong. You can disable ecc/oob calculations either by hand patching the mtd code to bypass ecc calculations or by merging the latest mtd cvs.
当然这针对2.4的内核，莫非2.6也涛声依旧？
)
