BDM/OCD with Macraigor Raven on MPC8xx from x86

BDM/OCD with Macraigor Raven on MPC8xx from x86

[Graham Stoney]

I'm wondering if anyone has had any success using gdb from an Linux x86
machine to debug an MPC8xx target via BDM using a Macraigor Raven OCDemon?

I've looked in the mailing list archives, and only found mention of using a
Windoze host with a Wiggler. I'm not keen on switching to Windoze, and would
like to take advantage of the Raven's extra speed if possible. Any pointers
greatly appreciated!

Thanks,
Graham
From sbjohnson@ozemail.com.au Sun Dec 05 22:11:00 1999
From: Steven Johnson <sbjohnson@ozemail.com.au>
To: Graham Stoney <greyham@research.canon.com.au>
Cc: gdb@sourceware.cygnus.com
Subject: Re: BDM/OCD with Macraigor Raven on MPC8xx from x86
Date: Sun, 05 Dec 1999 22:11:00 -0000
Message-id: <384B53DD.B65146C7@ozemail.com.au>
References: <19991206012315.93469F4E0@elph.research.canon.com.au>
X-SW-Source: 1999-q4/msg00448.html
Content-length: 668

Graham Stoney wrote:
> 
> I'm wondering if anyone has had any success using gdb from an Linux x86
> machine to debug an MPC8xx target via BDM using a Macraigor Raven OCDemon?
> 

Can not be done.

Macraigor will not release the specification to enable GDB to interface
directly to their OCD Debuggers. The only support is through the
Macraigor supplied DLL, and that only runs under windows. If you can get
the specs for their devices then you can always write the interface from
linux :).

Im building my own interface, specifically for Linux/GDB because of
this. When it's available i'll post to the list.

Regards,
Steven Johnson
Managing Director
Neurizon Pty Ltd
From qqi@world.std.com Sun Dec 05 22:27:00 1999
From: Quality Quorum <qqi@world.std.com>
To: Steven Johnson <sbjohnson@ozemail.com.au>
Cc: Graham Stoney <greyham@research.canon.com.au>, gdb@sourceware.cygnus.com
Subject: Re: BDM/OCD with Macraigor Raven on MPC8xx from x86
Date: Sun, 05 Dec 1999 22:27:00 -0000
Message-id: <Pine.SGI.3.95.991206012115.6759A-100000@world.std.com>
References: <384B53DD.B65146C7@ozemail.com.au>
X-SW-Source: 1999-q4/msg00449.html
Content-length: 1133

On Mon, 6 Dec 1999, Steven Johnson wrote:

> Graham Stoney wrote:
> > 
> > I'm wondering if anyone has had any success using gdb from an Linux x86
> > machine to debug an MPC8xx target via BDM using a Macraigor Raven OCDemon?
> > 
> 
> Can not be done.
> 
> Macraigor will not release the specification to enable GDB to interface
> directly to their OCD Debuggers. The only support is through the
> Macraigor supplied DLL, and that only runs under windows. If you can get
> the specs for their devices then you can always write the interface from
> linux :).

I am building something  (I call it labslave) like gdbserver, only for
embedded environment. So, one can run this labslave on NT talking to
Macraigor DLL one side, while communicating with remote GDB over standard 
remote protocol on anther side.. Current version is 0.1 and the only
target supported is 'remote' (and I am looking for pre-beta testers).


> 
> Im building my own interface, specifically for Linux/GDB because of
> this. When it's available i'll post to the list.
> 
> Regards,
> Steven Johnson
> Managing Director
> Neurizon Pty Ltd
> 

Thanks,

Aleksey

Re: BDM/OCD with Macraigor Raven on MPC8xx from x86

[Brendan Simon]

Graham Stoney wrote:

> I'm wondering if anyone has had any success using gdb from an Linux x86
> machine to debug an MPC8xx target via BDM using a Macraigor Raven OCDemon?
>
> I've looked in the mailing list archives, and only found mention of using a
> Windoze host with a Wiggler. I'm not keen on switching to Windoze, and would
> like to take advantage of the Raven's extra speed if possible. Any pointers
> greatly appreciated!

There are no known PowerPC BDM drivers for Linux.

Re: BDM/OCD with Macraigor Raven on MPC8xx from x86

[Gunter Magin]

> Graham Stoney wrote:
> 
> > I'm wondering if anyone has had any success using gdb from an Linux x86
> > machine to debug an MPC8xx target via BDM using a Macraigor Raven OCDemon?
> >
> > I've looked in the mailing list archives, and only found mention of using a
> > Windoze host with a Wiggler. I'm not keen on switching to Windoze, and would
> > like to take advantage of the Raven's extra speed if possible. Any pointers
> > greatly appreciated!
> 
> There are no known PowerPC BDM drivers for Linux.

