public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind@infradead.org>
To: Darwin Rambo <drambo@broadcom.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Matthieu CASTET <matthieu.castet@parrot.com>,
	Adrian Hunter <adrian.hunter@nokia.com>
Subject: RE: UBIFS and hardware ECC of all FF pages of MLC NAND
Date: Sun, 11 Oct 2009 11:39:17 +0300	[thread overview]
Message-ID: <1255250357.16942.0.camel@localhost> (raw)
In-Reply-To: <B125D8217ABC4B43826503DE00A2D44910D7F2EA60@SJEXCHCCR01.corp.ad.broadcom.com>

On Tue, 2009-09-29 at 06:26 -0700, Darwin Rambo wrote:
> A better error message would say something like:
> "UBI error: Data page incorrectly programmed to all 0xFFs with non-0xFF ECC."

Just FYI, I've created this FAQ section:

http://www.linux-mtd.infradead.org/faq/ubifs.html#L_why_ubiformat

Here is the full text in case someone would review:

Why I have to use ubiformat?
The first obvious reason is that ubiformat preserves erase counters, so
you do not lose your wear-leveling information when flashing new images.

The other reason is more subtle, and specific to NAND flashes which have
ECC calculation algorithm which produces ECC code not equivalent to all
0xFF bytes if the NAND page contains only 0xFF bytes. Consider an
example.

      * We erase whole flash, so everything is 0xFF'ed now.
      * We write an UBI/UBIFS image to flash using nandwrite.
      * Some eraseblocks in the UBIFS image may contain several empty
        NAND pages at the end, and UBIFS will write to them when it is
        run.
      * The nandwrite utility writes whole image, and it explicitely
        writes 0xFF bytes to those NAND pages.
      * The ECC checksums are calculated for these 0xFF'ed NAND pages
        and are stored in the OOB area. The ECC codes are not 0xFF'ed.
        This is often the case for HW ECC calculation engines, and it is
        difficult to fix this. Normally, ECC codes should be 0xFF'ed for
        such pages.
      * When later UBIFS runs, it writes data to these NAND pages, which
        means that a new ECC code is calculated, and written on top of
        the existing one (unsuccessfully, of course). This may trigger
        an error straight away, but usually at this point no error is
        triggered.
      * At some point UBIFS is trying to read from these pages, and gets
        and an ECC error (-EBADMSG = -74).

In fewer words, ubiformat makes sure that every NAND page is written
once and only once after the erasure. If you use nandwrite, some pages
are written twice - once by nandwrite, and once by UBIFS.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

  parent reply	other threads:[~2009-10-11  8:39 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
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 [this message]
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=1255250357.16942.0.camel@localhost \
    --to=dedekind@infradead.org \
    --cc=adrian.hunter@nokia.com \
    --cc=drambo@broadcom.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=matthieu.castet@parrot.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox