flash read performance

Andre Puschmann andre.puschmann at imms.de
Mon Nov 3 09:23:41 EST 2008


I spent some more time on this issue and investigated some mtd-maps
The kernel I am using is a 2.6.21 that comes out of the gumstix 
svn-repo. Unfortunately, it uses a legacy driver which only does a
ioremap() but no ioremap_nocache(). Patching the driver with this
additional call boosts up transfers up to around 5.5MB/s, which
is a fairly improvement.
I will send a patch to the gumstix list. Users of newer kernel might
not need this, as they use a newer driver (pxa2xx-flash.c) anyway.

But I am wondering if things still can go faster?!
Jamie, do you some information about the speed I can expect 
theoretically? Or do I have to switch over to another operation
mode (i.e. async) for higher speeds?

Thanks in advance.

Best regards,

Arnaud Mouiche schrieb:
> I was using redboot, configured to use the optimized memcpy (yes, it 
> gives the choice at configuration time)
> on kernel side, I just hack memcpy_fromio to add a "weak" attribute, and 
> rewrite it to directly use the linux optimized memcpy (shame on me for 
> this "not suggested" methode, but speed was my goal)
> after that, performances are equal between bootloader and linux, and 
> really near the one reached by a DMA access, which is also the 
> performances we can calculate from FLASH time access configuration.
> arnaud
> Andre Puschmann a écrit :
>> Hi,
>>> I was faced with the same wondering in the past : bootloader NOR access 
>>> was really much faster that Linux one.
>> About how much faster? It really depends on the access method. I am
>> using u-boot and if I use the basic cp.b routine its about the same
>> _slow_ speed. I tried to use the asm-optimised memcpy routine that the 
>> kernel has. This is much faster, around 5MB/s.
>>> Yes, no DMA was used (but the same on bootloader, and anyway that 
>>> doesn't impact the data rate, only the CPU load), but even worse, Linux 
>>> code was using memcpy_fromio which a basic byte by byte loop copy in the 
>>> default ARM implementation.
>> Yes, memcpy_fromio is quite slow. But using normal memcpy is not 
>> suggested, only use writel()/readl() and memcpy_[from|to]io().
>> I am not sure about the right _fast_ way to to such copies.
>> Regards,
>> Andre
>> ______________________________________________________
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

More information about the linux-mtd mailing list