Right.

Furthermore, if there is no publicly available HW spec of the Macraigor
Raven, there will be no Linux device driver, unless Macraigor itself starts
to support it, or some curious soul reverse engineers this piece of HW.

Please note the recent move of some major graphic card manufacturers
towards unveiling their top secret programming information without NDA, and 
their cooperation with the XFree maintainers, so high quality open source 
device drivers will become available. 

gm
-- 
Gunter Magin                                        magin[AT]skil.camelot.de
From jtc@redback.com Tue Dec 14 11:46:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Quality Quorum <qqi@world.std.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: remote nits
Date: Tue, 14 Dec 1999 11:46:00 -0000
Message-id: <5mr9gpb91r.fsf@jtc.redbacknetworks.com>
References: <Pine.SGI.3.95.991213162826.15572A-100000@world.std.com>
X-SW-Source: 1999-q4/msg00506.html
Content-length: 2074

>>>>> "Quality" == Quality Quorum <qqi@world.std.com> writes:
Quality> 1. I was mistaken there are 4 ways to represent thread:
Quality>    16-bit integer is used by 'qC' and 8-bit integer is used
Quality>    by 'TXX'.
Quality>
Quality> 2. Yes, there are at least 5 ways to solve this problem
Quality>    (invent something new or use one of 4 exiting ones). The
Quality>    question was which one is more appropriate ?

Perhaps the best thing to do is to deprecate the entire set of thread
commands and replace them with a consistantly designed and rigorously
specified set.  I believe that Michael Snyder expressed some interest
in doing some of this (in the context of thread list queries) in the
past.

Quality> I would go with following set of rules: (1)thread id is an
Quality> unsigned 64-bit integer represented on the wire in %x format
Quality> (leading zeros are omitted) in all transactions except 'qP',
Quality> 'qQ', 'qL' and 'qM' which use %08x representation;

Wouldn't that be %016x?

Quality> (2)requests 'Hc-xxxxxx' and 'Hg-xxxxx' should be interpreted
Quality> as 'all threads' regardless of the length and the pattern of
Quality> 'xxxxxx',

The notion of all-threads leads me to belive that perhaps we need some
way to specify both a context and a context id, even if GDB can't take
advantage of this at this time.  For example, possible contexts could
be 'system', 'process', or 'thread'.

The context id would most likely be irrelevant for the system context,
but would be the process id or or thread id for the process or thread
contexts.

One of our goals is a single GDB that can debug multiple processes the
same way (or even better) we can debug multiple threads today.  Since
those processes could have multiple threads, GDB will have to be able
to represent both the processes and the threads.  These contexts may
be a way to accomplish this.  I realize that a lot of work in GDB's
core is necessary, but if we're going to change the protocol at all,
we might as well future proof the investment.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From qqi@world.std.com Tue Dec 14 12:55:00 1999
From: Quality Quorum <qqi@world.std.com>
To: Gunter Magin <magin@skil.camelot.de>
Cc: bsimon@ctam.com.au, greyham@research.canon.com.au, gdb@sourceware.cygnus.com
Subject: Re: BDM/OCD with Macraigor Raven on MPC8xx from x86
Date: Tue, 14 Dec 1999 12:55:00 -0000
Message-id: <Pine.SGI.3.95.991214154813.10728A-100000@world.std.com>
References: <199912141750.SAA12619@skil.camelot.de>
X-SW-Source: 1999-q4/msg00507.html
Content-length: 1553

On Tue, 14 Dec 1999, Gunter Magin wrote:

> > Graham Stoney wrote:
> > 
> > > I'm wondering if anyone has had any success using gdb from an Linux x86
> > > machine to debug an MPC8xx target via BDM using a Macraigor Raven OCDemon?
> > >
> > > I've looked in the mailing list archives, and only found mention of using a
> > > Windoze host with a Wiggler. I'm not keen on switching to Windoze, and would
> > > like to take advantage of the Raven's extra speed if possible. Any pointers
> > > greatly appreciated!
> > 
> > There are no known PowerPC BDM drivers for Linux.
> 
> Right.
> 
> Furthermore, if there is no publicly available HW spec of the Macraigor
> Raven, there will be no Linux device driver, unless Macraigor itself starts
> to support it, or some curious soul reverse engineers this piece of HW.

