From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12236 invoked by alias); 18 Jul 2008 01:55:48 -0000 Received: (qmail 12086 invoked by uid 22791); 18 Jul 2008 01:55:46 -0000 X-Spam-Check-By: sourceware.org Received: from nskntmtas03p.mx.bigpond.com (HELO nskntmtas03p.mx.bigpond.com) (61.9.168.143) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 18 Jul 2008 01:55:27 +0000 Received: from nskntotgx02p.mx.bigpond.com ([58.172.128.171]) by nskntmtas03p.mx.bigpond.com with ESMTP id <20080718015524.MYQN17781.nskntmtas03p.mx.bigpond.com@nskntotgx02p.mx.bigpond.com>; Fri, 18 Jul 2008 01:55:24 +0000 Received: from kiwi.contemporary.net.au ([58.172.128.171]) by nskntotgx02p.mx.bigpond.com with ESMTP id <20080718015524.CCRV15862.nskntotgx02p.mx.bigpond.com@kiwi.contemporary.net.au>; Fri, 18 Jul 2008 01:55:24 +0000 Received: from [172.16.100.186] (kaka.contemporary.net.au [172.16.100.186]) by kiwi.contemporary.net.au (8.14.2/8.14.2) with ESMTP id m6I1tKrZ012313; Fri, 18 Jul 2008 11:55:21 +1000 Message-ID: <487FF808.5010505@contemporary.net.au> Date: Fri, 18 Jul 2008 01:55:00 -0000 From: Chris Johns User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: "Edward L. Hepler" CC: Bart Veer , gdb@sourceware.org Subject: Re: proposed extension for jtag debugging References: <20080717215720.GA1061@caradoc.them.org> <487FD725.1040002@contemporary.net.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Status: Clean X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150201.487FF80C.00FA,ss=1,fgs=0 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-07/txt/msg00200.txt.bz2 Edward L. Hepler wrote: > > I'd very much like to hear about this as it sounds similar to what I > have done. I added a target to the "mips" code to directly control > a JTAG cable connected to a PC parallel port. It did not use > gdbserver. As an aside, I also use GDB to control a "C" based > emulator and a VHDL based simulator. > > Since then, I have been looking into using gdbserver so I won't have > to apply patches to GDB... I'm also hoping that since gdbserver is > a separate process, some of the control issues that arise when trying > to control a separate VHDL simulator may be more easy handled... > The move to the remote protocol and a gdbserver has all been positive and worth the effort. For us the key feature added to gdb that enabled a smooth transition has been the ability to define registers overs the remote protocol. As new processors are added we can add support without the need to rebuild gdb. Our gdbserver code is in CVS in a directory m68k/gdbserver. The project link was posted earlier but here it is again: http://bdm.sourceforge.net/ The gdbserver code was taken from a recent gdb and has a number of changes to suite an embedded target rather than a host OS like Linux. They are: 1. Builds for Unix and Windows (MinGW). 2. Supports the GDB remote pipe mode. 3. Ability to control the XML register definition based on the detected processor. 4. Register cache changes to support hardware mapped register. The register cache only updated the hardware when a go, step etc was issues and this causes problems when initialising hardware. The cache has been extended to allow a back end to define which registers need to be passed directly to hardware. I am sure there are other things I have forgotten. I plan to get paper work in place and to send patches but time has been limited. Regards Chris