Hi Pekon,
On Wed, Apr 23, 2014 at 8:04 PM, Gupta, Pekon pekon@ti.com wrote:
Hello Marek,
From: Belisko Marek [mailto:marek.belisko@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.belisko@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