Damon McMahon wrote:
Thanks for the response, Nick, I'm almost there and just one
further query:
On 18/02/07, Nick Holland <[EMAIL PROTECTED]> wrote:
...
The Aptiva has an anaemic BIOS program, but by disabling one of the
two serial interfaces I now appear to have eliminated IRQ conflicts
and acquired a working serial console - BUT I lose nearly all of the
dmesg(8) and init(8) output at boot, with it being directed to the
screen instead. I also note that boot(8) tells me I have com0 and no
com1 (which is expected since I disabled it in the BIOS) whereas
dmesg(8) tells me I have pccom1 but no pccom0 and this seems a little
strange to me.
boot(8) tells you what the BIOS tells it. boot(8) uses the BIOS to
communicate.
dmesg(8) tells you what hardware OpenBSD actually found.
The BIOS can define ports as it wishes.
OpenBSD defines ports as spec'd in /usr/src/sys/arch/i386/conf/GENERIC
From your dmesg,
pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
That's not the standard definition for com0 (DOS COM1), but rather,
com1 (DOS COM2:)
From pccom(4):
pccom0 at isa? port 0x3f8 irq 4
pccom1 at isa? port 0x2f8 irq 3
To clarify, boot(8) tells me I have com0 available at boot. So in
/etc/boot.conf I tell it:
set tty com0
and it switches to the console but all that is output to the
console is:
OpenBSD/i386 BOOT 2.10
boot>
booting hd0a:/bsd: 4966344+867848 [52+255872+237161]=0x608d64
entry point at 0x100120
so once the kernel is loaded, your redirection is screwed up...
That's it for the output seen on the terminal, at this point the
dmesg(8) and init(8) output is directed to the screen. Then when
getty(8) is executed interactivity for _both_ the keyboard and the
serial console are restored.
I haven't played with this kind of config, but my guess is you are
sending the output to a non-existant com0, so the system falls back to
using the screen.
You get the serial IO again after boot because of your ttys setting
which has tty01 turned on, you would get the login prompt on the
serial port even if you didn't do the "set tty com0".
Any further thoughts will be appreciated; dmesg(8) and ttys(5) are
included below:
...thanks, snipped for size
# head -n 20 /etc/ttys
#
# $OpenBSD: ttys,v 1.17 2002/06/09 06:15:14 todd Exp $
#
# name getty type status
comments
#
console "/usr/libexec/getty Pc" vt220 off secure
ttyC0 "/usr/libexec/getty Pc" vt220 on secure
ttyC1 "/usr/libexec/getty Pc" vt220 on secure
ttyC2 "/usr/libexec/getty Pc" vt220 on secure
ttyC3 "/usr/libexec/getty Pc" vt220 on secure
ttyC4 "/usr/libexec/getty Pc" vt220 off secure
ttyC5 "/usr/libexec/getty Pc" vt220 on secure
ttyC6 "/usr/libexec/getty Pc" vt220 off secure
ttyC7 "/usr/libexec/getty Pc" vt220 off secure
ttyC8 "/usr/libexec/getty Pc" vt220 off secure
ttyC9 "/usr/libexec/getty Pc" vt220 off secure
ttyCa "/usr/libexec/getty Pc" vt220 off secure
ttyCb "/usr/libexec/getty Pc" vt220 off secure
tty00 "/usr/libexec/getty std.9600" vt220 on secure
tty01 "/usr/libexec/getty std.9600" vt220 on secure
What's hurting you is that non-standard first com port. Take another
look at your BIOS setup, see if there is anything that allows you to
change how it is defined. Also check to make sure you don't have any
BIOS-based redirection going..that can cause various problems that
might be similar to this on some machines. (BIOS redirection is
great, but unfortunately, not at all standardized, so results are
sometimes unpredictable.)
Nick.
