Re: MPC831x (and others?) NAND erase performance improvements

[Mark Mason <mason@postdiluvian.org>]

Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:

> Scott Wood <scottwood@freescale.com> wrote on 2010/12/08 18:18:39:
> >
> > On Wed, 8 Dec 2010 08:59:49 +0100
> > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> >
> > > >
> > > > On Mon, 6 Dec 2010 22:15:54 -0500
> > > > Mark Mason <mason@postdiluvian.org> wrote:
> > > >
> > > > > A few months ago I ran into some performance problems involving
> > > > > UBI/NAND erases holding other devices off the LBC on an MPC8315.  I
> > > > > found a solution for this, which worked well, at least with the
> > > > > hardware I was working with.  I suspect the same problem affects other
> > > > > PPCs, probably including multicore devices, and maybe other
> > > > > architectures as well.
> > > > >
> > > > > I don't have experience with similar NAND controllers on other
> > > > > devices, so I'd like to explain what I found and see if someone who's
> > > > > more familiar with the family and/or driver can tell if this is
> > > > > useful.
> > > > >
> > > > > The problem cropped up when there was a lot of traffic to the NAND
> > > > > (Samsung K9WAGU08U1B-PIB0), with the NAND being on the LBC along with
> > > > > a video chip that needed constant and prompt attention.
> > > >
> > > > If you attach NAND to the LBC, you should not attach anything else to
> > > > it which is latency-sensitive.
> > >
> > > This "feature" makes the LBC useless to us. Is there some workaround or plan
> > > to address this limitation?
> >
> > Complain to your support or sales contact.
> >
> > I've complained about it in the past, and got a "but pins are a limited
> > resource!" response.  They need to hear that it's a problem from
> > customers.
> 
> Done, lets see what I get in return. I think this problem will be
> a major obstacle for our next generation boards which will be NAND
> based.

It was a big problem, and a big surprise, for me too.  The next
generation of a couple of the chips on the bus have pcie, but those
are noticably more expensive.

Another problem I ran into was that the DMA performance from a
non-incrementing address was abysmal, PIO turned out to be
significantly faster.  I guess internally the bus does an entire
cacheline transfer for every word read from a fixed address, or
something like that.  I was doing DMA from a device that had only six
address bits, it should have been in the middle of the bus with the
bottom address pins not connected, which would have allowed
incrementing address DMA.  The transfer speed wasn't so much of a
problem, but the longer transfers meant that there was that much less
bus bandwidth for the other devices, so we wound up sacrificing CPU to
get more bus bandwidth.