[RFC] Change ECC algorithm from userspace

[RFC] Change ECC algorithm from userspace

[Javier Martinez Canillas]

Hello,

We've a custom board using an ARM OMAP DM3730 whose ROM boot loader
only supports 1-bit ECC correction using Hamming algorithm.

So, in order to be able to boot from the NAND, we have to configure
the GPMC (OMAP's memory controller that interfaces with NAND devices)
to use 1-bit HW ECC and write the loader binary to the first NAND
sector. That way the ROM boot will take this sector as valid and load
the loader binary to RAM.

The problem is that the SLC NAND device that we are using has a
minimum required ECC of 4-bit correction per each 512 bytes.

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?

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.
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.

Of course both approaches can only be used if the none of the nand
memory partitions are mounted.

Thank you and best regards,

-- 
Javier Martínez Canillas
(+34) 682 39 81 69
Barcelona, Spain
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Change ECC algorithm from userspace

[Matthieu CASTET]

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.


> 
> 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.

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Change ECC algorithm from userspace

[Javier Martinez Canillas]

On Fri, Oct 28, 2011 at 12:30 PM, Matthieu CASTET
<matthieu.castet@parrot.com> 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.
>
>

Hi Matthieu,

We also thought that solution but it wasn't clear for me if doing a
RAW write to the mtd device I skip the NAND driver and could also
write the oob section without that value being recalculate and rewrite
by the driver.

>>
>> 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.
>
> 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.
>

Yes I've read that on the DM3730 TRM but as far as I understand only
applies to MLC devices, but ours is SLC.

Thank you and best regards,

-- 
Javier Martínez Canillas
(+34) 682 39 81 69
Barcelona, Spain
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Change ECC algorithm from userspace

[Matthieu CASTET]

Javier Martinez Canillas a écrit :
> On Fri, Oct 28, 2011 at 12:30 PM, Matthieu CASTET
> <matthieu.castet@parrot.com> wrote:
>> 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.
>>
>
> Yes I've read that on the DM3730 TRM but as far as I understand only
> applies to MLC devices, but ours is SLC.
>
It also works on SLC devices. We are using it on micron slc that need 4 bits ECC.


Matthieu
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Change ECC algorithm from userspace

[Javier Martinez Canillas]

On Fri, Oct 28, 2011 at 1:51 PM, Matthieu CASTET
<matthieu.castet@parrot.com> wrote:
> Javier Martinez Canillas a écrit :
>> On Fri, Oct 28, 2011 at 12:30 PM, Matthieu CASTET
>> <matthieu.castet@parrot.com> wrote:
>>> 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.
>>>
>>
>> Yes I've read that on the DM3730 TRM but as far as I understand only
>> applies to MLC devices, but ours is SLC.
>>
> It also works on SLC devices. We are using it on micron slc that need 4 bits ECC.
>

That is a great thing to know, I didn't get that from the
documentation (DM3730 TRM).

And this ECC scheme that is supported for SLC devices it is also BCH?
Or the ROM boot uses a different algorithm to calculate the codes to
be stored on the oob?

Thank and best regards,

-- 
Javier Martínez Canillas
(+34) 682 39 81 69
Barcelona, Spain
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Change ECC algorithm from userspace

[Florian Fainelli]

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/

RE: [RFC] Change ECC algorithm from userspace

[Jon Povey]

linux-mtd-bounces@lists.infradead.org wrote:
> 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?

DM355 and DM365 has similar issues as the RBL expects a different OOB/ECC
layout to Linux.

> What is the best approach to store data in a NAND device using
> different ECC techniques?

What I have done is write a utility that calculates ECC and writes to
the mtd device in RAW mode. So to rewrite the bootloader I take care of
the ECC and layout at application level without changing the kernel.

--
Jon Povey
jon.povey@racelogic.co.uk

Racelogic is a limited company registered in England. Registered number 2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .

The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network



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

Re: [RFC] Change ECC algorithm from userspace

[Matthieu CASTET]

Jon Povey a écrit :
> linux-mtd-bounces@lists.infradead.org wrote:
>> 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?
> 
> DM355 and DM365 has similar issues as the RBL expects a different OOB/ECC
> layout to Linux.
> 
>> What is the best approach to store data in a NAND device using
>> different ECC techniques?
> 
> What I have done is write a utility that calculates ECC and writes to
> the mtd device in RAW mode. So to rewrite the bootloader I take care of
> the ECC and layout at application level without changing the kernel.
>
Note that the kernel raw mode doesn't write the page in one time : it write data
and then ecc. This may cause problem with NOP1 nand.

see http://lists.infradead.org/pipermail/linux-mtd/2010-August/031262.html


Matthieu
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Change ECC algorithm from userspace

[Javier Martinez Canillas]

On Fri, Oct 28, 2011 at 12:33 PM, Jon Povey <Jon.Povey@racelogic.co.uk> wrote:
> linux-mtd-bounces@lists.infradead.org wrote:
>> 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?
>
> DM355 and DM365 has similar issues as the RBL expects a different OOB/ECC
> layout to Linux.
>
>> What is the best approach to store data in a NAND device using
>> different ECC techniques?
>
> What I have done is write a utility that calculates ECC and writes to
> the mtd device in RAW mode. So to rewrite the bootloader I take care of
> the ECC and layout at application level without changing the kernel.
>

Hi Jon,

Thanks for your help. I see that both you and Matthieu use the same
approach so I guess that is the common workaround for this problem. I
will do the same.

Is your utility publicly available? It would be great if I can use it
as an starting point.

Thank you and best regards,

-- 
Javier Martínez Canillas
(+34) 682 39 81 69
Barcelona, Spain
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

DaVinci NAND writing utility release, was: RE: [RFC] Change ECC algorithm from userspace

[Jon Povey]

Adding davinci linux open source ML to CC as folk there might find this
utility useful.

Javier Martinez Canillas wrote:
> On Fri, Oct 28, 2011 at 12:33 PM, Jon Povey
> <Jon.Povey@racelogic.co.uk> wrote:
>> linux-mtd-bounces@lists.infradead.org wrote:
>> DM355 and DM365 has similar issues as the RBL expects a different
>> OOB/ECC layout to Linux.
>>
>> What I have done is write a utility that calculates ECC and writes to
>> the mtd device in RAW mode. So to rewrite the bootloader I take care
>> of the ECC and layout at application level without changing the
>> kernel.

> Is your utility publicly available? It would be great if I can use it
> as an starting point.

Management have given the thumbs-up, this is now released under GPL v2
at https://github.com/jonpovey/flashtool

Supports DM355 and DM365 RBL layouts, ECC generation, UBI image writing,
and various bad block / range handling.

Enjoy!

--
Jon Povey
jon.povey@racelogic.co.uk

Racelogic is a limited company registered in England. Registered number 2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .

The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network



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

Re: DaVinci NAND writing utility release, was: RE: [RFC] Change ECC algorithm from userspace

[Javier Martinez Canillas]

On Tue, Nov 1, 2011 at 5:18 AM, Jon Povey <Jon.Povey@racelogic.co.uk> wrote:
> Adding davinci linux open source ML to CC as folk there might find this
> utility useful.
>
> Javier Martinez Canillas wrote:
>> On Fri, Oct 28, 2011 at 12:33 PM, Jon Povey
>> <Jon.Povey@racelogic.co.uk> wrote:
>>> linux-mtd-bounces@lists.infradead.org wrote:
>>> DM355 and DM365 has similar issues as the RBL expects a different
>>> OOB/ECC layout to Linux.
>>>
>>> What I have done is write a utility that calculates ECC and writes to
>>> the mtd device in RAW mode. So to rewrite the bootloader I take care
>>> of the ECC and layout at application level without changing the
>>> kernel.
>
>> Is your utility publicly available? It would be great if I can use it
>> as an starting point.
>
> Management have given the thumbs-up, this is now released under GPL v2
> at https://github.com/jonpovey/flashtool
>
> Supports DM355 and DM365 RBL layouts, ECC generation, UBI image writing,
> and various bad block / range handling.
>
> Enjoy!
>
> --

Hi Jon, thanks for sharing your tool!

Today is holiday in Spain and I don't have proper hardware to test.
But tomorrow I will definitely give a try.

Thanks a lot and best regards,

-- 
Javier Martínez Canillas
(+34) 682 39 81 69
Barcelona, Spain
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [RFC] Change ECC algorithm from userspace

[Ricard Wanderlof]

On Fri, 28 Oct 2011, Jon Povey wrote:

> linux-mtd-bounces@lists.infradead.org wrote:
>> 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?
>
> DM355 and DM365 has similar issues as the RBL expects a different OOB/ECC
> layout to Linux.

Slightly off-topic, but in the 355/365 (etc) case it's possible to modify 
the Linux driver so it uses the RBL ECC layout. For us, it seemed the 
easiest thing to do, as having different ECC layouts in different parts
of the flash proved to be a pain. If you need different ECC algorithms in
different parts of the flash this wouldn't work of course.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

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

RE: [RFC] Change ECC algorithm from userspace

[Atlant Schmidt]

Javier:

  That's why most people boot from NOR Flash
  where a 1-bit ECC is adequate.

  I don't see how you can possibly expect to
  reliably, successfully boot from a NAND Flash
  using just 1 bit ECC; you've either got to
  change the boot loader to allow more ECC or
  use more-reliable Flash hardware.

                            Atlant

-----Original Message-----
From: linux-mtd-bounces@lists.infradead.org [mailto:linux-mtd-bounces@lists.infradead.org] On Behalf Of Javier Martinez Canillas
Sent: Friday, October 28, 2011 05:43
To: linux-mtd@lists.infradead.org; linux-omap@vger.kernel.org
Cc: Enric Balletbo i Serra
Subject: [RFC] Change ECC algorithm from userspace

Hello,

We've a custom board using an ARM OMAP DM3730 whose ROM boot loader
only supports 1-bit ECC correction using Hamming algorithm.

So, in order to be able to boot from the NAND, we have to configure
the GPMC (OMAP's memory controller that interfaces with NAND devices)
to use 1-bit HW ECC and write the loader binary to the first NAND
sector. That way the ROM boot will take this sector as valid and load
the loader binary to RAM.

The problem is that the SLC NAND device that we are using has a
minimum required ECC of 4-bit correction per each 512 bytes.

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?

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.
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.

Of course both approaches can only be used if the none of the nand
memory partitions are mounted.

Thank you and best regards,

--
Javier Martínez Canillas
(+34) 682 39 81 69
Barcelona, Spain

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


 Click https://www.mailcontrol.com/sr/y76zW8+ioPrTndxI!oX7Ulvwl1GqFAPr!F7OwTKhhUGNVQ5EfYl!2UQwm7gCP9RqaL!eAyER2lwjp+mmMV7JIw==  to report this email as spam.

This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/