converted to 1.6 markup
|No differences found!|
Current versions of GDB do not support programming flash memory, but patches have been posted to implement this. As of this writing, the latest versions are in the gdb-patches list archives for 2006-08-16. They only implement support for "load" to remote targets using flash memory; here are some related features which have been discussed, but not yet implemented.
- "set write-flash [on|off|load]"
- The current flash support allows flash writes from "load", but prohibits flash writes from any other context. For instance, you can't write "set var i = 1" if "i" is an initialized variable stored in flash memory. This is an unwise operation to perform by default:
- It can be very slow, because it might require erasing and rewriting an entire flash sector, which could be 128K or 256K.
- The limited nature of flash write cycles means some care is in order to prevent bugs from damaging hardware. For instance, GDB should never accidentally insert a software breakpoint in flash memory. Most flash-capable systems have some available hardware breakpoints which should be used instead.
- But sometimes the user may want to override this.
- Some smarts may be in order to allow multiple sets to a single flash sector; at this point it gets quite complicated.
- The implementation of this variable will require separating out the flash support from target_write_memory_blocks, and probably calling it from memory_xfer_partial. Doing a whole erase/rewrite cycle at this level may be immensely slow.
- Manual flash erase. Perhaps there should be a command "flash erase ADDRESS LENGTH".
- The current implementation of "load" does not attempt to preserve the contents of flash sectors which are partially written.
- For example, if a loaded program is 0x100 bytes and each flash sector is 0x2000 bytes, the load command will erase 0x2000 bytes and only write 0x100. The remaining contents will be lost. Normally this is fine; the prior contents will have been another version of the program which wasn't exactly the same size. However, in special circumstances, users may want to preserve everything not explicitly overwritten. So maybe we need another "set" variable for this.
- The current flash code hard-codes a long timeout, because a single packet can take a long time (programming flash can be much slower than writing to RAM).
- Maybe the protocol should include some form of progress notification or maybe the longer timeout should be configurable. Or maybe it's fine the way it is.
- The mostly obsolete data cache layer in GDB (dcache.c) will not interact well with flash memory.
- The whole dcache code could use an update. Regions should probably be marked "cacheable" or "volatile" rather than "cached" or "uncached", going back to a global knob to enable the cache. Then flash, rom, and even ram regions from the target memory maps can be marked as cacheable - the documentation might need to be clarified to not mention i/o regions as RAM. We might even want to cache ROM/flash across execution. The target can reprogram its own flash, but this is rare, and hurting debug performance to accomodate that possibility is unfortunate.