Re: GDB support for Flash memory programming

[Mark Kettenis <mark dot kettenis at xs4all dot nl>]

> 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.

> 
> ---
> 
> Background
> 
> Flash memory is a popular form of non-volatile memory. When reading,
> it is byte-addressable, like traditional RAM or ROM. An entire block
> (many kilobytes, typically) of flash can be erased with a single
> command. Individual bytes can be written only if they have been
> erased, but not subsequently written. Therefore, to write a single
> byte, without changing other bytes in the same block, one must read
> the block, erase the block, and then re-write the block using the
> previously read data, as modified by the intended write.
> 
> Flash is typically used for program storage. On some systems, flash is
> in fact the only place to store programs. For example, some systems
> have have relatively large amounts of flash, but very small amounts of
> RAM.
> 
> If the flash memory controller has a JTAG interface (most do) then the
> flash memory can typically be programmed using the same ICE/BDM unit
> that is used for debugging.
> 
> Because GDB already communicates with these ICE units (typically via a
> GDB stub), and because GDB already supports loading programs onto
> embedded systems (via the load command), it is natural that GDB
> support loading programs into flash memory as well. This document
> proposes a GDB user interface for loading programs into flash memory.
> 
> In what follows, the term "GDB" refers to the user's view of GDB,
> which includes GDB, any applicable stub, the ICE units, etc. Thus
> statements like "GDB must do X" are not meant to imply that GDB proper
> must do X, but rather that GDB must cause X to occur.  Program Images
> 
> 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.
> 
> If the target hardware requires any other modifications to special
> memory addresses (such as placing the initial value of the program
> counter at a specified address), then it is the responsibility of the
> programmer to ensure that the program image contains appropriate
> values at those addresses; GDB's responsibility is simply to
> accurately copy the program image to the target.
> 
> The rationale for using load (rather than an alternative flash
> command) is that, on a system in which programs are located in flash,
> loading a program implies placing it in flash. Furthermore, GUIs,
> scripts, etc., that use load (or the MI equivalent thereof) will not
> require change to work with flash systems.  Variables and Data
> 
> By default, variables and other data located in flash may not be
> modified by the user, other than by use of the load command. For
> example, if i is located in flash, then:
> 
>     set var i = 10
> 
> will result in an error message. (As a consequence, GDB must be able
> to determine which addresses lie in flash; otherwise, GDB, using a
> stub with a 100% transparent interface to flash, would not be able to
> issue an error.)
> 
> The rationale for forbidding modification of variables is that most
> such attempted modifications probably represent user
> error. Furthermore, because setting a single variable requires erasing
> and writing an entire flash sector, there might be some noticable
> delay in implementing this request.  Customization
> 
> GDB will have a new write-flash variable. This variable will have
> three possible states:
> 
>     * on
> 
>       All writes to flash, including those to variables/data, are
>       permitted. This mode may be used to permit explicit "poke"
>       operations, like the assignment above.
> 
>     * load
> 
>       The load command may write to flash; no other commands may write
>       to flash. This mode is the default.
> 
>     * off
> 
>       No commands may write to flash. This mode may be used for safety
>       when debugging a production system.
>