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
(text/plain)