[U-Boot] am33xx : bit-flip correction in oob

[Belisko Marek]

Hi Pekon,

On Wed, Apr 23, 2014 at 8:04 PM, Gupta, Pekon <pekon at ti.com> wrote:
> Hello Marek,
>
>>From: Belisko Marek [mailto:marek.belisko at gmail.com]
>>
>>CC-ing Pekon Gupta which add those changes in commit:
>>6e562b1106ea6afc78752f50925e87e9dd14f8b4
>>
>>On Tue, Apr 15, 2014 at 12:47 PM, Belisko Marek <marek.belisko at gmail.com> wrote:
>>> Hi,
>>>
>>> we're running 2014.04-rc3 on custom am335x board (same configuration as BBB).
>>> When spl is loading u-boot from nand flash we can see a lot of
>>> messages in console:
>>> nand: bit-flip corrected @oob=0
>>>
>>> It is always the same position (seems to be first byte in oob).
>>> Anybody experienced same problem?
>>> I've tested on 2 different flashes and result is same.
>>>
>>I was able to track down that read ecc from gpmc return always first
>>byte as 0xFF (in omap_calculate_ecc())
>
> This shouldn't be the case if the page is programmed.
> Following is the expected ECC layout of BCH8
Thanks for reply and sorry for wrong explanation. I mean read_ecc[0]
byte = 0xff.
What I found also is that data in read_ecc was completely different
from displayed when issue nand dump.
I found patch which fixes issue [1]. The u-boot doesn't anymore print
bit-flips in oob. I need to fix
also spl nand_read_page as when loading u-boot from nand in spl still
report issues.

One more question. Shouldn;t code for bitflip in oob looks like this:
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -403,7 +403,7 @@ static int omap_correct_data_bch(struct mtd_info
*mtd, uint8_t *dat,
                        dat[byte_pos] ^= 1 << bit_pos;
                        printf("nand: bit-flip corrected @data=%d\n", byte_pos);
                } else if (byte_pos < error_max) {
-                       read_ecc[byte_pos - SECTOR_BYTES] = 1 << bit_pos;
+                       read_ecc[byte_pos - SECTOR_BYTES] ^= 1 << bit_pos;
                        debug("nand: bit-flip corrected @oob=%d\n", byte_pos -
                                                                SECTOR_BYTES);
                } else {

> OOB[0]:   Bad block marker
> OOB[1]:   Bad block marker
> OOB[2]:   ecc_sector0_byte[0] = read_ecc[0]   <---
> OOB[3]:   ecc_sector0_byte[1]
> OOB[4]:   ecc_sector0_byte[2]
> OOB[5]:   ecc_sector0_byte[3]
> OOB[6]:   ecc_sector0_byte[4]
> OOB[7]:   ecc_sector0_byte[5]
> OOB[8]:   ecc_sector0_byte[6]
> OOB[9]:   ecc_sector0_byte[7]
> OOB[10]:   ecc_sector0_byte[8]
> OOB[11]:   ecc_sector0_byte[9]
> OOB[12]:   ecc_sector0_byte[10]
> OOB[13]:   ecc_sector0_byte[11]
> OOB[14]:   ecc_sector0_byte[12]
> OOB[15]:   ecc_sector0_byte[13]
> OOB[13]:   reserved (0x00)
> OOB[14]:   ecc_sector1_byte[0]
> OOB[15]:   ecc_sector1_byte[1]
> OOB[16]:   ecc_sector2_byte[2]
> OOB[17]:   ecc_sector3_byte[3]
> ....
>
>
>>and thus function omap_correct_data_bch() always trying to repair
>>bit-flips in first oob byte. Can this be caused by
>>flash? Any pointers?
>>
>>> In config we're using:
>>> #define CONFIG_NAND_OMAP_ECCSCHEME      OMAP_ECC_BCH8_CODE_HW
>>> #define CONFIG_NAND_OMAP_ELM
>>>
> Something seems to be wrong elsewhere.
> (1) please use 'nand dump' to check above layout
>
> (2) Also please send me your device datasheet
>
> (3) If you using x16 device, then you might need to pull-in following patch series..
> http://lists.denx.de/pipermail/u-boot/2014-April/176834.html
>
> OR
> Use below hack, just for testing (only for x16 devices)..
> -----------------------
> diff --git a/arch/arm/cpu/armv7/am33xx/mem.c b/arch/arm/cpu/armv7/am33xx/mem.c
> index 56c9e7d..b166a94 100644
> --- a/arch/arm/cpu/armv7/am33xx/mem.c
> +++ b/arch/arm/cpu/armv7/am33xx/mem.c
> @@ -64,7 +64,7 @@ void gpmc_init(void)
>         u32 base = CONFIG_SYS_FLASH_BASE;
>  #elif defined(CONFIG_NAND)
>  /* configure GPMC for NAND */
> -       const u32  gpmc_regs[GPMC_MAX_REG] = {  M_NAND_GPMC_CONFIG1,
> +       const u32  gpmc_regs[GPMC_MAX_REG] = {  M_NAND_GPMC_CONFIG1 | 0x1000,
>                                                 M_NAND_GPMC_CONFIG2,
>                                                 M_NAND_GPMC_CONFIG3,
>                                                 M_NAND_GPMC_CONFIG4,
> -----------------------
>
>
> with regards, pekon

[1] - http://e2e.ti.com/support/arm/sitara_arm/f/791/t/259699.aspx

BR,

marek

-- 
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com