[PATCH v3 4/4] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND

[Philip, Avinash]

On Wed, Nov 21, 2012 at 15:45:23, Daniel Mack wrote:
> On 20.11.2012 16:59, Peter Korsgaard wrote:
> >>>>>> "Daniel" == Daniel Mack <zonque at gmail.com> writes:
> > 
> > Hi,
> > 
> >  >>>> In omap2 driver NAND_ECC_HW ecc mode supports 3 ecc layout
> >  >>>> OMAP_ECC_HAMMING_CODE_HW_ROMCODE
> >  >>>> OMAP_ECC_BCH4_CODE_HW
> >  >>>> OMAP_ECC_BCH8_CODE_HW
> >  >>>> 
> >  >>>> So selection of ecc layout data should come from DT not ecc mode.
> >  >>> 
> >  >>> Ok, I see. I would still like to set them by string rather than magic
> >  >>> numbers that map to enum entries. Valid values would be "none", "hw",
> >  >>> "hw-romcode", "bch4" and "bch8". Are you ok with that?
> >  >> 
> >  >> Ok, that's nice. Better use ecc_opt instead of ecc_mode.
> > 
> >  Daniel> I did some more extensive tests that include reading the same
> >  Daniel> nand pages from both U-Boot and the kernel with BCH8 ECC, and
> >  Daniel> it turns out that -> is_elm_used needs to be set in the pdata
> >  Daniel> in order to make this work.
> > 
> > So what you're saying is that the choice of ELM or not is not just an
> > optimization, it really changes the ECC layout? Perhaps it should be
> > treated as a seperate layout (E.G. bch8-elm) then?

Peter,

In patch [1], mtd: nand: omap2: Support for hardware BCH

ecc_layout made compatible with Rom Boot Loader ECC layout for am335x.

This action is based on is_elm_used flag.

Requirement of this flag is to identify the whether the platform
ELM module & based on this configure ELM module if present.

But ideally BCH8 ecc lay out didn't have a dependency on ELM, it
can work with software BCH ecc. RBL compatibility is missing
in software BCH because of addition of constant polynomial to
ecc vector. If we remove the dependency on erased page handling
by ecc vector with constant polynomial, software BCH can do the
job of RBL compatibility.

Ivan,
Do you have any suggestions?
Discussion for RBL compatibility found at [2].

It is good that software BCH also support RBL compatibility by suppressing
constant polynomial modification. Then ecc layout can be selected from
DT entry and error correction can be chosen between software/hardware
depending on the availability of ELM hardware.
Currently RBL BCH8 compatibility depends on the availability of ELM
hardware. Later once software BCH start supporting RBL compatibility,
we can remove  the check.

> 
> That is what I experienced, yes. The kernel was unable to parse NAND
> pages that were written from U-Boot with bch8 hardware mode when the elm
> module was not active. Maybe someone from TI can explain that? Giving it
> a dedicated name would also solve the problem with the extra DT property.

Daniel,

Currently BCH8 is supported with software ecc error correction in mainline.
The layout for BCH8 ECC layout is
0-1 -> BAD block markers
2-11-> oob free area
12-63-> BCH8 ECC.

RBL ECC layout is
0-1 -> BAD block markers
2-57-> BCH8 ecc layout
58-63-> OOB free area

As u-boot also maintain RBL ecc layout, write from U-boot
and read from Linux requires compatibility with RBL ecc layout.
The same is achieved in the patch [1], with by setting is_elm_used
to true.

1. https://lkml.org/lkml/2012/10/31/87
2. https://lkml.org/lkml/2012/10/11/20

Thanks
Avinash
> 
> I'll wait until this is decided before I resend a new set that also
> fixes the issue with the errornousely forgotten Documentation file.
> 
> 
> Thanks,
> Daniel
> 
>