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>