Hi all,
I have seen an incompatibility between the NAND driver in u-boot for the davinci boards and the linux driver (kernel 2.6.38, mainline).
I think it is not related to the specific board I use. In any case, I am using the ea20 board (OMAP-L138 based, in u-boot mainline), and I have added NAND support setting for the driver:
#define CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST #define CONFIG_SYS_NAND_USE_FLASH_BBT
This is done in the linux driver, too. Both drivers are using ECC in Hardware, the number of bits for ECC is set to 4, the OOB is set first, and the oob layout is the same.
The NAND driver under u-boot works flawless. The kernel is stored on NAND (the board boots from a SPI-Flash), and everything seems correct.
The same thing under linux. In Linux I am able to set up a root filesystem with UBIfs, everything ok. Problems arises when u-boot tries to access to data written from Linux and viceversa. It seems to me that the management of ECC is different in u-boot and in kernel.
If I write under Linux a kernel Image in a NAND partition, after a reset I am not able to read that partition from u-boot. Setting MTDDEBUG and a couple of printf, I see that nand_do_read_ops() report an error:
if (mtd->ecc_stats.failed - stats.failed) return -EBADMSG;
This is the output of my board:
nboot aKernel
Loading from nand0, offset 0x0 Bad block table found at page 262080, version 0x01 Bad block table found at page 262016, version 0x01 Returning error 4 0 nand_bbt: ECC error while reading bad block table nand_read_bbt: Bad block at 0x000002220000 nand_read_bbt: Bad block at 0x00000b120000 nand_read_bbt: Bad block at 0x00001f100000 nand_isbad_bbt(): bbt info for offs 0x00000000: (block 0) 0x00 Returning error 8 4 NAND read from offset 0 failed -74 ** Read error
Checking the two drivers, it seems to me that they are doing different things. However, I do not know which one is correct. I would think that the driver in u-boot is old and must be synchronized with the Linux's driver, but after checking how u-boot gets the ecc's error from Hardware it seems to me it is correct.
Has anyone seen the same issue or have proposal, which driver should be modified ?
Best regards, Stefano Babic