This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GDB support for Flash memory programming


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]