the hardware ECC could only check for the 2K data and its own 36 bytes of
parity code, not for the other data in spare space. so here is the problem,

if the mini-ECC in yaffs2 is enabled, yaffs2 uses 28 bytes of spare space,
add the 36 bytes of hwecc, it's 64 bytes, there's no more space to store
the bad block mark (usually the first byte of spare space). and it causes MTD
layer to recognize the block is 'bad', but actually it's not. if we disable the bad block
check in MTD, then how can we know if a block is bad? since I haven't find any
ext tags in yaffs2 that tells a block is bad.

I think it's not necessary to use the mini-ECC when having a stronger hardware ECC,
the only reason we must keep it is to make sure the ext tags in oob/spare is correct,
so I started to think about writing a simpler CRC check only for the ext tags, this may
work faster and take less spare bytes than mini-ECC, so that I can leave the first 2 bytes
for bad block mark.

Thanks!

-- He Yong

2007/7/4, ian@brightstareng.com < ian@brightstareng.com>:

He,

On Tuesday 03 July 2007 01:42, He Yong wrote:
> I get yaffs2 working without ECC tags ( struct
> (yaffs_ECCOther) ). Now, yaffs2 only takes 12 bytes of Nand
> spare area, and our HWECC has enough space to store 36 bytes
> of parity code. Thanks!

So are you saying that the underlying hardware has some form
of ECC check/correction not only for the pages primary data (2k
bytes), but also for the spare/oob/tags data as written/read by
the application (mtd/yaffs)? If not, simply dropping the
mini-ecc is not so safe.

Thanks for the patch.