Re: Problem with clean markers/partial writes on Micron 4-bit ECC NAND

[Peter Barada <peter.barada@gmail.com>]

On 06/17/2011 05:00 PM, Ivan Djelic wrote:
> On Fri, Jun 17, 2011 at 06:52:24PM +0100, Peter Barada wrote:
> (...)
>> The problem I'm running into with JFFS2 is that empty flash is first
>> marked with a clean marker into the OOB, and then a 2nd write to the
>> main data area is done (w/o an intervening erase) to that page with data
>> which corrupts the ECCs that were first modified by writing the cleanmarker.
>>
> (...)
>> I believe I've figured out a workaround:
>>
>> 1) Modify the ecclayout to add the other 8 bytes of the OOB that are NOT
>> ECCd *after* the 16 bytes that are ECCd (so the ecc layout looks like):
>>
> (...)
>> 2) Then set ops.ooboffs to 16 in jffs2_write_nand_cleanmarker and
>> jffs2_check_nand_cleanmarker.
>>
>> This "offsets" the read/writes by 16 bytes to move the cleanmarker into
>> OOB bytes that do not perturb the ECCs, and so far it looks to work.
>>
> OK, so now the cleanmarker is in an unprotected area; did you also patch
> jffs2_check_nand_cleanmarker() so that it does its pattern comparison in a
> bitflip-robust way (instead of just doing a memcmp) ?
> I think you may also need to modify jffs2_check_oob_empty() to take into
> account the new offset of your cleanmarker.
No, I haven't yet created a bitflip-robust jffs2_check_nand_cleanmarker 
- will code up a version that calculates the number of flips between the 
expected and read markers and if less than some threshold accept it.  
I'm surprised such code isn't already in JFFS2, unless JFFS2 assumes 
that area of the OOB is already protected (and that protection is OOB-only).

>> However I feel this is a hack as our product will use two different NAND
>> chips, the other being a more traditional SLC that can use 1-bit hamming
>> for ECC (which does not ECC any bytes in the OOB).
>>
>> How can I best code this into the MTD layer such that JFFS2 (and other
>> NAND FSs that does partial writes including OOB bytes) can understand
>> that some OOB bytes perturb the data area ECC?
>>
>> I think adding a "non_ecc_oob_offset" variable to the ecclayout could
>> capture this nuance of the OOB/ECC interaction for this chip and JFFS2
>> could set ops.ooboffs to non_ecc_oob_offset in
>> jffs2_write_nand_cleanmarker and jffs2_check_nand_cleanmarker.
> I believe JFFS2 only uses oob for its cleanmarker; then, maybe you could just
> omit the ecc-protected bytes from the .oobfree list, like this:
>
>    ecclayout = {
>           eccbytes = 32,
>           eccpos = { 8, 9, 10, 11, 12, 13, 14, 15,
>                   24, 25, 26, 27, 28, 19, 30, 31,
>                   40, 41, 42, 43, 44, 45, 46, 47,
>                   56, 57, 58, 59, 60, 61, 62, 63},
>           .oobfree = {
>                   { .offset = 2,
>                     .length = 2},
>                   { .offset = 18,
>                     .length = 2},
>                   { .offset = 24,
>                     .length = 2},
>                   { .offset = 42,
>                     .length = 2},
>           },
> };
>
> and only modify jffs2_check_nand_cleanmarker() and jffs2_check_oob_empty()
> so that they are robust to bitflips in unprotected oob bytes ?
> Or are you also using on the same mtd device another filesystem requiring
> protected oob bytes, like YAFFS2 ?
Yes we are using YAFFS2 in our system so I need not only protected OOB 
bytes, but at least 16 of them for YAFFS to hold its meta data - hence 
our OOB layout.  What's nice is that the 16 currently available are ECCd 
so there's not need to ECC the YAFFS meta data (which saves time).

The issue I have is how can I best tell MTD (and FS layers on top of it) 
that some of the OOB bytes can not be used in partial writes due to 
those bytes perturbing the ECC, or how to change JFFS2 to erase the 
block after writing the cleanmarker when it wants to write data into the 
block.

Why does JFFS2 write a clean marker into the empty block?  Is it to 
cover some state transition where power could be interrupted?

> Regards,
>
> Ivan
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/


-- 
Peter Barada
peter.barada@gmail.com