Re: GDB support for Flash memory programming

[Jim Blandy <jimb@codesourcery.com>]

Steven Johnson <sjohnson@sakuraindustries.com> 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?