All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ivan Djelic <ivan.djelic@parrot.com>
To: "Philip, Avinash" <avinashphilip@ti.com>
Cc: "dwmw2@infradead.org" <dwmw2@infradead.org>,
	"artem.bityutskiy@linux.intel.com"
	<artem.bityutskiy@linux.intel.com>,
	"tony@atomide.com" <tony@atomide.com>,
	"Mohammed, Afzal" <afzal@ti.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"devicetree-discuss@lists.ozlabs.org" 
	<devicetree-discuss@lists.ozlabs.org>
Subject: Re: [PATCH 4/4] mtd: nand: omap2: Add data correction support
Date: Wed, 10 Oct 2012 19:08:06 +0200	[thread overview]
Message-ID: <20121010170806.GB13585@parrot.com> (raw)
In-Reply-To: <518397C60809E147AF5323E0420B992E3E9CA829@DBDE01.ent.ti.com>

On Tue, Oct 09, 2012 at 01:36:50PM +0100, Philip, Avinash wrote:
(...)
> > There are at least 2 potential problems when reading an erased page with bitflips:
> > 
> > 1. bitflip in data area and no bitflip in spare area (all 0xff)
> > Your code will not perform any ECC correction.
> > UBIFS does not like finding bitflips in empty pages, see for instance
> > http://lists.infradead.org/pipermail/linux-mtd/2012-March/040328.html.
> 
> In case of error correction using ELM, syndrome vector calculated after reading
> Data area & OOB area. So handling of erased page requires a software workaround.
> I am planning something as follows.
> 
> I will first check calculated ecc, which would be zero for non error pages.
> Then I would check 0xFF in OOB area (for erased page) by checking number of
> bit zeros in OOB area.  If it is 0xFF (number of bit zero count is zero),
> set entire page as 0xFF if number of bit zeros is less than max bit flips
> (8 or 4) by counting the number of bit zero's in data area.
> 
> This logic is implemented in fsmc_nand.c
> 
> See commit
> mtd: fsmc: Newly erased page read algorithm implemented
> 
> > 
> > 2. bitflip in ECC bytes in spare area
> > Your code will report an uncorrectable error upon reading; if this happens while reading a partially programmed UBI block,
> > I guess you will lose data.
> 
> In case of uncorrectable errors due to bit flips in spare area,
> I can go on checking number of bit zero's in data area + OOB area
> are less than max bit flips (8 or 4), I can go on setting the entire
> page as 0xFF.
> 

OK, sounds reasonable.
Another simple strategy could use the fact that you add a 14th zero byte to
the 13 BCH bytes for RBL compatibility:

Upon reading:
 - if this 14th byte is zero (*) => page was programmed: perform ECC
   correction as usual
 - else, page was not programmed: do not perform ECC, read entire data+spare
   area, and set it to 0xff if less than 8 or 4 (max bitflips) zero bits
   were found

(*) for robustness to bitflip in 14th byte, replace condition
"14th byte is zero" by e.g. "14th byte has less than 4 bits set to 1".

What do you think ?

BR,
--
Ivan

WARNING: multiple messages have this Message-ID (diff)
From: Ivan Djelic <ivan.djelic@parrot.com>
To: "Philip, Avinash" <avinashphilip@ti.com>
Cc: "Mohammed, Afzal" <afzal@ti.com>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"tony@atomide.com" <tony@atomide.com>,
	"artem.bityutskiy@linux.intel.com"
	<artem.bityutskiy@linux.intel.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"dwmw2@infradead.org" <dwmw2@infradead.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 4/4] mtd: nand: omap2: Add data correction support
Date: Wed, 10 Oct 2012 19:08:06 +0200	[thread overview]
Message-ID: <20121010170806.GB13585@parrot.com> (raw)
In-Reply-To: <518397C60809E147AF5323E0420B992E3E9CA829@DBDE01.ent.ti.com>

On Tue, Oct 09, 2012 at 01:36:50PM +0100, Philip, Avinash wrote:
(...)
> > There are at least 2 potential problems when reading an erased page with bitflips:
> > 
> > 1. bitflip in data area and no bitflip in spare area (all 0xff)
> > Your code will not perform any ECC correction.
> > UBIFS does not like finding bitflips in empty pages, see for instance
> > http://lists.infradead.org/pipermail/linux-mtd/2012-March/040328.html.
> 
> In case of error correction using ELM, syndrome vector calculated after reading
> Data area & OOB area. So handling of erased page requires a software workaround.
> I am planning something as follows.
> 
> I will first check calculated ecc, which would be zero for non error pages.
> Then I would check 0xFF in OOB area (for erased page) by checking number of
> bit zeros in OOB area.  If it is 0xFF (number of bit zero count is zero),
> set entire page as 0xFF if number of bit zeros is less than max bit flips
> (8 or 4) by counting the number of bit zero's in data area.
> 
> This logic is implemented in fsmc_nand.c
> 
> See commit
> mtd: fsmc: Newly erased page read algorithm implemented
> 
> > 
> > 2. bitflip in ECC bytes in spare area
> > Your code will report an uncorrectable error upon reading; if this happens while reading a partially programmed UBI block,
> > I guess you will lose data.
> 
> In case of uncorrectable errors due to bit flips in spare area,
> I can go on checking number of bit zero's in data area + OOB area
> are less than max bit flips (8 or 4), I can go on setting the entire
> page as 0xFF.
> 

