Re: [U-Boot-Users] u-boot on nadflash for at91sam9260ek
Hello Michel and all,
Thank you very much for your comments. By now I have the following on my at91sam9260ek work with nandflash:
1) In linux. Linux version 2.6.19 with maxim patches. Kernel configuration: at91-nand support but not CONFIG_MTD_NAND_ECC_SMC defined. So my Linux system is not performing ECC. In at91-nand.c is stated:
nand_chip->ecc.mode = NAND_ECC_SOFT; /* enable ECC */
So the Linux version (when configured) I assume is not using the HW ECC at91sam9260 processor provides. It has a c file nand_ecc.c with an algorithm to do it by soft. This is provide in linux 2.6.21 at91 patches? All in all, nandwrite and flash_eraseall commands work properly.
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?
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?
I'm getting really confused... any help will be welcomed.
Can ECC disabled in nandflash u-boot with some compilation option?
Best regards,
Víctor.
/////////////////////////
Hi Victor
We have the same problem. The u-boot 1.1.5 code from Atmel does not correctly support the ECC correction coding in the OOB (out of bounds) area of the nandflash when writing. I have tried playing around with the available settings to no avail. When you do saveenv the data is correctly written to nand flash but the oob area is filled with a 12 byte ECC code which makes the 5th byte in the OOB something other than FF and thus marks the sector as bad. The hw ECC controller of the AT91SAM9260 is hard coded to generate a 4 byte ECC in the first 4 bytes of the OOB. This is the ECC used by SAMBA (external pc programming tool) and the linux at91-nand driver. I have not found any support for this in the Atmel u-boot code (yet).
If anyone has fixed AT91SAM9260 hw ECC support in u-boot please send us a copy of your changes. Even a sw ECC that generates a correct 4 byte code would be useful.
U-boot on at91sam9260 can however read from nand (i think it ignores ECC by default) so its possible to boot an image that you have written to nand, its just not possible to write to nand from within u-boot. I use either samba or linux (flash_eraseall and nandwrite) to write data to the nandflash and fw_setenv and fw_printenv (compiled from u-boot tools dir) to modify u-boot environment variables during development
Atmel has a port of u-boot 1.2 available on www.at91.com. I have not been successful it getting that version to run yet. Does anyone know if it includes support for nandflash writes from u-boot?
Michel
Victor Librado Sancho Departamento I+D ------------------------------------------------------------------------
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 =====================================================================
participants (2)
-
Stefan Roese -
Victor Librado