OMAP3 NAND ECC selection

OMAP3 NAND ECC selection

[Peter Meerwald]

Hello,

on OMAP3, the NAND area holding MLO and u-boot need a different ECC scheme 
(hw) than the rootfs (sw)

is there a way to tell the kernel which ECC scheme to use on a 
per-partition basis?

I'd like to be able to update MLO and u-boot from within a booted Linux 
system on the device (I have to resort to u-boot for that where I can 
control the ECC scheme used)

thanks, regards, p.

-- 

Peter Meerwald
+43-664-2444418 (mobile)

Re: OMAP3 NAND ECC selection

[Enric Balletbo Serra]

Hi Peter,

2013/12/5 Peter Meerwald <pmeerw@pmeerw.net>:
> Hello,
>
> on OMAP3, the NAND area holding MLO and u-boot need a different ECC scheme
> (hw) than the rootfs (sw)
>

There is some discussion around this, please take a look at this thread,

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg98969.html

> is there a way to tell the kernel which ECC scheme to use on a
> per-partition basis?
>

At this moment this is not possible.

> I'd like to be able to update MLO and u-boot from within a booted Linux
> system on the device (I have to resort to u-boot for that where I can
> control the ECC scheme used)
>

Meanwhile, to do this we use a small userspace program created by
Javier Martinez in order to flash the MLO in our OMAP3 boards. See

http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary

Hope it helps you. Regards,
   Enric

> thanks, regards, p.
>
> --
>
> Peter Meerwald
> +43-664-2444418 (mobile)
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: OMAP3 NAND ECC selection

[Enric Balletbo Serra]

Hi Peter,

2013/12/5 Peter Meerwald <pmeerw@pmeerw.net>:
> Hello,
>
> on OMAP3, the NAND area holding MLO and u-boot need a different ECC scheme
> (hw) than the rootfs (sw)
>

There is some discussion around this, please take a look at this thread,

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg98969.html

> is there a way to tell the kernel which ECC scheme to use on a
> per-partition basis?
>

At this moment this is not possible.

> I'd like to be able to update MLO and u-boot from within a booted Linux
> system on the device (I have to resort to u-boot for that where I can
> control the ECC scheme used)
>

Meanwhile, to do this we use a small userspace program created by
Javier Martinez in order to flash the MLO in our OMAP3 boards. See

http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary

Hope it helps you. Regards,
   Enric

> thanks, regards, p.
>
> --
>
> Peter Meerwald
> +43-664-2444418 (mobile)
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: OMAP3 NAND ECC selection

[Andreas Bießmann]

[-- Attachment #1: Type: text/plain, Size: 654 bytes --]

Hi Peter,

On 12/05/2013 10:47 AM, Enric Balletbo Serra wrote:
> 2013/12/5 Peter Meerwald <pmeerw@pmeerw.net>:

<snip>

>> I'd like to be able to update MLO and u-boot from within a booted Linux
>> system on the device (I have to resort to u-boot for that where I can
>> control the ECC scheme used)
>>
> 
> Meanwhile, to do this we use a small userspace program created by
> Javier Martinez in order to flash the MLO in our OMAP3 boards. See
> 
> http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary

we used another aproach here. See

http://article.gmane.org/gmane.linux.drivers.mtd/43804

Best regards

Andreas Bießmann


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: OMAP3 NAND ECC selection

[Peter Meerwald]

> >> I'd like to be able to update MLO and u-boot from within a booted Linux
> >> system on the device (I have to resort to u-boot for that where I can
> >> control the ECC scheme used)

> > Meanwhile, to do this we use a small userspace program created by
> > Javier Martinez in order to flash the MLO in our OMAP3 boards. See
> > http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary

> we used another aproach here. See
> http://article.gmane.org/gmane.linux.drivers.mtd/43804

pretty much what I have been looking for, thanks!

p.

-- 

Peter Meerwald
+43-664-2444418 (mobile)

Re: OMAP3 NAND ECC selection

[Tony Lindgren]

* Peter Meerwald <pmeerw@pmeerw.net> [131205 08:13]:
> > >> I'd like to be able to update MLO and u-boot from within a booted Linux
> > >> system on the device (I have to resort to u-boot for that where I can
> > >> control the ECC scheme used)
> 
> > > Meanwhile, to do this we use a small userspace program created by
> > > Javier Martinez in order to flash the MLO in our OMAP3 boards. See
> > > http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary
> 
> > we used another aproach here. See
> > http://article.gmane.org/gmane.linux.drivers.mtd/43804
> 
> pretty much what I have been looking for, thanks!

Hmm well both methods should work, but is there anything stopping us
merging the module param patch to the mainline tree?

Regards,

Tony

Re: OMAP3 NAND ECC selection

[Tony Lindgren]

* Peter Meerwald <pmeerw@pmeerw.net> [131205 08:13]:
> > >> I'd like to be able to update MLO and u-boot from within a booted Linux
> > >> system on the device (I have to resort to u-boot for that where I can
> > >> control the ECC scheme used)
> 
> > > Meanwhile, to do this we use a small userspace program created by
> > > Javier Martinez in order to flash the MLO in our OMAP3 boards. See
> > > http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary
> 
> > we used another aproach here. See
> > http://article.gmane.org/gmane.linux.drivers.mtd/43804
> 
> pretty much what I have been looking for, thanks!

Hmm well both methods should work, but is there anything stopping us
merging the module param patch to the mainline tree?

Regards,

Tony

Re: OMAP3 NAND ECC selection

[Javier Martinez Canillas]

[adding Pekon and Thomas as cc]

On Thu, Dec 5, 2013 at 6:13 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Peter Meerwald <pmeerw@pmeerw.net> [131205 08:13]:
>> > >> I'd like to be able to update MLO and u-boot from within a booted Linux
>> > >> system on the device (I have to resort to u-boot for that where I can
>> > >> control the ECC scheme used)
>>
>> > > Meanwhile, to do this we use a small userspace program created by
>> > > Javier Martinez in order to flash the MLO in our OMAP3 boards. See
>> > > http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary
>>
>> > we used another aproach here. See
>> > http://article.gmane.org/gmane.linux.drivers.mtd/43804
>>
>> pretty much what I have been looking for, thanks!
>
> Hmm well both methods should work, but is there anything stopping us
> merging the module param patch to the mainline tree?
>

Hi Tony,

In the another thread [0] pointed out by Enric we were discussing the
same issue. Thomas suggested [1] that ideally we should be able to set
a per MTD partition ECC scheme. That way we can set 1 bit hamming for
the first MTD partition that has the SPL that the boot ROM needs to
read and the other partitions can use a more secure ECC scheme. I
completely agree with him.

In fact the data-sheet for the NAND device used on the IGEPv2 board says:

"Minimum required ECC 4-bit ECC per 528 bytes || Minimum required ECC
for block 0  1-bit ECC per 528 byte"

so I don't think we should impose a software limitation by having a
global ECC scheme and we should expand the GPMC NAND DT binding so
partitions support the "ti,nand-ecc-opt". I'll see if I can get some
free time to try to implement that.

Pekon does not agree with this solution though [2]

Thanks a lot and best regards,
Javier

[0]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg98969.html
[1]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg99008.html
[2]: http://permalink.gmane.org/gmane.linux.ports.arm.omap/108136

Re: OMAP3 NAND ECC selection

[Javier Martinez Canillas]

[adding Pekon and Thomas as cc]

On Thu, Dec 5, 2013 at 6:13 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Peter Meerwald <pmeerw@pmeerw.net> [131205 08:13]:
>> > >> I'd like to be able to update MLO and u-boot from within a booted Linux
>> > >> system on the device (I have to resort to u-boot for that where I can
>> > >> control the ECC scheme used)
>>
>> > > Meanwhile, to do this we use a small userspace program created by
>> > > Javier Martinez in order to flash the MLO in our OMAP3 boards. See
>> > > http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary
>>
>> > we used another aproach here. See
>> > http://article.gmane.org/gmane.linux.drivers.mtd/43804
>>
>> pretty much what I have been looking for, thanks!
>
> Hmm well both methods should work, but is there anything stopping us
> merging the module param patch to the mainline tree?
>

Hi Tony,

In the another thread [0] pointed out by Enric we were discussing the
same issue. Thomas suggested [1] that ideally we should be able to set
a per MTD partition ECC scheme. That way we can set 1 bit hamming for
the first MTD partition that has the SPL that the boot ROM needs to
read and the other partitions can use a more secure ECC scheme. I
completely agree with him.

In fact the data-sheet for the NAND device used on the IGEPv2 board says:

"Minimum required ECC 4-bit ECC per 528 bytes || Minimum required ECC
for block 0  1-bit ECC per 528 byte"

so I don't think we should impose a software limitation by having a
global ECC scheme and we should expand the GPMC NAND DT binding so
partitions support the "ti,nand-ecc-opt". I'll see if I can get some
free time to try to implement that.

Pekon does not agree with this solution though [2]

Thanks a lot and best regards,
Javier

[0]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg98969.html
[1]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg99008.html
[2]: http://permalink.gmane.org/gmane.linux.ports.arm.omap/108136

Re: OMAP3 NAND ECC selection

[Ezequiel Garcia]

Hi Javier,

(CCing Brian: What do you think about this?)

On Thu, Dec 05, 2013 at 06:39:10PM +0100, Javier Martinez Canillas wrote:
> On Thu, Dec 5, 2013 at 6:13 PM, Tony Lindgren <tony@atomide.com> wrote:
> 
> In the another thread [0] pointed out by Enric we were discussing the
> same issue. Thomas suggested [1] that ideally we should be able to set
> a per MTD partition ECC scheme. That way we can set 1 bit hamming for
> the first MTD partition that has the SPL that the boot ROM needs to
> read and the other partitions can use a more secure ECC scheme. I
> completely agree with him.
> 
[..]
> global ECC scheme and we should expand the GPMC NAND DT binding so
> partitions support the "ti,nand-ecc-opt". I'll see if I can get some
> free time to try to implement that.
> 

AFAIK, there's no hardware limitation that would prevent us from setting
a per-partition ECC, keep in mind this effort is not reduced to make
devicetree accept ECC on the partitions.

While there are some per MTD device (which model each partition), the
ECC mode is present in the, nand_chip structure. My understanding is that
the NAND core hasn't been designed for this use case, and thus some
major re-work is needed to accomplish it.

Therefore, it's a much short-term solution to implement the OMAP
module parameter to fix the issue.

Of course, feel free to prove me wrong :-)
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
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: OMAP3 NAND ECC selection

