From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18005 invoked by alias); 5 Jun 2006 21:28:30 -0000 Received: (qmail 17991 invoked by uid 22791); 5 Jun 2006 21:28:29 -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; Mon, 05 Jun 2006 21:28:28 +0000 Received: (qmail 3309 invoked from network); 5 Jun 2006 21:28:26 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Jun 2006 21:28:26 -0000 To: gdb@sourceware.org Subject: Re: GDB support for flash: implementation References: <20060605210238.GA1036@nevyn.them.org> From: Jim Blandy Date: Mon, 05 Jun 2006 21:28:00 -0000 In-Reply-To: <20060605210238.GA1036@nevyn.them.org> (Daniel Jacobowitz's message of "Mon, 5 Jun 2006 17:02:38 -0400") 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-06/txt/msg00028.txt.bz2 Daniel Jacobowitz writes: > On Mon, Jun 05, 2006 at 11:34:12AM -0700, Jim Blandy wrote: >> The GDB load command initially tries to place the program image in >> memory using ordinary memory write requests --- remote protocol M or X >> requests. However, when the stub detects that GDB has attempted to >> write to flash memory, it returns an error code of the form: >> >> Eflash:addr;length >> >> In this reply, addr and length are the start address and length of the >> block of flash memory the write request attempted to modify. That is, >> a write that overlaps any portion of a region of flash memory elicits >> an Eflash response giving the location and size of the entire flash >> memory. If the write request overlaps two areas of flash, the Eflash >> request reports the lowest-addressed area. When the stub returns an >> Eflash result, it should discard the entire write request; if portions >> of the request cover non-flash memory, the contents of that memory >> should be unchanged. > > Jim and I were talking about this earlier and didn't really come to a > conclusion. I don't like Eflash; I think it's unnecessarily > complicated, and that it would actually be simpler to ask the target > to tell us where its flash is. To be clear: once GDB knows where the flash is, you think the rest of the proposal is okay, right?