Hi Pekon,
On Wed, Apr 23, 2014 at 8:04 PM, Gupta, Pekon <pe...@ti.com> wrote:
> Hello Marek,
>
>>From: Belisko Marek [mailto:marek.beli...@gmail.com]
>>
>>CC-ing Pekon Gupta which add those changes in commit:
>>6e562b1106ea6afc78752f50925e87e9dd14f8b4
>>
>>On Tue, Apr 15, 2014 at 12:47 PM, Belisko Marek <marek.beli...@gmail.com>
>>wrote:
>>> Hi,
>>>
>>> we're running 2014.04-rc3 on custom am335x board (same configuration as
>>> BBB).
>>> When spl is loading u-boot from nand flash we can see a lot of
>>> messages in console:
>>> nand: bit-flip corrected @oob=0
>>>
>>> It is always the same position (seems to be first byte in oob).
>>> Anybody experienced same problem?
>>> I've tested on 2 different flashes and result is same.
>>>
>>I was able to track down that read ecc from gpmc return always first
>>byte as 0xFF (in omap_calculate_ecc())
>
> This shouldn't be the case if the page is programmed.
> Following is the expected ECC layout of BCH8
Thanks for reply and sorry for wrong explanation. I mean read_ecc[0]
byte = 0xff.
What I found also is that data in read_ecc was completely different
from displayed when issue nand dump.
I found patch which fixes issue [1]. The u-boot doesn't anymore print
bit-flips in oob. I need to fix
also spl nand_read_page as when loading u-boot from nand in spl still
report issues.
One more question. Shouldn;t code for bitflip in oob looks like this:
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -403,7 +403,7 @@ static int omap_correct_data_bch(struct mtd_info
*mtd, uint8_t *dat,
dat[byte_pos] ^= 1 << bit_pos;
printf("nand: bit-flip corrected @data=%d\n", byte_pos);
} else if (byte_pos < error_max) {
- read_ecc[byte_pos - SECTOR_BYTES] = 1 << bit_pos;
+ read_ecc[byte_pos - SECTOR_BYTES] ^= 1 << bit_pos;
debug("nand: bit-flip corrected @oob=%d\n", byte_pos -
SECTOR_BYTES);
} else {
> OOB[0]: Bad block marker
> OOB[1]: Bad block marker
> OOB[2]: ecc_sector0_byte[0] = read_ecc[0] <---
> OOB[3]: ecc_sector0_byte[1]
> OOB[4]: ecc_sector0_byte[2]
> OOB[5]: ecc_sector0_byte[3]
> OOB[6]: ecc_sector0_byte[4]
> OOB[7]: ecc_sector0_byte[5]
> OOB[8]: ecc_sector0_byte[6]
> OOB[9]: ecc_sector0_byte[7]
> OOB[10]: ecc_sector0_byte[8]
> OOB[11]: ecc_sector0_byte[9]
> OOB[12]: ecc_sector0_byte[10]
> OOB[13]: ecc_sector0_byte[11]
> OOB[14]: ecc_sector0_byte[12]
> OOB[15]: ecc_sector0_byte[13]
> OOB[13]: reserved (0x00)
> OOB[14]: ecc_sector1_byte[0]
> OOB[15]: ecc_sector1_byte[1]
> OOB[16]: ecc_sector2_byte[2]
> OOB[17]: ecc_sector3_byte[3]
> ....
>
>
>>and thus function omap_correct_data_bch() always trying to repair
>>bit-flips in first oob byte. Can this be caused by
>>flash? Any pointers?
>>
>>> In config we're using:
>>> #define CONFIG_NAND_OMAP_ECCSCHEME OMAP_ECC_BCH8_CODE_HW
>>> #define CONFIG_NAND_OMAP_ELM
>>>
> Something seems to be wrong elsewhere.
> (1) please use 'nand dump' to check above layout
>
> (2) Also please send me your device datasheet
>
> (3) If you using x16 device, then you might need to pull-in following patch
> series..
> http://lists.denx.de/pipermail/u-boot/2014-April/176834.html
>
> OR
> Use below hack, just for testing (only for x16 devices)..
> -----------------------
> diff --git a/arch/arm/cpu/armv7/am33xx/mem.c b/arch/arm/cpu/armv7/am33xx/mem.c
> index 56c9e7d..b166a94 100644
> --- a/arch/arm/cpu/armv7/am33xx/mem.c
> +++ b/arch/arm/cpu/armv7/am33xx/mem.c
> @@ -64,7 +64,7 @@ void gpmc_init(void)
> u32 base = CONFIG_SYS_FLASH_BASE;
> #elif defined(CONFIG_NAND)
> /* configure GPMC for NAND */
> - const u32 gpmc_regs[GPMC_MAX_REG] = { M_NAND_GPMC_CONFIG1,
> + const u32 gpmc_regs[GPMC_MAX_REG] = { M_NAND_GPMC_CONFIG1 | 0x1000,
> M_NAND_GPMC_CONFIG2,
> M_NAND_GPMC_CONFIG3,
> M_NAND_GPMC_CONFIG4,
> -----------------------
>
>
> with regards, pekon
[1] - http://e2e.ti.com/support/arm/sitara_arm/f/791/t/259699.aspx
BR,
marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