[Ezequiel Garcia]

Hi Javier,

(CCing Brian: What do you think about this?)

On Thu, Dec 05, 2013 at 06:39:10PM +0100, Javier Martinez Canillas wrote:
> On Thu, Dec 5, 2013 at 6:13 PM, Tony Lindgren <tony@atomide.com> wrote:
> 
> In the another thread [0] pointed out by Enric we were discussing the
> same issue. Thomas suggested [1] that ideally we should be able to set
> a per MTD partition ECC scheme. That way we can set 1 bit hamming for
> the first MTD partition that has the SPL that the boot ROM needs to
> read and the other partitions can use a more secure ECC scheme. I
> completely agree with him.
> 
[..]
> global ECC scheme and we should expand the GPMC NAND DT binding so
> partitions support the "ti,nand-ecc-opt". I'll see if I can get some
> free time to try to implement that.
> 

AFAIK, there's no hardware limitation that would prevent us from setting
a per-partition ECC, keep in mind this effort is not reduced to make
devicetree accept ECC on the partitions.

While there are some per MTD device (which model each partition), the
ECC mode is present in the, nand_chip structure. My understanding is that
the NAND core hasn't been designed for this use case, and thus some
major re-work is needed to accomplish it.

Therefore, it's a much short-term solution to implement the OMAP
module parameter to fix the issue.

Of course, feel free to prove me wrong :-)
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

Re: OMAP3 NAND ECC selection

[Javier Martinez Canillas]

Hi Ezequiel,

On Thu, Dec 5, 2013 at 7:26 PM, Ezequiel Garcia
<ezequiel.garcia@free-electrons.com> wrote:
> Hi Javier,
>
> (CCing Brian: What do you think about this?)
>
> On Thu, Dec 05, 2013 at 06:39:10PM +0100, Javier Martinez Canillas wrote:
>> On Thu, Dec 5, 2013 at 6:13 PM, Tony Lindgren <tony@atomide.com> wrote:
>>
>> In the another thread [0] pointed out by Enric we were discussing the
>> same issue. Thomas suggested [1] that ideally we should be able to set
>> a per MTD partition ECC scheme. That way we can set 1 bit hamming for
>> the first MTD partition that has the SPL that the boot ROM needs to
>> read and the other partitions can use a more secure ECC scheme. I
>> completely agree with him.
>>
> [..]
>> global ECC scheme and we should expand the GPMC NAND DT binding so
>> partitions support the "ti,nand-ecc-opt". I'll see if I can get some
>> free time to try to implement that.
>>
>
> AFAIK, there's no hardware limitation that would prevent us from setting
> a per-partition ECC, keep in mind this effort is not reduced to make
> devicetree accept ECC on the partitions.
>

Agreed, in fact if you look at what I shared from the Micron NAND
datasheet used on IGEPv2 it says that different ECC schemes could be
used for block 0 and the rest of the NAND so definitely this is a
software limitation.

> While there are some per MTD device (which model each partition), the
> ECC mode is present in the, nand_chip structure. My understanding is that
> the NAND core hasn't been designed for this use case, and thus some
> major re-work is needed to accomplish it.
>

I see thanks for the clarification. I'm not familiar with the MTD
subsystem to be honest so I somehow misunderstood that other nand
drivers did this already and thought that it was just a matter of
adding support to the OMAP NAND driver.

> Therefore, it's a much short-term solution to implement the OMAP
> module parameter to fix the issue.
>
> Of course, feel free to prove me wrong :-)

Agreed.

> --
> Ezequiel García, Free Electrons
> Embedded Linux, Kernel and Android Engineering
> http://free-electrons.com

Thanks a lot and best regards,
Javier
--
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: OMAP3 NAND ECC selection

[Javier Martinez Canillas]

Hi Ezequiel,