As I said I am developing extended enhanced gdbserver
( http://www.std.com/qqi/labslave/rproxy.html ). I am going to port it 
into native WinNT shortly. I am very curious to provide wiggler 
target (it is mere porting of gdb target into simplier environment),

So, you can debug everything you want using remote protocol from 
you linux (any other) box.

> 
> Please note the recent move of some major graphic card manufacturers
> towards unveiling their top secret programming information without NDA, and 
> their cooperation with the XFree maintainers, so high quality open source 
> device drivers will become available. 
> 
> gm
> -- 
> Gunter Magin                                        magin[AT]skil.camelot.de
> 

Thanks,

Aleksey

Re: BDM/OCD with Macraigor Raven on MPC8xx from x86

[Graham Stoney]

Graham Stoney wrote:
> I'm wondering if anyone has had any success using gdb from an Linux x86
> machine to debug an MPC8xx target via BDM using a Macraigor Raven OCDemon?

Steven Johnson writes:
> Can not be done.
> 
> Macraigor will not release the specification to enable GDB to interface
> directly to their OCD Debuggers. The only support is through the
> Macraigor supplied DLL, and that only runs under windows. If you can get
> the specs for their devices then you can always write the interface from
> linux :).

Looks like the only viable GDB option with the Raven is under Cygwin then;
has anyone had success getting this to work?  The gdb binary in B20 doesn't
appear to include the ocd target, which means configuring it myself...

Alternatively, is there a better option than Macraigor? I know we could wire
up our own BDM interface, but we have budget and I'd like to buy a commercial
one so we can focus on designing our target hardware.

Thanks,
Graham
From ac131313@cygnus.com Mon Dec 06 03:26:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: Quality Quorum <qqi@world.std.com>
Cc: gdb@sourceware.cygnus.com, Stan Shebs <shebs@cygnus.com>
Subject: Re: bugs in remote.c
Date: Mon, 06 Dec 1999 03:26:00 -0000
Message-id: <384B9CFD.38F32FD9@cygnus.com>
References: <Pine.SGI.3.95.991205140345.4355A-100000@world.std.com>
X-SW-Source: 1999-q4/msg00451.html
Content-length: 1711

Quality Quorum wrote:
> 
> Hi,
> 
> It seems to me that minimal requirements to a stub should be:
> 
> 1. Return empty on everything it does not understand.
> 2. Does not change its mind about understanding something while
>    in the middle of operation. E.g. if it supports extended ops
>    should also support restart.
> 3. Return 'ENN' if (a) fatal error occured or (b) memory error
>    occured.
> 
> It seems to me that it is an absolute minimum set of requirements,
> which will allow to complex stuff like queries to work properly.

(Have a read of what the protocol has to say about the query packet and
some of its its features :-)

> It seems to me that people with uncompliant stubs should keep
> using gdb-4.18 or earlier, which are pretty decent debuggers
> anyway. Also, it seems like really simple thing to add
> something like 'old-remote' target which will lack new and shining
> stuff (e.g. extended ops, single register assignments and queries) but
> will be more tolerant towards old screwed up stubs.

Remember, the existing stubs can't be described as non-compliant as,
when they were written, there was no spec to comply to :-).

I don't think it is realistic to be talking about deserting people with
less than a year old stub/gdb.  If there is going to be a cleanup of the
remote protocol then a way will need to be found that doesn't disrupt
the existing user base.  Per other discussions a remote-protocol v2 with
some of the existing protocol lint removed may be a solution.  The
old-remote might be useful.  (However, at present there is async and
extended-async while we transition the async code.  I'd rather have only
one protocol variant running at a time).

	enjoy,
		Andrew
From eliz@gnu.org Mon Dec 06 03:34:00 1999
From: Eli Zaretskii <eliz@gnu.org>
To: ac131313@cygnus.com
Cc: jimb@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: ST(i) and MMj
Date: Mon, 06 Dec 1999 03:34:00 -0000
Message-id: <199912061134.GAA16617@mescaline.gnu.org>
References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org> <npzovvc04o.fsf@zwingli.cygnus.com> <199912010821.DAA27130@mescaline.gnu.org> <npogca9tb8.fsf@zwingli.cygnus.com> <38478987.EECEEBF@cygnus.com>
X-SW-Source: 1999-q4/msg00452.html
Content-length: 1133

> > Grep the sources for NUM_REGS, and look for loops that traverse the
> > register set.  Prove to yourself that none of these loops will break
> > if register X aliases register Y.  Persuade yourself that nobody in
> > the future, innocent of the x86's sins, will write such a loop.
> > 
> > I tried, but I couldn't manage it.  :)
> 
> I agree with Jim.  The way GDB currently resolves register names/numbers
> ``freaks me out''.

