AM3517 Flash Tool v1.5 - ECC Failed, page 0x00080000

zxy:

Please let me know the version of PSP (x-loader, u-boot, kernel) software you are using. 

Older versions required u-boot and x-loader to be programmed using SWECC 1-bit.

Newer versions default to 4-bit BCH ECC scheme.

Original PSP v03.00.01.06 used SWECC 1-bit.   The PSP that is included with the AM3517 SDK

is also labelled v03.00.01.06 but has additions to support 4-bit BCH and 8-bit BCH and it defaults

to 4-bit BCH. 

You can tell by looking at your u-boot source in ./drivers/mtd/nand/Omap_gpmc.c.   Near the end of the

below function it sets the default for nand->ecc.mode to NAND_ECC_4BIT_SOFT.   This mode

calculates ECC parity bytes using GPMC hardware and performs software error checking and

correction.

int board_nand_init(struct nand_chip *nand)

{

/* code not shown here */

nand->ecc.mode = NAND_ECC_4BIT_SOFT;

}

Regards,

Michael T

PS: Please mark this post as answered via the Verify Answer button below if you think it answers your question.  Thanks!

Michael T:

All sources are provided with am3517evm board, and versions are as follows

x-loader 03.00.02.07

u-boot 03.00.02.07

kernel 2.6.32

in ./drivers/mtd/nand/Omap_gpmc.c, codes like this

int board_nand_init(struct nand_chip *nand)

{

    ...

    /* Default ECC mode */

    nand->ecc.mode = NAND_ECC_SOFT;

    return 0;

}

Kevin:

For that PSP version you will need to program NAND using flash tool as follows:

x-loader: HWECC, 1-bit

u-boot: SWECC, 1-bit

kernel: SWECC 1-bit

Regards,

Michael T

PS: Please mark this post as answered via the Verify Answer button below if you think it answers your question.  Thanks!

Michael T:

Thanks, it works, :-)

Best Wishes,

zxy

Hi Michael,

can you provide another word of clarification?

in omap2.c in drivers/mtd/nand

there is a constant : #define CONFIG_MTD_NAND_OMAP_HWECC

what does this flag represents? the hw detection?

Thanks

Oren.

Oren:

HWECC means the GPMC controller generates the ECC parity bytes when writing to NAND.

The NAND driver reads the ECC parity bytes from GPMC registers and writes it to spare area of NAND.

On NAND reads, GPMC generates ECC parity on the page.  NAND driver compares ECC parity from

GPMC with the ECC parity in spare area.   If the compare fails a software error correction fcn

is called.

In the SWECC mode, ECC parity bytes are generated, checked and corrected in software.

SWECC only uses 1-bit Hamming code.

See this wiki article about building for various ECC modes.  Flash Tool supports all of these ECC modes.

http://processors.wiki.ti.com/index.php/Error_Correction_User_Guide

The AM3517 SDK has PSP v03.00.01.06 with patches applied to support the ECC modes

described in the wiki article, and the SDK's pre-built u-boot image is set to 4-bit BCH mode.

Regards,

Michael T

PS: Please mark this post as answered via the Verify Answer button below if you think it answers your question.  Thanks!

Thanks Michael for your answer!

The reason i am asking, is since another thread (http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/103330/381200.aspx#381200)  has stated:

"Moving to DM3730 would allow you to use our software ECC as you stated and then you wouldn't have to worry about the Micron on-die ECC. "

while obviously using SW ecc would have severe implications on performance.

We can not use the NAND flash on-die ECC since NAND reset is not possible for for us.

why wasn't it advised to use HW 4 bit ecc while disabling the on-die ECC of the NAND Flash?

Thanks,

Oren.

Hello Oren,

I think part of the confusion here might be because we are discussing 3 different devices.  Thread was about the AM35x and the other thread we had going was about the OMAP35x and the AM/DM37x devices. 

For the AM35x and the AM/DM37x devices you can use our hw detection and sw correction for 4b ECC devices.  above Mike mentions HWECC and SWECC this is a confusing because it isn't really HW correction for HWECC.  It just means that the spare area mapping is aligned with our ROM code which is different from the 1b ECC mapping that we use after the ROM code is finished running. 

for the OMAP35x there is a bug in the GPMC which corrupts the 4b ECC data.  Because of this we recommend that you use Micron's on-die ECC. 

please let me know if that makes sense. 

Oren:

If you were using OMAP3530, that device does not support 4-bit BCH error detection.

DM3730 does not have that problem.

See wiki page:

http://processors.wiki.ti.com/index.php/Raw_NAND_ECC

Regards,

Michael T

Thanks Michael,

in order not to duplicate, i already replied on the previously refferred thread.

Oren

Hi Oren,

I am getting the same error I am using the latest x-loader and uboot

http://arago-project.org/git/projects/

Its 4.04

Please help with this