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

[Bruce Evans]

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: Thu, 3 Aug 2006 05:32:35 +1000 (EST)

 On Wed, 2 Aug 2006, Jo Rhett wrote:
 
 >> On Wed, 2 Aug 2006, Jo Rhett wrote:
 >>> 1. We can't/won't fix the sio0<->sio1 problem because fixing ACPI is hard
 >
 > On Aug 2, 2006, at 10:25 AM, Bruce Evans wrote:
 >> _I_ can't/won't fix it because not just the above :-).  Swapping of 
 >> consoles
 >> only could be fixed within the driver (so that ACPI is not involved and
 >> you don't have to change device.hints) since consoles have to be hard-wired
 >> in some way and the hints are good enough for wiring the unit number to
 >> the i/o address (provided it's an old ISA port -- otherwise hints based
 >> on the i/o address don't work).
 >
 > Sorry, color me dumb.  I'm getting lost here.  The problem I was observing is 
 > that device hints is being (mostly) ignored by ACPI and thus this is the root 
 > problem to fix.  I'm not sure what you're trying to say here.
 
 Console drivers have to and do use the hints directly so as to work before
 bus stuff like ACPI is initializated.  After bus stuff is initialized, they
 could keep using the working configuration read from device.hints.  sio
 already does this in most places, but in one place it neither checks for
 nor fixes up inconsistencies caused by ACPI ignoring the hints.
 
 >>> 2. The sio units are thus going to swap when entering high-level sio mode
 >>> 3. The workaround is to put flags 0x10 (or 0x90) on sio1
 >> 
 >> It also needs the port numbers swapped (for consoles to work) and other 
 >> hints
 >> swapped (to be consistent, so as to work if there is no ACPI so the other
 >> hints are actually used)
 >
 > Can you provide a clear list of instructions then?  I have no idea what you 
 > mean by "port numbers swapped".  Swapped where?
 
 Since it is too hard to change ACPI to use the hints, change the hints to
 give the same configuration as ACPI will give.  For 2 ports, you've already
 swapped them in the BIOS, but ACPI doesn't see that so they must be swapped
 back in device.hints to match.  This loses the benefits of the swapping
 inside FreeBSD but keeps them outside of FreeBSD including in the boot loader.
 I don't know if this is enough for you or if the benefits of the swapping
 are larger enough for it to be worth doing when you lose them inside
 FreeBSD.
 
 > I was assuming
 > 	/boot.config has -Dh
 > 	/boot/loader.conf has console="comconsole"
 
 Not changes to booting -- it keeps using COM1.
 
 > 	/boot/device.hints comment out #hint.sio.0.flags="0x10"
 > 	/boot/device.hints add hint.sio.1.flags="0x10"
 
 Swap all sio.0 entries, with the corresponding sio.1 entries, or if you
 only need to use the port at 0x3f8, then comment out or remove all sio.0
 entries and change all sio.1 entries to have the previous values of the
 sio.0 entries.  If both units had a console flag like 0x10 set for some
 reason, then to avoid complications, remove the one that you don't want
 instead of swapping it.
 
 > 	/etc/ttys - put a getty on ttyd1
 
 Yes, since ttyd* is a logically separate device from the console, it is not
 affected by changing device.hints.
 
 > What am I missing?
 >
 > If I understand correctly, the boot loader compiled in option sio0 on 0x3f8 
 > flags 0x10 will be in effect until the higher level sio driver is loaded, at
 
 Right.  At this point, unit numbers are only partly used.  I think they are
 used by sio0 to talk to the BIOS and there is a numerical unit number 0 or
 1 to talk to the BIOS on COM1 (or whatever is configured), but this is a
 bug -- the BIOS is limited to 9600 bps but everyone/everything should use
 115200 bps or larger.  Then in boot2, there is only an i/o port address to
 select the port, and 115200 bps has always been supported.
 
 > which point it reassigns all the ports based on ACPI and device.hints and the 
 > two changes to device.hints above will take effect, yes?
 
 Not quite.  The sio driver first initializes the low-level parts of
 the console driver (if the console is on sio) using device.hints, and
 some other subsystems and/or drivers print messages on the console.
 At this point, the unit number is only used to associate the hint for
 sio.N's flags with the hint for sio.N's port.  Eventually the ACPI
 subsystem runs and sets up a different association.  ACPI also uses
 the console to print messages about itself (ACPI).  Some time later, the
 sio driver initializes high-level parts of itself including high-level
 parts of the console driver.  This gives an inconsistency because the
 ACPI unit number association is different and the difference is not
 detected or fixed up.  The high-level parts are not used at this point,
 and sio uses the console driver uses itself to print messages about
 itself (including the console part of itself).  Next, other subsystems
 and drivers print messages on the low-level console.  Eventually, the
 high-level console is used and i/o to it will go to an inconsistent
 plays if ACPI disagrees with device.hints about the unit numbers.
 Changes to device.hints take effect in the first step by avoiding
 inconsistencies later, but the effects of the inconsistencies are not
 visible until the last step.
 
 >>> 4. There should be no ill effect from doing this.  Console will never 
 >>> break
 >>> and go to the wrong port.
 >> 
 >> Yes, "should be".  The wiring should be fairly deterministic once you
 >> get it to work.  I think it will continue to work even if someone fixes
 >> (?) ACPI to prefer the hints order to the ACPI order.  However, it would
 >> break if someone fixes (?) ACPI to prefer the BIOS order to both the hints
 >> order and the ACPI order (I think ACPI is using its own order and doesn't
 >> know that you've swapped the order in the BIOS).
 >
 > I'm not sure I understand the difference.  The ACPI order is the order that 
 > the BIOS presents them in when querying it via ACPI, yes?
 
 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.
 
 Bruce