flash read performance

[Jamie Lokier]

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