From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19171 invoked by alias); 24 May 2006 21:11:17 -0000 Received: (qmail 19150 invoked by uid 22791); 24 May 2006 21:11:14 -0000 X-Spam-Check-By: sourceware.org Received: from intranet.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.6) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 24 May 2006 21:10:41 +0000 Received: (qmail 358 invoked from network); 24 May 2006 21:10:39 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 24 May 2006 21:10:39 -0000 To: Steven Johnson Cc: gdb@sourceware.org Subject: Re: GDB support for Flash memory programming References: <4473B2D2.9000104@sakuraindustries.com> From: Jim Blandy Date: Wed, 24 May 2006 22:07:00 -0000 In-Reply-To: <4473B2D2.9000104@sakuraindustries.com> (Steven Johnson's message of "Wed, 24 May 2006 12:11:46 +1100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00354.txt.bz2 Steven Johnson 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?