Hi Victor,
On Thursday 07 June 2007, Victor Librado wrote:
2)In u-boot. I redefined the block of the nandflash for environment variables :
#ifdef CFG_ENV_IS_IN_NAND #define CFG_ENV_OFFSET 0x80000 /* environment starts here */ #define CFG_ENV_SIZE 0x20000 /* 1 sector = 128kB */ #endif
Now saveenv works properly! I think it was previously a bad block in my nandflash?
That can always happen. And the code *should* be able to handle this. If it is not able to handle this situation right now (sorry, I don't know for sure), then we (you? ;-)) should fix this. Patches always welcome.
I have a doubt, if I define the soft ECC (both linux, u-boot), the OOB section of each page of the SAMSUNG nandflash the board has (64 bytes), how will it be filled? Because the nandflash datasheet states that in a block the first byte of the OOB section in the 1st o 2nd pages must be FFh or it is a bad block. So it could be that ECC data (the 4 byte hw or software ECC) were written in this first byte of the OOB and mark the block as invalid for this nandflash....... (so every write will generate a bad bloack?)
In u-boot the eccmode:
nand->eccmode = NAND_ECC_HW12_2048; /* NAND_ECC_SOFT;*/
What part of the OOB writes?
See drivers/nand/nand_base.c
static struct nand_oobinfo nand_oob_64 = { .useecc = MTD_NANDECC_AUTOPLACE, .eccbytes = 24, .eccpos = { 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63}, .oobfree = { {2, 38} } };
So the ECC positions are: 40, 41, 42 etc, as defined above.
I'm getting really confused... any help will be welcomed.
Can ECC disabled in nandflash u-boot with some compilation option?
Not an compilation option, but a NAND driver option:
this->eccmode = NAND_ECC_NONE;
instead of
this->eccmode = NAND_ECC_SOFT;
But I wouldn't recommend this. Using NAND without ECC is definitely not a good idea. Even for reading. So we should try to investigate further and fix the source of the problem. Please stick with NAND_ECC_SOFT for now, since it is known to work on other platform, and we have less possible error sources (like CPU specific HW-ECC code).
Hope this helps a little.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================