• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 102 subscribers
  • Views 2010 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM335x boot problem with Spansion NAND

Dmitry Dzhuromsky
Prodigy 50 points
Other Parts Discussed in Thread: AM3358

Hello, TI Community!

We are currently debugging our custom board based on AM3358 processor with Spansion S34MS04G204 NAND memory. The problem is that we can only boot our board if SYSBOOT[9] bit is set to "1". With SYSBOOT[9] = 0 it starts XModem request. We are able to boot the board via UART0 and everything looks fine in Linux (NAND read and write without errors). The previous revision of this board was assembled with Micron MT29F4G16 NAND and works fine. We use BCH8 ECC scheme both in U-Boot SPL and in Linux. It seems we have the same issue like in this thread: e2e.ti.com/.../292452 but there is no solution. Please, help us to solve this problem.

Our NAND timing settings are:
gpmc,device-width = <2>;
gpmc,sync-clk-ps = <0>;
gpmc,cs-on-ns = <0>;
gpmc,cs-rd-off-ns = <44>;
gpmc,cs-wr-off-ns = <44>;
gpmc,adv-on-ns = <6>;
gpmc,adv-rd-off-ns = <34>;
gpmc,adv-wr-off-ns = <44>;
gpmc,we-on-ns = <0>;
gpmc,we-off-ns = <40>;
gpmc,oe-on-ns = <0>;
gpmc,oe-off-ns = <54>;
gpmc,access-ns = <64>;
gpmc,rd-cycle-ns = <82>;
gpmc,wr-cycle-ns = <82>;
gpmc,wait-on-read = "true";
gpmc,wait-on-write = "true";
gpmc,bus-turnaround-ns = <0>;
gpmc,cycle2cycle-delay-ns = <0>;
gpmc,clk-activation-ns = <0>;
gpmc,wait-monitoring-ns = <0>;
gpmc,wr-access-ns = <40>;
gpmc,wr-data-mux-bus-ns = <0>;

Best Regards
Dmitry

  • 0
    TI__Guru**** 393215 points

    Hi Dmitry,

    What is the page/spare area size of both NANDs? Which Linux version are you using?

  • 0 in reply to Biser Gatchev-XID
    Prodigy 50 points

    Hi Biser, thank you for quick reply.

    Micron MT29F4G16 (x16) page has 1024 words of data + 32 spare words.
    Spansion S34MS04G2 (x16) page has 1024 words of data + 64 spare words.
    We also changed the CONFIG_SYS_NAND_OOBSIZE setting from "64" to "128" with respect of this difference but the board doesn't boot.
    Linux version is 4.1

    Best Regards
    Dmitry

  • 0 in reply to Biser Gatchev-XID
    Prodigy 50 points
    Hi Biser, thank you for quick reply.

    Micron MT29F4G16 (x16) page has 1024 words of data + 32 spare words.
    Spansion S34MS04G2 (x16) page has 1024 words of data + 64 spare words.
    We also changed the CONFIG_SYS_NAND_OOBSIZE setting from "64" to "128" with respect of this difference but the board doesn't boot.
    Linux version is 4.1

    Best Regards
    Dmitry
  • 0 in reply to Dmitry Dzhuromsky
    TI__Guru**** 393215 points

    It seems to me that ROM code is expecting BCH-16 ECC algorithm based on the larger OOB size. This is supported in the latest TI Linux SDK releases, however I cannot say about v4.1, we don't support it at present.

  • 0 in reply to Biser Gatchev-XID
    Prodigy 50 points
    Hi Biser

    We have some interesting results. Board can boot with BCH-16 ECC setting, but there are error messages from omap-elm: uncorrectable ECC errors. Then we try to change CONFIG_SYS_NAND_ECCBYTES setting from "14" to "26" according to new ECC scheme and u-boot can't boot again.

    Our current settings are:
    +#define CONFIG_NAND_OMAP_GPMC
    +#define CONFIG_NAND_OMAP_ELM
    +#define CONFIG_SYS_NAND_5_ADDR_CYCLE
    +#define CONFIG_SYS_NAND_PAGE_COUNT<--->(CONFIG_SYS_NAND_BLOCK_SIZE / \
    +<-----><------><------><------><------> CONFIG_SYS_NAND_PAGE_SIZE)
    +#define CONFIG_SYS_NAND_PAGE_SIZE<---->2048
    +/* 128 - for Spansion, 64 - Micron */
    +#define CONFIG_SYS_NAND_OOBSIZE<------><------>128
    +#define CONFIG_SYS_NAND_BLOCK_SIZE<--->(128*1024)
    +#define CONFIG_SYS_NAND_BAD_BLOCK_POS<>NAND_LARGE_BADBLOCK_POS
    +#define CONFIG_SYS_NAND_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, }
    +#define CONFIG_SYS_NAND_ECCSIZE<------><------>512
    +/* 26 for Spansion, 14 for Micron NAND */
    +#define CONFIG_SYS_NAND_ECCBYTES<----->14
    +#define CONFIG_SYS_NAND_ONFI_DETECTION
    +#define CONFIG_SYS_NAND_BUSWIDTH_16BIT>16
    +/* BCH16 for Spansion, BCH8 for Micron NAND */
    +#define CONFIG_NAND_OMAP_ECCSCHEME<--->OMAP_ECC_BCH16_CODE_HW
    +#define CONFIG_SYS_NAND_U_BOOT_START<->CONFIG_SYS_TEXT_BASE
    +#define CONFIG_SYS_NAND_U_BOOT_OFFS<-->0x80000

    Should we change some other settings? CONFIG_SYS_NAND_ECCPOS maybe?

    Best Regards
    Dmitry
  • 0 in reply to Dmitry Dzhuromsky
    TI__Guru**** 393215 points

    I'm not a SW expert myself, so I have asked for help on this. Here is the TI Linux SDK wiki for ECC support, if that can help: http://processors.wiki.ti.com/index.php/Linux_Core_NAND_User's_Guide#ECC_schemes_support

  • 0 in reply to Dmitry Dzhuromsky
    TI__Guru**** 161600 points

    Hi Dmitry,

    Dmitry Dzhuromsky said:
    Should we change some other settings? CONFIG_SYS_NAND_ECCPOS maybe?

    Correct, you should set the CONFIG_SYS_NAND_ECCPOS as described in the link provided by Biser: 

        

    #define CONFIG_SYS_NAND_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, 58, 59, \
 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, \
 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, \
 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, \
 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, \
