On Sat, 2 Oct 1999, Greg A. Woods wrote:

> Date: Sat, 2 Oct 1999 16:01:39 -0400 (EDT)
> From: Greg A. Woods <woods@most.weird.com>
> Reply-To: NetBSD/sparc Discussion List <port-sparc@netbsd.org>
> To: port-sparc@netbsd.org
> Subject: Re: zs driver patch.
> 
> [ On Friday, October 1, 1999 at 16:45:57 (-0500), Ron Roskens wrote: ]
> > Subject: zs driver patch.
> >
> > The included patch updates the the zs driver, such that you need to key in
> > a sequence ( BREAK, any char, BREAK, any char, BREAK ) before it will drop
> > to the debugger/prom.

Well, I had to get used to sending this sequence at a place I worked at.
The client had hacked the zs driver in solaris to require this before
dropping the machine down. Something about terminal servers and serial
lines was the reason they added this feature.

And if you do something like this, then repeated reboots of a machine
would not send a machine into the debugger or prom. (eg:
BREAK-BREAK-BREAK) Although a timer could change that?

> I'm not sure I like that idea any better -- sometimes I want to drop the
> system into the debugger (or PROM) A.S.A.P. and without the possibility
> that I'll make any mistake with fumbling fingers.  It's hard enough to
> get the break sequence right with telnet/kermit/cu etc. in the first place!

What I'd like to do is make the sequence be user definable. But I need to
figure out sysctl's to define this there.

As far as telnet/kermit/cu go, I've found that I can send the signal
pretty quick with either telnet or kermit. Sure you lose a second or two
since its a sequence of characters, rather than a single entry.

From what I was doing in the zstty_rxint(), you could have it
look for a specific character after the break signal has bumped
zstty_abort_count. Then you could send it a BREAK-D for say the debugger,
or even BREAK-P for the prom. But I'm not sure how you would want to
pass this additional information down to the MD side. Currently this patch
is to the MI zs driver.

> The trick is to ensure that disconnecting the physical interface won't
> cause the signal line to float in such a way that the UART detects it as
> a BREAK.  It is said that a 4.7K-ohm resistor between pins 3 & 25 will
> prevent a floating RxD from being seen as a BREAK signal (pin 25 on
> systems that have separate A and B ports is supposedly a -5VDC source,
> except for some versions [501-1899] of the 4/4xx VME CPUs [the A/B ports
> on SLC, ELC, LX, Classic, SS10, etc. don't seem to have a -5vdc pin]).
> However I've also heard people recommend using a resistor and zener
> diode to keep the pull RxD line low.

The last time I touched a soldering iron was about 10 years ago. I don't
have as much faith in my ability now as I did then.  Then again I've never
considered doing any hardware modifications to my machines. I think if its
possibly to implement it in software, then it makes it easier and simpler
for the majority of people.

And the sparc port isn't the only one that could benefit from this...

Ron