From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28711 invoked by alias); 25 May 2006 02:35:36 -0000 Received: (qmail 22839 invoked by uid 22791); 25 May 2006 02:33:40 -0000 X-Spam-Check-By: sourceware.org Received: from whirlwind.netspace.net.au (HELO mail.netspace.net.au) (203.10.110.76) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 25 May 2006 02:33:38 +0000 Received: from [192.168.0.10] (220-253-109-214.VIC.netspace.net.au [220.253.109.214]) by mail.netspace.net.au (Postfix) with ESMTP id B061BDA09E for ; Thu, 25 May 2006 12:33:33 +1000 (EST) Message-ID: <4475177D.4040603@netspace.net.au> Date: Thu, 25 May 2006 03:05:00 -0000 From: Russell Shaw User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060205 Debian/1.7.12-1.1 MIME-Version: 1.0 Cc: gdb@sourceware.org Subject: Re: GDB support for Flash memory programming References: <4473BEC6.7050308@netspace.net.au> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed 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/msg00363.txt.bz2 Jim Blandy wrote: > Russell Shaw writes: > >>Jim Blandy wrote: >> >>>One of the problems GDB has in the embedded development world is its >>>lack of support for loading programs into flash memory. After some >>>conversation amongst ourselves to weed out patently stupid stuff (none >>>of the text below is mine... hey), we at CodeSourcery put together the >>>following proposal for general comments and criticism. We'd like to >>>reach consensus on what the user interface should be >>>before we worry about implementation details --- possible remote >>>protocol changes, and so on --- so let's leave those topics aside for >>>the time being. >>>What do folks think? >>>--- >>>Background >>>Flash memory is a popular form of non-volatile memory... >> >>I've done all this stuff for the AVR by adding my own comms handling >>and memory-space/type handling code to gdb for communicating with a >>specific jtag ice. >> >>IMO, the generic stub thing should only be used for targets that >>receive the commands without any intermediate ICE/debugger hardware >>(these targets interpret gdb commands with their own software). >> >>IMO, every supported hardware device (jtag debuggers etc) should >>have their own directory in gdb. It is much easier to take advantage >>of specific debugger features, instead of relying on lowest common >>denominator features of the generic gdb stub shim thing. Shims add >>unnecessary delay and cludginess because of the extra layer of comms >>overhead. > > Well, how the solution should be structured in the code is going to be > an interesting point of discussion. But as I say to Steven, we'd like > to get feedback on the user interface first. Would the interface as > proposed be useful in the work you're doing now? I've been stuck on desktop programming for months, so i haven't done embedded stuff for ages. Anything that improves the situation for embedded targets would be good. A characteristic of micro-controller embedded targets is multiple memory spaces, such as small ones just for programming device config. fuses etc. As well as being read/write or read-only, the spaces can vary in width. Some may be 8-bit, while others are 16-bit or more. Whether this needs improving, i can't tell until i get into gdb hacking again.