All,
We are attempting to set up a NAND chip on our board through u-Boot. Strange things are happening. 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.
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.).
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)?
If you have any information that might help us to figure out this issue, please pass it along. We'd be grateful for any help.
BTW, I'm currently attempting to move to 2013.07 to see if we change the behavior for the long lines issue as well as the NAND issue.
Thanks, Andy