Thanks for the quick answer, I suspected the MTD<->YAFFS integration because it seems to be the part that everybody has trouble with. I don't know where to start, anyone has a working version of mtdif for kernel 2.6.17 ? =) Seriously, what are the guidelines regarding ECC? This is what I have from "mtd_debug info" on the device: mtd.type = MTD_NANDFLASH mtd.flags = MTD_CLEAR_BITS | MTD_ERASEABLE | MTD_OOB | MTD_ECC mtd.size = 104857600 (100M) mtd.erasesize = 131072 (128K) mtd.oobblock = 2048 (2K) mtd.oobsize = 64 mtd.ecctype = MTD_ECC_SW regions = 0 So I guess I should review yaffs code to make sure I don't do any ECC on YAFFS side? Am I right? Thanks again, this is heavy stuff for me and I'm almost there... Actually, when I do the triple-write method described in my previous post I end up with a RO filesystem that's as robust as it will ever get according to the tests I did, I just want to understand where the bad (retired) blocks are coming from... I tried incorporating the newer MTD into my old kernel tree but this is getting dangerous real quick and for the moment, there is no way I can upgrade the kernel, we have too many dependencies (I'm at 2.6.17.4) Boris -----Original Message----- From: yaffs-bounces@lists.aleph1.co.uk [mailto:yaffs-bounces@lists.aleph1.co.uk] On Behalf Of ian@brightstareng.com Sent: Monday, August 28, 2006 12:48 PM To: yaffs@lists.aleph1.co.uk Subject: Re: [Yaffs] yaffs: NAND not properly erased or other problems... On Monday 28 August 2006 11:27, Boris Deschenes wrote: > and then (stay with me here please). If I re-rewrite the same > files, I have absolutely no message whatsoever, the files are > written correctly to the filesystem and I can boot on the FS > and use the files perfectly.. The only thing is that all these > blocks that were retired are now marked as bad.. so I have > like 25 bad blocks on the filesystem.. > > I have the same behavior on different boards (different NAND > flash chips), I even modified a version of the flash_eraseall > to erase the bad blocks so I start with a fresh empty BBT on > the flash and I can recreate exactly the same behavior. > > So.. I would like to know what's going on here exactly? > * Do I really have that many bad blocks on all the NAND chips? Very propably not. > * Do I have trouble erasing correctly (yaffs chunk was not > erased messages)? Probably not - this may be due to the problem with integrating Yaffs with MTD successfully. See the many many postings on the subject over the last year about tags, ecc, oob, spare etc. ---- I have seen this when bringing-up yaffs/MTD on new targets or with new codebases (yaffs, mtd, kernel etc). I STRONGLY RECOMMEND that anyone experimenting with any raw NAND filesystem (including YAFFS) disable any/all permanent bad block marking until the dust settles. I also recommend that *BEFORE* you start work, you record the initial bad block list that is installed by the manufacture. This will be DIFFERENT for every chip - so assocate the list with a specific NAND part (board serial# + chip# or the like). If you then get into trouble, and accumulate large numbers of false bad-block markings, you can restore the list to the factory set. If you get into the situation where you have to force-erase large numbers of bad block markers to 'recover' a chip to continue development, be sure NOT to use these chips for any production use. Relegate the board to 'development lab junk' status. When the manufacturer tested the chip, they did so for corner cases of temperature and voltage, so just because the 'recovered' chip (block) appears to work in the lab, or on your desk, it doesn't mean it will hold data when it gets hot, cold, or in two years time. -imcd _______________________________________________ yaffs mailing list yaffs@lists.aleph1.co.uk http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs