OMAP3 NAND ECC selection

[Brian Norris]

On Thu, Dec 5, 2013 at 11:06 AM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> On Thu, 5 Dec 2013 19:02:22 +0000, Gupta, Pekon wrote:
>
>> >From: Ezequiel Garcia [mailto:ezequiel.garcia at 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