gdb port to or1k

gdb port to or1k

[Marko Mlinar]

Hi!

I am Marko Mlinar, member of OpenCores group.
OpenCores is very serious open HW developement group,
which is growing rapidly. More info can be obtained
at www.opencores.org

or1k is 32bit extendable processor architecture, and has many
new features, including better (more general) HW (conditional)
breapoints, watchpoints, catchpoint and pretty general HW trace.
or1k is published under GNU LGPL public license.
Detailed architecture description is available on opencores CVS.

GCC, BFD, disasembler and some other tools has already been ported.
We plan to port gdb to our processor OpenRisc 1000 architecture.

Our first plan is to prepare remote debugger using JTAG via parallel
port. First question - does anybody know if /dev/lp0 or such are
compatibile across platforms (including IOCTL function read_status
0x060b, I think).
or1k TAP (Test Access Port) document is still in preparation, but is
fully compatible with JTAG.

This project will probably extend to Linux native debugger and
also or1k gdb target port(?). We also have simulator, but it is
currently not compatible with gdb.

I am new to gdb community, so I would appreciate any kind of help,
especially coders ;)

We will try to follow your guidelines and to make this cooperation
fruitful for both communities.

Best regards,
    Marko

Re: gdb port to or1k

[J.T. Conklin]

>>>>> "Marko" == Marko Mlinar <Marko.Mlinar@campus.fri.uni-lj.si> writes:
Marko> Our first plan is to prepare remote debugger using JTAG via
Marko> parallel port. First question - does anybody know if /dev/lp0
Marko> or such are compatibile across platforms (including IOCTL
Marko> function read_status 0x060b, I think).

No.  

Many host systems that GDB supports don't even have parallel ports.
Those that do don't suport the same set of capabilites (other than
open/close and write, those are pretty standard :-).

Marko> I am new to gdb community, so I would appreciate any kind of
Marko> help, especially coders ;)

I don't have enough bandwidth free to directly contribute, but I'll be
available to advise when the time comes.  I suspect that many of the GDB
hackers are in the same boat, but I'll let them speak for themselves.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: gdb port to or1k

[Marko Mlinar]

> Many host systems that GDB supports don't even have parallel ports.
> Those that do don't suport the same set of capabilites (other than
> open/close and write, those are pretty standard :-).
We are only interested to add debugging support for host that
will be really used e.g. we don't have any interest at all to use arm host.
So we can assume, host should be able to print and thus have printer port.
Do you perhaps know if this will work for SUN? And HP machines?
Is there any way to easily configure this, if platforms use different IOCTL
numbers? (not to include #ifdefs)
And on the other hand we don't wan't to use special driver for every
platform...
Well, in any case we can write centronics parallel port "compatible" drivers
for those hosts we want to have supported.

> I don't have enough bandwidth free to directly contribute, but I'll be
> available to advise when the time comes.  I suspect that many of the GDB
> hackers are in the same boat, but I'll let them speak for themselves.
Thanks.

Marko

Re: gdb port to or1k

[Andrew Cagney]

Marko Mlinar wrote:
> 
> > Many host systems that GDB supports don't even have parallel ports.
> > Those that do don't suport the same set of capabilites (other than
> > open/close and write, those are pretty standard :-).

