From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17864 invoked by alias); 25 May 2006 19:37:44 -0000 Received: (qmail 17848 invoked by uid 22791); 25 May 2006 19:37:43 -0000 X-Spam-Check-By: sourceware.org Received: from intranet.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.6) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 25 May 2006 19:37:15 +0000 Received: (qmail 17083 invoked from network); 25 May 2006 19:37:13 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 25 May 2006 19:37:13 -0000 To: Steven Johnson Cc: gdb@sourceware.org Subject: Re: GDB support for Flash memory programming References: <4474F8D3.3000708@sakuraindustries.com> <44751B5C.6090006@sakuraindustries.com> From: Jim Blandy Date: Fri, 26 May 2006 18:42:00 -0000 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00372.txt.bz2 Steven Johnson 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.