Ian McDonnell,
Thanks for the reminding, it's not safe.
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.
>
--
Best Regards!
He Yong
School of Information Security,
Shanghai Jiaotong University,
Dong cuan Road #800,
Minhang, Shanghai, P.R.China
(text/plain)