i386/100831: sio ignores BIOS information about serial ports - bounty offered

[Bruce Evans]

[freebsd-gnats-sbmit somewhat intentionally lost from the Cc]

On Fri, 4 Aug 2006, Jo Rhett wrote:

> On Aug 4, 2006, at 11:40 AM, Jo Rhett wrote:
>>> Just avoid inconsistencies by making all the hints match the unit number
>>> assignments that you get although these are not the unit number 
>>> assignments
>>> that you want.
>> 
>> I haven't the foggiest idea what you mean by this.  Exact instructions 
>> please?   I'm not kidding, this statement doesn't make sense to me. 
>> Everything is fine right now except where the console is directed.
>> 
>> I have no problem with the console being sio1, as long as sio1 is the 
>> console for all parts of the boot/run/shutdown process.  Therefore the 
>> console flags are the only thing I know to change.
>
> Maybe I was being dense when I wrote this.  Rethinking "making all the hints 
> match" comment I swapped the io port and irq assignments in device.hints to 
> match what is actually happening, rebooted, and it seems to work:
>
> hint.sio.0.at="isa"
> hint.sio.0.port="0x2F8"
> #hint.sio.0.flags="0x10"
> hint.sio.0.irq="3"
> hint.sio.1.at="isa"
> hint.sio.1.port="0x3F8"
> hint.sio.1.irq="4"
> hint.sio.1.flags="0x90"

Good.  I only tested it by understanding the source.

COM1 might mean 0x3F8 in DOS, but in FreeBSD sio0 just means whatever port
is mapped to unit 0 by hints or by another mechanism.  The hints give more
control over the mapping than in DOS, but don't always work now that there
is ACPI etc.

COM1 doesn't mean 0x3F8 in WinXP like you claimed in another reply and I
expected before I tested it.  Maybe WinXP would have mapped 0x3F8 to COM1
if I had reinstalled WinXP or if WinXP had rebuilt its driver database,
but when I just swapped COM1 with COM2 in the BIOS and rebooted, WinXP
didn't say that it was rebuilding its driver database and the ports were
just swapped in WinXP too.  My BIOS's labels for the ports are also
inconsistent with COM1 meaning 0x3F8 -- the first port is named COM1
(not COMA) and that port can be set to an address != 0x3F8, etc.  When
COM1 and COM2 were on ISA cards (especially when they were on separate
cards), it made much more sense for DOS to map the port at 0x3F8 to COM1,
etc.  ISTR that DOS has fixed mappings for COM1-COM4 but not for COM5 up,
and that it has magic mappings which don't work as well for LPT1-LPT2.

> Okay, so if this works then I'm guessing that boot0 or boot2 or both were 
> determining console based on the IO address from device.hints?  Can we use 
> what we know now to improve the documentation?

boot0 uses BIOS COM1 and boot2 uses non-BIOS whatever i/o address is
configured (default 0x3F8).  At least in man pages, the documentation for
this is hard to find.  I could only find it in boot0cfg(8) for boot0 and
and make.conf(5) for boot2.

> boot0 determines console how?  Compiled in...?  Can device.hints influence 
> that?  Since we don't yet have sio numbers assigned, how does it know which 
> port to use?  IO address?

As above; yes; no; hard-coded in assembler; BIOS unit number 0 (= COM1).

> boot2 determines console how?  (repeat all questions above)

As above; yes; no; soft-hard-coded in makefiles; i/o address.

> loader determines console how?  (repeat all questions above)

Same as boot2 (?).  Hopefully for everything except the port address, it
inherits settings (speed and parity etc.) from boot2.

> If I didn't name a process in the boot, add it to the list.

Kernel part of the boot.  Now uses hints.  Normally inherits all
settings from the previous stage provides it agrees on the port address
(it reads the settings from the port).

Bruce