Subject: Re: Breaker... Breaker...
To: Don Yuniskis <auryn@GCI-Net.com>
From: Greg A. Woods <woods@weird.com>
List: port-sparc
Date: 05/05/2002 15:00:07
[ On Saturday, May 4, 2002 at 22:27:13 (-0700), Don Yuniskis wrote: ]
> Subject: Re: Breaker... Breaker...
>
> > "John Refling" <johnr@imageworks.com> wrote:
> > 
> > The break issue on sparcs has been known about
> > and beaten to death over and over and over.
> 
> Yet, no one has said "this is why it works that way in
> a SPARC; these are the SPARCs that *have* the problem;
> these are the ones that don't; this is why it works that
> way under NBSD..."
> 
> Without a nice simple clarification of how and why
> it is the way it is, you're likely never to find a better
> solution -- unless someone gets fanatical about it!

On most any unix-like system, particularly servers, there's a notion of
having a "console" TTY-like device which is where the operator can
interact with first the system firmware, and later the operating system
boot code, and finally the operating system proper, eg. when in single
user mode.  The operating system will also print kernel-level messages
there.  Many of these systems have built-in kernel debugger support to,
and this device is where the systems programmer may invoke and interact
with the debugger.

In all of the above cases it is highly desirable to have a hardware
level signal to interrupt various operations and/or trigger state
transitions.

On bigger systems which have a front-end processor even for the console
(eg. IIRC even a VAX-11/780), this hardware signal can be generated by
the FEP, perhaps through an FEP command explicitly typed after throwing
a switch to wake up the FEP and tell it to pay attention to the console
terminal.

On systems where the console device is an RS-232(-like) serial port then
the BREAK condition is the ideal, and perhaps only, reliable way to
generate a hardware level interrupt which all of the various levels of
software mentioned above can intercept.  (Some systems tried to avoid
this problem by using a single ASCII character that would normally never
be typed, such as the Convergent MITIframe's <CTRL-B>, but imagine what
happens when an emacs user tries to use the console! :-)

On systems where the console device is actually a keyboard and frame
buffer (or similar video interface), then sometimes a special key
sequence can be used, especially if the keyboard processor is smart
enough to do this itself (not that that's how sparcstations work as far
as I know -- on sparcstations the keyboard is just a serial port and
from what I've understood of the code any BREAK condition on that line
is just ignored).

> This implies that the BREAK "feature" is not inevitable.
> So, what do you *lose* if you disable it?  Can you still
> interrupt the boot sequence with a serial console
> (i.e. stay at the ok prompt?)

Well, on a sun4-class sparcstation in particular, that'll depend on
exactly where and how you disable it.

If you use hardware logic to intercept and re-process your serial data
to ensure a BREAK condition can never occur then you'll never be able to
interrupt a boot or hard-halt the system from multi-user mode, or drop
into the debugger (ddb(8)) on demand, etc.

If you take out the code in the kernel which handles the BREAK condition
on the console serial port then I think you'll be able to interrupt a
boot up until the point where the kernel console code is attached and
activated, but you will not be drop to the monitor prompt or debugger
prompt.

There's still the BREAK detection in the firmware, of course...


All the issues you discuss w.r.t. UARTs and how they detect BREAK are of
course very real.  The older Sun sparcstations all (IIRC) use the z8530
UART (one for both ttya/ttyb and another for kybd/mouse).  The tty code
sets bit 0x80 in register 15 to enable BREAK status interrupts and then
checks bit 0x80 in register 0 to see if an interrupt was due to BREAK.

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>