[U-Boot] NAND on Davinci boards
Nick Thompson
nick.thompson at ge.com
Wed Mar 16 13:12:23 CET 2011
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.
More information about the U-Boot
mailing list