Date: Tue, 17 Jan 1995 15:17:13 +1100 From: Bruce Evans <bde@zeta.org.au> To: joerg_wunsch@uriah.sax.de, wpaul@skynet.ctr.columbia.edu Cc: freebsd-hackers@FreeBSD.org Subject: Re: serial consoles and keyboard probes Message-ID: <199501170417.PAA24105@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> | - 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199501170417.PAA24105>