On Thu, Dec 5, 2013 at 7:26 PM, Ezequiel Garcia
<ezequiel.garcia@free-electrons.com> wrote:
> Hi Javier,
>
> (CCing Brian: What do you think about this?)
>
> On Thu, Dec 05, 2013 at 06:39:10PM +0100, Javier Martinez Canillas wrote:
>> On Thu, Dec 5, 2013 at 6:13 PM, Tony Lindgren <tony@atomide.com> wrote:
>>
>> In the another thread [0] pointed out by Enric we were discussing the
>> same issue. Thomas suggested [1] that ideally we should be able to set
>> a per MTD partition ECC scheme. That way we can set 1 bit hamming for
>> the first MTD partition that has the SPL that the boot ROM needs to
>> read and the other partitions can use a more secure ECC scheme. I
>> completely agree with him.
>>
> [..]
>> global ECC scheme and we should expand the GPMC NAND DT binding so
>> partitions support the "ti,nand-ecc-opt". I'll see if I can get some
>> free time to try to implement that.
>>
>
> AFAIK, there's no hardware limitation that would prevent us from setting
> a per-partition ECC, keep in mind this effort is not reduced to make
> devicetree accept ECC on the partitions.
>

Agreed, in fact if you look at what I shared from the Micron NAND
datasheet used on IGEPv2 it says that different ECC schemes could be
used for block 0 and the rest of the NAND so definitely this is a
software limitation.

> While there are some per MTD device (which model each partition), the
> ECC mode is present in the, nand_chip structure. My understanding is that
> the NAND core hasn't been designed for this use case, and thus some
> major re-work is needed to accomplish it.
>

I see thanks for the clarification. I'm not familiar with the MTD
subsystem to be honest so I somehow misunderstood that other nand
drivers did this already and thought that it was just a matter of
adding support to the OMAP NAND driver.

> Therefore, it's a much short-term solution to implement the OMAP
> module parameter to fix the issue.
>
> Of course, feel free to prove me wrong :-)

Agreed.

> --
> Ezequiel García, Free Electrons
> Embedded Linux, Kernel and Android Engineering
> http://free-electrons.com

Thanks a lot and best regards,
Javier

RE: OMAP3 NAND ECC selection

[Gupta, Pekon]

Hi Ezequiel,


>From: Ezequiel Garcia [mailto:ezequiel.garcia@free-electrons.com]
[...]
>AFAIK, there's no hardware limitation that would prevent us from setting
>a per-partition ECC, keep in mind this effort is not reduced to make
>devicetree accept ECC on the partitions.
>
I had some reservations in doing so.. (as mentioned in previous email also [2])
I would rather like to understand long term benefits of such implementation.

Also, any constrain due to ROM code, or upgrading from remote can be
handled using various alternative approaches like [a] and [b].

[2]: http://permalink.gmane.org/gmane.linux.ports.arm.omap/108136

[a]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg99025.html
[b]: http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary


with regards, pekon

RE: OMAP3 NAND ECC selection

[Gupta, Pekon]

Hi Ezequiel,


>From: Ezequiel Garcia [mailto:ezequiel.garcia@free-electrons.com]
[...]
>AFAIK, there's no hardware limitation that would prevent us from setting
>a per-partition ECC, keep in mind this effort is not reduced to make
>devicetree accept ECC on the partitions.
>
I had some reservations in doing so.. (as mentioned in previous email also [2])
I would rather like to understand long term benefits of such implementation.

Also, any constrain due to ROM code, or upgrading from remote can be
handled using various alternative approaches like [a] and [b].

[2]: http://permalink.gmane.org/gmane.linux.ports.arm.omap/108136

[a]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg99025.html
[b]: http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary


with regards, pekon

Re: OMAP3 NAND ECC selection

[Thomas Petazzoni]

Dear Gupta, Pekon,

On Thu, 5 Dec 2013 19:02:22 +0000, Gupta, Pekon wrote:

> >From: Ezequiel Garcia [mailto:ezequiel.garcia@free-electrons.com]
> [...]
> >AFAIK, there's no hardware limitation that would prevent us from setting
> >a per-partition ECC, keep in mind this effort is not reduced to make
> >devicetree accept ECC on the partitions.
> >
> I had some reservations in doing so.. (as mentioned in previous email also [2])
> I would rather like to understand long term benefits of such implementation.

The long term benefits is simply to properly handle the hardware
constraints. We have hardware platforms were parts of the NAND *MUST*
use 1-bit ECC to be compatible with the ROM code, and other parts of
the NAND *MUST* use stronger 4-bits or 8-bits ECC to comply with the
NAND requirements.

Isn't handling hardware constraints properly not a sufficient
motivation for doing something?

> Also, any constrain due to ROM code, or upgrading from remote can be
> handled using various alternative approaches like [a] and [b].

And you're not realizing that these solutions are ugly and impractical?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: OMAP3 NAND ECC selection

[Thomas Petazzoni]

Dear Gupta, Pekon,

On Thu, 5 Dec 2013 19:02:22 +0000, Gupta, Pekon wrote:

> >From: Ezequiel Garcia [mailto:ezequiel.garcia@free-electrons.com]
> [...]
> >AFAIK, there's no hardware limitation that would prevent us from setting
> >a per-partition ECC, keep in mind this effort is not reduced to make
> >devicetree accept ECC on the partitions.
> >
> I had some reservations in doing so.. (as mentioned in previous email also [2])
> I would rather like to understand long term benefits of such implementation.

The long term benefits is simply to properly handle the hardware
constraints. We have hardware platforms were parts of the NAND *MUST*
use 1-bit ECC to be compatible with the ROM code, and other parts of
the NAND *MUST* use stronger 4-bits or 8-bits ECC to comply with the
NAND requirements.

Isn't handling hardware constraints properly not a sufficient
motivation for doing something?

> Also, any constrain due to ROM code, or upgrading from remote can be
> handled using various alternative approaches like [a] and [b].

And you're not realizing that these solutions are ugly and impractical?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: OMAP3 NAND ECC selection

[Brian Norris]

On Thu, Dec 5, 2013 at 10:26 AM, Ezequiel Garcia
<ezequiel.garcia@free-electrons.com> wrote:
> (CCing Brian: What do you think about this?)
>
> On Thu, Dec 05, 2013 at 06:39:10PM +0100, Javier Martinez Canillas wrote:
>> On Thu, Dec 5, 2013 at 6:13 PM, Tony Lindgren <tony@atomide.com> wrote:
>>
>> In the another thread [0] pointed out by Enric we were discussing the
>> same issue. Thomas suggested [1] that ideally we should be able to set
>> a per MTD partition ECC scheme. That way we can set 1 bit hamming for
>> the first MTD partition that has the SPL that the boot ROM needs to
>> read and the other partitions can use a more secure ECC scheme. I
>> completely agree with him.
>>
> [..]
>> global ECC scheme and we should expand the GPMC NAND DT binding so
>> partitions support the "ti,nand-ecc-opt". I'll see if I can get some
>> free time to try to implement that.
>>
>
> AFAIK, there's no hardware limitation that would prevent us from setting
> a per-partition ECC, keep in mind this effort is not reduced to make
> devicetree accept ECC on the partitions.
>
> While there are some per MTD device (which model each partition), the
> ECC mode is present in the, nand_chip structure. My understanding is that
> the NAND core hasn't been designed for this use case, and thus some
> major re-work is needed to accomplish it.

Yes, it looks like a lot of work for little benefit. IMO, the *right*
thing to do is have the bootloader use a sufficiently strong ECC for
the flash part, so you don't have to configure different strengths for
different partitions. But I'll concede that it may be *nice* to have
flexibility in some cases.

Part of the difficulty is in making this generic for all types of NAND
drivers. On some, you can simply change some high-level software
parameters to use a different ECC mode, while others may require hooks
for controlling hardware parameters. And switching this at runtime can
end up being a lot of work, since a sequence of reads/writes
alternating between two differently-configured partitions would rapid
reconfiguration of the ECC controller, which previously only needed
configured at module initialization time. It may be doable, but to
commit to this approach, you must do a lot of work.

