[U-Boot] Strange NAND issue on a P1014

[Scott Wood]

On Thu, 2013-08-15 at 18:34 +0000, ANDY KENNEDY wrote:
> All,
> 
> We are attempting to set up a NAND chip on our board through u-Boot.
> Strange things are happening. 

What sort of "strange things"?

>  During our debugging (of release
> 2013.04), we found the issue seemed to be in the file
> drivers/mtd/nand/nand_base.c file around line 2640:
> 
> 	chip->cmdfunc(mtd, NAND_CMD_READID, 0x00, -1);
> 
> An interesting comment is below this line:
> 
> 	/* Try again to make sure, as some systems the bus-hold or other
>        * interface concerns can cause random data which looks like a
>        * possibly credible NAND flash to appear. If the two results do
>        * not match, ignore the device completely.
>        */
> 
> Stranger still is that adding in a putc('x') makes the problem go away
> (tested via cold boot ~ 20 times, warm boot ~ 10 times).  In fact,
> adding in a dummy function and calling it seems to do just as well.
> 
> Other information is that we had issues with long command lines in
> u-boot.  To "fix" this (a serious hack), we adjusted config.mk's
> optimization level to -O1 from -Os.  It seems the putting this back to
> -Os makes the problem *better* but does seem to move it from a cold to a
> warm start issue.

Long command lines?  What sort of "issues"?

Please double check your DDR setup.  It sounds like you may have general
flakiness rather than a specific issue with NAND or command lines.  Have
you seen this on more than one board?

> The default configuration file for the P1014 we modified to address our
> specific NAND flash (Linux reports this as: NAND device: Manufacturer
> ID: 0x2c, Chip ID: 0xf1 (Micron MT29F1G08ABADAWP).  This is a
> replacement for an end of life dumb NAND.  We are configuring this chip
> to be in the dumb, non-embedded ECC mode.).

What does "dumb, non-embedded ECC mode" mean?

> Questions:
> 
> 1) Is this a known issue?
> 
> 2) Has anyone else experienced this with the P1014 IFC?
> 
> 3) How can one debug such a problem (using the JTAG debugger
> "CodeWarrior" has not proved helpful as changing the way we boot/the way
> we built the code/the attached debugger itself changes the behavior of
> the system)?

You should not need to alter anything about the code or how it's built
in order to use JTAG.  It would also be unusual for simply having a JTAG
connected to alter behavior.  Make sure that the debugger isn't trying
to initialize anything -- it should just sit there until it's time to
halt and inspect.

-Scott