On Thu, 2013-08-15 at 21:09 +0000, ANDY KENNEDY wrote:
hmmm, trimming off more text (to see if it makes it to the list this time). . .
On Thu, 2013-08-15 at 19:35 +0000, ANDY KENNEDY wrote:
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"?
e.g. NAND dropping out.
Again, could you be more specific? Is there a particular error message you're getting?
A copy/paste from the system.
U-Boot 2013.04 (Aug 13 2013 - 17:26:01)
CPU: P1014E, Version: 1.0, (0x80f90110) Core: E500, Version: 5.1, (0x80212151) Clock Configuration: CPU0:400 MHz, CCB:266.667 MHz, DDR:333.333 MHz (666.667 MT/s data rate) (Asynchronous), IFC:66.667 MHz L1: D-cache 32 kB enabled I-cache 32 kB enabled Board: TA1x48VI2C: ready DRAM: Configuring DDR for 666.667 MT/s data rate DRAM: Enabling Industrial Temp 256 MiB (DDR3, 16-bit, CL=6, ECC off) Flash: 32 MiB L2: 256 KB enabled NAND: No NAND device found!!! 0 MiB In: serial Out: serial Err: serial Net: Configuring Serdes 1: eTSEC1 Configuring Serdes 2: eTSEC2 Phy not found PHY reset timed out eTSEC1, eTSEC2 =>reset U-Boot 2013.04 (Aug 13 2013 - 17:26:01)
CPU: P1014E, Version: 1.0, (0x80f90110) Core: E500, Version: 5.1, (0x80212151) Clock Configuration: CPU0:400 MHz, CCB:266.667 MHz, DDR:333.333 MHz (666.667 MT/s data rate) (Asynchronous), IFC:66.667 MHz L1: D-cache 32 kB enabled I-cache 32 kB enabled Board: TA1x48VI2C: ready DRAM: Configuring DDR for 666.667 MT/s data rate DRAM: Enabling Industrial Temp 256 MiB (DDR3, 16-bit, CL=6, ECC off) Flash: 32 MiB L2: 256 KB enabled NAND: 128 MiB In: serial Out: serial Err: serial Net: Configuring Serdes 1: eTSEC1 Configuring Serdes 2: eTSEC2 Phy not found PHY reset timed out eTSEC1, eTSEC2
The ONLY thing that occurs here is we wiggled the reset GPIO of the P1014. Viola! Everything works.
What happens when the READ ID command is issued in the failing case? Is there an error status? IFC timeout? Bad data returned?
Have you double checked your NAND timings?
Yeah, as best as we can. Something else strange about this is even in the broken case, if we load Linux, Linux is happy with the configuration. Problem is, Linux lives on the NAND flash.
Another of your folks helped us with this issue. There is apparently some spreadsheet your folks have to figure out the four timing parameters that are in the config file. We've second and third guessed those. We always come up with the same thing.
Something timing related feels wrong, though. We have seen issues, for example, with reading the NAND ID. We found that if we put in a for loop around that location of the code, we can consistently read the NAND ID after a third read. It feels like there is a bus timing issue but we cannot make it fail consistently by doing anything.
What happens if you put a delay in before you try to access NAND for the first time?
Command lines that are > 1000 bytes getting truncated, etc.
Have you increased CONFIG_SYS_CBSIZE? Though I'm not sure why the behavior of exceeding CONFIG_SYS_CBSIZE would be unpredictable, unless there's some bounds checking bug.
Currently, it is set to 2048. Changing this larger doesn't seem to affect the problems.
That's quite large. You're likely causing the stack to overflow into the lmb area (unless you've adjusted the stack size too). Only 4K is reserved for the stack. I don't know if this is actually causing your problem, since you'd need to be running a command that does something with lmb (e.g. bootm), but it's not good.
If you really need this you could increase the stack size, but you may want to rethink why you need such long commands.
IFC doing the ECC is what I'd consider normal usage... I'm not familiar with non-raw modes.
What do you mean by a 4-bit OOB area? Searching for this chip shows it to have 2048 byte pages, and 64 bytes of OOB per page. NOP is 4. This chip should work with JFFS2.
It does in raw mode. If you change to the managed ECC type, you don't get the same usage. On another project (without the P1014), the NAND controller was too simple. We had to enable the managed NAND ability of the chip to do the ECC for us, however, this chewed up MOST of the OOB. The details escape me, but I remember JFFS2 wouldn't allow us to NOT use JFFS2's ECC, and would not do ECC (maybe it was 4 BYTES of OOB???) with too little OOB. YAFFS2, however, would.
JFFS2 doesn't have its own ECC, but it does require a few bytes (eight IIRC) of free OOB for cleanmarkers. In any case, I suggest looking into UBI as the "new and improved" technology.
-Scott