OK, sounds reasonable.
Another simple strategy could use the fact that you add a 14th zero byte to
the 13 BCH bytes for RBL compatibility:

Upon reading:
 - if this 14th byte is zero (*) => page was programmed: perform ECC
   correction as usual
 - else, page was not programmed: do not perform ECC, read entire data+spare
   area, and set it to 0xff if less than 8 or 4 (max bitflips) zero bits
   were found

(*) for robustness to bitflip in 14th byte, replace condition
"14th byte is zero" by e.g. "14th byte has less than 4 bits set to 1".

What do you think ?

BR,
--
Ivan

WARNING: multiple messages have this Message-ID (diff)
From: ivan.djelic@parrot.com (Ivan Djelic)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/4] mtd: nand: omap2: Add data correction support
Date: Wed, 10 Oct 2012 19:08:06 +0200	[thread overview]
Message-ID: <20121010170806.GB13585@parrot.com> (raw)
In-Reply-To: <518397C60809E147AF5323E0420B992E3E9CA829@DBDE01.ent.ti.com>

On Tue, Oct 09, 2012 at 01:36:50PM +0100, Philip, Avinash wrote:
(...)
> > There are at least 2 potential problems when reading an erased page with bitflips:
> > 
> > 1. bitflip in data area and no bitflip in spare area (all 0xff)
> > Your code will not perform any ECC correction.
> > UBIFS does not like finding bitflips in empty pages, see for instance
> > http://lists.infradead.org/pipermail/linux-mtd/2012-March/040328.html.
> 
> In case of error correction using ELM, syndrome vector calculated after reading
> Data area & OOB area. So handling of erased page requires a software workaround.
> I am planning something as follows.
> 
> I will first check calculated ecc, which would be zero for non error pages.
> Then I would check 0xFF in OOB area (for erased page) by checking number of
> bit zeros in OOB area.  If it is 0xFF (number of bit zero count is zero),
> set entire page as 0xFF if number of bit zeros is less than max bit flips
> (8 or 4) by counting the number of bit zero's in data area.
> 
> This logic is implemented in fsmc_nand.c
> 
> See commit
> mtd: fsmc: Newly erased page read algorithm implemented
> 
> > 
> > 2. bitflip in ECC bytes in spare area
> > Your code will report an uncorrectable error upon reading; if this happens while reading a partially programmed UBI block,
> > I guess you will lose data.
> 
> In case of uncorrectable errors due to bit flips in spare area,
> I can go on checking number of bit zero's in data area + OOB area
> are less than max bit flips (8 or 4), I can go on setting the entire
> page as 0xFF.
> 

OK, sounds reasonable.
Another simple strategy could use the fact that you add a 14th zero byte to
the 13 BCH bytes for RBL compatibility:

Upon reading:
 - if this 14th byte is zero (*) => page was programmed: perform ECC
   correction as usual
 - else, page was not programmed: do not perform ECC, read entire data+spare
   area, and set it to 0xff if less than 8 or 4 (max bitflips) zero bits
   were found

(*) for robustness to bitflip in 14th byte, replace condition
"14th byte is zero" by e.g. "14th byte has less than 4 bits set to 1".

What do you think ?

BR,
--
Ivan

  reply	other threads:[~2012-10-10 17:08 UTC|newest]

