GDB support for Flash memory programming

[Jim Blandy <jimb at codesourcery dot com>]

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?

---

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.