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

Bruce Evans bde at zeta.org.au
Fri Aug 4 12:40:22 UTC 2006


The following reply was made to PR i386/100831; it has been noted by GNATS.

From: Bruce Evans <bde at zeta.org.au>
To: Jo Rhett <jrhett at svcolo.com>
Cc: freebsd-gnats-submit at freebsd.org, freebsd-i386 at freebsd.org,
        njl at freebsd.org
Subject: Re: i386/100831: sio ignores BIOS information about serial ports -
 bounty offered
Date: Fri, 4 Aug 2006 22:29:40 +1000 (EST)

 On Wed, 2 Aug 2006, Jo Rhett wrote:
 
 > On Thu, Aug 03, 2006 at 05:32:35AM +1000, Bruce Evans wrote:
 >> I don't completely understand this either.  I think there is a non-ACPI part
 >> of the BIOS that FreeBSD (or all OS's doesn't see).  As I understand your
 >> configuration, you start with COM1 and COM2 at the usual places but don't
 >> want to use COM1 so you change the BIOS settings for COM2 to the usual ones
 >> for COM1 and maybe vice versa.  This changes soft jumpers or whatever is
 >> needed for FreeBSD to see it.  Then you use a BIOS option to swap the ports
 >> so that everything is supposed to see COM2 as COM1.  The boot loader sees
 >> this but ACPI in FreeBSD doesn't.  I think this changes is only made in
 >> some BIOS table that ACPI in FreeBSD doesn't know about.  In my test, I
 >> only swapped the settings of COM1 and COM2 in the BIOS, since I couldn't
 >> find a BIOS option to swap the unit number assignments, so it was not
 >> completely incorrect for ACPI in FreeBSD to swap the settings.
 >
 > Huh?  I separated this to make it clear.
 >
 > You can't make COM1 be COM2.  What you're saying is nonsense.
 > (not an insult, it just doesn't make sense)
 >
 > There are two serial ports: A and B.  I can assign 03f8 irq 4 to either of
 > them, and 02f8 irq 3 to the other.  (or com3 or com4 doesn't matter)
 
 It makes perfects sense when you understand that the unit number may be
 assigned at many levels, starting with the BIOS.  Whether you can make
 COM1 be COM2 at the BIOS level depends on BIOS support for this.  I've
 never seen a BIOS that supports this but thought that you had one with
 this feature and were using it (actually to make COMB be COM1), since
 you said that it works for booting and I forgot that boot2 doesn't use
 the BIOS.
 
 Later we mentioned boot0.  boot0 does use the BIOS and has COM1
 hard-wired, so assignment of COMB to COM1 at the BIOS level is the
 only way to make boot0 use COM1.
 
 Whether you can make COMB be COM1 at other levels depends on the other
 level's support for this.  Whether settings at lower levels are honored
 at higher levels also depends on the other levels' support for this.
 
 > FreeBSD is currently assigning sio0 to serial A, regardless of the IO and
 > IRQ settings.  Likewise sio1 to Serial B, regardless of configuration.  It
 > appears likely that they are assigned based entirely on the order that they
 > are presented via ACPI, and device hints are ignored entirely.
 
 This now seems a reasonable thing to do.  WinXP behaves similarly here
 (see another reply).  The hints are only hints, so they shouldn't be
 used if the hardware has been reconfigured but not moved.  Only something
 stronger than a hint should move the unit numbers if the hardware hasn't
 moved.  The problems are that the hints get used partially and there is
 nothing stronger.
 
 > However, the boot loader console does use device hints and does work
 > properly.
 
 Actually, the boot loader doesn't use hints:
 - boot0 has COM1 hard-coded in the source
 - boot2 has i/o port address 0x3f8 not so hard-coded in the Makefile.
    This can be changed using make.conf.
 - loader seems to be the same as boot2.
 There has been some discussion of propagating the settings used by the
 boot loader (at all stages) to subsequent stages, but nothing related
 seems to be implemented for the port/unit number.  Some of the settings
 (mainly the speed) are inherited by the sio console from the previous
 stage (boot2 or loader) provided the stages agree on the port/unit.
 
 Bruce


More information about the freebsd-i386 mailing list