Also, this requires major changes to the MTD framework. Right now, I
believe MTD partitions are a very small shim layer, where the bulk of
the MTD transactions are filtered through to the parent "master" MTD.

> Therefore, it's a much short-term solution to implement the OMAP
> module parameter to fix the issue.

That's possible, but even there, I don't see what the real benefit is.
If you only need special-case solutions (which it seems like this use
case is) for updating bootloader data, can't a simple 1-bit ECC
user-space tool (like the one you linked earlier) suffice? It seems
like it's only a small convenience to place this flexibility in a
module parameter, but it is much *less* generic; what if someone
builds omap2 into the kernel (not as a module)? So the user-space tool
seems superior in many cases.

Brian

Re: OMAP3 NAND ECC selection

[Brian Norris]

On Thu, Dec 5, 2013 at 10:26 AM, Ezequiel Garcia
<ezequiel.garcia@free-electrons.com> wrote:
> (CCing Brian: What do you think about this?)
>
> On Thu, Dec 05, 2013 at 06:39:10PM +0100, Javier Martinez Canillas wrote:
>> On Thu, Dec 5, 2013 at 6:13 PM, Tony Lindgren <tony@atomide.com> wrote:
>>
>> In the another thread [0] pointed out by Enric we were discussing the
>> same issue. Thomas suggested [1] that ideally we should be able to set
>> a per MTD partition ECC scheme. That way we can set 1 bit hamming for
>> the first MTD partition that has the SPL that the boot ROM needs to
>> read and the other partitions can use a more secure ECC scheme. I
>> completely agree with him.
>>
> [..]
>> global ECC scheme and we should expand the GPMC NAND DT binding so
>> partitions support the "ti,nand-ecc-opt". I'll see if I can get some
>> free time to try to implement that.
>>
>
> AFAIK, there's no hardware limitation that would prevent us from setting
> a per-partition ECC, keep in mind this effort is not reduced to make
> devicetree accept ECC on the partitions.
>
> While there are some per MTD device (which model each partition), the
> ECC mode is present in the, nand_chip structure. My understanding is that
> the NAND core hasn't been designed for this use case, and thus some
> major re-work is needed to accomplish it.

Yes, it looks like a lot of work for little benefit. IMO, the *right*
thing to do is have the bootloader use a sufficiently strong ECC for
the flash part, so you don't have to configure different strengths for
different partitions. But I'll concede that it may be *nice* to have
flexibility in some cases.

Part of the difficulty is in making this generic for all types of NAND
drivers. On some, you can simply change some high-level software
parameters to use a different ECC mode, while others may require hooks
for controlling hardware parameters. And switching this at runtime can
end up being a lot of work, since a sequence of reads/writes
alternating between two differently-configured partitions would rapid
reconfiguration of the ECC controller, which previously only needed
configured at module initialization time. It may be doable, but to
commit to this approach, you must do a lot of work.

Also, this requires major changes to the MTD framework. Right now, I
believe MTD partitions are a very small shim layer, where the bulk of
the MTD transactions are filtered through to the parent "master" MTD.

> Therefore, it's a much short-term solution to implement the OMAP
> module parameter to fix the issue.

That's possible, but even there, I don't see what the real benefit is.
If you only need special-case solutions (which it seems like this use
case is) for updating bootloader data, can't a simple 1-bit ECC
user-space tool (like the one you linked earlier) suffice? It seems
like it's only a small convenience to place this flexibility in a
module parameter, but it is much *less* generic; what if someone
builds omap2 into the kernel (not as a module)? So the user-space tool
seems superior in many cases.

Brian

Re: OMAP3 NAND ECC selection

[Brian Norris]

On Thu, Dec 5, 2013 at 11:06 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> On Thu, 5 Dec 2013 19:02:22 +0000, Gupta, Pekon wrote:
>
>> >From: Ezequiel Garcia [mailto:ezequiel.garcia@free-electrons.com]
>> [...]
>> >AFAIK, there's no hardware limitation that would prevent us from setting
>> >a per-partition ECC, keep in mind this effort is not reduced to make
>> >devicetree accept ECC on the partitions.
>> >
>> I had some reservations in doing so.. (as mentioned in previous email also [2])
>> I would rather like to understand long term benefits of such implementation.
>
> The long term benefits is simply to properly handle the hardware
> constraints. We have hardware platforms were parts of the NAND *MUST*
> use 1-bit ECC to be compatible with the ROM code, and other parts of
> the NAND *MUST* use stronger 4-bits or 8-bits ECC to comply with the
> NAND requirements.

Using 1-bit ECC on NAND is not a long-term solution. Given that fact,
I think your ROM code is what may need to change, not the entire MTD
subsystem.

> Isn't handling hardware constraints properly not a sufficient
> motivation for doing something?

I'm not convinced your hardware constraints are reasonable or
generally useful. But I could be convinced otherwise.

>> Also, any constrain due to ROM code, or upgrading from remote can be
>> handled using various alternative approaches like [a] and [b].
>
> And you're not realizing that these solutions are ugly and impractical?

Solution [a] is both ugly and impractical. Solution [b] is only a
little ugly but quite practical (you could flesh out a better
user-space ECC library, then combine it with nanddump/nandwrite
--noecc). Rewriting both the MTD and NAND layers is not exactly
practical and may still yield something ugly.

Brian

Re: OMAP3 NAND ECC selection

[Brian Norris]

On Thu, Dec 5, 2013 at 11:06 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> On Thu, 5 Dec 2013 19:02:22 +0000, Gupta, Pekon wrote:
>
>> >From: Ezequiel Garcia [mailto:ezequiel.garcia@free-electrons.com]
>> [...]
>> >AFAIK, there's no hardware limitation that would prevent us from setting
>> >a per-partition ECC, keep in mind this effort is not reduced to make
>> >devicetree accept ECC on the partitions.
>> >
>> I had some reservations in doing so.. (as mentioned in previous email also [2])
>> I would rather like to understand long term benefits of such implementation.
>
> The long term benefits is simply to properly handle the hardware
> constraints. We have hardware platforms were parts of the NAND *MUST*
> use 1-bit ECC to be compatible with the ROM code, and other parts of
> the NAND *MUST* use stronger 4-bits or 8-bits ECC to comply with the
> NAND requirements.

Using 1-bit ECC on NAND is not a long-term solution. Given that fact,
I think your ROM code is what may need to change, not the entire MTD
subsystem.

> Isn't handling hardware constraints properly not a sufficient
> motivation for doing something?

I'm not convinced your hardware constraints are reasonable or
generally useful. But I could be convinced otherwise.

>> Also, any constrain due to ROM code, or upgrading from remote can be
>> handled using various alternative approaches like [a] and [b].
>
> And you're not realizing that these solutions are ugly and impractical?

Solution [a] is both ugly and impractical. Solution [b] is only a
little ugly but quite practical (you could flesh out a better
user-space ECC library, then combine it with nanddump/nandwrite
--noecc). Rewriting both the MTD and NAND layers is not exactly
practical and may still yield something ugly.

Brian

Re: OMAP3 NAND ECC selection

[Thomas Petazzoni]

Dear Brian Norris,

On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote:

> > The long term benefits is simply to properly handle the hardware
> > constraints. We have hardware platforms were parts of the NAND *MUST*
> > use 1-bit ECC to be compatible with the ROM code, and other parts of
> > the NAND *MUST* use stronger 4-bits or 8-bits ECC to comply with the
> > NAND requirements.
> 
> Using 1-bit ECC on NAND is not a long-term solution. Given that fact,
> I think your ROM code is what may need to change, not the entire MTD
> subsystem.

