[U-Boot] Strange NAND issue on a P1014
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
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:
Is this a known issue?
Has anyone else experienced this with the P1014 IFC?
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
participants (2)
-
ANDY KENNEDY -
Scott Wood