From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Thompson Date: Wed, 16 Mar 2011 12:12:23 +0000 Subject: [U-Boot] NAND on Davinci boards In-Reply-To: <4D80A692.4040607@denx.de> References: <4D807351.4020504@denx.de> <4D808A87.6010406@ge.com> <4D80A692.4040607@denx.de> Message-ID: <4D80A927.6010307@ge.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 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.