Re: GDB support for Flash memory programming

[Jim Blandy <jimb at codesourcery dot com>]

Mark Kettenis <mark.kettenis@xs4all.nl> writes:
>> From: Jim Blandy <jimb@codesourcery.com>
>> Date: Tue, 23 May 2006 16:32:42 -0700
>> 
>> One of the problems GDB has in the embedded development world is its
>> lack of support for loading programs into flash memory.  After some
>> conversation amongst ourselves to weed out patently stupid stuff (none
>> of the text below is mine... hey), we at CodeSourcery put together the
>> following proposal for general comments and criticism.
>>
>> We'd like to reach consensus on what the user interface should be
>> before we worry about implementation details --- possible remote
>> protocol changes, and so on --- so let's leave those topics aside for
>> the time being.
>> 
>> What do folks think?
>
> I don't think the gdb user interface should depend on the sort of
> memory you're targeting, i.e. the interface should be the same for all
> memory whether it is RAM, EEPROM or flash.  So I think "write-flash"
> is the the wrong name for the command.
>
> Looks like what you really want is some sort of command to (partially)
> write-protect (parts of) memory.

Write-flash isn't the name of the command; that's just the name of the
setting which controls whether we treat attempts to mutate variables
in flash as errors or not.  The command for loading programs remains
'load', regardless of the type of memory being accessed.

We really don't want to allow single-variable writes by default, since
writing to a variable in flash could take tens of seconds on some
devices.  But loading programs into flash is a common operation, just
as common as using 'load' in ordinary development.  So what we want is
read-onlyness depending on the command used.  And we also want the
read-onlyness map pre-initialized to match the areas of flash on the
target, since the point is to warn people before attempting expensive
operations.  I think the useful semantics here are pretty
flash-specific.