Re: GDB support for Flash memory programming

[Steven Johnson <sjohnson at sakuraindustries dot com>]

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