Re: GDB support for flash: implementation

[Daniel Jacobowitz <drow@false.org>]

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