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@xxxxxxxxx> 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 > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
