All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ivan Djelic <ivan.djelic@parrot.com>
To: Peter Barada <peter.barada@gmail.com>
Cc: Eric Nelson <eric.nelson@logicpd.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Peter Barada <peter.barada@logicpd.com>
Subject: Re: Problem with clean markers/partial writes on Micron 4-bit ECC NAND
Date: Fri, 17 Jun 2011 23:00:14 +0200	[thread overview]
Message-ID: <20110617210014.GA28332@parrot.com> (raw)
In-Reply-To: <4DFB9458.1030304@gmail.com>

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.

> 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 ?
Regards,

Ivan

  reply	other threads:[~2011-06-17 21:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-17 17:52 Problem with clean markers/partial writes on Micron 4-bit ECC NAND Peter Barada
2011-06-17 21:00 ` Ivan Djelic [this message]
2011-06-18 16:37   ` Peter Barada
2011-06-18 17:49     ` Kevin Cernekee
2011-06-23  8:46 ` Artem Bityutskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110617210014.GA28332@parrot.com \
    --to=ivan.djelic@parrot.com \
    --cc=eric.nelson@logicpd.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=peter.barada@gmail.com \
    --cc=peter.barada@logicpd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.