Re: GDB support for Flash memory programming

[Jim Blandy <jimb@codesourcery.com>]

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?