Date: Tue, 20 Feb 2001 08:42:06 +1100 (EST) From: peter.jeremy@alcatel.com.au To: FreeBSD-gnats-submit@freebsd.org Subject: kern/25213: Bus abstraction interface doesn't allow physical device addresses Message-ID: <200102192142.f1JLg6m96100@gsmx07.alcatel.com.au>
next in thread | raw e-mail | index | archive | help
>Number: 25213
>Category: kern
>Synopsis: Bus abstraction interface doesn't allow physical device addresses
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Mon Feb 19 13:50:01 PST 2001
>Closed-Date:
>Last-Modified:
>Originator: Peter Jeremy
>Release: FreeBSD 5.0-CURRENT alpha
>Organization:
Alcatel Australia Limited
>Environment:
System:
FreeBSD multia.alcatel.com.au 5.0-CURRENT FreeBSD 5.0-CURRENT #4: Fri Feb 9 20:26:31 EST 2001 root@:/usr/obj/usr/src/sys/multia alpha
>Description:
This is not so much a software bug as a design bug, but there's
no class for the latter.
The existing bus abstraction interface does not provide any
mechanism to access a device by a `physical' address (bus type,
location on bus).
During early kernel initialisation, it is necessary to switch
from the firmware (BIOS/SRM/...) console to the FreeBSD console
(typically syscons). This switch currently occurs very early
in the kernel startup - well before device probing has occurred.
Typically, the firmware will provide the kernel with the console
device location as a physical location (eg PCI bus, bus number,
slot number, function).
In -STABLE, this access is possible (for the PCI bus) using
pci_cfg{read,write}(), and (on the Alpha)
pci_cvt_to_{sparse,dense}(). Following the re-organisation
of device access in -CURRENT, these interfaces are no longer
implemented (though there are still prototypes for the
pci_cvt_to_{sparse,dense}() functions).
The bus abstraction interface implemented in -CURRENT has no
mechanism to provide access via an address in a `physical' format.
Instead, the interface relies on access via a bus hierarchy
starting at (what used to be) nexus. This interface cannot be
used during system console initialisation for two reasons:
Firstly, the device probing has not yet occurred so the necessary
device_t information is not available. Secondly, the firmware
provides the address in a physical format which cannot be easily
translated into a device_t.
Currently, FreeBSD in the i386 and Alpha supports two console
types - serial and VGA. (I'm not sure how the ia64, Sun and
PPC consoles work). In both cases, the console initialisation
is achieved via a hack: The VGA console is assumed to be at
a fixed address on the ISA bus. A serial console must also
be at a known address on the ISA bus and is identified via a
hints flag. On an i386, no firmware console information is
used. On the Alpha, only the serial or graphical information
is used. The actual console location is ignored.
I identified this problem whilst trying to port a TGA console
driver to -CURRENT. (The TGA is a PCI only device and hence
does not have any known fixed addresses that can be hard-coded
into the driver). Whilst my particular problem is Alpha-
specific, there is a general problem with trying to create new
console types.
>How-To-Repeat:
Create a -CURRENT driver for a system console that is located
at an arbitrary PCI location.
>Fix:
Unknown.
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102192142.f1JLg6m96100>