Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Oct 2009 20:53:38 +0200
From:      Marius Strobl <marius@alchemy.franken.de>
To:        "M. Warner Losh" <imp@bsdimp.com>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, xcllnt@mac.com, src-committers@freebsd.org
Subject:   Re: svn commit: r197969 - head/sys/conf
Message-ID:  <20091014185338.GA26673@alchemy.franken.de>
In-Reply-To: <20091013.223459.-957891176.imp@bsdimp.com>
References:  <2E290D8D-BAF0-4E4E-A352-B00FAFD9DF83@mac.com> <20091013.180620.-1542634329.imp@bsdimp.com> <EC2B1366-67F5-4021-A5A0-040D035ADD6C@mac.com> <20091013.223459.-957891176.imp@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 13, 2009 at 10:34:59PM -0600, M. Warner Losh wrote:
> In message: <EC2B1366-67F5-4021-A5A0-040D035ADD6C@mac.com>
>             Marcel Moolenaar <xcllnt@mac.com> writes:
> : 
> : On Oct 13, 2009, at 5:06 PM, M. Warner Losh wrote:
> : 
> : > In message: <2E290D8D-BAF0-4E4E-A352-B00FAFD9DF83@mac.com>
> : >            Marcel Moolenaar <xcllnt@mac.com> writes:
> : > :
> : > : On Oct 13, 2009, at 10:32 AM, M. Warner Losh wrote:
> : > : > : > Why?  They should be scanned for on any system with a real isa
> : > : > bus...
> : > : > :
> : > : > : Other than i386, those are?
> : > : >
> : > : > So other than i386 and amd64, what systems use the isa device?
> : > :
> : > : I interpret the lack of answer as: none.
> : > :
> : > : isa(4) is usable on various architectures where the southbridge
> : > : contains a LPC or similar. The MPC8555 CDS, for example, has a
> : > : VIA southbridge that we need to talk to in order to get to the
> : > : ATPIC for dealing with the nested interrupt. isa(4) is the device
> : > : for this, but isaorm is causing kernel panics simply because
> : > : the memory between 0xC0000 and 0x100000 is not reserved for ISA
> : > : option ROMs. Likewise for Itanium, sparc64, etc...
> : >
> : > Does this mean that the memory cycles on the I/O bus isn't supported
> : > for these architectures?
> : 
> : Correct.
> 
> Sparc64 doesn't have an ISA bus at all.  Hmmm, NetBSD doesn't
> implement it, but it looks like we have ofw_isa that does implement
> it.  It looks like NetBSD implements all the ISA bus devices we have
> as ebus devices.  Not sure which is more correct, but it is clear from
> reading the sparc64 isa.c that it does unnatural acts to convince the
> rest of the system there's really an ISA bus there.  It looks to have
> memory ranges decoded form the ofw description.  It isn't clear to me
> if these are additional devices that NetBSD doesn't support that hang
> off a PCI-ISA bridge (in which case I'd imagine the memory cycles are
> passed down), or if they are on what NetBSD calls the ebus.

The EBus is a bus designed to be electrically compatible with
ISA devices so ISA Super I/O, sound chips etc can be used for 
on-board I/O purposes, but otherwise is a different beast with
proper DMA engines etc. It's a rather old bus already found as
SBus-EBus bridges in pre-sun4u and machines, PCI-EBus bridges
in old sun4u machines and JBus(i.e. host)-EBus brides in current
sun4u and sun4v machines.
The ISA busses found in sun4u and sun4v machines actually are
LPC beneath a PCI-ISA bridge as these machines use ordinary
PC-southbridges.
NetBSD treating ISA devices as EBus ones probably is just a
quick hack (which also involves turning I/O resources into
memory ones). Why they chose to leave it implemented like that
is beyond me, especially since thesy also have proper MI OFW
ISA code. Lack thereof and lack of easy expandibilty of isa(4)
at least is the reason why in FreeBSD ofw_isa.c does unnatural
things to fake PNP information.

> However,
> given the limited activity in the sparc64 port, I'm not sure a lot of
> work here is warranted.  We've been scanning orm on this architecture
> for a long time, and haven't had reports of crashes.

It would be really great if FreeBSD would distinguish between
LPC and real ISA so things like the ISAPNP code and ISA bus
front-ends of ATA, network and SCSI drivers etc wouldn't be
compliled into kernels for architectures that just have no
use for these as they have LPC but no ISA slots, but the lack
of activity in ISA driver development probably doesn't
warrant fixing this.

Marius




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091014185338.GA26673>