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

[Marko Mlinar <markom@opencores.org>]

> 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.
Yes these are almost mandatory features for appliacations under OS.
All debugers I've used or heard about them, have specific features ;)

> 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.
BTW: how fast does or1ksim run on your computer?
Do you think we should spend more time making it faster?

> > 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.
at least some things are simple ;)

> 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.
I know. Do you think we should migrate to gdb protocol instead of current 
JTAG. In both cases we would need JTAG server, which is connected to the 
board.

> > 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.
I see.

Great work!

Marko


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