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
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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to