Re: OMAP3 NAND ECC selection

[Thomas Petazzoni <thomas.petazzoni@free-electrons.com>]

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