i386/100831: sio ignores BIOS information about serial ports -
bde at zeta.org.au
Wed Aug 2 19:40:20 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 -
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
>> 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
>> 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
> 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
>>> 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.
More information about the freebsd-i386