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

[matti kaasinen]

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