Hi Gary,
I think I have found something that could explain this behaviour. They
happen to be on u-boot side. In fact I just wrote to u-boot mailin list
about this. I'll copy it below:

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 u-boot
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 have
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?

Regards,
Matti


2013/10/25 Gary Thomas <g...@mlbassoc.com>

> On 2013-10-25 00:01, matti kaasinen wrote:
>
>> Hi!
>>
>> Do anyone happen to know how u-boot should be set to access Linux created
>> ubifs partition correctly? I'm working on beaglebone variant board with
>> nand flash addition. Linux side (3.8.13) seems working fine provided that
>> I
>> don't mount it in u-boot side. However, if i do, it gets corrupted. For
>> instance, if I attach Linux created ubifs partition (ubi part
>> <partition>),
>> i will get tons of "ECC: uncorrectable" errors. After re-boot also Linux
>> side will get these errors.
>>
>> I'm using Angstrom distribution with following details.
>> BB_VERSION        = "1.17.0"
>> TARGET_ARCH       = "arm"
>> TARGET_OS         = "linux-gnueabi"
>> MACHINE           = "beaglebone"
>> DISTRO            = "angstrom"
>> DISTRO_VERSION    = "v2012.12"
>> TUNE_FEATURES     = "armv7a vfp neon cortexa8"
>> TARGET_FPU        = "vfp-neon"
>>
>> Any hints warmly appreciated.
>>
>
> Details about your NAND device will probably be necessary as well as the
> actual errors and operations you tried.
>
> I suspect that the problem may have to do with NAND sub-page writes.  I've
> experienced this on other platforms and was able to work around it by not
> letting UBI use them.  For example on my 2K Micron NAND device, I use this
> command to attach:
>   # ubiattach /dev/ubi_ctrl -m 3 -O 2048
> The -O option forces the UBI system to only use 2048 byte writes, as
> opposed
> to the 512 byte sub-pages that it would like to use.
>
> If you want to boot with this as your file system, use these kernel command
> line options:
>   root=ubi0:root ubi.mtd=3,2048 rootfstype=ubifs
>
> See if this helps.  If not, send as many details as you can.
>
> --
> ------------------------------**------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------**------------------------------
>
> ______________________________**_________________
> Angstrom-distro-devel mailing list
> Angstrom-distro-devel@**linuxtogo.org<Angstrom-distro-devel@linuxtogo.org>
> http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/**
> angstrom-distro-devel<http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel>
>
_______________________________________________
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel

Reply via email to