This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DM816x EVM: Mismatching BCH8 ECC layouts between Linux and U-BOOT

Hello TI:

I would like to completely use BCH8 ECC for NAND , (i.e., both U-BOOT firmware, and the kernel).     However there seems to be a mistmatch in the ECC layout selected by the kernel. We are using the DVR-RDK release 1.09 on our board which has the same NAND as the EVM.

Since U-BOOT is already booting BCH8, I assume that U-BOOT has the desired ECC layout.  (Right?) How can we get Linux to match? 

Following the advice in the link below I changed to use BCH8 OMAP_ECC_BCH8_CODE_HW.

http://e2e.ti.com/support/dsp/integra_dsparm/f/625/t/158503.aspx#576107 

By inspection of  ti81xx_nand.c and nand.h  U-BOOT uses........

#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 } } \
}

Linux is reporting this as its table.  

[    0.800000] NAND device: Maf ID: 0x2c, Chip ID: 0xca (Micron, )
[    0.800000]  erasesize: 0x20000, writesize: 2048, oobsize: 64
[    0.810000] omap_nand_probe OOBSIZE = 13 ECCBYTES 13 ECCSIZE=2048
[    0.820000] pos[0]=40
[    0.820000] pos[1]=41
[    0.820000] pos[2]=42
[    0.820000] pos[3]=43
[    0.830000] pos[4]=44
[    0.830000] pos[5]=45
[    0.830000] pos[6]=46
[    0.830000] pos[7]=47
[    0.840000] pos[8]=48
[    0.840000] pos[9]=49
[    0.840000] pos[10]=50
[    0.840000] pos[11]=51
[    0.850000] pos[12]=52

This can be observed by adding the following printk in omap2.c

        } else {

            omap_oobinfo.oobfree->offset = offset;
            omap_oobinfo.oobfree->length = info->mtd.oobsize -
                        offset - omap_oobinfo.eccbytes;
            /*
            offset is calculated considering the following :
            1) 12 bytes and 24 bytes ECC for OOB_64 can be supported
            2)Ecc bytes lie to the end of OOB area.
            3)Ecc layout must match with u-boot's ECC layout.
            */
            offset = info->mtd.oobsize - MAX_HWECC_BYTES_OOB_64;
            for (i = 0; i < omap_oobinfo.eccbytes; i++) {
                omap_oobinfo.eccpos[i] = i + offset;
                printk(KERN_INFO "pos[%d]=%d\n",i,omap_oobinfo.eccpos[i]);
            }
        }

Regards,

--B

  • Bandeg,

    Can you tell me which release version you are using? Changing the ECC option to "OMAP_ECC_BCH8_CODE_HW" at both the places in the kernel should make the default ECC scheme as BCH8 in the kernel. To verify that, you can write something to NAND from the kernel and see the OOB dump of that memory (you can use 'nandwrite' and 'nanddump' utilities for the same).

    Presently, the Uboot uses 1bit HW ECC by default. Once the Uboot has come up, you can change the ECC scheme to BCH8 by using the 'nandecc' command (#nandecc hw 2).

    Regards,

    Parth

  • Thanks Parth:

    We are using DVRRDK_01.09.00.16 and this uses PSP04.00.01.13

    The following are the OOB area for U-BOOT that was written using U-BOOT and the OOB area for a NAND partition that I wrote (from a BCH8 modified) Linux using nandwrite.

    U-BOOT seems to using a ECC Layout 2-57, and Linux seems to be using ECC Layout 40-52.

    The PSP Release notes indicate that there was a related bug fixed in this release.
    http://processors.wiki.ti.com/index.php/DM816x_AM389x_PSP_04.00.01.13_Release_Notes

    --> SDOCM00083827 omap:mtd:nand: unable to boot uboot if it is flashed from kernel

    1)  What was the fix (files involved)? 

    2) Should the kernel be using the 2-57 ECC layout to match the ECC used by u-boot?

    Regards, 

    --B

    ---- U-BOOT --BCH8--
    nanddump --oob /dev/mtd0 --bb=skipbad -p

    0x000007f0: 00 10 a0 e3 0a 20 a0 e3 76 8b 00 eb 08 00 84 e5
      OOB Data: ff ff cf 00 14 01 cb ab 34 6e a8 85 41 e1 cc 00
      OOB Data: da e7 0e f2 a3 85 c1 31 de ff 1c 22 39 00 5e ea
      OOB Data: 82 f4 df 89 fd 6a 20 f6 6a 2b d9 00 7b b6 95 a1
      OOB Data: 25 66 5e 6d 45 e4 15 ec 55 00 ff ff ff ff ff ff


    ----------LINUX ----------
    0x00000fe0: 07 00 12 e1 02 00 00 0a a2 20 a0 e1 07 00 12 e1
    0x00000ff0: fc ff ff 1a 00 00 52 e3 01 30 42 12 07 30 03 10
      OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      OOB Data: ff ff ff ff ff ff ff ff a9 7e b9 58 8d e9 c2 a5
      OOB Data: f8 2f 03 93 61 ff ff ff ff ff ff ff ff ff ff ff




  • Bandeg,

    1) The fix you mentioned was regarding alignment of ECC layout in Uboot and Kernel for 1-bit HW ECC (the ECC layout for both Uboot and Kernel were synchronised to 40-51 for 1-bit HW ECC). So, by default, both Uboot and Kernel support 1bit HW ECC with a 40-51 ECC layout.

    2) Now when you change the ECC layout in the Uboot to BCH8 (nandecc hw 2 command), then a corresponding change in the kernel code should be done to match it to the BCH8 ECC layout (2-57). For this you need to make 2 changes in the kernel and then compile it (this will make BCH8 as it's default ECC scheme):
    - kernel/arch/arm/mach-omap2/board-flash.c

    (board_nand_init function - "board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_HW;")

    -kernel/drivers/mtd/nand/omap2.c

    (probe function - "pdata->ecc_opt = OMAP_ECC_HAMMING_CODE_HW;")

    Please make sure that in the board-flash.c file, you are changing the option under the "cpu_is_ti81xx" condition. This is when the change will reflect on your platform.

    You should be able to verify the change by writing in the kernel (nandwrite command) and then dumping the written data (nanddump command).

    Regards,
    Parth

  • Hi,

     

    I would also like to have all the flash in BCH8 on my TI816x EVM.

    And like Bandeg, after inspecting the kernel code I have noticed that the BCH8 ECC is not correctly supported in the PSP04.00.01.13 kernel.

     

    Bandeg, were you finally able to make it work?

     

    Best regards,

    Pierre

  • No I have not.  I made the two kernel changes that were suggested, and reported the problem here.  I wanted to take a fresh look at it to see if it was something I was doing wrong but haven't had the time.  It seems like you concur that the kernel may not be handling this properly, even with the kernel changes.

  • Bandeng,

    Is this issue resolved?