[U-Boot] u-boot hw assisted BCH8 not compatible with am335x architecure

[matti kaasinen]

Editing those findings did not help.
In fact I was referring a wrong file in my last message. File README.omap3
refers to is:
arch/arm/include/asm/arch-omap3/omap_gpmc.h
Whereas in my last message I was referring:
arch/arm/include/asm/arch-am33x/omap_gpmc.h

However, there was one mistake also in that correct file.  Definition found
in that file has wrong .eccbytes value.

#define GPMC_NAND_HW_BCH8_ECC_LAYOUT {\
    .eccbytes = 56,\
    .eccpos = {12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22,\

            23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36,\
            37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50,\
            51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63},\
    .oobfree = {\
        {.offset = 2,\
         .length = 10 } } \
}


Unfortunately fixing that to correct value 52 did not help either.

-Matti


2013/10/25 matti kaasinen <matti.kaasinen at gmail.com>

> Hi!
> I have found that ubifs formatted on Linux (2.8.13) side is not compatible
> on u-boot side. Executing ubi part <partition> throws tons of ECC error
> messages and in fact this same ubifs partition will be found corrupted on
> Linux side immediately after this single operation. I have investigated
> this issue and have found following:
>
> Linux 3.8.13 seems to use 52 ecc bytes mapping them to positions 12..64.
>
> Default u-boot set-up found from include/asm/arch-am33x/omap_gpmc.h define:
> #define GPMC_NAND_HW_BCH8_ECC_LAYOUT {\
>     .eccbytes = 56,\
>     .eccpos = {2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,\
>                 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27,\
>                 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39,\
>                 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51,\
>                 52, 53, 54, 55, 56, 57},\
>     .oobfree = {\
>         {.offset = 58,\
>          .length = 6 } } \
> }
> that seems using 56 ecc bytes, mapping them to positions 2..57.
> This 56 bytes seems fighting with the fact found from README.omap3/BCH8
> set-up that points, that
>  * CONFIG_SYS_NAND_ECCBYTES must be 13 for this BCH8 set-up
> On the other hand, am335x_evm.h use CONFIG_SYS_NAND_ECCBYTES to calculate
> CONFIG_SYS_NAND_ECCTOTAL that is same as .eccbytes in
> GPMC_NAND_HW_BCH8_ECC_LAYOUT definition. Value 13 gives 52 bytes that is
> compatible with Linux whereas 14 gives that 56 found from
> GPMC_NAND_HW_BCH8_ECC_LAYOUT definition above.
>
> Also text in README.omap3 states:
> "The NAND OOB layout is the same as in linux kernel, if the linux kernel
> BCH8
> implementation for OMAP3 works for you so the u-boot version should also.
> When you require the SPL to read with BCH8 there are two more configs to
> change:
>
>  * CONFIG_SYS_NAND_ECCPOS (must be the same as .eccpos in
>    GPMC_NAND_HW_BCH8_ECC_LAYOUT defined in
>    arch/arm/include/asm/arch-omap3/omap_gpmc.h)
>  * CONFIG_SYS_NAND_ECCSIZE must be 512
>  * CONFIG_SYS_NAND_ECCBYTES must be 13 for this BCH8 setup"
>
> I would interpret this so that no modifications are needed
> GPMC_NAND_HW_BCH8_ECC_LAYOUT structure.
> That can't be true even if the mapping was the same as .eccbytes field hae
> wrong value considering what the last line states for BCH8 set-up.
> If above assumption is correct, isn't this really a bug in omap_gpmc.h,
> not just a Linux version related problem?
>
> My questions are:
> 1) Are my findings correct or should I try try find something else?
> 2) If 1) ok, then should I edit both omap_gpmc.h and am335x_evm.h or just
> one of them?
> 3) Is there anything else to be taken into account?
>
> Best regards,
> Matti
>