nindy protocol

nindy protocol

[J.T. Conklin]

Does anyone have a copy of the Nindy protocol specification or an old
Intel gnu960 (aka CTOOLS) distribution that contains Nindy source?  I
checked developer.intel.com, but the CTOOLS distributions currently
available all have mon960 instead of Nindy.

The reason I ask is because I'd like to get rid of the dcache_fetch()
and dcache_poke() functions which are only used by remote-nindy.c and
remote-bug.c.  

Unlike most remote targets, the nindy_xfer_inferior_memory() function
breaks the transfer into multiple word-aligned word-sized transfers.
These word-sized transfers are performed through dcache_fetch() and
dcache_poke().  The header comment for nindy_xfer_inferior_memory()
states:
        "This is stolen almost directly from infptrace.c's
        child_xfer_memory, which also deals with a word-oriented
        memory interface.  Sometime, FIXME, rewrite this to not use
        the word-oriented routines."

I'm not sure whether this means that nindy protocol supports non-word-
aligned, non-word-sized transfers, and the code just needs to be fixed
to use them, or if something more substantial must be done.  I checked
the code in nindy-share/nindy.c, which seems to indicate that the
protocol supports arbitrary sized/aligned transfers, but it's not 
explicitly stated.  I'd like to confirm this before submitting a patch.

In case anyones wondering, the primary reason I'd like to get rid of
these functions is that otherwise I'd have to adapt them to take a
mem_attrib parameter.  They also seem to be poorly specified.  They
read and write a host word, when I'd think they would be defined in
terms of the target's word size.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: nindy protocol

[Stan Shebs]

"J.T. Conklin" wrote:
> 
> Does anyone have a copy of the Nindy protocol specification or an old
> Intel gnu960 (aka CTOOLS) distribution that contains Nindy source?  I
> checked developer.intel.com, but the CTOOLS distributions currently
> available all have mon960 instead of Nindy.

I squirreled away a couple copies of CTOOLs when I was at Cygnus, but
I don't know if any were old enough to include Nindy sources still;
don't remember ever seeing actual Nindy sources.

> The reason I ask is because I'd like to get rid of the dcache_fetch()
> and dcache_poke() functions which are only used by remote-nindy.c and
> remote-bug.c.

IMHO we should officially declare Nindy support obsolete.  As you observed,
Intel now denies its existence :-), the last physical board I knew of
(at Cygnus) died ca 1996, and the last couple of years of GDB churning
probably broke the Nindy support, but nobody appears to have noticed,
or cared enough to report it as a bug.

I could do the research to justify obsoleting Nindy, then you'd be free
to whack the dcache functions (remote-bug.c is also an obsoletion
possibility BTW).

Stan

Re: nindy protocol

[J.T. Conklin]

>>>>> "Stan" == Stan Shebs <shebs@apple.com> writes:
Stan> I squirreled away a couple copies of CTOOLs when I was at Cygnus, but
Stan> I don't know if any were old enough to include Nindy sources still;
Stan> don't remember ever seeing actual Nindy sources.

Do you still have access to them?  I found the CTOOLS 5.0 release
notes on developer.intel.com --- it looks like Nindy was replaced
then.  If you have an earlier release, it should have the Nindy
sources.

>> The reason I ask is because I'd like to get rid of the dcache_fetch()
>> and dcache_poke() functions which are only used by remote-nindy.c and
>> remote-bug.c.

Stan> IMHO we should officially declare Nindy support obsolete.  As
Stan> you observed, Intel now denies its existence :-), the last
Stan> physical board I knew of (at Cygnus) died ca 1996, and the last
Stan> couple of years of GDB churning probably broke the Nindy
Stan> support, but nobody appears to have noticed, or cared enough to
Stan> report it as a bug.

Stan> I could do the research to justify obsoleting Nindy, then you'd
Stan> be free to whack the dcache functions (remote-bug.c is also an
Stan> obsoletion possibility BTW).

Feel free.  I'm not going to argue against it.  However, if Nindy
supports arbitrary sized and aligned memory transfers the changes
necessary to remove dcache_fetch() and dcache_poke() are trivial.  If
we can't determine whether it's safe, and you want to wait more before
obsoleting the config, I propose that we commit it anyway.  If it
breaks anything and anyone cares, we'll hear about it soon enough.

It appears that the remote-bug.c implements read/write by downloading
and uploading s-records, so there should be no problems at all removing
dcache_fetch() and dcache_poke() from it (at least I've never heard of
any srec reader that didn't support arbitrary addresses).

If the MVME187BUG monitor is anything like the m68k, ppc, and coldfire
versions of BUG, it could be rewritten to use the generic monitor code,
resulting in a smaller and more robust target.  Whether anyone cares to
do so is another story.  If remote-bug.c is obsoleted, it appears that
most of remote-utils.c (all the gr_* stuff) can too.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: nindy protocol

[Stan Shebs]

"J.T. Conklin" wrote:
> 
> >>>>> "Stan" == Stan Shebs <shebs@apple.com> writes:
> Stan> I squirreled away a couple copies of CTOOLs when I was at Cygnus, but
> Stan> I don't know if any were old enough to include Nindy sources still;
> Stan> don't remember ever seeing actual Nindy sources.
> 
> Do you still have access to them?  I found the CTOOLS 5.0 release
> notes on developer.intel.com --- it looks like Nindy was replaced
> then.  If you have an earlier release, it should have the Nindy
> sources.

Actually, I think 5.0 is the earliest I have too.

> Stan> I could do the research to justify obsoleting Nindy, then you'd
> Stan> be free to whack the dcache functions (remote-bug.c is also an
> Stan> obsoletion possibility BTW).
> 
> Feel free.  I'm not going to argue against it.  However, if Nindy
> supports arbitrary sized and aligned memory transfers the changes
> necessary to remove dcache_fetch() and dcache_poke() are trivial.  If
> we can't determine whether it's safe, and you want to wait more before
> obsoleting the config, I propose that we commit it anyway.  If it
> breaks anything and anyone cares, we'll hear about it soon enough.

Fine by me.

> If the MVME187BUG monitor is anything like the m68k, ppc, and coldfire
> versions of BUG, it could be rewritten to use the generic monitor code,
> resulting in a smaller and more robust target.  Whether anyone cares to
> do so is another story.

There was at least one m88k workstation alive recently, somebody on this
whose name I forget (sorry) sent in some patches for it last year or so.
But embedded m88k boards these days?  Rather unlikely I think.

> If remote-bug.c is obsoleted, it appears that
> most of remote-utils.c (all the gr_* stuff) can too.

Yup, an attractive side benefit.  To borrow from S&W, "omit needless code". :-)

Stan