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


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






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