public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Adrian Hunter <adrian.hunter@nokia.com>
To: Darwin Rambo <drambo@broadcom.com>
Cc: Artem Bityutskiy <dedekind@infradead.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: UBIFS and hardware ECC of all FF pages of MLC NAND
Date: Thu, 24 Sep 2009 16:20:36 +0300	[thread overview]
Message-ID: <4ABB7224.8000804@nokia.com> (raw)
In-Reply-To: <B125D8217ABC4B43826503DE00A2D44910D7E85DFD@SJEXCHCCR01.corp.ad.broadcom.com>

Darwin Rambo wrote:
> I have a 512 byte-at-a time hardware ECC generator that generates a particular non-FF code for 512 bytes of FF data. For a 4K MLC NAND flash, that means in the OOB, I have 8 ECCs/page.
> 
> Ubinize creates large download files which in some cases have 64 byte headers, followed by a page of FFs, and in other cases, the entire page is FFs. (I noticed that mkfs.jffs2 doesn't appear to create large blocks of FFs in the image file. In fact, by 6MB jffs2 file became 14MB when I rebuilt for UBIFS, much of the file being large blocks of FFs).
> 
> When I download and program the flash I took the decision to program the ECC even for all FF pages.
> 
> I was getting ECC corruption on startup, and eventually traced it down to UBIFS writing new data to these all FF pages, but because the FS noticed that the page was blank, didn't erase anything, and wrote data, even though the ECCs were still programmed and were non-FF. The result is that the new ECC collided with the old ECC that was there, and I got corruption of a nearby page's ECC as well as the ECC in the page that was written.
> 
> When I changed the downloader to detect all FF pages and to leave the ECC area of the OOB at FF, then UBIFS works fine.
> 
> I had originally wanted the ECC even on all FF pages since this should help stuck bit problems, even for erased all FF pages.
> 
> So the questions are
> 1. should UBIFS use the FF pattern alone as an assumption of a writable page, or should it also check the ECC?

Sorry for the slow reply.

UBIFS assumes FF pages at the end of eraseblocks are empty.  UBI and UBIFS are
designed not to require OOB and will not read or write it.

> 2. for initial downloading, should an ECC be programmed on all FF data pages? Is there any correction advantage?

In your case, as you have discovered, you must not program ECC for FF pages at
the end of eraseblocks.

> 3. for runtime page writes, should an all FF page leave the ECC at FF as well?

No.  The only time UBI or UBIFS will write an all FF page is if that is the
data to be stored - in which case, it should be given an ECC.

> 
> I apologize in advance if this particular issue has already been covered elsewhere. Thanks!

  reply	other threads:[~2009-09-24 13:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-18 21:31 UBIFS and hardware ECC of all FF pages of MLC NAND Darwin Rambo
2009-09-24 13:20 ` Adrian Hunter [this message]
2009-09-24 14:51   ` Artem Bityutskiy
2009-09-24 15:36   ` Matthieu CASTET
2009-09-25  7:05     ` Artem Bityutskiy
2009-09-29 13:26       ` Darwin Rambo
2009-09-29 15:42         ` Artem Bityutskiy
2009-09-29 16:13           ` Darwin Rambo
2009-09-29 16:20             ` Artem Bityutskiy
2009-09-29 17:03               ` Darwin Rambo
2009-10-11  8:39         ` Artem Bityutskiy
2009-10-11 14:38           ` Darwin Rambo
2009-10-11 15:04             ` Artem Bityutskiy
2009-10-11 17:36               ` Darwin Rambo

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=4ABB7224.8000804@nokia.com \
    --to=adrian.hunter@nokia.com \
    --cc=dedekind@infradead.org \
    --cc=drambo@broadcom.com \
    --cc=linux-mtd@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox