Bug 25213
| Summary: | Bus abstraction interface doesn't allow physical device addresses | ||
|---|---|---|---|
| Product: | Base System | Reporter: | peter.jeremy <peter.jeremy> |
| Component: | kern | Assignee: | Andre Oppermann <andre> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 5.0-CURRENT | ||
| Hardware: | Any | ||
| OS: | Any | ||
Responsible Changed From-To: freebsd-bugs->peter This bug isn't going to go anywhere until it gets assigned to somebody who might know how to reasonably evaluate it. Doug Rabson is one such person. So is Peter Wemm. So, I'll punt it to Peter, who might very irritably punt it to someone else. But having it sit 9 months is silly. Peter, is this still a problem? I remember some hacks around this issue which had to be done for sparc64 or so. -- Andre State Changed From-To: open->feedback Idle for too long. Asking Originator if problem still exists. Responsible Changed From-To: peter->andre Idle for too long. Asking Originator if problem still exists. On Sat, Dec 27, 2003 at 04:34:22PM +0100, Andre Oppermann wrote:
>is this still a problem? I remember some hacks around this
>issue which had to be done for sparc64 or so.
Not for the specific situation I described (getting TGA working on an
Alpha). The Alpha code has been changed to do all I/O via the SRM
console I/O functions until syscons probe/attach is complete. (I
suspect this is what was done for sparc64 as well).
AFAIK, there's no general solution and there is still an issue with
i386 relying on potential console devices being found at magic
addresses. The above hack is not totally compatible with legacy-free
PCs but it's not clear that the 'use the firmware console I/O
functions' approach is compatible with PC BIOS either.
I wouldn't object to this PR being closed but suggest you check with
(eg) peter@ and see if this PR is wanted as a placeholder for the
general issue. (I suspect not since there's nothing in the history).
Peter
Peter (Wemm),
What is your take on this? Is it ok to close the PR or do you want
to keep it?
--
Andre
Peter Jeremy wrote:
>
> On Sat, Dec 27, 2003 at 04:34:22PM +0100, Andre Oppermann wrote:
> >is this still a problem? I remember some hacks around this
> >issue which had to be done for sparc64 or so.
>
> Not for the specific situation I described (getting TGA working on an
> Alpha). The Alpha code has been changed to do all I/O via the SRM
> console I/O functions until syscons probe/attach is complete. (I
> suspect this is what was done for sparc64 as well).
>
> AFAIK, there's no general solution and there is still an issue with
> i386 relying on potential console devices being found at magic
> addresses. The above hack is not totally compatible with legacy-free
> PCs but it's not clear that the 'use the firmware console I/O
> functions' approach is compatible with PC BIOS either.
>
> I wouldn't object to this PR being closed but suggest you check with
> (eg) peter@ and see if this PR is wanted as a placeholder for the
> general issue. (I suspect not since there's nothing in the history).
>
> Peter
State Changed From-To: feedback->closed No feedback from Peter Wemm. Closing PR according to suggestion from Peter Jeremy. |
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. Fix: Unknown. How-To-Repeat: Create a -CURRENT driver for a system console that is located at an arbitrary PCI location.