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.

EZSDK_5_04 U-BOOT NAND ERR

I've got the EVM8168 Rev.G platform.

I have just updated the u-boot with the latest released EZSDK_5_04
With the EZSDK_5_04:  U-boot ERROR!!! Cannot find NAND! (Boot Info Below)

NAND:  HW ECC BCH8 Selected
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xca (Micron NAND 256MiB 3,3V 16-bit)
NAND bus width 8 instead 16 bit
No NAND device found!!!
0 MiB
MMC:   OMAP SD/MMC: 0
*** Warning - bad CRC or NAND, using default environment


The u-boot cmd 'nand erase' 'saveenv' gets no use.

Then, I changed the u-boot back to previous version.

With the EZSDK_5_03: (Boot info below)

NAND:  HW ECC Hamming Code selected
256 MiB
*** Warning - bad CRC or NAND, using default environment

Ha, Everything seems well.

WHY? Is this a new BUG the latest release EZSDK raised?

  • Hello Haoran Li, 

    I am facing similar problems with my DM8148. So I've already encountered your bug. I have traced it down to a code change in the following file: 

    ezsdk_5_04_00_11/board-support/u-boot-2010.06-psp04.04.00.01/arch/arm/cpu/arm_cortexa8/ti81xx/sys_info.c

    It appears that the return values in the funtion u32 get_sysboot_bw(void) have been swapped (as compared to EZSDK 5.03). That is, a 16-bit NAND is set as 8-bit and vise versa. If you swap it back to the way it is in EZSDK 5.03, this error appears to go away.

  • However, after doing this I run into another problem where the MLO has problem reading NAND when booting the 2nd stage u-boot. My serial terminal shows this:

    U-Boot 2010.06-svn49 (May 24 2012 - 12:52:02)

    TI8148-GP rev 2.1

    ARM clk: 600MHz
    DDR clk: 400MHz

    DRAM: 2 GiB
    NAND: HW ECC BCH8 Selected
    256 MiB
    Using default environment

    The 2nd stage U-Boot will now be auto-loaded
    Please do not interrupt the countdown till TI8148_EVM prompt if 2nd stage is already flashed
    Hit any key to stop autoboot: 0

    NAND read: device 0 offset 0x20000, size 0x60000
    ECC: uncorrectable.
    ECC: uncorrectable.
    .................
    <insert many more lines of "ECC: uncorrectable." here>
    .................
    ECC: uncorrectable.
    ECC: uncorrectable.

    NAND read from offset 2000
    393216 bytes read: ERROR

    So I am still trying to figure out what the root of the problem is and whether my first change was the correct one. Any additional help would be appreciated.

  • After doing a bit more digging, it appears that u-boot in EZSDK 5.04 has changed the default NAND ECC mode set to BCH8. This used to only apply to MLO in 5.03, but now it looks like U-Boot uses it by default. Which explains why my working EZSDK 5.03 system would report "ECC: uncorrectable." errors after updating it with the MLO generated by EZSDK 5.04.

    I found that the second last line of code in function int board_nand_init(struct nand_chip *nand) from "ezsdk/board-support/u-boot-2010.06-psp04.04.00.01/drivers/mtd/nand/ti81xx_nand.c" was changed from: 

    ti81xx_nand_switch_ecc(NAND_ECC_HW, 0); in EZSDK 5.03

    to 

    ti81xx_nand_switch_ecc(NAND_ECC_HW, 2); in EZSDK 5.04

    which appears to change the default ECC mode from Hamming to BCH8

    My first attempt at a solution was to run "nandecc hw 2" before I "nand write.i" any U-Boot image and before I do a "saveenv". This allowed me to load both MLO, U-Boot 2nd stage and read ENV variables without ECC problems.

    However, when I tried to load the Linux kernel, I got "ECC: uncorrectable." again. I tried writing the Linux kernel to NAND using BCH8, but there were a lot of ECC read errors when loading.

    So, I am getting closer, but I still don't quite have a working system booting from NAND that is build by EZSDK 5.04

  • I found that everything works properly when all partitions are read/written using BCH8. I took a look at the EZSDK release notes again and found that I missed one very important line: 

    "The default ECC scheme used across Uboot, Kernel and File System is changed to 8-bit BCH ECC."

  • Hi Nicholas,

    Have you figured this out this out? I've almost solved the problem with BCH8. Still some more work is left. 

  • Yes, my last post was to say that I had figured it out. 

  • Hi Renjith,

    I have similar problem http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/375822.aspx were you able to fix it ?

    Thanks & Regards

    Mike