[U-Boot] NAND on Davinci boards

[Nick Thompson <nick.thompson@ge.com>]

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.