RE: [openrisc] Patch: Reduced gdb<->target communication

["Scott Furman" <sfurman@rosum.com>]

> -----Original Message-----
> From: owner-openrisc@opencores.org
[mailto:owner-openrisc@opencores.org]
> On Behalf Of Marko Mlinar
> Sent: Monday, April 07, 2003 10:24 PM
> To: openrisc@opencores.org
> Subject: Re: [openrisc] Patch: Reduced gdb<->target communication
> 
> On Tuesday 08 April 2003 04:29, Scott Furman wrote:
> > I use the or32 version of gdb both with JTAG targets and serial
targets
> > (the latter target uses the GDB serial stubs support in eCos).  In
the
> > serial case, the debugger can be rather sluggish, especially when
> > generating backtraces, due to the large amount of serial traffic
> > generated.  The attached patch cures two shortcomings with the
current
> > code:
> How is it working with serial port otherwise. As far as I understood
from
> gdb'ers experiences serial target is too slow and somehow unusable.

I can only speak for my experience with eCos, since I have not used gdb
serial targets for any other or32-based OS.  It does seem to work OK -
that is, gdb seems to be no more or less buggy than the JTAG target.
With eCos stubs, the serial target has the advantage over the JTAG
target that it is thread-aware, so it is possible to list all eCos
threads in the debugger, put in thread-local breakpoints, etc.

Under simulation w/ or1ksim, the serial target is extremely slow, partly
since stub code must run on the simulator for every serial message
exchange and partly because the effective baud rate of the simulated
UART is quite low.  I can combat this slowness by setting a very high
baud rate on the simulated UART.  For example, I set the divisor to run
the UART at 921 kb/s which is too high a baud rate to run on the real HW
but makes it a little less sluggish when simulated.

> Do you download the code through serial port also?

Yes, I can download code via gdb's 'load' command using a serial port
target.  This requires that the gdb stubs be resident in the target
system.  This can be trivially done by enabling the "include GDB stubs"
option in the eCos-based Redboot firmware monitor.

The gdb serial protocol is very inefficient, though, since it is not a
binary protocol, i.e. it is designed to be human-readable.  This results
in a download transfer rate of only a few KB/s when simulating the
target.

> Do you have two separate cables connected to the board?

Yes, one cable is used for the console.  The other is dedicated to the
debugger.  It is, however, *possible* to use just a single cable when
using eCos stubs, since there is support in the gdb serial protocol for
multiplexing console output with debugger-related traffic.

-Scott



--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml