[PATCH] Bug on atmel_nand HW ECC : OOB info not correctly written

[Richard Genoud]

2008/10/13 Haavard Skinnemoen <haavard.skinnemoen at atmel.com>:
> I have no clue, I'm afraid. What's the difference between NAND_ECC_HW
> and NAND_ECC_HW_SYNDROME?
>
> I do think I have a large page NAND flash available for testing though,
> so I can do that. Will any potential problems be easy to spot?
>
> In other words: What are the consequences of this bug?
>
> Haavard
>

The NAND_ECC_HW_SYNDROME is normally used with "non standard" ECC
controllers that need to have a complete access on the OOB area ( the
OOB pointer is given in the xxx_nand_calculate function whereas in
NAND_ECC_HW, only an ecc code pointer is given).
The read and write mechanisms are also a "little bit" more complicated
in syndrome mode, they admit ecc post-pad and pre-pad data which are
not used in our case.

The reported bug was from a small pages user :
mount -tyaffs2 /dev/mtdblock0 /mnt/part
touch /mnt/part/foo
rm /mnt/part/foo
umount /mnt/part
mount -tyaffs2 /dev/mtdblock0 /mnt/part
... and foo is still there.

the code in cause was in atmel_nand_write_oob_512, the writing start
position was pos = eccsize + chunk; instead of pos = eccsize; (eccsize
= size of a page). The OOB info was written with an offset of 4 bytes
(=chunk) and so Yaffs didn't manage to read its deleted file marker.
With this patch, the deleted files are removed.

There's the same mechanism for large pages (the at91sam9263-ek has large pages).
Today, nand_write_oob_syndrome is used and we've got pos = steps *
(eccsize + chunk); with steps = 1.
There's no reason to have an offset of 4 bytes (chunk).

I'm not sure that there will be the same bug with yaffs and large
pages, but there will certairnly be some problems.

maybe there's a way with the mtdtools to call the read/write_oob_ functions.
In this case, it would be easy to see the bug.

(I would have do it myself, but I have no board left...)

richard.