From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14771 invoked by alias); 25 May 2006 01:11:09 -0000 Received: (qmail 14752 invoked from network); 25 May 2006 01:11:02 -0000 Received: from unknown (202.80.33.51) by sourceware.org with QMTP; 25 May 2006 01:11:02 -0000 Received: (qmail 4354 invoked from network); 25 May 2006 01:11:00 -0000 X-Anti-Virus: Message scanned for viruses by TVL Received: from dsl2-modem31.tvl.vu (HELO [192.168.2.14]) ([202.80.43.31]) (envelope-sender ) by mail.vanuatu.com.vu (qmail-ldap-1.03) with SMTP for ; 25 May 2006 01:11:00 -0000 Message-ID: <44750421.3000003@sakuraindustries.com> Date: Thu, 25 May 2006 02:35:00 -0000 From: Steven Johnson User-Agent: Mozilla Thunderbird 1.0.6-7.2.20060mdk (X11/20050322) MIME-Version: 1.0 To: Jim Blandy CC: gdb@sourceware.org Subject: Re: GDB support for Flash memory programming References: <4473B2D2.9000104@sakuraindustries.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00361.txt.bz2 Jim Blandy wrote: >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 > 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