public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Trent Piepho <tpiepho@freescale.com>
Cc: Arnaud Mouiche <arnaud.mouiche@thomson.net>,
	Andre Puschman <andre.puschmann@imms.de>,
	MTD mailing list <linux-mtd@lists.infradead.org>
Subject: Re: flash read performance
Date: Fri, 7 Nov 2008 04:02:00 +0000	[thread overview]
Message-ID: <20081107040200.GB17593@shareable.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0811061815190.3864@t2.domain.actdsltmp>

Trent Piepho wrote:
> On Tue, 4 Nov 2008, Andre Puschman wrote:
> > Jamie Lokier schrieb:
> >> I don't know much about this area, but will _writing_ to the flash
> >> work reliably if ioremap_cached() is used?
> >>
> > Good point. I only was into reading and so I totally forgot writing ;-)
> > I gave it a try, although it was terribly slow (only a few kb/s), it worked.
> > I just did a cp uImage /dev/mtd3. On the other hand, I never tried writing
> > with the old driver. So I don't know if this is faster.
> 
> I've found that writes do not work with caching enabled.  When the CPU writes
> to the flash and then reads it back, it gets returned what it wrote.

Thanks, both.

Based on Andre's observation, I will soon try enabling cache for my
NOR, and see if it makes a difference to cold-cache read performance.
I don't expect it, but it's worth a try.

If that helps significantly, then I'll look at doing writes properly.

> That's not what is supposed to happen.  For example, to program
> flash word 'i' to the value 'val' using the Spansion/AMD method, you
> do this:
> 
> flash[0] = 0xf0f0;
> flash[0x555] = 0xaaaa;
> flash[0x2aa] = 0x5555;
> flash[0x555] = 0xa0a0;
> flash[i] = val;
> while(flash[i] != val); /* wait for it to finish */
> 
> After this flash[0] should be whatever data was there before, not 0xf0f0. 
> Same with flash[0x555] and the rest.  Only flash[i] should be modified.  But
> if flash is cached, the cpu will use the cached values and think flash[0] is
> 0xf0f0 until the cache gets flushed.

You might also find the write operation to be unreliable, if the
caching mode is write-back rather than write-through.

Really, you should use an uncached mapping to write commands to the
flash, flush the cached mapping (for reads) when commands are written,
and prevent any access during the writes (this is in MTD normally).
You could optimise by flushing only the cached read regions which are
affected by write and erase commands.

> > I also did some more testing with my improved flash-timing parameters,
> > which yields to read speeds of up to 18-19MB/s, which is really fast
> > compared
> > to 1,3MB/s at the beginning :-)
> 
> My results, from a mpc8572 (powerpc) with a spansion s96gl064n flash
> chip on a 100 MHz bus.
> 
> Mapping				Speed (MB/sec) (MB = 1048576 bytes)
> un-cached and guarded		12.30
> cached and gaurded		14.24
> cached and un-guarded		14.31
> un-cached and un-guarded	14.66
> 
> I measured by reading flash linearly from beginning to end 32-bits at a time. 
> Since the flash is bigger than the cache, ever read should have come from the
> flash.  If I just read the same 1k over and over that would obviously be much
> faster if it could come from the cache.

That's nice to see that cache helps cold-read performance too, not
just cached reads.  Thanks :-)

> The biggest bootup delay I have now is waiting for the ethernet phy to get
> online, which takes almost 3 seconds.

Do you need to delay everything else for that, or can you parallelise?

-- Jamie

  reply	other threads:[~2008-11-07  4:02 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-28 10:14 flash read performance Andre Puschmann
2008-10-29 11:42 ` Josh Boyer
2008-10-29 12:03   ` Jamie Lokier
2008-10-29 15:52   ` Andre Puschmann
2008-10-30  8:33     ` Arnaud Mouiche
2008-10-30  9:52       ` Andre Puschmann
2008-10-30 10:06         ` Arnaud Mouiche
2008-11-03 14:23           ` Andre Puschmann
2008-11-04  8:30             ` Andre Puschmann
2008-11-04 11:42             ` Jamie Lokier
2008-11-04 14:31               ` Andre Puschman
2008-11-07  2:41                 ` Trent Piepho
2008-11-07  4:02                   ` Jamie Lokier [this message]
2008-11-07  5:36                     ` Trent Piepho
2008-11-07  5:57                       ` Jamie Lokier
2008-11-07  9:47                   ` Andre Puschmann
2008-11-08  5:28                     ` Trent Piepho
2008-11-11 13:28                       ` Andre Puschmann
2008-11-15  2:02                         ` Trent Piepho

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081107040200.GB17593@shareable.org \
    --to=jamie@shareable.org \
    --cc=andre.puschmann@imms.de \
    --cc=arnaud.mouiche@thomson.net \
    --cc=linux-mtd@lists.infradead.org \
    --cc=tpiepho@freescale.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox