GDB support for Flash memory programming

GDB support for Flash memory programming

[Jim Blandy]

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.

Re: GDB support for Flash memory programming

[Steven Johnson]

Hi,

I've been using GDB to debug programs (and load them with "load") in
flash for a long time.  What I do, isn't necessarily generic, but i
thought it worth relaying given the current topic, my experience may be
useful (or not).

What I do is this:

GDB has "pre" and "post" hooks to commands.  If I want to flash load,
what I do is this:

Install a "Pre" hook on load. "define hook-load" something like this:

# Set memory variables
set $FLASH_BASE=0xFFF00000
set $RAM_BASE=0x00000000
set $FLASH_SIZE=(512*1024)

define hook-load
  # Initialise the target so it is downloadable.
 
  # Macro which resets the target
  TARGET_RESET

  # Macro which sets the processor speed
  SET_SPEED

  # Macro which sets up the chip select logic
  SETUP_SRAM_AND_FLASH_CS

  # Macro which sets up sdram, so it can be used.
  SETUP_SDRAM

  # If flash contained stuff that you wanted to preserve, it could be
"copy before over-write" with another stub command like this:
  # monitor memcopy $FLASH_BASE $RAM_BASE $FLASH_SIZE
  # so that anything not "loaded" over would be re-written back to the
flash.
  # but we don't care, so we don't do it.

  # re-map memory, so a load to flash, goes to SDRAM
  monitor memremap $RAM_BASE $FLASH_BASE $FLASH_SIZE
  # Now  any writes or reads to flash, by the remote protocol will be
re-directed from
  # the flash base address to the ram base address, up to flash_size
  # for example, a write to 0xFFF00300 will be remaped by the stub to be
a write to 0x00000300

  # Set the size of the download packet for maximum performance.
  set download-write-size 1024
end

So, before a "load" the montor (or target stub) is told to re-direct all
writes and reads to flash to an area of ram, where it is safe to do so.

The load then occurs, and the load can write to the flash area, but the
target will actually put the data loaded, in ram, at a known location.

Then I define a post-load hook, like this:

define hookpost-load
  # Clear all memory remapping installed by the pre-hook.
  monitor resetmemremap

  # download a small flash burning stub (binary image) directly to
address 0x100000
  # This works, because my monitor is in the PC, and it uses JTAG to
talk to the target
  # If the monitor was resident in the target, the flash burn stub could
be part of
  # the monitor and this step could be skipped
  # for example, you could just call something like "monitor burn <from>
<to> <size>
  # bput is a command which allows the monitor to squirt an arbitrary
binary image
  # anywhere into memory, we use it to do downloads when we don't want
GDB to know
  # about them
  set remotetimeout 60
  monitor bput utility/flashburn.bin 00100000
  set remotetimeout 5

  # Run the flash burn stub.  By convention the first instruction of the
stub
  # jumps to the stub code, and the second instruction of the stub is where
  # all execution will end.  It makes it easier to call stubs this way,
because
  # we can easily put a breakpoint on the end of the stub execution
  set $r0=$FLASH_BASE
  set $r1=$RAM_BASE
  set $r2=$FLASH_SIZE
  break *0x100004
  jump  *0x100000
  clear  *0x100004

  # After this, the flash has been programmed with the contents of
memory from address 0x00000000
  # which was put there by the load.
 
  # Macro which causes a hardware reset of the target.
  TARGET_RESET
end

Then after the load has completed, the code to be loaded is in flash at
the correct place, and because the
code we are downloading here specifically is executed immediately after
a hardware reset (its the boot code)
the target is in the correct state.

As far as GDB is concerned it just "loaded" the memory, which it did,
but by these "hooks" we managed the
process of burning the load into flash (transparently).

Its a little clunky and requires some small custom commands to be added
to the monitor stub (none of which are very difficult), but it works
well is 100% reliable and is fast.  Now if bput'ing and mem-remapping
(or the like) became standard commands and gdb did it, instead of the
stub, so much
better.  In my opinion that's all that's really required for a GDB
generic approach, because, there are so many different targets with
different flash
programming requirements (different algorithms, 8, 16, 32 bit, etc.)
that I'm not sure a fully "generic" approach is ever going to be very
workable.  At the very least, there is going to need to be different
flash programming algorithms, and then GDB is going to have to be taught
what ones are appropriate for a particular memory space on a particulat
target, and it may have multiple different ones, etc..  With the method
I describe here it doesn't matter, because the user provides a "flash
burning stub" which takes care of it for the target in question.

I have concerns about GDB "Burning" flash directly, because burning
flash directly over a JTAG interface is (in my experience) orders of
magnitude slower than burning from target ram to flash.  Provided the
target has available ram to do it, i would always prefer a load to ram,
burn from there approach, because it is heaps faster, and speed matters
(especially at load).  no one wants to wait 10 minutes or more, every
time they want to do a new "load" to test a bug.

Anyway, I'm not evangelising this approach, its just what I do, and it
works for me.

Steven J


Jim Blandy wrote:

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

Re: GDB support for Flash memory programming

[Jim Blandy]

Steven Johnson <sjohnson@sakuraindustries.com> writes:
> I've been using GDB to debug programs (and load them with "load") in
> flash for a long time.  What I do, isn't necessarily generic, but i
> thought it worth relaying given the current topic, my experience may be
> useful (or not).

Thanks for taking the time to look over the proposal!  From my point
of view, this list hardly ever has much discussion on issues that are
specific to embedded development (as opposed to more generic concerns,
like, say, stack unwinding), so I'm encouraged to think that there
could be a solid base of users whose experience we can build on.

That's quite a setup you've got there.

> Its a little clunky and requires some small custom commands to be added
> to the monitor stub (none of which are very difficult), but it works
> well is 100% reliable and is fast.  Now if bput'ing and mem-remapping
> (or the like) became standard commands and gdb did it, instead of the
> stub, so much
> better.  In my opinion that's all that's really required for a GDB
> generic approach, because, there are so many different targets with
> different flash
> programming requirements (different algorithms, 8, 16, 32 bit, etc.)
> that I'm not sure a fully "generic" approach is ever going to be very
> workable.  At the very least, there is going to need to be different
> flash programming algorithms, and then GDB is going to have to be taught
> what ones are appropriate for a particular memory space on a particulat
> target, and it may have multiple different ones, etc..  With the method
> I describe here it doesn't matter, because the user provides a "flash
> burning stub" which takes care of it for the target in question.
>
> I have concerns about GDB "Burning" flash directly, because burning
> flash directly over a JTAG interface is (in my experience) orders of
> magnitude slower than burning from target ram to flash.  Provided the
> target has available ram to do it, i would always prefer a load to ram,
> burn from there approach, because it is heaps faster, and speed matters
> (especially at load).  no one wants to wait 10 minutes or more, every
> time they want to do a new "load" to test a bug.

Well, I think you're making assumptions about the implementation that
aren't implied by the proposal.  As we say:

    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.

For the time being, let's assume that detailed knowledge of the device
can be placed somewhere appropriate, that we can work out ways to use
efficient transfer methods, and so on.  For example, the details of
the flash programming algorithm don't need to be in GDB itself: the
stub could be responsible for the details, and GDB would simply need
to provide the stub blocks of data in some convenient way.

I guess what we really want to settle at this point is, if we could
arrange for the commands to Just Work as described, would that
actually be what you need for your workflow?  Or are there other needs
that we don't understand yet?

Re: GDB support for Flash memory programming

[Steven Johnson]

Jim Blandy wrote:

>Steven Johnson <sjohnson@sakuraindustries.com> writes:
>  
>
>>I've been using GDB to debug programs (and load them with "load") in
>>flash for a long time.  What I do, isn't necessarily generic, but i
>>thought it worth relaying given the current topic, my experience may be
>>useful (or not).
>>    
>>
>
>Thanks for taking the time to look over the proposal!  From my point
>of view, this list hardly ever has much discussion on issues that are
>specific to embedded development
>
Embedded is my field, I hardly ever use GDB in any other context.

> (as opposed to more generic concerns,
>like, say, stack unwinding), 
>
 Grrr, don't get me started on stack unwinding on embedded targets at
boot on GDB, I could rave all day about that.

>so I'm encouraged to think that there
>could be a solid base of users whose experience we can build on.
>
>That's quite a setup you've got there.
>  
>
I'm proud of it. :)

>>I have concerns about GDB "Burning" flash directly
>>    
>>
>
>Well, I think you're making assumptions about the implementation that
>aren't implied by the proposal.  As we say:
>
>    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.
>  
>
Yes, I understand.  I did get an impression there was a tendancy to want
to directly (byte at a time) program flash over the Jtag/BDM Interface
(regardless of if its the stub, or GDB directly).  I'm just expressing
that while that obviously might be required for some targets, any design
should not end up making this the only or preferred mechanism, because
of potential speed problems.  I may have overstated the point.

>For the time being, let's assume that detailed knowledge of the device
>can be placed somewhere appropriate, that we can work out ways to use
>efficient transfer methods, and so on.  For example, the details of
>the flash programming algorithm don't need to be in GDB itself: the
>stub could be responsible for the details, and GDB would simply need
>to provide the stub blocks of data in some convenient way.
>
>I guess what we really want to settle at this point is, if we could
>arrange for the commands to Just Work as described, would that
>actually be what you need for your workflow?  Or are there other needs
>that we don't understand yet?
>  
>
I agree that "load" should just "work as described" (regardless of if
its in flash or otherwise).  Which is why I did all of the hook stuff to
give load the necessary extra operations so it could work that way. 

All of the custom "monitor" things (or variations there of) my stub does
could be standard (if obscure) GDB operations, it certainly already has
the ability with the remote protocol to write arbitrary data anywhere
and it could also be told to re-map addresses.  (I'm not suggesting
that's the correct thing to do BTW, but for discussion) If they where,
then for the case I have, the "solution" to debugging from flash is a
wiki entry that shows how to hang a generic flash programming example
together, using the special features in GDB available for it.

On Re-mapping it would be a very useful GDB feature aside from just
flash programming.  I've looked into it before, but couldn't work out a
nice way to do it.  For example, I have an embedded system that when it
runs, uses virtual memory addressing.  But the nature of the Jtag is
that when the target breaks, all addresses are looked up with "real"
addresses.  Which means that address 0x40000 may actually be at 0x100000
and there be a big hole in memory between 0x40000 and 0xFFFFF (due to
the SDRAM bank architecture on that target).  It would be useful if (for
embedded systems) GDB could be taught the targets memory map, so that
when 0x40000 is addressed by GDB, it actually references address
0x100000.  Of course, this feature could then be used to force a load
from one location to another, so that it could be burnt after loading.

Maybe re-mapping could be remote protocol specific, and then the remote
protocol could handle things like address range parameters, remapping
etc, transparent from the upper level GDB operations.  So if you aren't
using the remote protocol, those features aren't available.

This doesn't handle the case of not enough Ram to load and program flash
from in 1 hit of course.

Steven J

Re: GDB support for Flash memory programming

[Nathan J. Williams]

Jim Blandy <jimb@codesourcery.com> writes:

> GDB will have a new write-flash variable. This variable will have
> three possible states:
> 
>     * on
>     * load
>     * off

How about breakpoints? Should using memory breakpoints require full
"on" access? (There are some possible optimizations there; the whole
"step: insert breakpoints, run, remove breakpoints" model is kind of
bad when the breakpoints are being written to flash).

        - Nathan

Re: GDB support for Flash memory programming

[Jim Blandy]

"Nathan J. Williams" <nathanw@wasabisystems.com> writes:
> Jim Blandy <jimb@codesourcery.com> writes:
>
>> GDB will have a new write-flash variable. This variable will have
>> three possible states:
>> 
>>     * on
>>     * load
>>     * off
>
> How about breakpoints? Should using memory breakpoints require full
> "on" access? (There are some possible optimizations there; the whole
> "step: insert breakpoints, run, remove breakpoints" model is kind of
> bad when the breakpoints are being written to flash).

Flash breakpoints are a challenge.  You can use hardware breakpoints,
if available; you can use an MMU and shadow flash pages with RAM
pages, if available; etc.

For the time being, let's assume that GDB will do the best it can with
breakpoints under all settings.  Together with the stub, it has enough
information to do as well as can be done.

Re: GDB support for Flash memory programming

[Russell Shaw]

Jim Blandy wrote:
> 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...

I've done all this stuff for the AVR by adding my own comms handling
and memory-space/type handling code to gdb for communicating with a
specific jtag ice.

IMO, the generic stub thing should only be used for targets that
receive the commands without any intermediate ICE/debugger hardware
(these targets interpret gdb commands with their own software).

IMO, every supported hardware device (jtag debuggers etc) should
have their own directory in gdb. It is much easier to take advantage
of specific debugger features, instead of relying on lowest common
denominator features of the generic gdb stub shim thing. Shims add
unnecessary delay and cludginess because of the extra layer of comms
overhead.

I practically finished my patch a year ago and tested it (it still had
some bugs), but haven't done anything with it since (i'll get back to
it after solving another problem related to gdb).

The code handled all the memory spaces the jtag ice supported, as well
hardware and software breakpoints, and self diagnostics. Code could be
uploaded and downloaded from the jtag ice, new jtag firmware uploaded etc.
It is easy to add your own gdb commands, which only exist when your specific
extension is enabled in gdb.

Re: GDB support for Flash memory programming

[Jim Blandy]

Russell Shaw <rjshaw@netspace.net.au> writes:
> Jim Blandy wrote:
>> 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...
>
> I've done all this stuff for the AVR by adding my own comms handling
> and memory-space/type handling code to gdb for communicating with a
> specific jtag ice.
>
> IMO, the generic stub thing should only be used for targets that
> receive the commands without any intermediate ICE/debugger hardware
> (these targets interpret gdb commands with their own software).
>
> IMO, every supported hardware device (jtag debuggers etc) should
> have their own directory in gdb. It is much easier to take advantage
> of specific debugger features, instead of relying on lowest common
> denominator features of the generic gdb stub shim thing. Shims add
> unnecessary delay and cludginess because of the extra layer of comms
> overhead.

Well, how the solution should be structured in the code is going to be
an interesting point of discussion.  But as I say to Steven, we'd like
to get feedback on the user interface first.  Would the interface as
proposed be useful in the work you're doing now?

Re: GDB support for Flash memory programming

[Russell Shaw]

Jim Blandy wrote:
> Russell Shaw <rjshaw@netspace.net.au> writes:
> 
>>Jim Blandy wrote:
>>
>>>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...
>>
>>I've done all this stuff for the AVR by adding my own comms handling
>>and memory-space/type handling code to gdb for communicating with a
>>specific jtag ice.
>>
>>IMO, the generic stub thing should only be used for targets that
>>receive the commands without any intermediate ICE/debugger hardware
>>(these targets interpret gdb commands with their own software).
>>
>>IMO, every supported hardware device (jtag debuggers etc) should
>>have their own directory in gdb. It is much easier to take advantage
>>of specific debugger features, instead of relying on lowest common
>>denominator features of the generic gdb stub shim thing. Shims add
>>unnecessary delay and cludginess because of the extra layer of comms
>>overhead.
> 
> Well, how the solution should be structured in the code is going to be
> an interesting point of discussion.  But as I say to Steven, we'd like
> to get feedback on the user interface first.  Would the interface as
> proposed be useful in the work you're doing now?

I've been stuck on desktop programming for months, so i haven't done
embedded stuff for ages. Anything that improves the situation for
embedded targets would be good.

A characteristic of micro-controller embedded targets is multiple memory
spaces, such as small ones just for programming device config. fuses etc.
As well as being read/write or read-only, the spaces can vary in width.
Some may be 8-bit, while others are 16-bit or more. Whether this needs
improving, i can't tell until i get into gdb hacking again.

GDB and remote protocols

[Daniel Jacobowitz]

This is a bit tangential to the poll Jim's conducting, so I've changed
the subject.

On Wed, May 24, 2006 at 12:02:46PM +1000, Russell Shaw wrote:
> I've done all this stuff for the AVR by adding my own comms handling
> and memory-space/type handling code to gdb for communicating with a
> specific jtag ice.
> 
> IMO, the generic stub thing should only be used for targets that
> receive the commands without any intermediate ICE/debugger hardware
> (these targets interpret gdb commands with their own software).
> 
> IMO, every supported hardware device (jtag debuggers etc) should
> have their own directory in gdb. It is much easier to take advantage
> of specific debugger features, instead of relying on lowest common
> denominator features of the generic gdb stub shim thing. Shims add
> unnecessary delay and cludginess because of the extra layer of comms
> overhead.

We've talked about this before.  I take the opposite view, and I think
the GDB community has been mostly moving in that direction.  One of my
biggest motivations is that when GDB has extra code to support a
particular ICE, it is extremely unlikely that anyone making changes can
test with that ICE, and the code rots quickly.  Most of the ones we've
got in the source tree right now are in pretty bad shape.

My last six months of GDB work can basically be described by:

  - Make the one remote protocol (remote.c) more powerful, so that it
    is not restricted to lowest common denominator features, e.g.
    support for autodetecting register sets.

  - Make the remote protocol more efficient where the communication
    overhead is a problem.  Large packet size negotiation and quicker
    feature probing are the subject of my current project, qSupported,
    which I hope to have done Real Soon.  Another project I've got
    going would provide the infrastructure for binary memory reads
    from the target (complementing the X packet for writes).

> The code handled all the memory spaces the jtag ice supported, as well
> hardware and software breakpoints, and self diagnostics. Code could be
> uploaded and downloaded from the jtag ice, new jtag firmware uploaded etc.
> It is easy to add your own gdb commands, which only exist when your specific
> extension is enabled in gdb.

This is something we're obviously hearing needs to be supported.  But
there's other ways to do it: for instance, having the stub report its
ICE name, and GDB search a local database for command files associated
with that target name, and do all the commands in a scripting language. 
Wouldn't that be nicer than having to build a custom GDB binary?  But,
of course, it only gets done when someone works on it.

[In theory you could even download commands from the stub; but that
presents some security questions that it might be best to simply
avoid.]

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB and remote protocols

[Russell Shaw]

Daniel Jacobowitz wrote:
> This is a bit tangential to the poll Jim's conducting, so I've changed
> the subject.
> 
> On Wed, May 24, 2006 at 12:02:46PM +1000, Russell Shaw wrote:
> 
>>I've done all this stuff for the AVR by adding my own comms handling
>>and memory-space/type handling code to gdb for communicating with a
>>specific jtag ice.
>>
>>IMO, the generic stub thing should only be used for targets that
>>receive the commands without any intermediate ICE/debugger hardware
>>(these targets interpret gdb commands with their own software).
>>
>>IMO, every supported hardware device (jtag debuggers etc) should
>>have their own directory in gdb. It is much easier to take advantage
>>of specific debugger features, instead of relying on lowest common
>>denominator features of the generic gdb stub shim thing. Shims add
>>unnecessary delay and cludginess because of the extra layer of comms
>>overhead.
> 
> We've talked about this before.  I take the opposite view, and I think
> the GDB community has been mostly moving in that direction.  One of my
> biggest motivations is that when GDB has extra code to support a
> particular ICE, it is extremely unlikely that anyone making changes can
> test with that ICE, and the code rots quickly.  Most of the ones we've
> got in the source tree right now are in pretty bad shape.

