* Re: OMAP3 NAND ECC selection
@ 2013-12-05 18:26 ` Ezequiel Garcia
0 siblings, 0 replies; 36+ messages in thread
From: Ezequiel Garcia @ 2013-12-05 18:26 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Tony Lindgren, Gupta, Pekon, Thomas Petazzoni,
Enric Balletbo Serra, linux-mtd, linux-omap@vger.kernel.org,
Andreas Bießmann, Peter Meerwald, Brian Norris
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: OMAP3 NAND ECC selection
2013-12-05 18:26 ` Ezequiel Garcia
@ 2013-12-05 18:58 ` Javier Martinez Canillas
-1 siblings, 0 replies; 36+ messages in thread
From: Javier Martinez Canillas @ 2013-12-05 18:58 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Thomas Petazzoni, Brian Norris, Tony Lindgren,
Enric Balletbo Serra, linux-mtd, Gupta, Pekon, Peter Meerwald,
linux-omap@vger.kernel.org, Andreas Bießmann
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: OMAP3 NAND ECC selection
@ 2013-12-05 18:58 ` Javier Martinez Canillas
0 siblings, 0 replies; 36+ messages in thread
From: Javier Martinez Canillas @ 2013-12-05 18:58 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Tony Lindgren, Gupta, Pekon, Thomas Petazzoni,
Enric Balletbo Serra, linux-mtd, linux-omap@vger.kernel.org,
Andreas Bießmann, Peter Meerwald, Brian Norris
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: OMAP3 NAND ECC selection
2013-12-05 18:26 ` Ezequiel Garcia
@ 2013-12-05 19:02 ` Gupta, Pekon
-1 siblings, 0 replies; 36+ messages in thread
From: Gupta, Pekon @ 2013-12-05 19:02 UTC (permalink / raw)
To: Ezequiel Garcia, Javier Martinez Canillas
Cc: Thomas Petazzoni, Brian Norris, Tony Lindgren,
Enric Balletbo Serra, linux-mtd@lists.infradead.org,
Peter Meerwald, linux-omap@vger.kernel.org, Andreas Bießmann
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: OMAP3 NAND ECC selection
@ 2013-12-05 19:02 ` Gupta, Pekon
0 siblings, 0 replies; 36+ messages in thread
From: Gupta, Pekon @ 2013-12-05 19:02 UTC (permalink / raw)
To: Ezequiel Garcia, Javier Martinez Canillas
Cc: Tony Lindgren, Thomas Petazzoni, Enric Balletbo Serra,
linux-mtd@lists.infradead.org, linux-omap@vger.kernel.org,
Andreas Bießmann, Peter Meerwald, Brian Norris
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: OMAP3 NAND ECC selection
2013-12-05 19:02 ` Gupta, Pekon
@ 2013-12-05 19:06 ` Thomas Petazzoni
-1 siblings, 0 replies; 36+ messages in thread
From: Thomas Petazzoni @ 2013-12-05 19:06 UTC (permalink / raw)
To: Gupta, Pekon
Cc: Brian Norris, Peter Meerwald, Tony Lindgren, Enric Balletbo Serra,
linux-mtd@lists.infradead.org, Ezequiel Garcia,
Javier Martinez Canillas, linux-omap@vger.kernel.org,
Andreas Bießmann
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: OMAP3 NAND ECC selection
@ 2013-12-05 19:06 ` Thomas Petazzoni
0 siblings, 0 replies; 36+ messages in thread
From: Thomas Petazzoni @ 2013-12-05 19:06 UTC (permalink / raw)
To: Gupta, Pekon
Cc: Ezequiel Garcia, Javier Martinez Canillas, Tony Lindgren,
Enric Balletbo Serra, linux-mtd@lists.infradead.org,
linux-omap@vger.kernel.org, Andreas Bießmann, Peter Meerwald,
Brian Norris
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: OMAP3 NAND ECC selection
2013-12-05 19:06 ` Thomas Petazzoni
@ 2013-12-05 19:24 ` Brian Norris
-1 siblings, 0 replies; 36+ messages in thread
From: Brian Norris @ 2013-12-05 19:24 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Peter Meerwald, Tony Lindgren, Enric Balletbo Serra,
linux-mtd@lists.infradead.org, Gupta, Pekon, Ezequiel Garcia,
Javier Martinez Canillas, linux-omap@vger.kernel.org,
Andreas Bießmann
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: OMAP3 NAND ECC selection
@ 2013-12-05 19:24 ` Brian Norris
0 siblings, 0 replies; 36+ messages in thread
From: Brian Norris @ 2013-12-05 19:24 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Gupta, Pekon, Ezequiel Garcia, Javier Martinez Canillas,
Tony Lindgren, Enric Balletbo Serra,
linux-mtd@lists.infradead.org, linux-omap@vger.kernel.org,
Andreas Bießmann, Peter Meerwald
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: OMAP3 NAND ECC selection
2013-12-05 19:24 ` Brian Norris
@ 2013-12-05 19:32 ` Thomas Petazzoni
-1 siblings, 0 replies; 36+ messages in thread
From: Thomas Petazzoni @ 2013-12-05 19:32 UTC (permalink / raw)
To: Brian Norris
Cc: Peter Meerwald, Tony Lindgren, Enric Balletbo Serra,
linux-mtd@lists.infradead.org, Gupta, Pekon, Ezequiel Garcia,
Javier Martinez Canillas, linux-omap@vger.kernel.org,
Andreas Bießmann
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: OMAP3 NAND ECC selection
@ 2013-12-05 19:32 ` Thomas Petazzoni
0 siblings, 0 replies; 36+ messages in thread
From: Thomas Petazzoni @ 2013-12-05 19:32 UTC (permalink / raw)
To: Brian Norris
Cc: Gupta, Pekon, Ezequiel Garcia, Javier Martinez Canillas,
Tony Lindgren, Enric Balletbo Serra,
linux-mtd@lists.infradead.org, linux-omap@vger.kernel.org,
Andreas Bießmann, Peter Meerwald
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: OMAP3 NAND ECC selection
2013-12-05 19:32 ` Thomas Petazzoni
@ 2013-12-05 19:38 ` Tony Lindgren
-1 siblings, 0 replies; 36+ messages in thread
From: Tony Lindgren @ 2013-12-05 19:38 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: linux-omap@vger.kernel.org, Peter Meerwald, Enric Balletbo Serra,
linux-mtd@lists.infradead.org, Gupta, Pekon, Ezequiel Garcia,
Javier Martinez Canillas, Brian Norris, Andreas Bießmann
* 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: OMAP3 NAND ECC selection
@ 2013-12-05 19:38 ` Tony Lindgren
0 siblings, 0 replies; 36+ messages in thread
From: Tony Lindgren @ 2013-12-05 19:38 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Brian Norris, Gupta, Pekon, Ezequiel Garcia,
Javier Martinez Canillas, Enric Balletbo Serra,
linux-mtd@lists.infradead.org, linux-omap@vger.kernel.org,
Andreas Bießmann, Peter Meerwald
* 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: OMAP3 NAND ECC selection
2013-12-05 19:38 ` Tony Lindgren
@ 2013-12-08 20:59 ` Mike Dunn
-1 siblings, 0 replies; 36+ messages in thread
From: Mike Dunn @ 2013-12-08 20:59 UTC (permalink / raw)
To: Tony Lindgren
Cc: Thomas Petazzoni, Brian Norris, Ezequiel Garcia,
Enric Balletbo Serra, linux-mtd@lists.infradead.org, Gupta, Pekon,
Peter Meerwald, Javier Martinez Canillas,
linux-omap@vger.kernel.org, Andreas Bießmann
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
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: OMAP3 NAND ECC selection
@ 2013-12-08 20:59 ` Mike Dunn
0 siblings, 0 replies; 36+ messages in thread
From: Mike Dunn @ 2013-12-08 20:59 UTC (permalink / raw)
To: Tony Lindgren
Cc: Thomas Petazzoni, Brian Norris, Ezequiel Garcia,
Enric Balletbo Serra, linux-mtd@lists.infradead.org, Gupta, Pekon,
Peter Meerwald, Javier Martinez Canillas,
linux-omap@vger.kernel.org, Andreas Bießmann
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/
^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: OMAP3 NAND ECC selection
2013-12-05 19:32 ` Thomas Petazzoni
@ 2013-12-09 4:33 ` Gupta, Pekon
-1 siblings, 0 replies; 36+ messages in thread
From: Gupta, Pekon @ 2013-12-09 4:33 UTC (permalink / raw)
To: Thomas Petazzoni, Brian Norris, Mike Dunn
Cc: Peter Meerwald, Tony Lindgren, Enric Balletbo Serra,
linux-mtd@lists.infradead.org, Ezequiel Garcia,
Javier Martinez Canillas, linux-omap@vger.kernel.org,
Andreas Bießmann
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: OMAP3 NAND ECC selection
@ 2013-12-09 4:33 ` Gupta, Pekon
0 siblings, 0 replies; 36+ messages in thread
From: Gupta, Pekon @ 2013-12-09 4:33 UTC (permalink / raw)
To: Thomas Petazzoni, Brian Norris, Mike Dunn
Cc: Ezequiel Garcia, Javier Martinez Canillas, Tony Lindgren,
Enric Balletbo Serra, linux-mtd@lists.infradead.org,
linux-omap@vger.kernel.org, Andreas Bießmann, Peter Meerwald
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: OMAP3 NAND ECC selection
2013-12-09 4:33 ` Gupta, Pekon
@ 2013-12-09 11:06 ` Matthieu CASTET
-1 siblings, 0 replies; 36+ messages in thread
From: Matthieu CASTET @ 2013-12-09 11:06 UTC (permalink / raw)
To: Gupta, Pekon
Cc: Thomas Petazzoni, linux-omap@vger.kernel.org, Mike Dunn,
Ezequiel Garcia, Tony Lindgren, Enric Balletbo Serra,
linux-mtd@lists.infradead.org, Peter Meerwald,
Javier Martinez Canillas, Brian Norris, Andreas Bießmann
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: OMAP3 NAND ECC selection
@ 2013-12-09 11:06 ` Matthieu CASTET
0 siblings, 0 replies; 36+ messages in thread
From: Matthieu CASTET @ 2013-12-09 11:06 UTC (permalink / raw)
To: Gupta, Pekon
Cc: Thomas Petazzoni, linux-omap@vger.kernel.org, Mike Dunn,
Ezequiel Garcia, Tony Lindgren, Enric Balletbo Serra,
linux-mtd@lists.infradead.org, Peter Meerwald,
Javier Martinez Canillas, Brian Norris, Andreas Bießmann
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/
^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: OMAP3 NAND ECC selection
2013-12-09 11:06 ` Matthieu CASTET
@ 2013-12-09 11:50 ` Gupta, Pekon
-1 siblings, 0 replies; 36+ messages in thread
From: Gupta, Pekon @ 2013-12-09 11:50 UTC (permalink / raw)
To: Matthieu CASTET
Cc: Thomas Petazzoni, linux-omap@vger.kernel.org, Mike Dunn,
Ezequiel Garcia, Tony Lindgren, Enric Balletbo Serra,
linux-mtd@lists.infradead.org, Peter Meerwald,
Javier Martinez Canillas, Brian Norris, Andreas Bießmann
>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
^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: OMAP3 NAND ECC selection
@ 2013-12-09 11:50 ` Gupta, Pekon
0 siblings, 0 replies; 36+ messages in thread
From: Gupta, Pekon @ 2013-12-09 11:50 UTC (permalink / raw)
To: Matthieu CASTET
Cc: Thomas Petazzoni, Brian Norris, Mike Dunn, Peter Meerwald,
Tony Lindgren, Enric Balletbo Serra,
linux-mtd@lists.infradead.org, Ezequiel Garcia,
Javier Martinez Canillas, linux-omap@vger.kernel.org,
Andreas Bießmann
>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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: OMAP3 NAND ECC selection
2013-12-05 18:26 ` Ezequiel Garcia
@ 2013-12-05 19:13 ` Brian Norris
-1 siblings, 0 replies; 36+ messages in thread
From: Brian Norris @ 2013-12-05 19:13 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Thomas Petazzoni, Tony Lindgren, Enric Balletbo Serra,
linux-mtd@lists.infradead.org, Gupta, Pekon, Peter Meerwald,
Javier Martinez Canillas, linux-omap@vger.kernel.org,
Andreas Bießmann
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: OMAP3 NAND ECC selection
@ 2013-12-05 19:13 ` Brian Norris
0 siblings, 0 replies; 36+ messages in thread
From: Brian Norris @ 2013-12-05 19:13 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Javier Martinez Canillas, Tony Lindgren, Gupta, Pekon,
Thomas Petazzoni, Enric Balletbo Serra,
linux-mtd@lists.infradead.org, linux-omap@vger.kernel.org,
Andreas Bießmann, Peter Meerwald
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
^ permalink raw reply [flat|nested] 36+ messages in thread