From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15540 invoked by alias); 25 May 2006 00:52:10 -0000 Received: (qmail 15531 invoked by uid 22791); 25 May 2006 00:52:09 -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 00:52:08 +0000 Received: (qmail 31593 invoked from network); 25 May 2006 00:52:05 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 25 May 2006 00:52:05 -0000 To: Steven Johnson Cc: gdb@sourceware.org Subject: Re: GDB support for Flash memory programming References: <4474F8D3.3000708@sakuraindustries.com> From: Jim Blandy Date: Thu, 25 May 2006 02:18:00 -0000 In-Reply-To: <4474F8D3.3000708@sakuraindustries.com> (Steven Johnson's message of "Thu, 25 May 2006 11:22:43 +1100") 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/msg00360.txt.bz2 Steven Johnson writes: > Answering the ideas proposed directly below: > >>Background Well, the "Background" section was mostly meant to explain what flash is and why it needs special treatment, for people who aren't familiar with it. The comments you've posted on that seem like they'll be important when we get down to talking about implementation, so I'll leave them aside for now. >>If the program image loaded by the load command will result in any >>portion of the program image being placed in flash memory, then GDB is >>responsible for modifying the flash accordingly. GDB must not modify >>bytes outside of the program image itself. Therefore, if the program >>image occupies only a portion of a flash sector, GDB is responsible >>for arranging flash read/erase/write commands appropriately so as to >>avoid changing unmodified portions of the sector. >> >> > This should be optional, doing the copy away and back takes time. If > there are no parameters in the flash, then it slows down the "load" for > no gain. 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? Does the time required to write a sector depend on how much you actually modify from the "erased" state? > I think the ability to tell GDB about a targets "memory map" in a > generic way would be good, for example being able to tell GDB: > 1. A region of memory is read only (whether it be flash or otherwise) > 2. A region of memory is not to be read cached. ie, it must be fetched > from the target each time it is read by GDB. > 3. A region of memory doesnt exist, don't read or write it. Actually, GDB already has this, to some extent; look at the "mem" command, or see (gdb)Memory Region Attributes in the GDB manual. I could see making flash state a new kind of memory region attribute. Assuming that we can expand in this way as needed, do you think the single global option could be useful in the first cut?