Re: nindy protocol

[jtc at redback dot com (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