All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Fainelli <ffainelli@freebox.fr>
To: linux-mtd@lists.infradead.org
Cc: Javier Martinez Canillas <martinez.javier@gmail.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	Enric Balletbo i Serra <eballetbo@iseebcn.com>,
	Matthieu CASTET <matthieu.castet@parrot.com>
Subject: Re: [RFC] Change ECC algorithm from userspace
Date: Mon, 31 Oct 2011 10:02:35 +0100	[thread overview]
Message-ID: <5769554.XO3QpDQ76H@flexo> (raw)
In-Reply-To: <4EAA845B.1020009@parrot.com>

Hi,

On Friday 28 October 2011 12:30:51 Matthieu CASTET wrote:
> Hi,
> 
> Javier Martinez Canillas a écrit :
> > Hello,
> > 
> > I want to be able to use 1-bit ECC for the first partition where I
> > save the loader binary and has to be accessed by the ROM boot but use
> > a 4-bit ECC for my rootfs partition.
> > 
> > Does anyone have this same issue?
> 
> We use raw programming and compute the ecc in software.

We are doing something similar here as well. Our bootloader also requires the 
data to be layed out differently (data + ecc interleaved inside a page + oob).

> 
> > What is the best approach to store data in a NAND device using
> > different ECC techniques?
> > 
> > I've think of two approaches:
> > 
> > 1- Adding an ioctl to mtdchar (something like ECCSETBITS) to change
> > the ECC technique used.
> 
> But this won't work if there is concurrent acess to mtd. One program may
> want 1 bit ecc other want 4 bits ecc.
> 
> > 2- Use a platform data field to notify the omap2 nand driver that the
> > ROM boot only supports 1-bit ECC. So it can use a 1-bit ECC to write
> > and read the first 4 sectors but a 4-bit ECC for the rest.
> 
> This may be better.

Would not it better to add infrastructure for allowing per-partition ECC 
scheme? This should allow the kernel to also be able to properly handle the 
bootloader partitions (bad-block scanning ...).

> 
> Matthieu
> 
> PS : note that some OMAP ROM support a better protection than Hamming (but
> the details are not public AFAIK)
> 
> From OMAP34xx Multimedia Device, Silicon Revision 3.1.x, public version :
> 
> Pages can contain errors caused by memory alteration. To correct these
> errors, the ROM code uses ECC,
> based on Hamming codes for SLC NAND and BCH (Bose, Ray-Chaudhuri,
> Hocquenghem) code for
> multilevel cell (MLC) devices. The computed ECC is compared to ECC stored in
> the spare area of the
> corresponding page. If there are uncorrectable errors, the ROM code returns
> with FAIL.
--
Florian

WARNING: multiple messages have this Message-ID (diff)
From: Florian Fainelli <ffainelli@freebox.fr>
To: linux-mtd@lists.infradead.org
Cc: Javier Martinez Canillas <martinez.javier@gmail.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	Enric Balletbo i Serra <eballetbo@iseebcn.com>,
	Matthieu CASTET <matthieu.castet@parrot.com>
Subject: Re: [RFC] Change ECC algorithm from userspace
Date: Mon, 31 Oct 2011 10:02:35 +0100	[thread overview]
Message-ID: <5769554.XO3QpDQ76H@flexo> (raw)
In-Reply-To: <4EAA845B.1020009@parrot.com>

Hi,

On Friday 28 October 2011 12:30:51 Matthieu CASTET wrote:
> Hi,
> 
> Javier Martinez Canillas a écrit :
> > Hello,
> > 
> > I want to be able to use 1-bit ECC for the first partition where I
> > save the loader binary and has to be accessed by the ROM boot but use
> > a 4-bit ECC for my rootfs partition.
> > 
> > Does anyone have this same issue?
> 
> We use raw programming and compute the ecc in software.

We are doing something similar here as well. Our bootloader also requires the 
data to be layed out differently (data + ecc interleaved inside a page + oob).

> 
> > What is the best approach to store data in a NAND device using
> > different ECC techniques?
> > 
> > I've think of two approaches:
> > 
> > 1- Adding an ioctl to mtdchar (something like ECCSETBITS) to change
> > the ECC technique used.
> 
> But this won't work if there is concurrent acess to mtd. One program may
> want 1 bit ecc other want 4 bits ecc.
> 
> > 2- Use a platform data field to notify the omap2 nand driver that the
> > ROM boot only supports 1-bit ECC. So it can use a 1-bit ECC to write
> > and read the first 4 sectors but a 4-bit ECC for the rest.
> 
> This may be better.

Would not it better to add infrastructure for allowing per-partition ECC 
scheme? This should allow the kernel to also be able to properly handle the 
bootloader partitions (bad-block scanning ...).

> 
> Matthieu
> 
> PS : note that some OMAP ROM support a better protection than Hamming (but
> the details are not public AFAIK)
> 
> From OMAP34xx Multimedia Device, Silicon Revision 3.1.x, public version :
> 
> Pages can contain errors caused by memory alteration. To correct these
> errors, the ROM code uses ECC,
> based on Hamming codes for SLC NAND and BCH (Bose, Ray-Chaudhuri,
> Hocquenghem) code for
> multilevel cell (MLC) devices. The computed ECC is compared to ECC stored in
> the spare area of the
> corresponding page. If there are uncorrectable errors, the ROM code returns
> with FAIL.
--
Florian

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

  parent reply	other threads:[~2011-10-31  9:03 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-28  9:42 [RFC] Change ECC algorithm from userspace Javier Martinez Canillas
2011-10-28  9:42 ` Javier Martinez Canillas
2011-10-28 10:30 ` Matthieu CASTET
2011-10-28 10:30   ` Matthieu CASTET
2011-10-28 11:10   ` Javier Martinez Canillas
2011-10-28 11:10     ` Javier Martinez Canillas
2011-10-28 11:51     ` Matthieu CASTET
2011-10-28 11:51       ` Matthieu CASTET
2011-10-28 12:00       ` Javier Martinez Canillas
2011-10-28 12:00         ` Javier Martinez Canillas
2011-10-31  9:02   ` Florian Fainelli [this message]
2011-10-31  9:02     ` Florian Fainelli
2011-10-28 10:33 ` Jon Povey
2011-10-28 10:33   ` Jon Povey
2011-10-28 10:40   ` Matthieu CASTET
2011-10-28 10:40     ` Matthieu CASTET
2011-10-28 11:13   ` Javier Martinez Canillas
2011-10-28 11:13     ` Javier Martinez Canillas
2011-11-01  4:18     ` DaVinci NAND writing utility release, was: " Jon Povey
2011-11-01  4:18       ` Jon Povey
2011-11-01 10:34       ` Javier Martinez Canillas
2011-11-01 10:34         ` Javier Martinez Canillas
2011-10-31  8:04   ` Ricard Wanderlof
2011-10-31  8:04     ` Ricard Wanderlof
2011-10-28 10:43 ` Atlant Schmidt
2011-10-28 10:43   ` Atlant Schmidt
2011-10-28 11:13   ` Angus CLARK
2011-10-28 11:21     ` Javier Martinez Canillas

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=5769554.XO3QpDQ76H@flexo \
    --to=ffainelli@freebox.fr \
    --cc=eballetbo@iseebcn.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=martinez.javier@gmail.com \
    --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 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.