Re: flash read performance

[Andre Puschmann <andre.puschmann@imms.de>]

Hi,

Trent Piepho wrote:
> 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.  That's
> not what is supposed to happen.  

Sure, writes should be uncached and unbuffered. But I thought the mtd 
layer handles this correctly as there are two different ioremap's in the 
driver:

map.virt = ioremap(..);
map.cached = ioremap_cached(..);
map.inval_cache = inval_cache_fct();

So, calling inval_cache_fct() just before any write operation and then 
using the uncached mapping should do the trick, no? On the other hand, I 
am not sure if the mtd-layer really behaves like that. Can somebody 
confirm this?
Anyway, I tried to write a cramfs-image to a previously (in uboot) 
erased flash area. After that, I could successfully boot the system 
using this cramfs as my root. So I would reason that writes are OK.
Time is another point (cramfs_xip.bin is 1.6MB):

# time cp cramfs_xip.bin /dev/mtd3
real    4m 13.52s
user    0m 0.00s
sys     4m 13.03s

This is around 6,3kB/s. Doing the same write in uboot with cp.b takes 
about 26sec. So this is around 62kB/s.


> 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.

I measured by reading from mtd char device, which is not reading the 
same data over and over again.
I copied the whole partition into a ramdisk. mtd3 is 3MB in size so this 
yields to a read speed of 11.53MB/s

# time cp /dev/mtd3 /tmp/test
real    0m 0.26s
user    0m 0.01s
sys     0m 0.24s


> I'm just using the GPCM mode of the Freescale eLBC, which means I have to use
> the same timings both for writes and reads.  There are parts of the timing I
> could make faster for reads, but then they would be too short for writes, and
> vice versa.  It also means I can't use the page burst mode, which would
> speed up reads significantly.

I am not familiar with GPCM and eLBC, but it sounds about the same here. 
Same timings for writes and reads. But I use burst mode (4 words), but 
this only applies to reads.

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

Same here, ethernet phy takes sooo long. Here is what I do: I am using a 
parallel init. On script is just for loading the ethernet-module which 
is done next to the other scripts. So 2sec is cheated, cause ethernet 
isn't really available at this point of time.

Regards,
Andre