> We are only interested to add debugging support for host that
> will be really used e.g. we don't have any interest at all to use arm host.
> So we can assume, host should be able to print and thus have printer port.
> Do you perhaps know if this will work for SUN? And HP machines?
> Is there any way to easily configure this, if platforms use different IOCTL
> numbers? (not to include #ifdefs)
> And on the other hand we don't wan't to use special driver for every
> platform...
> Well, in any case we can write centronics parallel port "compatible" drivers
> for those hosts we want to have supported.

Provided your target is implemented correctly it will just build and
work from any host.  There is also gdb/ser-unix.c which addresses many
of the portability issues (provided it is talking to something that
looks like a serial device).

One thing, people have found that trying to bash bits through lpt can be
really slow.  There is an open source project that included a (linux)
device driver to do that bit banging (I've lost the url? :-( ).

The GDB home page also lists several open source remote servers that you
might be interested in.

	Andrew

Re: gdb port to or1k

[Marko Mlinar]

> Provided your target is implemented correctly it will just build and
> work from any host.  There is also gdb/ser-unix.c which addresses many
> of the portability issues (provided it is talking to something that
> looks like a serial device).
Huh, do you know where can I get infos neeed for various platforms and
test them? What is the practice for this in GNU?

> One thing, people have found that trying to bash bits through lpt can be
> really slow.  There is an open source project that included a (linux)
> device driver to do that bit banging (I've lost the url? :-( ).
I've seen JTAG driver or BDM driver.
I am aware that JTAG driver is very slow.
We are hoping we can get troughput of 75kB/sec (with some extra logic),
and 15kB/sec without any logic.
Do you think that is enough?

> The GDB home page also lists several open source remote servers that you
> might be interested in.

thanks,
    Marko

Re: gdb port to or1k

[Andrew Cagney]

Marko Mlinar wrote:
> 
> > Provided your target is implemented correctly it will just build and
> > work from any host.  There is also gdb/ser-unix.c which addresses many
> > of the portability issues (provided it is talking to something that
> > looks like a serial device).
> Huh, do you know where can I get infos neeed for various platforms and
> test them? What is the practice for this in GNU?

Sorry, you've lost me here.

> > One thing, people have found that trying to bash bits through lpt can be
> > really slow.  There is an open source project that included a (linux)
> > device driver to do that bit banging (I've lost the url? :-( ).
> I've seen JTAG driver or BDM driver.
> I am aware that JTAG driver is very slow.
> We are hoping we can get troughput of 75kB/sec (with some extra logic),
> and 15kB/sec without any logic.
> Do you think that is enough?

Given I've never used jtag via a parallel port I'm not the one to ask
:-)  Hopefully others will be able to answer.

	Andrew

Re: gdb port to or1k

[J.T. Conklin]

>>>>> "Marko" == Marko Mlinar <Marko.Mlinar@campus.fri.uni-lj.si> writes:
Marko> I've seen JTAG driver or BDM driver.  I am aware that JTAG
Marko> driver is very slow.  We are hoping we can get troughput of
Marko> 75kB/sec (with some extra logic), and 15kB/sec without any
Marko> logic.  Do you think that is enough?

I have found that latency tends to matter a great deal more in a
typical debugging session than bandwidth.  

For example, think of stepping a single line of code.  The debugger
determines the the range of code represented by the line, and then
issues a step instruction command.  Then it waits until the target
responds with a exception or trap.  The debugger then must fetch the
the program counter to determine whether the step has taken the PC
out of range.  If not it repeats the processes.

As you can see, the commands and responses themselves aren't too long.
But if there is significiant communications overhead, it adds up fast.
And that is all with relatively high level commands like "step insn".
If instead you must fetch the processor control word, or in a trace
mode bit, and the store it; or if you fetch the word at the memory
location after the PC and then store a trap/breakpoint instruction;
it gets that much worse.

Even with GDB's remote protocol which had relatively high level commands, 
I recently added a command for "step over range" which would single step
until the PC goes outside the address range specified in the command.  I
did this just to improve the interactive performance of GDB.

Where bandwith matters, is bulk transfers.  This usually occurs when
fetching or storing the whole register set, and when downloading code.

I don't know enough about your interface and processor whether you
will be able to fetch and store single registers, or whether you'll
have to do the whole set.  In most cases, GDB only needs the PC and
stack and frame pointers, after a trap to determine "where it is".
It's user commands after that which may require more of the registers
to be fetched.  

But even if the whole set has to be fetched or stored, at 75kB/s, a
~512B (32 64-bit int regs, 32 64-bit fp regs, plus a handful of config
regs) should be acceptable assuming low communcation overhead.  But at
15kB/s, communication overhead will have to be low, since we're already
at 1/3 the 0.1 second threshold for interactive response.

With a JTAG like interface, I suspect you will want the ability to
download code.  At 75kB/s, you can download a decent size application
in a minute.  But for very large applications, I'd probably use the
interface to download a secondary boot program that would load the
"real" program over a faster medium (ethernet?)

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: gdb port to or1k

[J.T. Conklin]

>>>>> "Marko" == Marko Mlinar <Marko.Mlinar@campus.fri.uni-lj.si> writes:
>> Many host systems that GDB supports don't even have parallel ports.
>> Those that do don't suport the same set of capabilites (other than
>> open/close and write, those are pretty standard :-).

Marko> We are only interested to add debugging support for host that
Marko> will be really used e.g. we don't have any interest at all to
Marko> use arm host.  So we can assume, host should be able to print
Marko> and thus have printer port.

Please note that it is a GDB goal (or at least one of my my goals as 
a GDB hacker) that features be available on as many host machines as
possible.  While there have been back ends which have been integrated
into GDB that need a special vendor-supplied DLL which ties it to a 
single host platform (ie. windows), I'd rather avoid this if at all
possible.

If I understand your intentions, you intend to use a bi-directional
parallel port to bit-bang a JTAG like interface.  This limits the
feature to machines with bi-directional parallel hardware running
OS's that allow user-level programs access to the individual lines.
I think this is OK.

Marko> Do you perhaps know if this will work for SUN? And HP machines?
Marko> Is there any way to easily configure this, if platforms use
Marko> different IOCTL numbers? (not to include #ifdefs)

I believe that Andrew Cagney mentioned the ser-* abstraction GBD uses
for serial ports.  It may be necessary to do something equivalent for
parallel ports.

Since the ioctl's used by serial tty's is much more standardized on
UNIX and UNIX-like systems (e.g. sgtty, termio or termios), support
for all is located in one source file ser-unix.c.  For parallel, we
might need par-hp.c, par-sun.c, etc.  It won't be a requirement for
you to supply implementations for all platforms, just that the scheme
be extensible and not preclude other people adding support for their
platforms.

Marko> And on the other hand we don't wan't to use special driver for
Marko> every platform...

I don't think this is as bad as you think.  If you make the split
correctly, the bulk will be host independent.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: gdb port to or1k

[Damjan Lampret]

----- Original Message -----
From: "J.T. Conklin" <jtc@redback.com>

> Please note that it is a GDB goal (or at least one of my my goals as
> a GDB hacker) that features be available on as many host machines as
> possible.  While there have been back ends which have been integrated
> into GDB that need a special vendor-supplied DLL which ties it to a
> single host platform (ie. windows), I'd rather avoid this if at all
> possible.
>
> If I understand your intentions, you intend to use a bi-directional
> parallel port to bit-bang a JTAG like interface.  This limits the
> feature to machines with bi-directional parallel hardware running
> OS's that allow user-level programs access to the individual lines.
> I think this is OK.
>

In fact this is our goal as well. We'd like to be able to use any platform
in order to debug our target (Linux, Solaris, Windows etc).

So we don't want to have a low level driver for a parallel port that would
work just on Linux/i386. At the moment we are investigating compatibility
between parallel ports on different platforms and it seems that basic
centronics (8 out + 5 in) is supported by majority of them. We could
certainly use help from GDB community to help us test different parallel
port implementations and access to them under different operating systems
(Marko and me only have access to i386 HW running Linux or Windows and to
Sun Blade 100 running Solaris 8).

I think it would be great to have a "standard" parallel port interface for
all targets that use JTAG/BDM or something similar. As you probably know a
lot of microcontrollers lately use some kind of serial debug protocol and
having a common infrastructure in GDB to support all of them through a much
faster parallel port would be great (something faster than a serial port on
a host).

regards,
Damjan

Re: gdb port to or1k

[Andrew Cagney]

"J.T. Conklin" wrote:

> Marko> Do you perhaps know if this will work for SUN? And HP machines?
> Marko> Is there any way to easily configure this, if platforms use
> Marko> different IOCTL numbers? (not to include #ifdefs)
> 
> I believe that Andrew Cagney mentioned the ser-* abstraction GBD uses
> for serial ports.  It may be necessary to do something equivalent for
> parallel ports.

Just FYI, ser-* has both an event-based and a polling based
implementation.  par-* would need to be similar.

	Andrew

Re: gdb port to or1k

[Marko Mlinar]

> I believe that Andrew Cagney mentioned the ser-* abstraction GBD uses
> for serial ports.  It may be necessary to do something equivalent for
> parallel ports.
We would really appreciate that. And, like Damjan said -- parallel ports
are becomming more and more used.

> Since the ioctl's used by serial tty's is much more standardized on
> UNIX and UNIX-like systems (e.g. sgtty, termio or termios), support
> for all is located in one source file ser-unix.c.  For parallel, we
> might need par-hp.c, par-sun.c, etc.  It won't be a requirement for
> you to supply implementations for all platforms, just that the scheme
> be extensible and not preclude other people adding support for their
> platforms.
Our interface is designed in a way, that it needs 8 outputs and 3 inputs.
This can be accomplished by centronics (oldest parallel port mode) and
is fully supported by IOCTLs (LP driver).
But, this kind of interface would be pretty slow. It would be much better
if we use INP and OUTP, where port addresses and interface is same
for all parallel ports. It would be nice if this faster option would be
available
for at least most popular hosts (Linux, win, sun).
Looking it long term for GDB - parallel port can be much faster (especially
bidirectional - EPP or ECP) than serial ports or ethernet, so many vendors
may choose it as a base for their remote protocol.

Marko