From: Steven Johnson <sjohnson@sakuraindustries.com>
To: gdb@sourceware.org
Subject: Re: GDB support for Flash memory programming
Date: Sat, 27 May 2006 00:02:00 -0000 [thread overview]
Message-ID: <44776B9A.6010309@sakuraindustries.com> (raw)
In-Reply-To: <vt2k689rj4o.fsf@theseus.home.>
Jim Blandy wrote:
>
>On the board I happen to have handy, it takes 26 seconds to write a
>full 128k flash sector over the JTAG interface. Unless this is
>extremely slow compared to what's typical out there, I'd tend to agree
>that preserving unloaded sector contents is important to leave
>optional, or not require at all. I wouldn't mind waiting a handful of
>seconds, but even ten would be too long.
>
>
Yes, also, you don't want (or need) to do it if the whole sector is
going to be programmed. Maybe another memory attribute would be
"Preserve unaltered contents of flash on reprogram"
To put it in perspective (I don't know what type of flash you have, if
you give me a part number, I'd be interested to do this analysis on your
part),
Using an accelerated buffer programming algorithm for the Spansion S29GL
family of flash the following is the theoretical typical case sector
programming time:
Typical time to program 32 bytes = 240us
Therefore 128K Bytes / 32 * 240us = 983ms total typical sector
programming time
It might be an unfair comparison, so using the traditional "Byte at a
time" algorithm for the same family, we get:
Typical time to program 1 byte = 60us
Therefore 128K Bytes * 60us = 7.8 seconds total typical sector
programming time
Both of which are significantly under your JTag Speeds to do the same
operation.
However that said, your Jtag speeds are very respectable, I've seen lots
worse, 10-20 (or more) times slower programming of flash over Jtag.
Steven J
next prev parent reply other threads:[~2006-05-26 20:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-24 1:44 Jim Blandy
2006-05-24 2:03 ` Steven Johnson
2006-05-24 22:07 ` Jim Blandy
2006-05-25 2:35 ` Steven Johnson
2006-05-24 4:43 ` Nathan J. Williams
2006-05-24 22:17 ` Jim Blandy
2006-05-24 8:03 ` Russell Shaw
2006-05-25 0:22 ` Jim Blandy
2006-05-25 3:05 ` Russell Shaw
2006-05-25 0:39 ` GDB and remote protocols Daniel Jacobowitz
2006-05-25 3:04 ` Russell Shaw
2006-05-25 0:52 ` GDB support for Flash memory programming Steven Johnson
2006-05-25 1:11 ` Peter Barada
2006-05-25 2:18 ` Jim Blandy
2006-05-25 3:29 ` Steven Johnson
2006-05-26 18:42 ` Jim Blandy
2006-05-27 0:02 ` Steven Johnson [this message]
2006-06-17 20:07 ` Mark Kettenis
2006-06-18 9:55 ` Jim Blandy
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=44776B9A.6010309@sakuraindustries.com \
--to=sjohnson@sakuraindustries.com \
--cc=gdb@sourceware.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