[ On Monday, June 19, 2000 at 19:00:56 (-0700), Jason R Thorpe wrote: ]
> Subject: Re: SUPPORT_SERIAL=?
>
> Of course, Sun's aren't PCs, and thus don't suffer from the wide
> range of lossage that crappy PC hardware can cause... such as "keyboard
> is really connected, but still fails the `reset' command".

Ever since I left 286s behind I seem to be under the impression that
every PC can detect keyboard errors in the BOIS, and most more modern
machines (probably most Pentium and newer) can also be configured to
bypass keyboard errors on boot.

Now assuming nobody ever has to bypass keyboard errors just to get their
only keyboard to work, this would suggest that on every machine there's
code in the BIOS that will detect a keyboard.  If I remember correctly
the results of the BIOS startup POSTs are put in a data structure that
can be read after boot too.

If this is so, and if this code is always in a reliable place, then it
should be possible to ivoke it just before switching to real mode (or
perhaps even use its results if they're in a common area of POST codes).

If this BIOS code reliably detects the absense of a keyboard too then
we're really laughing, but I'm less worried about this case than that of
failing to detect a connected and functional keyboard.  Where a display
adapter is optional its absense could also be used to trigger switching
to a serial console.

I do know that the code I borrowed from FreeBSD to detect a keyboard
would return success on a Compaq 3500 (I think that was the number) even
when the keyboard was disconnected and disabled in the BIOS.  I don't
remember for sure if the newer FreeBSD code worked better or not.  That
code did work just fine on an IBM PC Server 325 and on an Intel
TC430hx.  I'm still using those boot blocks on my 1.3.3 i386 machines.

> Yes, it is.  I've been having to deal with this ... quite
> up-close-and-personal for the last couple of months.  PCs suck, I just
> wish I could be using Alphas for my particular application.

Can't disagree with that!  ;-)

> A better idea would be to have the values in /boot itself, which /boot
> could subsequently modify by writing the correct block back to disk.
> That way, installboot could easily frob the values, too.

I could live with that too -- at least then you know exactly where they
are and they can't exactly get lost very easily.....

BTW, I'm not terribly interested in supporting, by default, consoles on
anything but COM1, as COM1 is defined by the BIOS.  Those who need
something more special than this can still use custom boot code.

-- 
							Greg A. Woods

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