From owner-freebsd-hackers Mon Jan 16 20:21:10 1995 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id UAA28127 for hackers-outgoing; Mon, 16 Jan 1995 20:21:10 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id UAA28110 for ; Mon, 16 Jan 1995 20:20:58 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id PAA24105; Tue, 17 Jan 1995 15:17:13 +1100 Date: Tue, 17 Jan 1995 15:17:13 +1100 From: Bruce Evans Message-Id: <199501170417.PAA24105@godzilla.zeta.org.au> To: joerg_wunsch@uriah.sax.de, wpaul@skynet.ctr.columbia.edu Subject: Re: serial consoles and keyboard probes Cc: freebsd-hackers@FreeBSD.org Sender: hackers-owner@FreeBSD.org Precedence: bulk >> | - 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. My debugger uses this method (of broadcasting to all attached devices). It also merges reads from all attached devices. I think this would be good for both the bootstrap and for the console device. However, space is short in the boostrap, and there are complications in the console driver (it already messes up multiplexing between 3 devices: logical console, physical console and virtual (TIOCCONS) console) as well as the configuration of the physical console). >> 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. I rewrote the bootstrap serial console i/o routines in C. This takes only about 32 bytes more, but 32 is too many for Joerg :-). >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) You can have that :-). I've already made precisely these changes, plus replacing the twiddle() code with putchar('.'), in order to enable my debugging code (-DBDE_DEBUGGER) and the code to load the symbol table. >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. It would be nice if the old capabilities of the boot code weren't lost. The load address is defined in the Makefile (BOOTSEG). Nothing forces it to be low except the fact that the boot won't actually work if the kernel expects to be loaded low. I'd like the position- independentness of the boot code to be preserved and for boot.c to check that it doesn't overwrite itself, or write to nonexistent memory... >- 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). Have you considered the case of keyboard without a screen? :-). This isn't completely unreasonable. Screens worth using are large and expensive compared with keyboards worth using, and after the system has booted, the screen might be in the wrong (X) mode. >- 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 bootstrap should pass a list of console device names, not magic boot flags or device numbers. >The cost of this extra functionality: an added 224 bytes: And more unmaintaiable assembler code? >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 limit is 15 sectors = 7680 bytes for the text+data of `boot'. There is room for one more sector below the filesystem, but start.S can only handle 15 sectors, at least on 15-sector disks. Expansion possibilities include - a multi-stage boot (no fancy stuff in the first stage). - honor d_bbsize in labels and make it larger. It is currently sometimes blown away by BBSIZE = 8192. Space for bootblocks is reserved on all file systems so making d_bbsize and/or BBSIZE much large would be wasteful. Bruce