Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 5 Aug 2006 16:53:06 -0700
From:      Jo Rhett <jrhett@svcolo.com>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        freebsd-i386@freebsd.org
Subject:   Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered
Message-ID:  <20060805235306.GA80053@svcolo.com>
In-Reply-To: <20060806085626.S2624@delplex.bde.org>
References:  <200608022150.k72LoQtn098666@freefall.freebsd.org> <20060804223000.P97440@delplex.bde.org> <5F770D91-34A1-4406-AEF8-719E29AFFA87@svcolo.com> <3FB8BF25-F047-427C-9062-07ADF85D5169@svcolo.com> <20060806085626.S2624@delplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 06, 2006 at 09:33:15AM +1000, Bruce Evans wrote:
> 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.
 
I know this.  COM1 is a DOS/Windows term, and not a hardware term.

> 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

Again, this is a nonsense statement.  It's much like saying 

> 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

Then your BIOS is intentionally confusing and the vendor should be rebuked.
These aren't vague terms, they have established and well defined meanings.
If someone is using the terms to refer to physical hardware ports then they
are not using the terms correctly.

What if I said to you that I assigned sio0 to sio1 ?  You'd raise your
eyebrows and think I was a fool or ignorant.  Exactly so.  COM1 can be
assigned to COM2 no more than sio0 can be assigned to sio1.

> >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 

Meaning what?  I doubt that you have loaded a piece of DOS code in to
determine what COM1 is.  IO address, or first serial port?  
FYI: it must be IO address because we're currently and always have had
boot0 using the SerialB port just fine...

> and boot2 uses non-BIOS whatever i/o address is configured (default 0x3F8).

What is the difference here?  Seriously, both have always worked in this
configuration.  It's only when it switches over to sio that it failed.

> 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.

Man pages are not useful documentation.  They're only useful if you know
where to look, which is effectively the secret handshake to the club.

I was referring to the Handbook.  Which is welcome to refer to the
appropriate manpages, and thus the secret handshake is not necessary.

> >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).

This is untrue.  Or if true, then it raises questions about how the sio
numbers are assigned, because boot0 has always used the proper (unit 1)
port.

> >boot2 determines console how?  (repeat all questions above)
> 
> As above; yes; no; soft-hard-coded in makefiles; i/o address.
 
This is also not true, because it appears to reference device.hints for the
console flags, based on our last test.

> >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.

No, this clearly does read device.hints.

> >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).

I'm really not sure I know the difference between boot2, loader and kernel.
Where does each leave off?

-- 
Jo Rhett
senior geek
SVcolo : Silicon Valley Colocation



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