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/
>
>
next prev parent 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