Thread overview: 103+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-03 14:29 [PATCH 0/4] mtd: nand: OMAP: Add support to use ELM as error correction module Philip, Avinash
2012-10-03 14:29 ` Philip, Avinash
2012-10-03 14:29 ` Philip, Avinash
2012-10-03 14:29 ` Philip, Avinash
2012-10-03 14:29 ` [PATCH 1/4] mtd: nand: omap2: Update nerrors using ecc.strength Philip, Avinash
2012-10-03 14:29   ` Philip, Avinash
2012-10-03 14:29   ` Philip, Avinash
2012-10-03 14:29   ` Philip, Avinash
2012-10-15 18:56   ` Peter Korsgaard
2012-10-15 18:56     ` Peter Korsgaard
2012-10-15 18:56     ` Peter Korsgaard
2012-10-15 18:56     ` Peter Korsgaard
2012-10-23 10:17     ` Philip, Avinash
2012-10-23 10:17       ` Philip, Avinash
2012-10-23 10:17       ` Philip, Avinash
2012-10-23 10:17       ` Philip, Avinash
2012-10-03 14:29 ` [PATCH 2/4] mtd: devices: elm: Add support for ELM error correction Philip, Avinash
2012-10-03 14:29   ` Philip, Avinash
2012-10-03 14:29   ` Philip, Avinash
2012-10-03 14:29   ` Philip, Avinash
2012-10-03 15:10   ` Peter Meerwald
2012-10-03 15:10     ` Peter Meerwald
2012-10-03 15:10     ` Peter Meerwald
2012-10-04  7:49     ` Philip, Avinash
2012-10-04  7:49       ` Philip, Avinash
2012-10-04  7:49       ` Philip, Avinash
2012-10-04  7:49       ` Philip, Avinash
2012-10-15 19:40   ` Peter Korsgaard
2012-10-15 19:40     ` Peter Korsgaard
2012-10-15 19:40     ` Peter Korsgaard
2012-10-15 19:40     ` Peter Korsgaard
2012-10-23 10:17     ` Philip, Avinash
2012-10-23 10:17       ` Philip, Avinash
2012-10-23 10:17       ` Philip, Avinash
2012-10-23 10:17       ` Philip, Avinash
2012-10-03 14:29 ` [PATCH 3/4] ARM: OMAP2: gpmc: Add support for BCH ECC scheme Philip, Avinash
2012-10-03 14:29   ` Philip, Avinash
2012-10-03 14:29   ` Philip, Avinash
2012-10-03 14:29   ` Philip, Avinash
2012-10-03 18:54   ` Ivan Djelic
2012-10-03 18:54     ` Ivan Djelic
2012-10-03 18:54     ` Ivan Djelic
2012-10-03 18:54     ` Ivan Djelic
2012-10-04  8:03     ` Philip, Avinash
2012-10-04  8:03       ` Philip, Avinash
2012-10-04  8:03       ` Philip, Avinash
2012-10-04  8:03       ` Philip, Avinash
2012-10-04 12:04       ` Ivan Djelic
2012-10-04 12:04         ` Ivan Djelic
2012-10-04 12:04         ` Ivan Djelic
2012-10-04 12:04         ` Ivan Djelic
2012-10-15 18:48   ` Peter Korsgaard
2012-10-15 18:48     ` Peter Korsgaard
2012-10-15 18:48     ` Peter Korsgaard
2012-10-15 18:48     ` Peter Korsgaard
2012-10-23 10:18     ` Philip, Avinash
2012-10-23 10:18       ` Philip, Avinash
2012-10-23 10:18       ` Philip, Avinash
2012-10-23 10:18       ` Philip, Avinash
2012-10-03 14:29 ` [PATCH 4/4] mtd: nand: omap2: Add data correction support Philip, Avinash
2012-10-03 14:29   ` Philip, Avinash
2012-10-03 14:29   ` Philip, Avinash
2012-10-03 14:29   ` Philip, Avinash
2012-10-03 19:20   ` Ivan Djelic
2012-10-03 19:20     ` Ivan Djelic
2012-10-03 19:20     ` Ivan Djelic
2012-10-03 19:20     ` Ivan Djelic
2012-10-04 10:22     ` Philip, Avinash
2012-10-04 10:22       ` Philip, Avinash
2012-10-04 10:22       ` Philip, Avinash
2012-10-04 10:22       ` Philip, Avinash
2012-10-05  8:51     ` Philip, Avinash
2012-10-05  8:51       ` Philip, Avinash
2012-10-05  8:51       ` Philip, Avinash
2012-10-05  8:51       ` Philip, Avinash
2012-10-05 14:23       ` Ivan Djelic
2012-10-05 14:23         ` Ivan Djelic
2012-10-05 14:23         ` Ivan Djelic
2012-10-05 14:23         ` Ivan Djelic
2012-10-09 12:36         ` Philip, Avinash
2012-10-09 12:36           ` Philip, Avinash
2012-10-09 12:36           ` Philip, Avinash
2012-10-09 12:36           ` Philip, Avinash
2012-10-10 17:08           ` Ivan Djelic [this message]
2012-10-10 17:08             ` Ivan Djelic
2012-10-10 17:08             ` Ivan Djelic
2012-10-10 17:08             ` Ivan Djelic
2012-10-11  5:27             ` Philip, Avinash
2012-10-11  5:27               ` Philip, Avinash
2012-10-11  5:27               ` Philip, Avinash
2012-10-11  5:27               ` Philip, Avinash
2012-10-11  8:21               ` Ivan Djelic
2012-10-11  8:21                 ` Ivan Djelic
2012-10-11  8:21                 ` Ivan Djelic
2012-10-11  8:21                 ` Ivan Djelic
2012-10-11  9:05                 ` Philip, Avinash
2012-10-11  9:05                   ` Philip, Avinash
2012-10-11  9:05                   ` Philip, Avinash
2012-10-11  9:05                   ` Philip, Avinash
2012-10-11 14:41                 ` Tony Lindgren
2012-10-11 14:41                   ` Tony Lindgren
2012-10-11 14:41                   ` Tony Lindgren
2012-10-11 14:41                   ` Tony Lindgren

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=20121010170806.GB13585@parrot.com \
    --to=ivan.djelic@parrot.com \
    --cc=afzal@ti.com \
    --cc=artem.bityutskiy@linux.intel.com \
    --cc=avinashphilip@ti.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=dwmw2@infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=tony@atomide.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.