[U-Boot] Strange NAND issue on a P1014
Scott Wood
scottwood at freescale.com
Fri Aug 16 04:59:42 CEST 2013
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
More information about the U-Boot
mailing list