Subject: Re: Breaker... Breaker...
To: Don Yuniskis <auryn@GCI-Net.com>
From: Greg A. Woods <woods@weird.com>
List: port-sparc
Date: 05/06/2002 15:19:20
[ On Monday, May 6, 2002 at 10:48:26 (-0700), Don Yuniskis wrote: ]
> Subject: Re: Breaker... Breaker...
>
> For example, seeing the BREAK and just *remembering* that
> you saw it.  Then, waiting for some (multiple?) character sequence
> to actually cause the trap to the monitor.  Perhaps something as
> hokey as
>     BREAK 's' 't' 'o' 'p'
> Of course, this means folks who want to use this feature are
> now burdened with this (annoying) keystroke sequence.  So,
> perhaps something easier
>     BREAK  BREAK
> (with a timeout to "forget" the first BREAK after some amount of time)

That's how it works today, but with the logic somewhat inversed.

The system sees a BREAK condition, then it waits for you to type
something.  Unfortunately for you it waits indefinitely and it doesn't
do anything else while it's waiting.  If you don't want to stop the
machine you type "go<CR>" and it goes back to what it was doing before
you or your terminal device (or your noisy cable) so rudely interrupted
it!  :-)

If you and your terminal devices and cabling, etc., don't generate
unintended BREAK conditions then the current logic works just fine and
has the added advantage that it can be used as an "emergency halt".

> [As an aside, can you still interrupt the boot using the *keyboard*
> if the BREAK is *completely* disabled?]

The keyboard on a Sun workstation, and the system console port(s) are on
totally separate UARTs.  Disabling BREAK detection on the serial ports
won't affect the keyboard, but you can only use one at a time -- either/or.

> > 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
> 
> How soon/late is that?  I.e. could you quit before the kernel completely
> loads?  Could you quit while all the probe()s are taking place?

I dunno for sure -- you could load -current and test though...

> Fortunately (?  Heh heh heh), the SCC doesn't sense MARK->SPACE
> transitions to signal the START bit detection.  (some UARTs do -- so,
> once a BREAK starts, they will not recognize the start of a *new*
> character until the BREAK terminates)  So, once the "misframed NUL"
> is detected, the SCC will keep receiving "characters" as long as the
> RxD line remains in the SPACE state (i.e if held to SPACE, it will keep
> receiving an endless stream of NULs).  This can be exploited to do a
> more "accurate" BREAK detect -- if the first character following the
> START OF BREAK detected is also a NUL (framed *or* misframed,
> though if framed properly, no other NULs -- see below -- can follow)
> *and* can be verified as having *immediately* followed the first NUL
> (i.e. so you can state for sure that the data line did not return to MARK
> between the characters), then you have a bonafide BREAK.
> 
> Note that any number of misframed NULs can then occur.  And, the
> "last" character in this "string" will be one in which there are no "0"
> bits more significant than the least significant "1" bit  (e.g., 0x00, 0x80,
> 0xC0, 0xE0, 0xF0, 0xF8... 0xFF).  If the last sch character is a NUL,
> it may be framed or misframed.  All other characters must be framed
> properly.
> 
> IIRC, the SCC will generate a *second* "BREAK" interrupt when
> the RxD line returns to MARKing, again -- an END OF BREAK
> interrupt.  If your interrupt latency is low enough <big grin> *and*
> you know you won't drop any interrupts, you can use these
> START/END interrupts to detect the event -- and then just qualify
> it with a gross count of the number of bits/characters between those
> events.

Hmmmm..... that's quite interesting.  I didn't know about the second
BREAK interrupt....  I wonder if the driver could be fixed to do
this.....

> Note that I have ignored the role of parity in all this... :-(

I'd be happy with being forced to use 8,N,1 on the console!  ;-)

> If my memory is a bit fuzzy, my apologies.  If someone wants to
> dig into this deeper, I can possibly be persuaded to try to locate
> any SCC materials in my "stash" (though I still have two workstations
> to get up and running here -- "So little time, so much to do...")

There's an impossible to read online copy of the "Product Spec.":

	http://www.zilog.com/docs/serial/ps0113.pdf

but all the detailed stuff is here:

	http://www.zilog.com/products/familydocs.asp?BusinessLineID=261

(aside:  I came across Taligent's USA patent 5,574,915 for "An object
oriented booting framework" when looking online for 8530 info! :-)

-- 
								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>