From: Jim Blandy <jimb@codesourcery.com>
To: Steven Johnson <sjohnson@sakuraindustries.com>
Cc: gdb@sourceware.org
Subject: Re: GDB support for Flash memory programming
Date: Fri, 26 May 2006 18:42:00 -0000 [thread overview]
Message-ID: <vt2k689rj4o.fsf@theseus.home.> (raw)
In-Reply-To: <44751B5C.6090006@sakuraindustries.com>
Steven Johnson <sjohnson@sakuraindustries.com> writes:
>>That's a good point. It's important for the interface to allow
>>efficient implementations; performance is part of the user interface.
>>If everyone hacks around it because it's slow, then we haven't
>>contributed much.
>>
>>In your experience, on modern devices, what's the longest it takes to
>>copy a sector of flash to RAM?
>>
> Well, its a memory to memory copy, so it will take as long as any memory
> to memory copy. That will depend on the speed of the Flash, Ram and CPU
> Bus, and width of each device. That isn't really a problem, for devices
> with enough memory to back up the page "In Ram" the extra time to backup
> copy wouldn't be a lot, in comparison to the programming time. The
> issue is systems without enough memory, then you are talking memory read
> speeds thought the debug interface. In Practice, the overhead is
> probably like this:
>
> A Spansion S29GL128N NOR with a 128K Page and 8 bit bus (Writing that 1
> page):
>
> 1. Read 128K (128K Read Cycles over the Jtag Bus)
> 2. Erase Page (0.5 - 3.5 seconds, excluding time to auto-preprogram all
> bits to 0)
> 3.1 Write Byte (4 write cycles)
> 3.2 Read Byte for status (If status is OK, continue otherwise repeat),
> assume 1 repeat is normal. (will need to wait approx 60us)
> 3.3 Repeat to 3.1 for the 128K Bytes.
>
> We have 128K Reads + 4*128K Writes + 2*128K Reads, so just in read/write
> performance, excluding sector erase time, reading the page increases the
> time to program by around 16%.
All right. So, to figure the worst-case cost of that requirement,
we're looking at programming a single byte in a sector which is
otherwise full of non-0xFF data, over a JTAG interface. We're
comparing these two operations:
- read (almost) the sector over the JTAG interface, erase the sector,
and then write it all back
versus:
- erase the sector, and then write one byte.
The erasure time is needed no matter what we do; that doesn't count.
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.
next prev parent reply other threads:[~2006-05-25 19:37 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 [this message]
2006-05-27 0:02 ` Steven Johnson
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=vt2k689rj4o.fsf@theseus.home. \
--to=jimb@codesourcery.com \
--cc=gdb@sourceware.org \
--cc=sjohnson@sakuraindustries.com \
/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