On 16/03/11 12:01, Stefano Babic wrote:
On 03/16/2011 11:01 AM, Nick Thompson wrote:
Hi Nick,
I'm using da830evm (OMAP-L137) with more or less up-to-date U-Boot, but quite old 2.6.18+ kernel from Montavista.
#define CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST #define CONFIG_SYS_NAND_USE_FLASH_BBT
I don't have BBT enabled.
Thanks, I have tried to disable it. No improvement, I got always ECC errors.
Neither ;)
I think the U-Boot NAND driver for davinci has always been setup to be compatible with the TI & Montavista Kernels.
This is probably the problem. I cannot check the montavista sources (I do not use them, but it seems that the old source.mvista.com went offline), but if u-boot sticks to mvista kernel is surely not aligned to the kernel mainline.
What I'm not sure about is if those Kernels are compatible with mainline Linux and in particular the very latest mainline kernels. In fact I'm not sure if it is compatible with the very latest TI Kernels.
I think I can answer: no. I checked PSP_3.20 from Texas, and even on the arago project. TI went from their 2.x version of PSP tools to 3.x from mvista kernel to mainline kernel, and probably at that point u-boot and kernel were not anymore compatible. I have not seen patches in drivers/mtd/davinci_nand.c related to make it suitable for newer kernels.
You may be correct, but maybe you have another problem first...
Have you tried "nand dump" of a Linux programmed Kernel and compared it with "nand dump" of a U-Boot programmed Kernel?
I have tried now to get the first page (=2048 bytes) from both and I have compared byte-per-byte. They are identical, inclusive the oob part.
You would be able to see identical data in each case, but you will be able to compare the differences in the OOB. You only need to look at the first page to see if the OOB data or position of the OOB data differs.
No differences at all. For both, I get in the oob:
OOB: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Is this really from the OOB for the first _kernel_ page. It looks wrong.
I see:
nand dump 0x100000
<snip> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 9a ea 40 97 85 bc 5f f5 2e 15 91 c2 c6 93 14 c0 03 e3 b6 4c 35 40 2d 8f 7e 74 10 13 59 47 cf 09 24 10 6a 0a 8b e2 f1 b0
The part after all the ff's is the ECC. IIRC a zero ECC implies all the data in the page is zero also. That would be an odd start to a Kernel image.
Can you confirm what it is you dumped?
However, u-boot complain about it:
nand read kernel_addr_r 0 800
NAND read: device 0 offset 0x0, size 0x800 Getting too many errors Getting too many errors Getting too many errors Getting too many errors 2048 bytes read: OK
You errors all seem to be in the BBT handling. I don't use BBT here.
Rather it is not enough - already tried to disable, same errors. It seems I can exclude errors by writing or reading raw data from the NAND. It seems the problem is related to a different interpretation of ECC results.
Stefano
Nick.