I don't know, it might be that I'm missing some crucial aspect of
this, but I did grep the sources for NUM_REGS, and didn't see anything
that cannot be taken care of by a combination of two simple tricks:

  * Make macros like REGISTER_BYTES, REGISTER_BYTE, REGISTER_RAW_SIZE,
    etc. behave as if the MMX registers, when stored in memory, have
    zero length;

  * Change functions that read and write registers from/to memory to
    handle the MMX registers specially by looking at the appropriate
    ST(i) register instead.

Both of these aspects are either target-specific or rely heavily on
target-specific subroutines, so it shouldn't be too hard to do it
without affecting other platforms.
From ac131313@cygnus.com Mon Dec 06 03:55:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: Quality Quorum <qqi@world.std.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: remote.c patch
Date: Mon, 06 Dec 1999 03:55:00 -0000
Message-id: <384BA3CB.6E5DD7BC@cygnus.com>
References: <Pine.SGI.3.95.991204145527.3680A-200000@world.std.com>
X-SW-Source: 1999-q4/msg00453.html
Content-length: 1431

Quality Quorum wrote:
> 
> Hi,
> 
> I got this patch attached, I made it against latest snapshot I have
> (gdb-19990913).
> 
> Now a few related comments:
> 
> 1. I used gdbserver to test remote target.
> 
>    a. It is not part of default compilation on my Linux RH5.2.
> 
>    b. It did not compile.
> 
>    c. It was quite painful to make it work. I can clean it up too, if
>       necessary, howver, I do not have access to anything but Linux RH5.2
>       and FreeBSD 3.2.
> 

Thanks for this, it's going to take some time to look it over but yes,
some of the things are bugs.  Not checking that a Z packet continues to
be supported, for instance, is definitly a bug.

	Andrew


Just FYI,

> ***************
> *** 4385,4393 ****
>         if (strcmp (buf, "OK") == 0)
>         break;
> !       if (strlen (buf) == 3 && buf[0] == 'E'
> !         && isdigit (buf[1]) && isdigit (buf[2]))
>         {
>           error ("Protocol error with Rcmd");
>         }
>         for (p = buf; p[0] != '\0' && p[1] != '\0'; p += 2)
>         {
> --- 4536,4545 ----
>         if (strcmp (buf, "OK") == 0)
>         break;
> ! 
> !       if (buf[0] == 'E')
>         {
>           error ("Protocol error with Rcmd");
>         }
> + 
>         for (p = buf; p[0] != '\0' && p[1] != '\0'; p += 2)
>         {
> ***************

A two hex-digit response with digit ``E'' is valid. That is why the code
had such a complicated check.

	Andrew
From ac131313@cygnus.com Mon Dec 06 04:00:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: remote.c patch
Date: Mon, 06 Dec 1999 04:00:00 -0000
Message-id: <384BA54B.A55B3E91@cygnus.com>
References: <Pine.SGI.3.95.991204145527.3680A-200000@world.std.com> <384BA3CB.6E5DD7BC@cygnus.com>
X-SW-Source: 1999-q4/msg00454.html
Content-length: 91

Andrew Cagney wrote:
	...

Sorry, I should have send the response to gdb-patches.

	Andrew
From qqi@world.std.com Mon Dec 06 07:36:00 1999
From: Quality Quorum <qqi@world.std.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: remote.c patch
Date: Mon, 06 Dec 1999 07:36:00 -0000
Message-id: <Pine.SGI.3.95.991206103517.8150D-100000@world.std.com>
References: <384BA3CB.6E5DD7BC@cygnus.com>
X-SW-Source: 1999-q4/msg00455.html
Content-length: 1009

On Mon, 6 Dec 1999, Andrew Cagney wrote:

> > ***************
> > *** 4385,4393 ****
> >         if (strcmp (buf, "OK") == 0)
> >         break;
> > !       if (strlen (buf) == 3 && buf[0] == 'E'
> > !         && isdigit (buf[1]) && isdigit (buf[2]))
> >         {
> >           error ("Protocol error with Rcmd");
> >         }
> >         for (p = buf; p[0] != '\0' && p[1] != '\0'; p += 2)
> >         {
> > --- 4536,4545 ----
> >         if (strcmp (buf, "OK") == 0)
> >         break;
> > ! 
> > !       if (buf[0] == 'E')
> >         {
> >           error ("Protocol error with Rcmd");
> >         }
> > + 
> >         for (p = buf; p[0] != '\0' && p[1] != '\0'; p += 2)
> >         {
> > ***************
> 
> A two hex-digit response with digit ``E'' is valid. That is why the code
> had such a complicated check.

Thanks, is it possible to get a pointer to where recent additions
are described ? 

BTW, was it possible to pick up another character beside 'E' ? :)

> 
> 	Andrew
> 

Thanks,

Aleksey