From jeremyp@gsmx07.alcatel.com.au  Mon Feb 19 13:42:22 2001
Return-Path: <jeremyp@gsmx07.alcatel.com.au>
Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27])
	by hub.freebsd.org (Postfix) with ESMTP id A788C37B491
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 19 Feb 2001 13:42:19 -0800 (PST)
Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1])
	by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id IAA11992
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 20 Feb 2001 08:42:12 +1100 (EDT)
Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au
 (PMDF V5.2-32 #37645) with ESMTP id <01K0BSCVTLZ4O2JOE7@cim.alcatel.com.au>
 for FreeBSD-gnats-submit@freebsd.org; Tue, 20 Feb 2001 08:42:00 +1100
Received: (from jeremyp@localhost)	by gsmx07.alcatel.com.au (8.11.1/8.11.1)
 id f1JLg6m96100; Tue, 20 Feb 2001 08:42:06 +1100 (EST envelope-from jeremyp)
Message-Id: <200102192142.f1JLg6m96100@gsmx07.alcatel.com.au>
Date: Tue, 20 Feb 2001 08:42:06 +1100 (EST)
From: peter.jeremy@alcatel.com.au
Reply-To: peter.jeremy@alcatel.com.au
To: FreeBSD-gnats-submit@freebsd.org
Subject: Bus abstraction interface doesn't allow physical device addresses
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         25213
>Category:       kern
>Synopsis:       Bus abstraction interface doesn't allow physical device addresses
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    andre
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Feb 19 13:50:01 PST 2001
>Closed-Date:    Thu Jan 15 05:08:07 PST 2004
>Last-Modified:  Thu Jan 15 05:08:07 PST 2004
>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:
Responsible-Changed-From-To: freebsd-bugs->peter 
Responsible-Changed-By: mjacob 
Responsible-Changed-When: Mon Oct 1 21:59:35 PDT 2001 
Responsible-Changed-Why:  
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. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=25213 
State-Changed-From-To: open->feedback 
State-Changed-By: andre 
State-Changed-When: Sat Dec 27 07:36:13 PST 2003 
State-Changed-Why:  
Idle for too long.  Asking Originator if problem still exists. 


Responsible-Changed-From-To: peter->andre 
Responsible-Changed-By: andre 
Responsible-Changed-When: Sat Dec 27 07:36:13 PST 2003 
Responsible-Changed-Why:  
Idle for too long.  Asking Originator if problem still exists. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=25213 

From: Andre Oppermann <andre@freebsd.org>
To: freebsd-gnats-submit@FreeBSD.org, peter.jeremy@alcatel.com.au
Cc:  
Subject: Re: kern/25213: Bus abstraction interface doesn't allow physical
 device addresses
Date: Sat, 27 Dec 2003 16:34:22 +0100

 Peter,
 
 is this still a problem?  I remember some hacks around this
 issue which had to be done for sparc64 or so.
 
 -- 
 Andre
 
 

From: Peter Jeremy <PeterJeremy@optushome.com.au>
To: Andre Oppermann <andre@FreeBSD.org>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/25213: Bus abstraction interface doesn't allow physical device addresses
Date: Tue, 30 Dec 2003 12:14:41 +1100

 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

From: Andre Oppermann <andre@freebsd.org>
To: peter@freebsd.org
Cc: Peter Jeremy <PeterJeremy@optushome.com.au>,
	freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/25213: Bus abstraction interface doesn't allow physical device 
 addresses
Date: Tue, 30 Dec 2003 11:54:42 +0100

 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 
State-Changed-By: andre 
State-Changed-When: Thu Jan 15 05:07:17 PST 2004 
State-Changed-Why:  
No feedback from Peter Wemm.  Closing PR according to suggestion 
from Peter Jeremy. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=25213 
>Unformatted:
