public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Arnaud Mouiche <arnaud.mouiche@thomson.net>
To: Andre Puschmann <andre.puschmann@imms.de>
Cc: linux-mtd@lists.infradead.org
Subject: Re: flash read performance
Date: Thu, 30 Oct 2008 11:06:14 +0100	[thread overview]
Message-ID: <49098716.1010404@thomson.net> (raw)
In-Reply-To: <gec051$efd$1@ger.gmane.org>

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

  reply	other threads:[~2008-10-30 10:06 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 [this message]
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
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=49098716.1010404@thomson.net \
    --to=arnaud.mouiche@thomson.net \
    --cc=andre.puschmann@imms.de \
    --cc=linux-mtd@lists.infradead.org \
    /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