• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 99 subscribers
  • Views 1104 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

ECC error message when SPL loads u-boot

Ron Olson
Intellectual 680 points
Other Parts Discussed in Thread: AM3517

We're developing a board that is a derivative of the AM3517EVM eval board.  It contains an 8-bit, 2Gbyte, ONFI device (Micron MT29F16G08AJADAWP).

I'm using the TI flash tool to burn SPL and u-boot (2011.12) to the NAND device on our board, and that process appears to go smoothly.  Following the burn, I'm able to boot from the NAND device and get to the u-boot console without problem.

But - during the boot, SPL reports exactly 4 error messages for each u-boot page it reads.  The message is 'Error: Bad compare!', and it comes out of the omap_gpmc.c module.

I'm suspicious that the ECC algorithms used by the flash tool when burning, and by SPL when reading, differ.  I believe I have the flash tool set correctly, but for the u-boot config I'm not so sure.  My config settings are the same as used by the eval board, except I've also specified CONFIG_SYS_NAND_ONFI_DETECTION.

Here's the flash tool log, which looks good to me:

» Sending data (41008 bytes) :::::::::::::::::::: [41008]
          Interface 'OMAPFLASH DRIVER v5'
          Driver 'NAND ONFI 16/8 BIT'
          Driver configuration: gpmc = 0x6E000000
          Driver configuration: cs = 0x00000000
          Driver configuration: address = 0x30000000
          Driver configuration: bberase = 0x00000000
          Driver configuration: onfi = 0x00000001
          Driver configuration: eccoffset = 0x00000002
          NAND HW ECC
          NAND BCH Mode = 0
          NAND HWECC offset = 1, size = 12
          NAND ONFIv2 VENDOR 0x2C MICRON
          NAND 8 BIT DEVICE 0xD3 MT29F16G08AJADAWP
          NAND NAND CYCLES 0x23 (3 ROW, 2 COLUMN)
          NAND 2048 BYTES/PAGE (SPARE 64)
          NAND 64 PAGES/BLOCK (131072 BYTES/BLOCK)
          NAND 4096 BLOCKS/UNIT (536870912 BYTES/UNIT)
          NAND DRIVER ONLY SUPPORTS 1 OF 4 UNITS
          NAND 4 BIT(S) ECC REQUIRED
          NAND 2048 MB TOTAL SIZE
          NAND ONFI DRIVER INIT COMPLETE
» Downloading complete

I'd appreciate any insights on the SPL error messages.  Also, notice that the ONFI parameters reported by the flash tool say 'NAND 4 BIT(S) ECC REQUIRED'.  The device manual says the same thing.  I'm wondering if this is in any way related.

Thanks,
Ron

  • 0
    Intellectual 680 points

    I've been fighting this ECC problem for several days now, and it's come down to this.  With the flash tool 1.6 configured for eccoffset=2, the resulting NAND HWECC offset becomes 1.  So, the NAND's OOB is setup incorrectly, and SPL complains about the mismatches.  I tried other offsets of 1, 3, and 4, and they are all correct.

    This looks, at least on the surface, like a flash tool bug, and a strange one at that, given that offsets of 1, 3, and 4 are fine, but not 2.

    RBL must be seeing the same mismatch, but doesn't show any signs of trouble, at least not that I see.  I guess it silently ignores the problem and continues, not that it would have a way of informing me even if it wanted to.

    A workaround would be very much appreciated.  I could workaround it by reconfiguring SPL for the 'wrong' offset, but prefer to fix it at the source.

    By the way, I never got any response for my original posting.  If there's a better forum for this kind of issue, please let me know.

    Thanks,
    Ron

    ===== eccoffset 2 becomes NAND HWECC offset = 1 (BAD!!)
    » chip_driver NAND1BITBOOT Targets\Flash-Drivers\nand_onfi_16bit_8bit.bin gpmc 0x6E000000 cs 0 address 0x30000000 bberase 0 onfi 1 eccoffset 2
    . . .
              Driver configuration: eccoffset = 0x00000002
              NAND HW ECC
              NAND BCH Mode = 0
              NAND HWECC offset = 1, size = 12


    ===== eccoffset 1 becomes NAND HWECC offset = 1 (OK)
    » chip_driver NAND1BITBOOT Targets\Flash-Drivers\nand_onfi_16bit_8bit.bin gpmc 0x6E000000 cs 0 address 0x30000000 bberase 0 onfi 1 eccoffset 1
    . . .
              Driver configuration: eccoffset = 0x00000001
              NAND HW ECC
              NAND BCH Mode = 0
              NAND HWECC offset = 1, size = 12

    ===== eccoffset 3 becomes NAND HWECC offset = 3 (OK)
    » chip_driver NAND1BITBOOT Targets\Flash-Drivers\nand_onfi_16bit_8bit.bin gpmc 0x6E000000 cs 0 address 0x30000000 bberase 0 onfi 1 eccoffset 3
    . . .
              Driver configuration: eccoffset = 0x00000003
              NAND HW ECC
              NAND BCH Mode = 0
              NAND HWECC offset = 3, size = 12

    ===== eccoffset 4 becomes NAND HWECC offset = 4 (OK)
    » chip_driver NAND1BITBOOT Targets\Flash-Drivers\nand_onfi_16bit_8bit.bin gpmc 0x6E000000 cs 0 address 0x30000000 bberase 0 onfi 1 eccoffset 4
    . . .
              Driver configuration: eccoffset = 0x00000004
              NAND HW ECC
              NAND BCH Mode = 0
              NAND HWECC offset = 4, size = 12

  • 0 in reply to Ron Olson
    Expert 1125 points

    Having side effects due to the described issue on AM3517 while programming MLO and u-boot images using flash_tool 1.6

    I am setting the programmer config to use ecc_offset=1 (since offset=2 doesn't work, had to add workaround in u-boot for that to work) and getting "ghost" bad blocks at blocks where the images are written. Currently this side effect seems harmless.

    Simple scrub removes the bad blocks, they show again after writing.

    I wonder if there are any plans to fix the "offset" bug in the flash_tool and could these "ghost bad blocks" be related to the specific offset I am using? 

    Regards

    Yakir