As someone (Tom Rini maybe?) pointed out, today the shift is 1-bit ECC
supported by ROM code vs. 4 or 8 bits required by NAND. But we can very
well imagine that tomorrow ROM code will support BCH4 (and the NAND
will ensure block 0 is OK for use with BCH4) but the rest of the NAND
will require BCH16 or something like that.

I'm not designing ROM code, and the fact that they today have this
limitation, should be an indication that Linux should be capable of
handling different ECC schemes to handle those hardware constraints.

> > Isn't handling hardware constraints properly not a sufficient
> > motivation for doing something?
> 
> I'm not convinced your hardware constraints are reasonable or
> generally useful. But I could be convinced otherwise.

They may not be reasonable, but they exist :)

> >> Also, any constrain due to ROM code, or upgrading from remote can be
> >> handled using various alternative approaches like [a] and [b].
> >
> > And you're not realizing that these solutions are ugly and impractical?
> 
> Solution [a] is both ugly and impractical. Solution [b] is only a
> little ugly but quite practical (you could flesh out a better
> user-space ECC library, then combine it with nanddump/nandwrite
> --noecc). Rewriting both the MTD and NAND layers is not exactly
> practical and may still yield something ugly.

It's not practical because it wasn't thought like this originally, but
technically speaking, being able to use a different ECC scheme for
different areas of the NAND makes a lot of sense.

That being said, it is true that having a good and reusable userspace
tool to write data with arbitrary ECC schemes would be useful to
workaround this situation.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: OMAP3 NAND ECC selection

[Thomas Petazzoni]

Dear Brian Norris,

On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote:

> > The long term benefits is simply to properly handle the hardware
> > constraints. We have hardware platforms were parts of the NAND *MUST*
> > use 1-bit ECC to be compatible with the ROM code, and other parts of
> > the NAND *MUST* use stronger 4-bits or 8-bits ECC to comply with the
> > NAND requirements.
> 
> Using 1-bit ECC on NAND is not a long-term solution. Given that fact,
> I think your ROM code is what may need to change, not the entire MTD
> subsystem.

As someone (Tom Rini maybe?) pointed out, today the shift is 1-bit ECC
supported by ROM code vs. 4 or 8 bits required by NAND. But we can very
well imagine that tomorrow ROM code will support BCH4 (and the NAND
will ensure block 0 is OK for use with BCH4) but the rest of the NAND
will require BCH16 or something like that.

I'm not designing ROM code, and the fact that they today have this
limitation, should be an indication that Linux should be capable of
handling different ECC schemes to handle those hardware constraints.

> > Isn't handling hardware constraints properly not a sufficient
> > motivation for doing something?
> 
> I'm not convinced your hardware constraints are reasonable or
> generally useful. But I could be convinced otherwise.

They may not be reasonable, but they exist :)

> >> Also, any constrain due to ROM code, or upgrading from remote can be
> >> handled using various alternative approaches like [a] and [b].
> >
> > And you're not realizing that these solutions are ugly and impractical?
> 
> Solution [a] is both ugly and impractical. Solution [b] is only a
> little ugly but quite practical (you could flesh out a better
> user-space ECC library, then combine it with nanddump/nandwrite
> --noecc). Rewriting both the MTD and NAND layers is not exactly
> practical and may still yield something ugly.

It's not practical because it wasn't thought like this originally, but
technically speaking, being able to use a different ECC scheme for
different areas of the NAND makes a lot of sense.

That being said, it is true that having a good and reusable userspace
tool to write data with arbitrary ECC schemes would be useful to
workaround this situation.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: OMAP3 NAND ECC selection

[Tony Lindgren]

* Thomas Petazzoni <thomas.petazzoni@free-electrons.com> [131205 11:33]:
> Dear Brian Norris,
> 
> On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote:
> 
> > > The long term benefits is simply to properly handle the hardware
> > > constraints. We have hardware platforms were parts of the NAND *MUST*
> > > use 1-bit ECC to be compatible with the ROM code, and other parts of
> > > the NAND *MUST* use stronger 4-bits or 8-bits ECC to comply with the
> > > NAND requirements.
> > 
> > Using 1-bit ECC on NAND is not a long-term solution. Given that fact,
> > I think your ROM code is what may need to change, not the entire MTD
> > subsystem.
> 
> As someone (Tom Rini maybe?) pointed out, today the shift is 1-bit ECC
> supported by ROM code vs. 4 or 8 bits required by NAND. But we can very
> well imagine that tomorrow ROM code will support BCH4 (and the NAND
> will ensure block 0 is OK for use with BCH4) but the rest of the NAND
> will require BCH16 or something like that.
> 
> I'm not designing ROM code, and the fact that they today have this
> limitation, should be an indication that Linux should be capable of
> handling different ECC schemes to handle those hardware constraints.

Yeah and it seems that for the bootloader partition we need to be able
to specify the ECC scheme in the .dts file to avoid having people trash
their system unless they really want to do it.

/me at least has rebooted and reflashed way too many times unnecessarily
while trying to update MLO or u-boot from the kernel.

Regards,

Tony

Re: OMAP3 NAND ECC selection

[Tony Lindgren]

* Thomas Petazzoni <thomas.petazzoni@free-electrons.com> [131205 11:33]:
> Dear Brian Norris,
> 
> On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote:
> 
> > > The long term benefits is simply to properly handle the hardware
> > > constraints. We have hardware platforms were parts of the NAND *MUST*
> > > use 1-bit ECC to be compatible with the ROM code, and other parts of
> > > the NAND *MUST* use stronger 4-bits or 8-bits ECC to comply with the
> > > NAND requirements.
> > 
> > Using 1-bit ECC on NAND is not a long-term solution. Given that fact,
> > I think your ROM code is what may need to change, not the entire MTD
> > subsystem.
> 
> As someone (Tom Rini maybe?) pointed out, today the shift is 1-bit ECC
> supported by ROM code vs. 4 or 8 bits required by NAND. But we can very
> well imagine that tomorrow ROM code will support BCH4 (and the NAND
> will ensure block 0 is OK for use with BCH4) but the rest of the NAND
> will require BCH16 or something like that.
> 
> I'm not designing ROM code, and the fact that they today have this
> limitation, should be an indication that Linux should be capable of
> handling different ECC schemes to handle those hardware constraints.

Yeah and it seems that for the bootloader partition we need to be able
to specify the ECC scheme in the .dts file to avoid having people trash
their system unless they really want to do it.

/me at least has rebooted and reflashed way too many times unnecessarily
while trying to update MLO or u-boot from the kernel.

Regards,

Tony

Re: OMAP3 NAND ECC selection

[Peter Meerwald]

Hello, 

> Meanwhile, to do this we use a small userspace program created by
> Javier Martinez in order to flash the MLO in our OMAP3 boards. See
> 
> http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary

I tried this with a 3.7 kernel and the following NAND; it does not work 
for me

# ./writeloader -i /boot/u-boot.img  -o /dev/mtd1
Error writing ECC in OOB area: Invalid argument

nand_do_write_oob() in nand_base.c fails with
	if ((ops->ooboffs + ops->ooblen) > len) {
		pr_debug("%s: attempt to write past end of page\n",
				__func__);
		return -EINVAL;
	}

ops->ooboffs, ops->ooblen, len is 1536, 64, 64, resp.

