Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Gunter Magin <magin@skil.camelot.de>
To: bsimon@ctam.com.au
Cc: 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 09:50:00 -0000	[thread overview]
Message-ID: <199912141750.SAA12619@skil.camelot.de> (raw)
In-Reply-To: <38556906.F1D1D7F8@ctam.com.au>

> 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


  reply	other threads:[~1999-12-14  9:50 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-12-05 17:23 Graham Stoney
1999-12-13 14:48 ` Brendan Simon
1999-12-14  9:50   ` Gunter Magin [this message]
     [not found] <384B53DD.B65146C7@ozemail.com.au>
1999-12-06  0:08 ` Graham Stoney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199912141750.SAA12619@skil.camelot.de \
    --to=magin@skil.camelot.de \
    --cc=bsimon@ctam.com.au \
    --cc=gdb@sourceware.cygnus.com \
    --cc=greyham@research.canon.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox