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@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:
- Are my findings correct or should I try try find something else?
- 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