100, 101, 102, 103, 104, 105, 106, 107, 108, 109, \
110, 111, 112, 113, 114, 115, 116, 117, 118, 119, \
120, 121, 122, 123, 124, 125, 126, 127, 128, 129, \
130, 131, 132, 133, 134, 135, 136, 137, 138, 139, \
140, 141, 142, 143, 144, 145, 146, 147, 148, 149, \
150, 151, 152, 153, 154, 155, 156, 157, 158, 159, \
160, 161, 162, 163, 164, 165, 166, 167, 168, 169, \
170, 171, 172, 173, 174, 175, 176, 177, 178, 179, \
180, 181, 182, 183, 184, 185, 186, 187, 188, 189, \
190, 191, 192, 193, 194, 195, 196, 197, 198, 199, \
200, 201, 202, 203, 204, 205, 206, 207, 208, 209, }

    Best Regards, 

    Yordan

  • 0 in reply to Yordan Kovachev
    Prodigy 50 points
    Hi Biser and Yordan

    Thank you very much for your help! We have success with these new settings. Board can boot correctly now (with SYSBOOT[9]=0). There are some problems with writing a big portions of data, but I think it depends of GPMC timing settings.

    # nand write $loadaddr rootfs $filesize
    NAND write: device 0 offset 0x780000, size 0x6c00000
    Timeout!NAND write to offset 1260000 failed -5
    11272192 bytes written: ERROR

    Final question about this issue: is it mandatory to use BCH16 for all NAND memories which have OOB size = 128 bytes? Why can't we use BCH8?

    Best Regards
    Dmitry
  • 0 in reply to Dmitry Dzhuromsky
    TI__Guru**** 393215 points

    Dmitry Dzhuromsky said:
    Final question about this issue: is it mandatory to use BCH16 for all NAND memories which have OOB size = 128 bytes? Why can't we use BCH8?

    If you intend to boot from this NAND, then it's mandatory, because the processor ROM code selects BCH16 for OOB size greater than 64 bytes.