I'd just send an email to the tool maintainer to say what has changed in
the gdb interface, and let them adapt it. If there's no maintainer, tough.
If someone needs it, it'll soon get fixed. The same problem exists for shims
if the stub protocol is changed (tho it's less exposed to gdb changes).

I'd think the current non-maintained-ness of the hardware drivers in
gdb is more due to lack of documentation and policy guidelines. I only
found that stuff by accident, even after having searched for it in the
manual (couple of years ago).

Another way is for gdb to have a "dlopen" interface that loads whatever
hardware driver the user selects, so there wouldn't need to be any code
for specific hardware in gdb. An advantage over shims is less comms
overhead and less delays due to system process switches between gdb and
shim.

The other advantage is that there would be no need to change the generic
stub code to add features for hardware debuggers, which would impact 99%
of targets that connect directly to gdb.

> My last six months of GDB work can basically be described by:
> 
>   - Make the one remote protocol (remote.c) more powerful, so that it
>     is not restricted to lowest common denominator features, e.g.
>     support for autodetecting register sets.
> 
>   - Make the remote protocol more efficient where the communication
>     overhead is a problem.  Large packet size negotiation and quicker
>     feature probing are the subject of my current project, qSupported,
>     which I hope to have done Real Soon.  Another project I've got
>     going would provide the infrastructure for binary memory reads
>     from the target (complementing the X packet for writes).
> 
> 
>>The code handled all the memory spaces the jtag ice supported, as well
>>hardware and software breakpoints, and self diagnostics. Code could be
>>uploaded and downloaded from the jtag ice, new jtag firmware uploaded etc.
>>It is easy to add your own gdb commands, which only exist when your specific
>>extension is enabled in gdb.
> 
> 
> This is something we're obviously hearing needs to be supported.  But
> there's other ways to do it: for instance, having the stub report its
> ICE name, and GDB search a local database for command files associated
> with that target name, and do all the commands in a scripting language. 
> Wouldn't that be nicer than having to build a custom GDB binary?  But,
> of course, it only gets done when someone works on it.
> 
> [In theory you could even download commands from the stub; but that
> presents some security questions that it might be best to simply
> avoid.]

The shim approach may be ok, but i thought i should just state some
obvious points.

Re: GDB support for Flash memory programming

[Steven Johnson]

Answering the ideas proposed directly below:

>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.
>  
>
Also, don't forget some flash is NAND, and so is page'd and sequentially
addressed, a growing number of CPU's will boot from these devices.  So
any flash programming solution should also work with NAND. No?

>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.
>  
>
Others have Large amounts of RAM, in comparison to the flash, ie (8MB
Flash, 512MB SDRAM). Id be wary of a lowest common denominator approach
here, for fear of slow speeds on targets that can use RAM to make the
flash programming experience a lot faster.

>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.
>  
>
Yes, but my experience is this is horribly slow,  due to the polling
that has to occur of each byte (or programming word for 16bit and 32bit
wide flashes) as it is programmed.  I think directly programming over
JTAG/BDM should be avoided, unless there is no alternative.  Even on
systems where ram is limited, flash could be programmed in chunks, eg:

(Assume 64K Flash, 2K SRAM, micro controller)

1. Read Flash from target to JTAG Stub. (To preserve un-written areas).
2. Execute flash erase using JTAG.
3. Write 1K of data destined for flash to SRAM.
4. Execute burning stub on target (maybe from other 1K of SRAM) to
program 1K.
5. Repeat to 3, 63 more times, until all memory programmed.

Would be a lot faster than "Write byte to flash over Jtag, poll wait,
repeat".

>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
>  
>
See my other post, with work, it can do this already, although my method
could be made a lot better with help from GDB.

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

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

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

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

>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.
>
>
>  
>
Extending above, i think further options for memory then could be:
4. A Region of memory may be "loaded"
5. A Region must be read after write (maybe with an optional warning on
mismatch). Ie, don't assume just because you wrote "FE" the memory
contains "FE".
6. Im sure there are other settings that could be set for regions of
memory on a target.

And unless otherwise specified GDB can write/read and do anything to any
address.  So the default is fully permisive, as it is now.

I don't think a single global option would suffice, because a target
could easily have multiple flash banks used for different purposes, for
example 1 could contain code, and so you only want to allow "loads" to
it.  but another contains "Parameters", so poking it arbitrarily is what
is wanted, but not loaded.

Steven J

Re: GDB support for Flash memory programming

[Peter Barada]

>>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.
>>  
>>
>Yes, but my experience is this is horribly slow,  due to the polling
>that has to occur of each byte (or programming word for 16bit and 32bit
>wide flashes) as it is programmed.  I think directly programming over
>JTAG/BDM should be avoided, unless there is no alternative.  Even on
>systems where ram is limited, flash could be programmed in chunks, eg:

Another possibility is to have GDB could download/execute a small PIC
function that does the flash programming with its inherent polling
which should speed things up *immensely*.  Also this function can be
tailored to the specifics of the layout (or use global variables for
it). I think the necessary "programming stub" would be small enough to
download, and it would leverage the code that GDB uses to call a
procedure on the target, captures the return, aka:

(gdb) p burn_to_flash(flash_addr, buf_addr, sector_size)

Of course presented to the user to appear as a command as in:

(gdb) burn-flash <src> <sector_size>

where the buf_addr could be on the stack, and capture the result from
the download/call as a command result, that can then generate an error
as in "flash block locked".

This result is extremely extensible to do far more flexible things
that require target manipulation at speeds *far* faster than the
remote protocol can do.

It also allows for manipulating a target that uses a stub that doesn't
even have a JTAG/BDM interface...

-- 
Peter Barada
peter@the-baradas.com

Re: GDB support for Flash memory programming

[Jim Blandy]

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?

Re: GDB support for Flash memory programming

[Steven Johnson]

Jim Blandy wrote:

>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?  
>
Well, its a memory to memory copy, so it will take as long as any memory
to memory copy.  That will depend on the speed of the Flash, Ram and CPU
Bus, and width of each device.  That isn't really a problem, for devices
with enough memory to back up the page "In Ram" the extra time to backup
copy wouldn't be a lot, in comparison to the programming time.  The
issue is systems without enough memory, then you are talking memory read
speeds thought the debug interface.    In Practice, the overhead is
probably like this:

A Spansion S29GL128N NOR with a 128K Page and 8 bit bus (Writing that 1
page):

1. Read 128K (128K Read Cycles over the Jtag Bus)
2. Erase Page (0.5 - 3.5 seconds, excluding time to auto-preprogram all
bits to 0)
3.1 Write Byte (4 write cycles)
3.2 Read Byte for status (If status is OK, continue otherwise repeat),
assume 1 repeat is normal. (will need to wait approx 60us)
3.3 Repeat to 3.1 for the 128K Bytes.

We have 128K Reads + 4*128K Writes + 2*128K Reads, so just in read/write
performance, excluding sector erase time, reading the page increases the
time to program by around 16%.

If you can cache things in the targets memory, then you approach
theoretical maximum flash programming speeds.  Otherwise you are limited
to the speed of the Jtag interface (which aren't known for their speediness)

>  
>
>Does the time required to write a
>sector depend on how much you actually modify from the "erased" state?
>  
>
Yes, especially if you are smart about it (no need to issue program
operations for any byte that is 0xFF, for example).  The programming
time may also vary, in my experience, depending on how many bits you are
knocking from 1 to 0. (as you know, 1 is the erased state and you can
only change 1's to 0's).  The more bits cleared from 1 to 0, the longer
the time to program.

>>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?
>
>  
>
I don't think a single global would cut it for me, others might
disagree, but my targets have different flash used for different
things.  Adding to the mem command would be ideal in my opinion (thanks
for pointing it out BTW, I've not noticed it before). 

It would seem your proposed "on" and "off" options are already handled
by "mem" they would be the "ro" and "rw" attributes.

It looks like the ideal place to add memory "re-mapping" and the flash
attributes.

eg,
realbase=<address> could be used to implement address translation
(Region X thru Y bytes is actually at address <address>, so translate
all accesses to this region)
none                             could be used to specify part of memory
doesn't exist (i.e. no memory there).
loadable                       could be used to specify if a load
operation can write to the region
noload                          cant load into the region
flash="type"                region is a flash memory of "type"

loadable should be different to ro, so a ro,loadable section could be
flash or ram where you can load code into, but you cant write variables
or random memory there.  whereas rw,noload could be ram or flash where
you can change individual bytes, but load will fail if it tries to write
into it.

The flash attribute could then be used to specify a region is flash and
the string in "type" is just that, a string.  The Stub might then have a
way to interrogate (or be told) that a particular region is flash of
"type" it would be up to the stub to define what "type" meant, and that
way, it is being told use algorithm X to program memory in this region.
Algorithm X is stub specific, because it is target specific.

The only part of this the stub would need to know about is the "flash"
part, because all of the other attributes would seem to be able to be
handled at the GDB level.

Just an idea.


Steven J

Re: GDB support for Flash memory programming

[Jim Blandy]

Steven Johnson <sjohnson@sakuraindustries.com> writes:
>>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?  
>>
> Well, its a memory to memory copy, so it will take as long as any memory
> to memory copy.  That will depend on the speed of the Flash, Ram and CPU
> Bus, and width of each device.  That isn't really a problem, for devices
> with enough memory to back up the page "In Ram" the extra time to backup
> copy wouldn't be a lot, in comparison to the programming time.  The
> issue is systems without enough memory, then you are talking memory read
> speeds thought the debug interface.    In Practice, the overhead is
> probably like this:
>
> A Spansion S29GL128N NOR with a 128K Page and 8 bit bus (Writing that 1
> page):
>
> 1. Read 128K (128K Read Cycles over the Jtag Bus)
> 2. Erase Page (0.5 - 3.5 seconds, excluding time to auto-preprogram all
> bits to 0)
> 3.1 Write Byte (4 write cycles)
> 3.2 Read Byte for status (If status is OK, continue otherwise repeat),
> assume 1 repeat is normal. (will need to wait approx 60us)
> 3.3 Repeat to 3.1 for the 128K Bytes.
>
> We have 128K Reads + 4*128K Writes + 2*128K Reads, so just in read/write
> performance, excluding sector erase time, reading the page increases the
> time to program by around 16%.

All right.  So, to figure the worst-case cost of that requirement,
we're looking at programming a single byte in a sector which is
otherwise full of non-0xFF data, over a JTAG interface.  We're
comparing these two operations:

- read (almost) the sector over the JTAG interface, erase the sector,
  and then write it all back

versus:

- erase the sector, and then write one byte.

The erasure time is needed no matter what we do; that doesn't count.

On the board I happen to have handy, it takes 26 seconds to write a
full 128k flash sector over the JTAG interface.  Unless this is
extremely slow compared to what's typical out there, I'd tend to agree
that preserving unloaded sector contents is important to leave
optional, or not require at all.  I wouldn't mind waiting a handful of
seconds, but even ten would be too long.

Re: GDB support for Flash memory programming

[Steven Johnson]

Jim Blandy wrote:

>
>On the board I happen to have handy, it takes 26 seconds to write a
>full 128k flash sector over the JTAG interface.  Unless this is
>extremely slow compared to what's typical out there, I'd tend to agree
>that preserving unloaded sector contents is important to leave
>optional, or not require at all.  I wouldn't mind waiting a handful of
>seconds, but even ten would be too long.
>  
>
Yes, also, you don't want (or need) to do it if the whole sector is
going to be programmed.  Maybe another memory attribute would be
"Preserve unaltered contents of flash on reprogram"

To put it in perspective (I don't know what type of flash you have, if
you give me a part number, I'd be interested to do this analysis on your
part),

Using an accelerated buffer programming algorithm for the Spansion S29GL
family of flash the following is the theoretical typical case sector
programming time:

Typical time to program 32 bytes = 240us
Therefore 128K Bytes / 32 * 240us = 983ms total typical sector
programming time

It might be an unfair comparison, so using the traditional "Byte at a
time" algorithm for the same family, we get:

Typical time to program 1 byte = 60us
Therefore 128K Bytes * 60us = 7.8 seconds total typical sector
programming time

Both of which are significantly under your JTag Speeds to do the same
operation.

However that said, your Jtag speeds are very respectable, I've seen lots
worse, 10-20 (or more) times slower programming of flash over Jtag.

Steven J

Re: GDB support for Flash memory programming

[Mark Kettenis]

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

Re: GDB support for Flash memory programming

[Jim Blandy]

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.