From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27347 invoked by alias); 5 Jun 2006 21:02:43 -0000 Received: (qmail 27335 invoked by uid 22791); 5 Jun 2006 21:02:42 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Mon, 05 Jun 2006 21:02:40 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FnMDe-0000Jz-QS for gdb@sourceware.org; Mon, 05 Jun 2006 17:02:38 -0400 Date: Mon, 05 Jun 2006 21:02:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org Subject: Re: GDB support for flash: implementation Message-ID: <20060605210238.GA1036@nevyn.them.org> Mail-Followup-To: gdb@sourceware.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11+cvs20060403 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/msg00026.txt.bz2 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. So, my counter-proposal is: - Merge the bits of XML support that I've already done on a branch, but only those bits related to receiving and parsing target descriptions. Most of what I've got there is actually related to changing the gdbarch based on the results, e.g. adding new registers. That's a separate problem from this one, but I can separate out the transport layer bits easily enough. - Send a qXfer:features packet to the target, and get its response. The response will include descriptions of each flash device on the target. How verbose we want those to be is up in the air; I think that given Jim's proposal, the only things we would outright need are base address and size. We might want to define other common attributes, such as block size and width, so that we can... - ...implement "info flash" based on the results. - Generate flash write packets when a write would cover flash. -- Daniel Jacobowitz CodeSourcery