Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 16 Jan 1995 16:14:22 -0500 (EST)
From:      Wankle Rotary Engine <wpaul@skynet.ctr.columbia.edu>
To:        joerg_wunsch@uriah.sax.de
Cc:        freebsd-hackers@FreeBSD.org
Subject:   Re: serial consoles and keyboard probes
Message-ID:  <199501162114.QAA00387@skynet.ctr.columbia.edu>
In-Reply-To: <199501161534.QAA02863@bonnie.tcd-dresden.de> from "J Wunsch" at Jan 16, 95 04:34:51 pm

next in thread | previous in thread | raw e-mail | index | archive | help
They say this J Wunsch person was kidding when he wrote:
> 
> As Wankle Rotary Engine wrote:
> | 
> | - Merged biosboot and serialboot -- the keyboard i/o routines and the
> |   serial port i/o routines are contained in the same boot block: putchar()
> |   writes to both the serial port and the standard graphics display, and
> |   getchar() can be told to read either from the serial port of the
> |   PC's keyboard.
> 
> Two problems i'm seeing here: i had already a hard job to even fit the
> serial boot stuff w/o VGA/kbd BIOS into the existing boot blocks.
> Having both there would bloat them again, and space is really a scarce
> resource.

Yes, I know. I had to cheat a bit to actually make all of my most recent
changes fit. First, I had to compile with -O2, and second I had to yank
out what appeared to me to be an archaic section of code from boot.c:

/*      if(addr < ouraddr)
        {
                if((addr + head.a_text + head.a_data) > ouraddr)
                {
                        printf("kernel overlaps loader\n");
                        return;
                }
                if((addr + head.a_text + head.a_data + head.a_bss) > 0xa0000)
                {
                        printf("bss exceeds 640k limit\n");
                        return;
                }
        } */

It seems to me that since the kernel is now always loaded into high
memory that the condition that this code tests for can never happen:
'addr' can never be less than 'ouraddr' unless things are compiled 
differently, so what's the point.
 
> Second: assume sio0 is connected to a modem.  Since the bootblocks
> would then echo all their neat garbage to the modem, too, the modem
> might get confused.  Consider the case the user on the keyboard hits
> ``?'' to see the file list, and on of the files has the nifty name
> ``atd2345''... :-)

Okay, I've taken care of this. I have managed to find a way to probe
for a keyboard: syscons does it by trying to reset the keyboard hardware,
so I yanked the snippet of code that does this and created a small
probe routine. What happens now is this:

- The serial port is initialized whether we intend to use it or not, but
  nothing it printed to it initially. The 'serial' flag is cleared by 
  default.

- The probe_keyboard() function tries to reset the keyboard. If it fails,
  we assume the keyboard isn't plugged in and the 'serial' flag is set.
  From here, we assume that that the serial port is the default console
  device. If the keyboard is reset successfully, then we assume that the
  VGA display is the console device and nothing is printed to the serial
  port.

- Whether we default to serial mode or not, the serial port is still
  probed for characters along with the PC's keyboard.

When combined with the stuff I mentioned in my previous message, this
allows for the following functionality:

- If the keyboard is present, we can accept input from either it *or*
  the serial port, although the banner message will only be printed to
  the VGA display so that we don't confuse any modems that might be
  present on COM1. (Happy now? :)

- If the keyboard is not present, we do the opposite: the banner message
  goes to the serial port (along with an extra 'No keyboard found' message)
  but we still probe for characters on both the serial port and the
  keyboard (in case the user plugs the keyboard back in).

- The user can force the kernel to boot into 'serial console' mode using
  the -h flag from the keyboard, if he/she wants.

- In either case, 'options COMCONSOLE' becomes a thing of the past and
  booting from a serial port is now possible without any special 
  modifications, like God intended it to be. :) We also don't need a
  seperate 'serialboot' boot block.

The cost of this extra functionality: an added 224 bytes:

-r--r--r--  3 bin  bin    512 Jan  9 13:09 wdboot
-r--r--r--  3 bin  bin   6864 Jan  9 13:09 bootwd

-rw-r--r--  1 root  bin    512 Jan 16 15:30 boot1
-rw-r--r--  1 root  bin   7088 Jan 16 15:30 boot2

Again, this is with -O2. This is quite a bit bigger than before, but it
it's still within the limit (I think the upper limit is 7168).

> The above aside: i like the idea.

So what do you think of it now? :)

> -- 
> cheers, J"org                             work:      --- no longer ---
>                                           private:   joerg_wunsch@uriah.sax.de

-Bill

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~T~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Bill Paul            (212) 854-6020 | System Manager
Work:         wpaul@ctr.columbia.edu | Center for Telecommunications Research
Home:  wpaul@skynet.ctr.columbia.edu | Columbia University, New York City
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Møøse Illuminati: ignore it and be confused, or join it and be confusing!
~~~~~~~~ FreeBSD 2.1.0-Development #0: Fri Jan 13 22:04:07 EST 1995 ~~~~~~~~~



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199501162114.QAA00387>