Date: Sat, 5 Aug 2006 02:20:12 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Warner Losh <imp@bsdimp.com> Cc: jrhett@svcolo.com, freebsd-gnats-submit@freebsd.org, nate@root.org, freebsd-i386@freebsd.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered Message-ID: <20060805005106.I97912@delplex.bde.org> In-Reply-To: <20060803.152816.112545225.imp@bsdimp.com> References: <44D151DF.10000@root.org> <20060803.111243.74675763.imp@bsdimp.com> <4D601BDF-4D76-43CB-A565-30837492E3DE@xcllnt.net> <20060803.152816.112545225.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 3 Aug 2006, Warner Losh wrote:
>> On Aug 3, 2006, at 10:12 AM, Warner Losh wrote:
[Warner Losh didn't write:]
>> Like I said before: hints are abused for way too many purposes.
>> It's better to come up with a new scheme where you clearly separate
>> the different functions we're looking for and design *as many*
>> different mechanisms to implement these functions.
>
> The only thing that's not well suited for hints is the 'what is my
> console' function. The others can be made to work well with only a
Hints are actually almost perfectly suited to specifying the console,
though not for other things. This is because the console wiring must
be decided early so whatever specifies the wiring must be simple and
non-ambiguous. Then whatever wiring is used for the console must be
respected by more general wiring in ACPI etc. It doesn't matter much
whether the console wiring is determined by hints that are actually
"forces" or by "forces" that have to have precedence over other wiring
possibilities later. It is just clearer for hints to never be forces.
> few engineering compromises :-). I'll agree that the flags in sio
> used to specify which UNIT is the console is lame and should be
> replaced with a generalization of the uart method.
I'll disagree with this. The flags actually work almost perfectly
for specifying which physical device is the console, but not for other
things. This is again because the console wiring must be decided
early, etc., and because the unit number is mostly used only to
correlate the hint that specifies flags with the hint that specifies
the i/o port address. Low-level consoles are associated in this way
with the i/o port address, and work because the unit number is only
used in similar ways at a low level (it used to be an index, but is
now more like a cookie, and it still works at low levels because the
cookie is always the same although it is different from the high-level
logical unit number in broken cases).
Problems occur if ACPI etc., associates a different unit number with
the i/o port address being used for the console. High-level sio
probe/attach matches on the port address to avoid problems, but a
critical part of high-level console attachment happens too early, and
sio neither detects nor fixes up the problem. uart fixes up the problem
using a partially delayed attachment ("Yedi trick"). This helps a bit
for consoles but has no effect for non-consoles. Even for consoles,
non-console flags don't work when the unit numbers are inconsistently
chosen -- all flags remain on the original unit number where they
probably no longer apply since flags are more associated with port
addresses than with logical unit numbers; the flags for sio consoles
have almost no effect when they are on a wrong unit (they are just
printed in the boot messages), but the flags for non-consoles on
any device are misapplied.
>> One approach would be to make ACPI unconditional, as it's there
>> to describe the existence of legacy devices and thus serves the
>> same purpose as our current hints and define hints to *only*
>> allow wiring down hardware to unit numbers. These can be called
>> hints because I'm sure we can not always guarantee it.
>
> ACPI unconditional can't happen. There are many machines being made
> today that simply do not implement ACPI. I have several boards at
> work that implement PNPBIOS, but don't implement ACPI. These are
> boards that are brand new. I think ACPI is an extra cost option, but
I thought that the idea was to use ACPI's configuration format even if
the BIOS doesn't support it.
>> Marking devices as special, like the sio flags is an entirely
>> different function alltogether and should therefore not be done
>> with the same hints. That would just create the convolution, so
>> you create different hints for that.
>
> Agreed. However, the sio flags to designate a unit as console is the
> only thing that doesn't fit well with hints, as presently implemented.
> It should really be something like: console.type={serial,video}
> console.location=<io=xxx,mem=yyy>
>
> so that would could use a video card not mapped to the default address
> as the console, etc. It would be up to the driver at attach time to
> look at the available console meta-information to see if this driver
> matches that information. Then it wouldn't matter for a serial
> console point of view what driver unit is assigned. It might matter
> for other reasons...
Marcel wrote in a reply:
% This is exactly what I implemented for uart(4). As long as the I/O
% location used by the low-level console is actually being "found"
% during bus-enumeration and the right driver is being attached,
% then you always have a working console for going to single-user
% mode. Not to mention that the firmware typically exports console
% information in terms of I/O location (see DIG64 HCDP or Microsoft
% SPCR), so you can trivially use that too (see for a real example
% src/sys/dev/uart/uart_cpu_ia64.c).
sio mostly uses the i/o location too.
Something higher-level should really be used. The firmware may decide
to put the location in a different place on each boot. Memory mapped
i/o locations tend to change when new hardware is added. It takes
something like a dummy boot and reading the boot messages just to see
where things moved to.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060805005106.I97912>