write_ecc() in writeloader.c does
	oob.start = (sector_cnt - 1) * SECTOR_SIZE;
	oob.ptr = oobbuf;
	oob.length = 64;

	return ioctl(ofd, MEMWRITEOOB, &oob) != 0;
where sector_cnt is 4

this looks weird to me -- any ideas?

NAND device: Manufacturer ID: 0x2c, Chip ID: 0xbc (Micron NAND 512MiB 1,8V 16-bit), page size: 2048, OOB size: 64

# ./mtdinfo  -a
Count of MTD devices:           6
Present MTD devices:            mtd0, mtd1, mtd2, mtd3, mtd4, mtd5
Sysfs interface supported:      yes

mtd0
Name:                           MLO
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          4 (524288 bytes, 512.0 KiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  512 bytes
OOB size:                       64 bytes
Character device major/minor:   90:0
Bad blocks are allowed:         true
Device is writable:             true

mtd1
Name:                           u-Boot
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          4 (524288 bytes, 512.0 KiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  512 bytes
OOB size:                       64 bytes
Character device major/minor:   90:2
Bad blocks are allowed:         true
Device is writable:             true

thanks, regards, p.

-- 

Peter Meerwald
+43-664-2444418 (mobile)

Re: OMAP3 NAND ECC selection

[Peter Meerwald]

Hello, 

> Meanwhile, to do this we use a small userspace program created by
> Javier Martinez in order to flash the MLO in our OMAP3 boards. See
> 
> http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary

I tried this with a 3.7 kernel and the following NAND; it does not work 
for me

# ./writeloader -i /boot/u-boot.img  -o /dev/mtd1
Error writing ECC in OOB area: Invalid argument

nand_do_write_oob() in nand_base.c fails with
	if ((ops->ooboffs + ops->ooblen) > len) {
		pr_debug("%s: attempt to write past end of page\n",
				__func__);
		return -EINVAL;
	}

ops->ooboffs, ops->ooblen, len is 1536, 64, 64, resp.

write_ecc() in writeloader.c does
	oob.start = (sector_cnt - 1) * SECTOR_SIZE;
	oob.ptr = oobbuf;
	oob.length = 64;

	return ioctl(ofd, MEMWRITEOOB, &oob) != 0;
where sector_cnt is 4

this looks weird to me -- any ideas?

NAND device: Manufacturer ID: 0x2c, Chip ID: 0xbc (Micron NAND 512MiB 1,8V 16-bit), page size: 2048, OOB size: 64

# ./mtdinfo  -a
Count of MTD devices:           6
Present MTD devices:            mtd0, mtd1, mtd2, mtd3, mtd4, mtd5
Sysfs interface supported:      yes

mtd0
Name:                           MLO
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          4 (524288 bytes, 512.0 KiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  512 bytes
OOB size:                       64 bytes
Character device major/minor:   90:0
Bad blocks are allowed:         true
Device is writable:             true

mtd1
Name:                           u-Boot
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          4 (524288 bytes, 512.0 KiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  512 bytes
OOB size:                       64 bytes
Character device major/minor:   90:2
Bad blocks are allowed:         true
Device is writable:             true

thanks, regards, p.

-- 

Peter Meerwald
+43-664-2444418 (mobile)

Re: OMAP3 NAND ECC selection

[Andreas Bießmann]

[-- Attachment #1: Type: text/plain, Size: 1243 bytes --]

On 12/05/2013 06:13 PM, Tony Lindgren wrote:
> * Peter Meerwald <pmeerw@pmeerw.net> [131205 08:13]:
>>>>> I'd like to be able to update MLO and u-boot from within a booted Linux
>>>>> system on the device (I have to resort to u-boot for that where I can
>>>>> control the ECC scheme used)
>>
>>>> Meanwhile, to do this we use a small userspace program created by
>>>> Javier Martinez in order to flash the MLO in our OMAP3 boards. See
>>>> http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary
>>
>>> we used another aproach here. See
>>> http://article.gmane.org/gmane.linux.drivers.mtd/43804
>>
>> pretty much what I have been looking for, thanks!
> 
> Hmm well both methods should work, but is there anything stopping us
> merging the module param patch to the mainline tree?

We could do so, should I provide a proper patch?
On the other hand I think this approach is a workaround to circumvent
the MTD architecture flaws mostly needed in embedded systems where we
control the whole environment. Should we really introduce this switch to
the whole bunch of users working with mainline distros on their beagle
style HW?
I think the user space tool approach is more useful there.

regards

Andreas Bießmann


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: OMAP3 NAND ECC selection

[Mike Dunn]

On 12/05/2013 11:38 AM, Tony Lindgren wrote:
> * Thomas Petazzoni <thomas.petazzoni@free-electrons.com> [131205 11:33]:
>> Dear Brian Norris,
>>
>> On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote:
>>
>>>> The long term benefits is simply to properly handle the hardware
>>>> constraints. We have hardware platforms were parts of the NAND *MUST*
>>>> use 1-bit ECC to be compatible with the ROM code, and other parts of
>>>> the NAND *MUST* use stronger 4-bits or 8-bits ECC to comply with the
>>>> NAND requirements.
>>>
>>> Using 1-bit ECC on NAND is not a long-term solution. Given that fact,
>>> I think your ROM code is what may need to change, not the entire MTD
>>> subsystem.
>>
>> As someone (Tom Rini maybe?) pointed out, today the shift is 1-bit ECC
>> supported by ROM code vs. 4 or 8 bits required by NAND. But we can very
>> well imagine that tomorrow ROM code will support BCH4 (and the NAND
>> will ensure block 0 is OK for use with BCH4) but the rest of the NAND
>> will require BCH16 or something like that.
>>
>> I'm not designing ROM code, and the fact that they today have this
>> limitation, should be an indication that Linux should be capable of
>> handling different ECC schemes to handle those hardware constraints.
> 
> Yeah and it seems that for the bootloader partition we need to be able
> to specify the ECC scheme in the .dts file to avoid having people trash
> their system unless they really want to do it.
> 
> /me at least has rebooted and reflashed way too many times unnecessarily
> while trying to update MLO or u-boot from the kernel.


The M-Sys/Sandisk docg4 flash chip has a similiar issue, but is even more
esoteric than merely a different ecc scheme for the SPL/u-boot partition.  Not
only is a different ecc scheme used for the SPL (actually it uses no ecc at
all), but the flash controller must be placed into a special (proprietary) mode
("reliable mode") before the SPL is written.  Like the omap2 solution, the docg4
driver can be loaded with a special module parameter that enables writing the
SPL partition in this mode.

The docg4 is kind of a special case, though, because it is a nand flash wrapped
inside a proprietary non-standard flash controller.

Mike


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

Re: OMAP3 NAND ECC selection

[Mike Dunn]

On 12/05/2013 11:38 AM, Tony Lindgren wrote:
> * Thomas Petazzoni <thomas.petazzoni@free-electrons.com> [131205 11:33]:
>> Dear Brian Norris,
>>
>> On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote:
>>
>>>> The long term benefits is simply to properly handle the hardware
>>>> constraints. We have hardware platforms were parts of the NAND *MUST*
>>>> use 1-bit ECC to be compatible with the ROM code, and other parts of
>>>> the NAND *MUST* use stronger 4-bits or 8-bits ECC to comply with the
>>>> NAND requirements.
>>>
>>> Using 1-bit ECC on NAND is not a long-term solution. Given that fact,
>>> I think your ROM code is what may need to change, not the entire MTD
>>> subsystem.
>>
>> As someone (Tom Rini maybe?) pointed out, today the shift is 1-bit ECC
>> supported by ROM code vs. 4 or 8 bits required by NAND. But we can very
>> well imagine that tomorrow ROM code will support BCH4 (and the NAND
>> will ensure block 0 is OK for use with BCH4) but the rest of the NAND
>> will require BCH16 or something like that.
>>
>> I'm not designing ROM code, and the fact that they today have this
>> limitation, should be an indication that Linux should be capable of
>> handling different ECC schemes to handle those hardware constraints.
> 
> Yeah and it seems that for the bootloader partition we need to be able
> to specify the ECC scheme in the .dts file to avoid having people trash
> their system unless they really want to do it.
> 
> /me at least has rebooted and reflashed way too many times unnecessarily
> while trying to update MLO or u-boot from the kernel.


The M-Sys/Sandisk docg4 flash chip has a similiar issue, but is even more
esoteric than merely a different ecc scheme for the SPL/u-boot partition.  Not
only is a different ecc scheme used for the SPL (actually it uses no ecc at
all), but the flash controller must be placed into a special (proprietary) mode
("reliable mode") before the SPL is written.  Like the omap2 solution, the docg4
driver can be loaded with a special module parameter that enables writing the
SPL partition in this mode.

The docg4 is kind of a special case, though, because it is a nand flash wrapped
inside a proprietary non-standard flash controller.

Mike

RE: OMAP3 NAND ECC selection

[Gupta, Pekon]

Hi,

>From: Thomas Petazzoni [mailto:thomas.petazzoni@free-electrons.com]
>>On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote:
[...]

>> Using 1-bit ECC on NAND is not a long-term solution. Given that fact,
>> I think your ROM code is what may need to change, not the entire MTD
>> subsystem.
>
>As someone (Tom Rini maybe?) pointed out, today the shift is 1-bit ECC
>supported by ROM code vs. 4 or 8 bits required by NAND. But we can very
>well imagine that tomorrow ROM code will support BCH4 (and the NAND
>will ensure block 0 is OK for use with BCH4) but the rest of the NAND
>will require BCH16 or something like that.
>
>I'm not designing ROM code, and the fact that they today have this
>limitation, should be an indication that Linux should be capable of
>handling different ECC schemes to handle those hardware constraints.
>
Just to highlight few more points:
(1) ROM code on newer OMAP platforms like AM33xx do have the ability
to select ECC scheme by reading a specific location from EEPROM
connected to I2C0. 
Reference:
	http://www.ti.com/product/am3359
	http://www.ti.com/litv/pdf/spruh73i 
	Chapter 26: Initialization  
	Section: 26.1.7.4  Memory Booting > NAND
  	Table 26-17. NAND Geometry Information on I2C EEPROM

(2) And going forward, ECC based NAND devices may be phased out,
and BE-NAND (Built-in) NAND devices are becoming popular. As both
cost and density wise they are same to SLC NANDs today.  Thus issue
of un-compatibility of ecc-scheme with ROM code, will not hold true.
We already have some BE-NAND support in our generic driver.
http://patchwork.ozlabs.org/patch/222186/

However, I also support user space tool approach rather than having
this included in NAND driver.


with regards, pekon

RE: OMAP3 NAND ECC selection

[Gupta, Pekon]

Hi,

>From: Thomas Petazzoni [mailto:thomas.petazzoni@free-electrons.com]
>>On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote:
[...]

>> Using 1-bit ECC on NAND is not a long-term solution. Given that fact,
>> I think your ROM code is what may need to change, not the entire MTD
>> subsystem.
>
>As someone (Tom Rini maybe?) pointed out, today the shift is 1-bit ECC
>supported by ROM code vs. 4 or 8 bits required by NAND. But we can very
>well imagine that tomorrow ROM code will support BCH4 (and the NAND
>will ensure block 0 is OK for use with BCH4) but the rest of the NAND
>will require BCH16 or something like that.
>
>I'm not designing ROM code, and the fact that they today have this
>limitation, should be an indication that Linux should be capable of
>handling different ECC schemes to handle those hardware constraints.
>
Just to highlight few more points:
(1) ROM code on newer OMAP platforms like AM33xx do have the ability
to select ECC scheme by reading a specific location from EEPROM
connected to I2C0. 
Reference:
	http://www.ti.com/product/am3359
	http://www.ti.com/litv/pdf/spruh73i 
	Chapter 26: Initialization  
	Section: 26.1.7.4  Memory Booting > NAND
  	Table 26-17. NAND Geometry Information on I2C EEPROM

(2) And going forward, ECC based NAND devices may be phased out,
and BE-NAND (Built-in) NAND devices are becoming popular. As both
cost and density wise they are same to SLC NANDs today.  Thus issue
of un-compatibility of ecc-scheme with ROM code, will not hold true.
We already have some BE-NAND support in our generic driver.
http://patchwork.ozlabs.org/patch/222186/

However, I also support user space tool approach rather than having
this included in NAND driver.


with regards, pekon

Re: OMAP3 NAND ECC selection

[Matthieu CASTET]

Le Mon, 9 Dec 2013 04:33:51 +0000,
"Gupta, Pekon" <pekon@ti.com> a écrit :

> Hi,
> 
> >From: Thomas Petazzoni [mailto:thomas.petazzoni@free-electrons.com]
> >>On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote:
> [...]
> 
> >> Using 1-bit ECC on NAND is not a long-term solution. Given that
> >> fact, I think your ROM code is what may need to change, not the
> >> entire MTD subsystem.
> >
> >As someone (Tom Rini maybe?) pointed out, today the shift is 1-bit
> >ECC supported by ROM code vs. 4 or 8 bits required by NAND. But we
> >can very well imagine that tomorrow ROM code will support BCH4 (and
> >the NAND will ensure block 0 is OK for use with BCH4) but the rest
> >of the NAND will require BCH16 or something like that.
> >
> >I'm not designing ROM code, and the fact that they today have this
> >limitation, should be an indication that Linux should be capable of
> >handling different ECC schemes to handle those hardware constraints.
> >
> Just to highlight few more points:
> (1) ROM code on newer OMAP platforms like AM33xx do have the ability
> to select ECC scheme by reading a specific location from EEPROM
> connected to I2C0. 
AFAIK on omap3, the rom code first try to read data with bch and if it
doesn't work it fallback on haming 1 bit ecc.

> 
> (2) And going forward, ECC based NAND devices may be phased out,
> and BE-NAND (Built-in) NAND devices are becoming popular. As both
> cost and density wise they are same to SLC NANDs today.  Thus issue
> of un-compatibility of ecc-scheme with ROM code, will not hold true.
> We already have some BE-NAND support in our generic driver.
> http://patchwork.ozlabs.org/patch/222186/
> 
Yes but these flash are not always compatible with the ROM.

If the rom is expecting some ECC and the internal controller expect
other ecc you are stuck.


Matthieu

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

Re: OMAP3 NAND ECC selection

[Matthieu CASTET]

Le Mon, 9 Dec 2013 04:33:51 +0000,
"Gupta, Pekon" <pekon@ti.com> a écrit :

> Hi,
> 
> >From: Thomas Petazzoni [mailto:thomas.petazzoni@free-electrons.com]
> >>On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote:
> [...]
> 
> >> Using 1-bit ECC on NAND is not a long-term solution. Given that
> >> fact, I think your ROM code is what may need to change, not the
> >> entire MTD subsystem.
> >
> >As someone (Tom Rini maybe?) pointed out, today the shift is 1-bit
> >ECC supported by ROM code vs. 4 or 8 bits required by NAND. But we
> >can very well imagine that tomorrow ROM code will support BCH4 (and
> >the NAND will ensure block 0 is OK for use with BCH4) but the rest
> >of the NAND will require BCH16 or something like that.
> >
> >I'm not designing ROM code, and the fact that they today have this
> >limitation, should be an indication that Linux should be capable of
> >handling different ECC schemes to handle those hardware constraints.
> >
> Just to highlight few more points:
> (1) ROM code on newer OMAP platforms like AM33xx do have the ability
> to select ECC scheme by reading a specific location from EEPROM
> connected to I2C0. 
AFAIK on omap3, the rom code first try to read data with bch and if it
doesn't work it fallback on haming 1 bit ecc.

> 
> (2) And going forward, ECC based NAND devices may be phased out,
> and BE-NAND (Built-in) NAND devices are becoming popular. As both
> cost and density wise they are same to SLC NANDs today.  Thus issue
> of un-compatibility of ecc-scheme with ROM code, will not hold true.
> We already have some BE-NAND support in our generic driver.
> http://patchwork.ozlabs.org/patch/222186/
> 
Yes but these flash are not always compatible with the ROM.

If the rom is expecting some ECC and the internal controller expect
other ecc you are stuck.


Matthieu

RE: OMAP3 NAND ECC selection

[Gupta, Pekon]

>From: Matthieu CASTET [mailto:matthieu.castet@parrot.com]
>> From: Pekon Gupta [mailto: pekon@ti.com]
>> >From: Thomas Petazzoni [mailto:thomas.petazzoni@free-electrons.com]
>> >>On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote:
[...]
>> >> Using 1-bit ECC on NAND is not a long-term solution. Given that
>> >> fact, I think your ROM code is what may need to change, not the
>> >> entire MTD subsystem.
>> >
>> >As someone (Tom Rini maybe?) pointed out, today the shift is 1-bit
>> >ECC supported by ROM code vs. 4 or 8 bits required by NAND. But we
>> >can very well imagine that tomorrow ROM code will support BCH4 (and
>> >the NAND will ensure block 0 is OK for use with BCH4) but the rest
>> >of the NAND will require BCH16 or something like that.
>> >
>> >I'm not designing ROM code, and the fact that they today have this
>> >limitation, should be an indication that Linux should be capable of
>> >handling different ECC schemes to handle those hardware constraints.
>> >
>> Just to highlight few more points:
>> (1) ROM code on newer OMAP platforms like AM33xx do have the ability
>> to select ECC scheme by reading a specific location from EEPROM
>> connected to I2C0.
>> 
>AFAIK on omap3, the rom code first try to read data with bch and if it
>doesn't work it fallback on haming 1 bit ecc.
>
I'm afraid, the OMAP35xx TRM does give much information about BCH
ecc-scheme being used by ROM code. Though it says that BCH4 ecc-scheme
would be selected for booting in cases when NAND_ID2 matches a
particular value. But nothing much is clear (Reference [1]).
Can you please point me to any other document or link which gives more
info about the same ?


>> (2) And going forward, ECC based NAND devices may be phased out,
>> and BE-NAND (Built-in) NAND devices are becoming popular. As both
>> cost and density wise they are same to SLC NANDs today.  Thus issue
>> of un-compatibility of ecc-scheme with ROM code, will not hold true.
>> We already have some BE-NAND support in our generic driver.
>> http://patchwork.ozlabs.org/patch/222186/
>>
>Yes but these flash are not always compatible with the ROM.
>
>If the rom is expecting some ECC and the internal controller expect
>other ecc you are stuck.
>
For AM33xx and newer DRA7xx platforms, allows user to explicitly select
between no ECC, BCH8 or BCH16. Thus ROM code of newer OMAP devices
supports BE-NAND. (refer [2]).

[1]	http://www.ti.com/product/omap3530
	http://www.ti.com/litv/pdf/spruf98x
	Chapter 25: Initialization
	 Section 25.4.7.4 NAND
	Table 25-34. ID2 Byte Description

[2] 	http://www.ti.com/product/am3359
	http://www.ti.com/litv/pdf/spruh73i 
	Chapter 26: Initialization  
	Section: 26.1.7.4  Memory Booting > NAND
  	Table 26-17. NAND Geometry Information on I2C EEPROM

with regards, pekon

RE: OMAP3 NAND ECC selection

[Gupta, Pekon]

>From: Matthieu CASTET [mailto:matthieu.castet@parrot.com]
>> From: Pekon Gupta [mailto: pekon@ti.com]
>> >From: Thomas Petazzoni [mailto:thomas.petazzoni@free-electrons.com]
>> >>On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote:
[...]
>> >> Using 1-bit ECC on NAND is not a long-term solution. Given that
>> >> fact, I think your ROM code is what may need to change, not the
>> >> entire MTD subsystem.
>> >
>> >As someone (Tom Rini maybe?) pointed out, today the shift is 1-bit
>> >ECC supported by ROM code vs. 4 or 8 bits required by NAND. But we
>> >can very well imagine that tomorrow ROM code will support BCH4 (and
>> >the NAND will ensure block 0 is OK for use with BCH4) but the rest
>> >of the NAND will require BCH16 or something like that.
>> >
>> >I'm not designing ROM code, and the fact that they today have this
>> >limitation, should be an indication that Linux should be capable of
>> >handling different ECC schemes to handle those hardware constraints.
>> >
>> Just to highlight few more points:
>> (1) ROM code on newer OMAP platforms like AM33xx do have the ability
>> to select ECC scheme by reading a specific location from EEPROM
>> connected to I2C0.
>> 
>AFAIK on omap3, the rom code first try to read data with bch and if it
>doesn't work it fallback on haming 1 bit ecc.
>
I'm afraid, the OMAP35xx TRM does give much information about BCH
ecc-scheme being used by ROM code. Though it says that BCH4 ecc-scheme
would be selected for booting in cases when NAND_ID2 matches a
particular value. But nothing much is clear (Reference [1]).
Can you please point me to any other document or link which gives more
info about the same ?


>> (2) And going forward, ECC based NAND devices may be phased out,
>> and BE-NAND (Built-in) NAND devices are becoming popular. As both
>> cost and density wise they are same to SLC NANDs today.  Thus issue
>> of un-compatibility of ecc-scheme with ROM code, will not hold true.
>> We already have some BE-NAND support in our generic driver.
>> http://patchwork.ozlabs.org/patch/222186/
>>
>Yes but these flash are not always compatible with the ROM.
>
>If the rom is expecting some ECC and the internal controller expect
>other ecc you are stuck.
>
For AM33xx and newer DRA7xx platforms, allows user to explicitly select
between no ECC, BCH8 or BCH16. Thus ROM code of newer OMAP devices
supports BE-NAND. (refer [2]).

[1]	http://www.ti.com/product/omap3530
	http://www.ti.com/litv/pdf/spruf98x
	Chapter 25: Initialization
	 Section 25.4.7.4 NAND
	Table 25-34. ID2 Byte Description

[2] 	http://www.ti.com/product/am3359
	http://www.ti.com/litv/pdf/spruh73i 
	Chapter 26: Initialization  
	Section: 26.1.7.4  Memory Booting > NAND
  	Table 26-17. NAND Geometry Information on I2C EEPROM

with regards, pekon