svn commit: r197969 - head/sys/conf
Author: marcel Date: Sun Oct 11 20:42:26 2009 New Revision: 197969 URL: http://svn.freebsd.org/changeset/base/197969 Log: Scan for option ROMs on i386 and amd64 only. Modified: head/sys/conf/files head/sys/conf/files.amd64 head/sys/conf/files.i386 Modified: head/sys/conf/files == --- head/sys/conf/files Sun Oct 11 20:19:45 2009(r197968) +++ head/sys/conf/files Sun Oct 11 20:42:26 2009(r197969) @@ -1919,7 +1919,6 @@ gnu/fs/reiserfs/reiserfs_vnops.c optiona isa/isa_if.m standard isa/isa_common.c optional isa isa/isahint.c optional isa -isa/orm.c optional isa isa/pnp.c optional isa isapnp isa/pnpparse.c optional isa isapnp fs/cd9660/cd9660_bmap.coptional cd9660 Modified: head/sys/conf/files.amd64 == --- head/sys/conf/files.amd64 Sun Oct 11 20:19:45 2009(r197968) +++ head/sys/conf/files.amd64 Sun Oct 11 20:42:26 2009(r197969) @@ -228,6 +228,7 @@ dev/syscons/scvtb.c optionalsc dev/uart/uart_cpu_amd64.c optionaluart dev/wpi/if_wpi.c optionalwpi isa/atrtc.cstandard +isa/orm.c optionalisa isa/syscons_isa.c optionalsc isa/vga_isa.c optionalvga kern/link_elf_obj.cstandard Modified: head/sys/conf/files.i386 == --- head/sys/conf/files.i386Sun Oct 11 20:19:45 2009(r197968) +++ head/sys/conf/files.i386Sun Oct 11 20:42:26 2009(r197969) @@ -362,6 +362,7 @@ i386/svr4/svr4_locore.s optional compat i386/svr4/svr4_machdep.c optional compat_svr4 # isa/atrtc.coptional atpic +isa/orm.c optional isa isa/syscons_isa.c optional sc isa/vga_isa.c optional vga kern/imgact_aout.c optional compat_aout ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197969 - head/sys/conf
In message: <200910112042.n9bkgrcq029...@svn.freebsd.org> Marcel Moolenaar writes: : Author: marcel : Date: Sun Oct 11 20:42:26 2009 : New Revision: 197969 : URL: http://svn.freebsd.org/changeset/base/197969 : : Log: : Scan for option ROMs on i386 and amd64 only. Why? They should be scanned for on any system with a real isa bus... Warner : Modified: : head/sys/conf/files : head/sys/conf/files.amd64 : head/sys/conf/files.i386 : : Modified: head/sys/conf/files : == : --- head/sys/conf/files Sun Oct 11 20:19:45 2009(r197968) : +++ head/sys/conf/files Sun Oct 11 20:42:26 2009(r197969) : @@ -1919,7 +1919,6 @@ gnu/fs/reiserfs/reiserfs_vnops.coptiona : isa/isa_if.m standard : isa/isa_common.c optional isa : isa/isahint.coptional isa : -isa/orm.coptional isa : isa/pnp.coptional isa isapnp : isa/pnpparse.c optional isa isapnp : fs/cd9660/cd9660_bmap.c optional cd9660 : : Modified: head/sys/conf/files.amd64 : == : --- head/sys/conf/files.amd64 Sun Oct 11 20:19:45 2009(r197968) : +++ head/sys/conf/files.amd64 Sun Oct 11 20:42:26 2009(r197969) : @@ -228,6 +228,7 @@ dev/syscons/scvtb.c optionalsc : dev/uart/uart_cpu_amd64.coptionaluart : dev/wpi/if_wpi.c optionalwpi : isa/atrtc.c standard : +isa/orm.coptionalisa : isa/syscons_isa.coptionalsc : isa/vga_isa.coptionalvga : kern/link_elf_obj.c standard : : Modified: head/sys/conf/files.i386 : == : --- head/sys/conf/files.i386 Sun Oct 11 20:19:45 2009(r197968) : +++ head/sys/conf/files.i386 Sun Oct 11 20:42:26 2009(r197969) : @@ -362,6 +362,7 @@ i386/svr4/svr4_locore.s optional compat : i386/svr4/svr4_machdep.c optional compat_svr4 : # : isa/atrtc.c optional atpic : +isa/orm.coptional isa : isa/syscons_isa.coptional sc : isa/vga_isa.coptional vga : kern/imgact_aout.c optional compat_aout : ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197969 - head/sys/conf
On Oct 12, 2009, at 10:22 PM, M. Warner Losh wrote: In message: <200910112042.n9bkgrcq029...@svn.freebsd.org> Marcel Moolenaar writes: : Author: marcel : Date: Sun Oct 11 20:42:26 2009 : New Revision: 197969 : URL: http://svn.freebsd.org/changeset/base/197969 : : Log: : Scan for option ROMs on i386 and amd64 only. Why? They should be scanned for on any system with a real isa bus... Other than i386, those are? -- Marcel Moolenaar xcl...@mac.com ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197969 - head/sys/conf
On Tue, Oct 13, 2009 at 08:59:42AM -0700, Marcel Moolenaar wrote: > > On Oct 12, 2009, at 10:22 PM, M. Warner Losh wrote: > > > In message: <200910112042.n9bkgrcq029...@svn.freebsd.org> > >Marcel Moolenaar writes: > > : Author: marcel > > : Date: Sun Oct 11 20:42:26 2009 > > : New Revision: 197969 > > : URL: http://svn.freebsd.org/changeset/base/197969 > > : > > : Log: > > : Scan for option ROMs on i386 and amd64 only. > > > > Why? They should be scanned for on any system with a real isa bus... > > Other than i386, those are? Well, I know that there were machines using Alpha and PowerPC processors (and MIPS, and PA-RISC, and ...) that provided real (E)ISA-slots. Those might not count though since recent releases of FreeBSD have dropped support for Alpha, and the relevant PowerPC (etc.) machines have probably never been supported by FreeBSD. For machines that are currently supported by FreeBSD and which provides ISA-slots it is probably only the i386 architecture that qualifies. (There might also be some motherboard out there that has ISA-slots and supports amd64-capable CPUs but one will have to look fairly hard to find one.) -- Erik Trulsson ertr1...@student.uu.se ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197969 - head/sys/conf
On Tue, 13 Oct 2009, Erik Trulsson wrote: ET> (There might also be some motherboard out there that has ISA-slots and ET> supports amd64-capable CPUs but one will have to look fairly hard to find ET> one.) Oh, I would love to see at least a photo of such a beast ;-) (As for my experience, the highest CPU on a mobo with [E]ISA slots were Intel Pentium, or similar AMD K6) ;-P -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197969 - head/sys/conf
On Tuesday 13 October 2009 04:42 pm, Dmitry Morozovsky wrote: > On Tue, 13 Oct 2009, Erik Trulsson wrote: > > ET> (There might also be some motherboard out there that has > ISA-slots and ET> supports amd64-capable CPUs but one will have to > look fairly hard to find ET> one.) > > Oh, I would love to see at least a photo of such a beast ;-) > > (As for my experience, the highest CPU on a mobo with [E]ISA slots > were Intel Pentium, or similar AMD K6) Physical ISA slots on motherboard may be hard to find item these days but PCI-to-ISA bridge boards exist and should work on any architecture, at least theoretically. :-) Jung-uk Kim ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197969 - head/sys/conf
In message: Marcel Moolenaar writes: : : On Oct 12, 2009, at 10:22 PM, M. Warner Losh wrote: : : > In message: <200910112042.n9bkgrcq029...@svn.freebsd.org> : >Marcel Moolenaar writes: : > : Author: marcel : > : Date: Sun Oct 11 20:42:26 2009 : > : New Revision: 197969 : > : URL: http://svn.freebsd.org/changeset/base/197969 : > : : > : Log: : > : Scan for option ROMs on i386 and amd64 only. : > : > 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? Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197969 - head/sys/conf
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 0xC and 0x10 is not reserved for ISA option ROMs. Likewise for Itanium, sparc64, etc... In short: scanning for option ROMs is not possible in all cases where ISA compatibility is provided. -- Marcel Moolenaar xcl...@mac.com ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197969 - head/sys/conf
On Wed, Oct 14, 2009 at 12:42:19AM +0400, Dmitry Morozovsky wrote:
> On Tue, 13 Oct 2009, Erik Trulsson wrote:
>
> ET> (There might also be some motherboard out there that has ISA-slots and
> ET> supports amd64-capable CPUs but one will have to look fairly hard to find
> ET> one.)
>
> Oh, I would love to see at least a photo of such a beast ;-)
Turned out to Actually be surprisingly easy to find with Google. Take a good
look:
http://www.ibase.com.tw/2009/mb945.htmL
That motherboard supports modern Core2{Quad,Duo} CPUs and has an ISA-slot.
>
> (As for my experience, the highest CPU on a mobo with [E]ISA slots were Intel
> Pentium, or similar AMD K6)
The most modern mainboard with an ISA-slot that I have actually held in my own
hands supports dual Pentium-III (Socket 370) CPUs.
I know that there also exist mainboards for Pentium-4 (Socket 478) and
Athlon (Socket A) CPUs that have ISA-slots.
--
Erik Trulsson
ertr1...@student.uu.se
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197969 - head/sys/conf
On Wed, 14 Oct 2009, Erik Trulsson wrote:
ET> > ET> (There might also be some motherboard out there that has ISA-slots
and
ET> > ET> supports amd64-capable CPUs but one will have to look fairly hard to
find
ET> > ET> one.)
ET> >
ET> > Oh, I would love to see at least a photo of such a beast ;-)
ET>
ET> Turned out to Actually be surprisingly easy to find with Google. Take a
good look:
ET>
ET> http://www.ibase.com.tw/2009/mb945.htmL
ET>
ET> That motherboard supports modern Core2{Quad,Duo} CPUs and has an ISA-slot.
Yes, embedded/industrial needs are quite different from usual/casual; I totally
forgot about these areas.
ET> > (As for my experience, the highest CPU on a mobo with [E]ISA slots were
Intel
ET> > Pentium, or similar AMD K6)
ET>
ET> The most modern mainboard with an ISA-slot that I have actually held in my
own
ET> hands supports dual Pentium-III (Socket 370) CPUs.
ET>
ET> I know that there also exist mainboards for Pentium-4 (Socket 478) and
ET> Athlon (Socket A) CPUs that have ISA-slots.
Well, there avoid me; however, I vaguely remember i686 (aka PentiumPro[tm])
servers with EISA in our colleagues' office back in late 90's...
--
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer: ma...@freebsd.org ]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru ***
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197969 - head/sys/conf
In message: <2e290d8d-baf0-4e4e-a352-b00fafd9d...@mac.com> Marcel Moolenaar 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 0xC and 0x10 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? Or that it is and we just don't implement it in the platform specific interfaces for it? The memory space is reserved for any system that has a ISA bus, but it might not be at physical address 0xc, etc. : In short: scanning for option ROMs is not possible in all cases : where ISA compatibility is provided. Why is that? The platform specific code needs to implement the necessary hooks to support this. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197969 - head/sys/conf
In message: Dmitry Morozovsky writes: : On Tue, 13 Oct 2009, Erik Trulsson wrote: : : ET> (There might also be some motherboard out there that has ISA-slots and : ET> supports amd64-capable CPUs but one will have to look fairly hard to find : ET> one.) : : Oh, I would love to see at least a photo of such a beast ;-) : : (As for my experience, the highest CPU on a mobo with [E]ISA slots were Intel : Pentium, or similar AMD K6) I have a MIPS-base PC that has EISA slots on it... Deskstation rPC44 with a R4400PC CPU... There's a number of ARM boards that have PC-104 expansion bus as well. The Cirrus logic boards from embeddedarm.com are but one example. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197969 - head/sys/conf
In message: <200910131703.50700.j...@freebsd.org> Jung-uk Kim writes: : On Tuesday 13 October 2009 04:42 pm, Dmitry Morozovsky wrote: : > On Tue, 13 Oct 2009, Erik Trulsson wrote: : > : > ET> (There might also be some motherboard out there that has : > ISA-slots and ET> supports amd64-capable CPUs but one will have to : > look fairly hard to find ET> one.) : > : > Oh, I would love to see at least a photo of such a beast ;-) : > : > (As for my experience, the highest CPU on a mobo with [E]ISA slots : > were Intel Pentium, or similar AMD K6) : : Physical ISA slots on motherboard may be hard to find item these days : but PCI-to-ISA bridge boards exist and should work on any : architecture, at least theoretically. :-) The code in question is scannign for expansion ROMs on a ISA connected card. These ROMs are x86 code, but that's not relevant to the scanning of the bus for them since the card will decode those memory ranges even if the host CPU can't execute the code. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197969 - head/sys/conf
On Oct 13, 2009, at 5:06 PM, M. Warner Losh wrote: In message: <2e290d8d-baf0-4e4e-a352-b00fafd9d...@mac.com> Marcel Moolenaar 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 0xC and 0x10 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. Or that it is and we just don't implement it in the platform specific interfaces for it? No. The memory space is reserved for any system that has a ISA bus, but it might not be at physical address 0xc, etc. It's uncommon to have an actual ISA bus and even more uncommon that the option ROM is actually being used. : In short: scanning for option ROMs is not possible in all cases : where ISA compatibility is provided. Why is that? The platform specific code needs to implement the necessary hooks to support this. There are no hooks to implement. If there is any FreeBSD supported board that actually needs to have the option ROMs scanned by orm(4), then we can always make it conditional upon ``device isa_orm''. Making it dependent on isa(4) is causing real problems and my change limits the use of orm(4) to platforms where it can possibly have any chance of being useful -- provided orm(4) is changed to do something useful. -- Marcel Moolenaar xcl...@mac.com ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197969 - head/sys/conf
In message: Marcel Moolenaar writes: : : On Oct 13, 2009, at 5:06 PM, M. Warner Losh wrote: : : > In message: <2e290d8d-baf0-4e4e-a352-b00fafd9d...@mac.com> : >Marcel Moolenaar 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 0xC and 0x10 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. Then it isn't an ISA bus. : > Or that it is and we just don't implement it : > in the platform specific interfaces for it? : : No. Then they aren't real ISA buses. : > The memory space is : > reserved for any system that has a ISA bus, but it might not be at : > physical address 0xc, etc. : : It's uncommon to have an actual ISA bus and even more uncommon : that the option ROM is actually being used. ISA memory ranges are quite common on actual cards. : > : In short: scanning for option ROMs is not possible in all cases : > : where ISA compatibility is provided. : > : > Why is that? The platform specific code needs to implement the : > necessary hooks to support this. : : There are no hooks to implement. If there is any FreeBSD supported : board that actually needs to have the option ROMs scanned by orm(4), FreeBSD does support boards that need to have option ROMs scanned. Every PC made today even has them. Today they are primarily video BIOS that's being scanned. They are also on SCSI controllers and can be on network cards. FreeBSD still has support for all these devices. All PC Cards, even those in CardBus slots, need to have this functionality to avoid mapping their CIS on top of a ROM that may be there. : then we can always make it conditional upon ``device isa_orm''. Making : it dependent on isa(4) is causing real problems and my change limits : the use of orm(4) to platforms where it can possibly have any chance : of being useful -- provided orm(4) is changed to do something useful. Every system that has an ISA bus needs to have it scanned for the ROMs. It is part of the ISA specification. If there are variants that don't have any way to create memory bus cycles on the ISA bus, then we need some systemic way to cope. Remove orm is a half-assed kludge since it breaks ISA PNP boards that have memory ranges, for example. So let's fix this right, and avoid yet another kludge like the one you've committed. And this time, let's talk about the fix rather than doing a drive-by? Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197969 - head/sys/conf
In message:
Marcel Moolenaar writes:
:
: On Oct 13, 2009, at 5:06 PM, M. Warner Losh wrote:
:
: > In message: <2e290d8d-baf0-4e4e-a352-b00fafd9d...@mac.com>
: >Marcel Moolenaar 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 0xC and 0x10 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. 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.
sys/powerpc/mpc85xx/isa.c could easily reflect that there's no memory
available by failing all SYS_RES_MEMORY requests. This would properly
fix the bus to reflect reality, and would break things with a proper
message (can't allocate the memory resource on the bus). This would
move the orm problem from a crash to minor code bloat. That's a much
easier problem to solve, and won't break ARM systems that have a
PC-104 expansion bus that do support memory address cycles on the
pc-104 bus. This code isn't yet in the tree.
The itanium stuff I can't comment on, but if it is the same, then a
similar trick could be used as for powerpc.
I've included something that should be sufficient for powerpc to
behave properly.
Warner
Index: isa.c
===
--- isa.c (revision 197533)
+++ isa.c (working copy)
@@ -51,6 +51,14 @@
struct resource_list *rl = &idev->id_resources;
int isdefault, passthrough, rids;
+ /*
+* MPC85xx reference boards have most of a pseudo ISA bus, but
+* don't pass memory cycles to the cards. Fail all allocation
+* attempts to reflect this.
+*/
+ if (type == SYS_RES_MEMORY)
+ return NULL;
+
isdefault = (start == 0UL && end == ~0UL) ? 1 : 0;
passthrough = (device_get_parent(child) != bus) ? 1 : 0;
@@ -59,7 +67,6 @@
switch (type) {
case SYS_RES_IOPORT:rids = ISA_PNP_NPORT; break;
case SYS_RES_IRQ: rids = ISA_PNP_NIRQ; break;
- case SYS_RES_MEMORY:rids = ISA_PNP_NMEM; break;
default:rids = 0; break;
}
if (*rid < 0 || *rid >= rids)
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197969 - head/sys/conf
On Oct 13, 2009, at 9:04 PM, M. Warner Losh wrote:
: > Does this mean that the memory cycles on the I/O bus isn't
supported
: > for these architectures?
:
: Correct.
Then it isn't an ISA bus.
Of course it isn't an ISA bus. It's all LPC. Leaving the specialized
embedded market aside, there's no point discussing real ISA busses
in the FreeBSD context. Noone cares and as long as it doesn't break
anything noone is going to put in effort to fix the code.
: There are no hooks to implement. If there is any FreeBSD supported
: board that actually needs to have the option ROMs scanned by orm(4),
FreeBSD does support boards that need to have option ROMs scanned.
orm(4) doesn't do anything with it. Other than claim the memory
region and indirectly enforce policy, there's nothing orm(4) does.
Policy should be implemented in the platform code where the knowledge
exists and it should not be done as a side-effect of a driver that
encodes the knowledge of a single platform by way of hardcoding numbers
that don't hold on other platforms.
orm(4) causes machine checks and kernel panics on PowerPC and Itanium
and none of the non-i386 hardware has any real history with ISA, so
the sensible thing is to have orm(4) be specific to PC hardware where
it has relevance. If orm(4) is actually *required* on non-PC hardware
then one only has to add the appropriate line to file.${ARCH} and it's
there.
--
Marcel Moolenaar
xcl...@mac.com
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197969 - head/sys/conf
> On Oct 13, 2009, at 9:04 PM, M. Warner Losh wrote:
> > : > Does this mean that the memory cycles on the I/O bus isn't
> > supported
> > : > for these architectures?
> > :
> > : Correct.
> >
> > Then it isn't an ISA bus.
>
> Of course it isn't an ISA bus. It's all LPC. Leaving the specialized
> embedded market aside, there's no point discussing real ISA busses
> in the FreeBSD context. Noone cares and as long as it doesn't break
> anything noone is going to put in effort to fix the code.
LPC is a real ISA bus in this context, since it passes the memory range
decodes.
Your changes to break things.
It is a kludge.
I can't be more clear than this. You keep ignoring me, and it is very
frustrating.
> > : There are no hooks to implement. If there is any FreeBSD supported
> > : board that actually needs to have the option ROMs scanned by orm(4),
> >
> > FreeBSD does support boards that need to have option ROMs scanned.
>
> orm(4) doesn't do anything with it. Other than claim the memory
> region and indirectly enforce policy, there's nothing orm(4) does.
> Policy should be implemented in the platform code where the knowledge
> exists and it should not be done as a side-effect of a driver that
> encodes the knowledge of a single platform by way of hardcoding numbers
> that don't hold on other platforms.
Please listen. orm(4) isn't the problem. The problem is that the
powerpc and itanium isa modules allow memory ranges that shouldn't be
allowed. That's the platform specific code that needs to be fixed.
> orm(4) causes machine checks and kernel panics on PowerPC and Itanium
> and none of the non-i386 hardware has any real history with ISA, so
> the sensible thing is to have orm(4) be specific to PC hardware where
> it has relevance. If orm(4) is actually *required* on non-PC hardware
> then one only has to add the appropriate line to file.${ARCH} and it's
> there.
To be pedantic: powerpc's buggy isa MD code is causing these
problems. orm(4) is just a symptom, not the disease.
Warner
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197969 - head/sys/conf
On Oct 14, 2009, at 10:39 AM, Warner Losh wrote: I can't be more clear than this. You keep ignoring me, and it is very frustrating. I'm not ignoring you. I'm still talking. You simply haven't convinced me. While it's possible (likely?) that I don't understand the issues, all you've achieved so far is that I'm more convinced that limiting orm(4) to i386 and amd64 is the right thing, because the alternative is not at all appealing. The problem is that the powerpc and itanium isa modules allow memory ranges that shouldn't be allowed. That's the platform specific code that needs to be fixed. isa_set_resource() is MI code and it happily adds whatever resources a driver wants. The only chance MD code has is to fail the allocation, but since the whole ISA code bypasses the newbus hierarchy, there's no way we know in the isa MD code what is valid and what isn't unless we add kluges to platform code. If you want to fix it for real, does that mean fix it for real or does that mean add kluges to platform code? Shouldn't we have ISA bridges obtain the set of valid resources from their parent in the newbus hierarchy? To be pedantic: powerpc's buggy isa MD code is causing these problems. orm(4) is just a symptom, not the disease. Fine, be pedantic. I eliminated the symptom. Good, now at least I'm not blocked and we can really discuss the disease and fix it. See above. -- Marcel Moolenaar xcl...@mac.com ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197969 - head/sys/conf
On Tue, Oct 13, 2009 at 10:34:59PM -0600, M. Warner Losh wrote: > In message: > Marcel Moolenaar writes: > : > : On Oct 13, 2009, at 5:06 PM, M. Warner Losh wrote: > : > : > In message: <2e290d8d-baf0-4e4e-a352-b00fafd9d...@mac.com> > : >Marcel Moolenaar 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 0xC and 0x10 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 ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197969 - head/sys/conf
On Wednesday 14 October 2009 2:35:16 pm Marcel Moolenaar wrote: > On Oct 14, 2009, at 10:39 AM, Warner Losh wrote: > > > > I can't be more clear than this. You keep ignoring me, and it is very > > frustrating. > > I'm not ignoring you. I'm still talking. You simply haven't convinced > me. While it's possible (likely?) that I don't understand the issues, > all you've achieved so far is that I'm more convinced that limiting > orm(4) to i386 and amd64 is the right thing, because the alternative > is not at all appealing. > > > The problem is that the > > powerpc and itanium isa modules allow memory ranges that shouldn't be > > allowed. That's the platform specific code that needs to be fixed. > > isa_set_resource() is MI code and it happily adds whatever resources > a driver wants. The only chance MD code has is to fail the allocation, > but since the whole ISA code bypasses the newbus hierarchy, there's > no way we know in the isa MD code what is valid and what isn't unless > we add kluges to platform code. > > If you want to fix it for real, does that mean fix it for real or > does that mean add kluges to platform code? > > Shouldn't we have ISA bridges obtain the set of valid resources > from their parent in the newbus hierarchy? Hmm, can we even know that? PCI-ISA bridges in x86 at least don't have any I/O limit registers like PCI-PCI bridges, instead they are subtractively decoded, i.e. they "eat" any memory request that no one else claims. I'm not sure if other platforms have a way of knowing this however. Are you aware of something in OFW to communicate this? ACPI does this for Host-PCI bridges via ResourceProvider() resource entries, but I've never seen ACPI do it for a PCI-ISA bridge. -- John Baldwin ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197969 - head/sys/conf
On Oct 14, 2009, at 1:45 PM, John Baldwin wrote: On Wednesday 14 October 2009 2:35:16 pm Marcel Moolenaar wrote: On Oct 14, 2009, at 10:39 AM, Warner Losh wrote: I can't be more clear than this. You keep ignoring me, and it is very frustrating. I'm not ignoring you. I'm still talking. You simply haven't convinced me. While it's possible (likely?) that I don't understand the issues, all you've achieved so far is that I'm more convinced that limiting orm(4) to i386 and amd64 is the right thing, because the alternative is not at all appealing. The problem is that the powerpc and itanium isa modules allow memory ranges that shouldn't be allowed. That's the platform specific code that needs to be fixed. isa_set_resource() is MI code and it happily adds whatever resources a driver wants. The only chance MD code has is to fail the allocation, but since the whole ISA code bypasses the newbus hierarchy, there's no way we know in the isa MD code what is valid and what isn't unless we add kluges to platform code. If you want to fix it for real, does that mean fix it for real or does that mean add kluges to platform code? Shouldn't we have ISA bridges obtain the set of valid resources from their parent in the newbus hierarchy? Hmm, can we even know that? PCI-ISA bridges in x86 at least don't have any I/O limit registers like PCI-PCI bridges, instead they are subtractively decoded, i.e. they "eat" any memory request that no one else claims. The key here being requests that reach the PCI-ISA bridge. It's entirely platform specific which I/O memory addresses generated by the CPU gets decoded and forwarded in such a way that it's visible to the PCI-ISA bridge. This is what needs to be obtained from the parent in the newbus hierarchy. Rather than hardcoding [0xC .. 0x10> as the ISA option ROM memory range, it should be something like [isa_mem_base+0xC .. isa_mem_base + 0x10> or even [isa_rom_base .. isa_rom_base + 0x4>. -- Marcel Moolenaar xcl...@mac.com ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197969 - head/sys/conf
On Wednesday 14 October 2009 5:20:38 pm Marcel Moolenaar wrote: > > On Oct 14, 2009, at 1:45 PM, John Baldwin wrote: > > > On Wednesday 14 October 2009 2:35:16 pm Marcel Moolenaar wrote: > >> On Oct 14, 2009, at 10:39 AM, Warner Losh wrote: > >>> > >>> I can't be more clear than this. You keep ignoring me, and it is > >>> very > >>> frustrating. > >> > >> I'm not ignoring you. I'm still talking. You simply haven't convinced > >> me. While it's possible (likely?) that I don't understand the issues, > >> all you've achieved so far is that I'm more convinced that limiting > >> orm(4) to i386 and amd64 is the right thing, because the alternative > >> is not at all appealing. > >> > >>> The problem is that the > >>> powerpc and itanium isa modules allow memory ranges that shouldn't > >>> be > >>> allowed. That's the platform specific code that needs to be fixed. > >> > >> isa_set_resource() is MI code and it happily adds whatever resources > >> a driver wants. The only chance MD code has is to fail the > >> allocation, > >> but since the whole ISA code bypasses the newbus hierarchy, there's > >> no way we know in the isa MD code what is valid and what isn't unless > >> we add kluges to platform code. > >> > >> If you want to fix it for real, does that mean fix it for real or > >> does that mean add kluges to platform code? > >> > >> Shouldn't we have ISA bridges obtain the set of valid resources > >> from their parent in the newbus hierarchy? > > > > Hmm, can we even know that? PCI-ISA bridges in x86 at least don't > > have any > > I/O limit registers like PCI-PCI bridges, instead they are > > subtractively > > decoded, i.e. they "eat" any memory request that no one else claims. > > The key here being requests that reach the PCI-ISA bridge. It's entirely > platform specific which I/O memory addresses generated by the CPU gets > decoded and forwarded in such a way that it's visible to the PCI-ISA > bridge. This is what needs to be obtained from the parent in the newbus > hierarchy. Rather than hardcoding [0xC .. 0x10> as the ISA > option > ROM memory range, it should be something like [isa_mem_base+0xC .. > isa_mem_base + 0x10> or even [isa_rom_base .. isa_rom_base + > 0x4>. That might certainly be a reasonable IVAR for isab(4) to provide to isa(4): a ROM base. However, orm(4) should be enabled for all ISA bridges assuming that is fixed. OTOH, the way many bus drivers I've seen handle this so far is to change the base address of SYS_RES_MEMORY objects as they pass through the relevant bridge so that the actual memory address is properly adjusted when it gets to the equivalent of the nexus. This is how many of the Foo->PCI bridges in arm that I've looked at work, and I think this is more inline with Warner's original patch which is to allow the various platform-specific ISA bridge drivers reject memory ranges they do not decode and provide any needed adjustments to ranges they do decode to transform them into suitable resources for their parent. Then orm(4) would just see it's attempts to do bus_alloc_resource() fail and end up DTRT. Given that, I do think this logic belongs in the ISA bridge drivers rather than in individual ISA drivers. We don't make ISA peripheral drivers add an 'isa_mem_base' or equivalent to their I/O resources, and in terms of I/O resources, orm(4) is just a special blackhole device (much like the ACPI or PnPBIOS system resource devices, or the ram0 or apic0 devices on x86). -- John Baldwin ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197969 - head/sys/conf
In message: <6b860a3c-c1f0-42a0-8ecb-3d41da698...@mac.com> Marcel Moolenaar writes: : : On Oct 14, 2009, at 1:45 PM, John Baldwin wrote: : : > On Wednesday 14 October 2009 2:35:16 pm Marcel Moolenaar wrote: : >> On Oct 14, 2009, at 10:39 AM, Warner Losh wrote: : >>> : >>> I can't be more clear than this. You keep ignoring me, and it is : >>> very : >>> frustrating. : >> : >> I'm not ignoring you. I'm still talking. You simply haven't convinced : >> me. While it's possible (likely?) that I don't understand the issues, : >> all you've achieved so far is that I'm more convinced that limiting : >> orm(4) to i386 and amd64 is the right thing, because the alternative : >> is not at all appealing. : >> : >>> The problem is that the : >>> powerpc and itanium isa modules allow memory ranges that shouldn't : >>> be : >>> allowed. That's the platform specific code that needs to be fixed. : >> : >> isa_set_resource() is MI code and it happily adds whatever resources : >> a driver wants. The only chance MD code has is to fail the : >> allocation, : >> but since the whole ISA code bypasses the newbus hierarchy, there's : >> no way we know in the isa MD code what is valid and what isn't unless : >> we add kluges to platform code. : >> : >> If you want to fix it for real, does that mean fix it for real or : >> does that mean add kluges to platform code? : >> : >> Shouldn't we have ISA bridges obtain the set of valid resources : >> from their parent in the newbus hierarchy? : > : > Hmm, can we even know that? PCI-ISA bridges in x86 at least don't : > have any : > I/O limit registers like PCI-PCI bridges, instead they are : > subtractively : > decoded, i.e. they "eat" any memory request that no one else claims. : : The key here being requests that reach the PCI-ISA bridge. It's entirely : platform specific which I/O memory addresses generated by the CPU gets : decoded and forwarded in such a way that it's visible to the PCI-ISA : bridge. This is what needs to be obtained from the parent in the newbus : hierarchy. Rather than hardcoding [0xC .. 0x10> as the ISA : option : ROM memory range, it should be something like [isa_mem_base+0xC .. : isa_mem_base + 0x10> or even [isa_rom_base .. isa_rom_base + : 0x4>. 0xc..0x10 is the right range of addresses to use. It is the responsibility of the bus space to translate that to whatever physical address to use. These are bus addresses, and are by definition platform independent. If other platforms map these bus addresses to other physical addresses, then it is their responsibility to map them in the bus_space layer. I think that's the primary disconnect here. The powerpc bus_space doesn't do this at all, but should for those platforms that actually implement it. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197969 - head/sys/conf
In message: <200910141738.43910@freebsd.org> John Baldwin writes: : On Wednesday 14 October 2009 5:20:38 pm Marcel Moolenaar wrote: : > : > On Oct 14, 2009, at 1:45 PM, John Baldwin wrote: : > : > > On Wednesday 14 October 2009 2:35:16 pm Marcel Moolenaar wrote: : > >> On Oct 14, 2009, at 10:39 AM, Warner Losh wrote: : > >>> : > >>> I can't be more clear than this. You keep ignoring me, and it is : > >>> very : > >>> frustrating. : > >> : > >> I'm not ignoring you. I'm still talking. You simply haven't convinced : > >> me. While it's possible (likely?) that I don't understand the issues, : > >> all you've achieved so far is that I'm more convinced that limiting : > >> orm(4) to i386 and amd64 is the right thing, because the alternative : > >> is not at all appealing. : > >> : > >>> The problem is that the : > >>> powerpc and itanium isa modules allow memory ranges that shouldn't : > >>> be : > >>> allowed. That's the platform specific code that needs to be fixed. : > >> : > >> isa_set_resource() is MI code and it happily adds whatever resources : > >> a driver wants. The only chance MD code has is to fail the : > >> allocation, : > >> but since the whole ISA code bypasses the newbus hierarchy, there's : > >> no way we know in the isa MD code what is valid and what isn't unless : > >> we add kluges to platform code. : > >> : > >> If you want to fix it for real, does that mean fix it for real or : > >> does that mean add kluges to platform code? : > >> : > >> Shouldn't we have ISA bridges obtain the set of valid resources : > >> from their parent in the newbus hierarchy? : > > : > > Hmm, can we even know that? PCI-ISA bridges in x86 at least don't : > > have any : > > I/O limit registers like PCI-PCI bridges, instead they are : > > subtractively : > > decoded, i.e. they "eat" any memory request that no one else claims. : > : > The key here being requests that reach the PCI-ISA bridge. It's entirely : > platform specific which I/O memory addresses generated by the CPU gets : > decoded and forwarded in such a way that it's visible to the PCI-ISA : > bridge. This is what needs to be obtained from the parent in the newbus : > hierarchy. Rather than hardcoding [0xC .. 0x10> as the ISA : > option : > ROM memory range, it should be something like [isa_mem_base+0xC .. : > isa_mem_base + 0x10> or even [isa_rom_base .. isa_rom_base + : > 0x4>. : : That might certainly be a reasonable IVAR for isab(4) to provide to isa(4): a : ROM base. However, orm(4) should be enabled for all ISA bridges assuming : that is fixed. OTOH, the way many bus drivers I've seen handle this so far : is to change the base address of SYS_RES_MEMORY objects as they pass through : the relevant bridge so that the actual memory address is properly adjusted : when it gets to the equivalent of the nexus. This is how many of the : Foo->PCI bridges in arm that I've looked at work, and I think this is more : inline with Warner's original patch which is to allow the various : platform-specific ISA bridge drivers reject memory ranges they do not decode : and provide any needed adjustments to ranges they do decode to transform them : into suitable resources for their parent. Then orm(4) would just see it's : attempts to do bus_alloc_resource() fail and end up DTRT. Given that, I do : think this logic belongs in the ISA bridge drivers rather than in individual : ISA drivers. We don't make ISA peripheral drivers add an 'isa_mem_base' or : equivalent to their I/O resources, and in terms of I/O resources, orm(4) is : just a special blackhole device (much like the ACPI or PnPBIOS system : resource devices, or the ram0 or apic0 devices on x86). This is exactly what I've been trying to say: the memory addresses that orm is using are ISA BUS addresses. These just happen to map 1:1 on x86, but will map to something else on other platforms. But our kernel API is that the driver requests the bus address, and that any necessary translation happen in the bus_space layer. I disagree that it belongs entirely in the isa bridge drivers. They may communicate information to the bus_space implementation, but it is bus_space that ultimately does this translation. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197969 - head/sys/conf
In message: <200910141738.43910@freebsd.org> John Baldwin writes: : On Wednesday 14 October 2009 5:20:38 pm Marcel Moolenaar wrote: : > : > On Oct 14, 2009, at 1:45 PM, John Baldwin wrote: : > : > > On Wednesday 14 October 2009 2:35:16 pm Marcel Moolenaar wrote: : > >> On Oct 14, 2009, at 10:39 AM, Warner Losh wrote: : > >>> : > >>> I can't be more clear than this. You keep ignoring me, and it is : > >>> very : > >>> frustrating. : > >> : > >> I'm not ignoring you. I'm still talking. You simply haven't convinced : > >> me. While it's possible (likely?) that I don't understand the issues, : > >> all you've achieved so far is that I'm more convinced that limiting : > >> orm(4) to i386 and amd64 is the right thing, because the alternative : > >> is not at all appealing. : > >> : > >>> The problem is that the : > >>> powerpc and itanium isa modules allow memory ranges that shouldn't : > >>> be : > >>> allowed. That's the platform specific code that needs to be fixed. : > >> : > >> isa_set_resource() is MI code and it happily adds whatever resources : > >> a driver wants. The only chance MD code has is to fail the : > >> allocation, : > >> but since the whole ISA code bypasses the newbus hierarchy, there's : > >> no way we know in the isa MD code what is valid and what isn't unless : > >> we add kluges to platform code. They aren't kludges. They are codifying the restrictions the platform has for that bus. : > >> If you want to fix it for real, does that mean fix it for real or : > >> does that mean add kluges to platform code? We add proper code to the platform code. The problem exists if you accidentally configure aha. It will probe memory. : > >> Shouldn't we have ISA bridges obtain the set of valid resources : > >> from their parent in the newbus hierarchy? We likely should have the ISA bridge create and give out a bus_space that maps the ISA bus addresses to wherever they are mapped on the host. : > > Hmm, can we even know that? PCI-ISA bridges in x86 at least don't : > > have any : > > I/O limit registers like PCI-PCI bridges, instead they are : > > subtractively : > > decoded, i.e. they "eat" any memory request that no one else claims. Correct. They always assume the default x86 mapping of the ISA bus space to physical memory. : > The key here being requests that reach the PCI-ISA bridge. It's entirely : > platform specific which I/O memory addresses generated by the CPU gets : > decoded and forwarded in such a way that it's visible to the PCI-ISA : > bridge. This is what needs to be obtained from the parent in the newbus : > hierarchy. Rather than hardcoding [0xC .. 0x10> as the ISA : > option : > ROM memory range, it should be something like [isa_mem_base+0xC .. : > isa_mem_base + 0x10> or even [isa_rom_base .. isa_rom_base + : > 0x4>. Hard coding 0xc, etc is proper here because that's not a physical address. It is an ISA bus address. This address needs to be mapped to the host memory segment at the bus_space level so that the drivers we have in the tree will work on those architectures where the mapping isn't the identity like on x86. The drivers should have no knowledge this is happening if they are using bus_space routines. That's what they exist for. : That might certainly be a reasonable IVAR for isab(4) to provide to isa(4): a : ROM base. However, orm(4) should be enabled for all ISA bridges assuming : that is fixed. OTOH, the way many bus drivers I've seen handle this so far : is to change the base address of SYS_RES_MEMORY objects as they pass through : the relevant bridge so that the actual memory address is properly adjusted : when it gets to the equivalent of the nexus. This is how many of the : Foo->PCI bridges in arm that I've looked at work, and I think this is more : inline with Warner's original patch which is to allow the various : platform-specific ISA bridge drivers reject memory ranges they do not decode : and provide any needed adjustments to ranges they do decode to transform them : into suitable resources for their parent. I think that they are done at the wrong level if they are done there. They should be done in the bus_space layer so that the driver can get the bus addresses to maybe program into pci hardware. : Then orm(4) would just see it's : attempts to do bus_alloc_resource() fail and end up DTRT. Yes and no. bus_alloc_resource would do the right thing. If the bridge driver knew that it had a private mapping, it would create an rman that had the memory ranges (in ISA memory space) that it decoded. It would then carve out allocates from this rman for any child devices that asked for it. It would return a bus_space handle that could be used by the driver and bus_space_read* to get the right thing from the memory. For x86, you couldn't implement this because the bus_space assumes one global space. On arm and mips, for example, their bus_space implementations are such that at
Re: svn commit: r197969 - head/sys/conf
On Oct 14, 2009, at 9:44 PM, M. Warner Losh wrote: This is also the source of my frustration with the thread, I think. I don't think that Marcel understood this world view and assumed that no mapping was needed and therefore orm was this horribly x86 specific code. Since I didn't understand this until today, I reacted badly and lost my temper, for which I'd like to apologize. I should have stopped and explained this view better. Apology accepted. Sorry, if I appeared frustrated as well. I can respect the PoV that the hardcoding in drivers are bus addresses. I have no problem with that. It isn't my PoV, because it doesn't match with the existence of functions like inb(), outb(), inw(), outw(), etc. The I/O port numbers passed to those functions are typically absolute due to the total lack of newbus involvement. I merely extrapolated the memory addresses as behaving in the same way. They do actually, because VGA frame buffer memory is at 0xA and part of the PCI specification and you don't want to translate that, so how does MD code know when to map and when not to? It doesn't, so the only logical interpretation is that the addresses are absolute and no mapping can be done. I don't mind changing the interpretation of I/O ports and memory addresses as being ISA bus addresses, but that means that we need to get rid off inb(), outb(), et al and use newbus through out. Until that's done (and people figure out how to deal with VGA resources) or there's a real need for orm(4), it's safest for non-PC platforms to not have orm(4) wreck havoc. -- Marcel Moolenaar xcl...@mac.com ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197969 - head/sys/conf
In message: Marcel Moolenaar writes: : : On Oct 14, 2009, at 9:44 PM, M. Warner Losh wrote: : > This is also the source of my frustration with the thread, I think. I : > don't think that Marcel understood this world view and assumed that no : > mapping was needed and therefore orm was this horribly x86 specific : > code. Since I didn't understand this until today, I reacted badly and : > lost my temper, for which I'd like to apologize. I should have : > stopped and explained this view better. : : Apology accepted. Sorry, if I appeared frustrated as well. : : I can respect the PoV that the hardcoding in drivers are bus addresses. : I have no problem with that. It isn't my PoV, because it doesn't match : with the existence of functions like inb(), outb(), inw(), outw(), etc. inb, etc, aren't part of bus_space and exist outside of it. These functions typically don't exist on !x86 platforms, and when they do they are very platform specific.. : The I/O port numbers passed to those functions are typically absolute : due to the total lack of newbus involvement. I merely extrapolated the : memory addresses as behaving in the same way. They do actually, because : VGA frame buffer memory is at 0xA and part of the PCI specification : and you don't want to translate that, so how does MD code know when to : map and when not to? It doesn't, so the only logical interpretation is : that the addresses are absolute and no mapping can be done. The PCI specification says that the frame buffer is at 0xa in the pci bus space. It doesn't say anything about how that bus space is mapped into the processor's address space (although it comments on x86's traditional mapping in many places). : I don't mind changing the interpretation of I/O ports and memory : addresses as being ISA bus addresses, but that means that we need to : get rid off inb(), outb(), et al and use newbus through out. Until : that's done (and people figure out how to deal with VGA resources) or : there's a real need for orm(4), it's safest for non-PC platforms to not : have orm(4) wreck havoc. There is a real need for orm. I'm open to ways to improve the situation without requiring the complete implementation of the ISA stuff. The reason that it does wreck havoc is because there's problems in the ISA implementation on the platforms it wrecks havoc on. You can mask these problems by removing orm. However, any other isa device that reads memory will have issues on these platforms. The VGA resource issue should be a simple one to deal with via bus_spae. This is the first time I've heard of it, frankly, so would be interested in learning more about it. We've also, as a project, have strongly encouraged drivers to move away from inb, et al, and direct memory access to using bus_space interfaces since around FreeBSD 4.0. Many drivers have been converted. I think the few stragglers were killed as part of the network modernization efforts, although some pre-ISA PNP support still uses inb/outb directly. I think I'd quibble that it is !x86. It is specific to powerpc and itanium platforms. Sparc64 handles it correctly, as does arm (at east in the projects/arm tree). I don't think that mips has any ISA support, even in the projects/mips tree. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197969 - head/sys/conf
On Wednesday 14 October 2009 6:11:15 pm M. Warner Losh wrote: > In message: <200910141738.43910@freebsd.org> > John Baldwin writes: > : On Wednesday 14 October 2009 5:20:38 pm Marcel Moolenaar wrote: > : > > : > On Oct 14, 2009, at 1:45 PM, John Baldwin wrote: > : > > : > > On Wednesday 14 October 2009 2:35:16 pm Marcel Moolenaar wrote: > : > >> On Oct 14, 2009, at 10:39 AM, Warner Losh wrote: > : > >>> > : > >>> I can't be more clear than this. You keep ignoring me, and it is > : > >>> very > : > >>> frustrating. > : > >> > : > >> I'm not ignoring you. I'm still talking. You simply haven't convinced > : > >> me. While it's possible (likely?) that I don't understand the issues, > : > >> all you've achieved so far is that I'm more convinced that limiting > : > >> orm(4) to i386 and amd64 is the right thing, because the alternative > : > >> is not at all appealing. > : > >> > : > >>> The problem is that the > : > >>> powerpc and itanium isa modules allow memory ranges that shouldn't > : > >>> be > : > >>> allowed. That's the platform specific code that needs to be fixed. > : > >> > : > >> isa_set_resource() is MI code and it happily adds whatever resources > : > >> a driver wants. The only chance MD code has is to fail the > : > >> allocation, > : > >> but since the whole ISA code bypasses the newbus hierarchy, there's > : > >> no way we know in the isa MD code what is valid and what isn't unless > : > >> we add kluges to platform code. > : > >> > : > >> If you want to fix it for real, does that mean fix it for real or > : > >> does that mean add kluges to platform code? > : > >> > : > >> Shouldn't we have ISA bridges obtain the set of valid resources > : > >> from their parent in the newbus hierarchy? > : > > > : > > Hmm, can we even know that? PCI-ISA bridges in x86 at least don't > : > > have any > : > > I/O limit registers like PCI-PCI bridges, instead they are > : > > subtractively > : > > decoded, i.e. they "eat" any memory request that no one else claims. > : > > : > The key here being requests that reach the PCI-ISA bridge. It's entirely > : > platform specific which I/O memory addresses generated by the CPU gets > : > decoded and forwarded in such a way that it's visible to the PCI-ISA > : > bridge. This is what needs to be obtained from the parent in the newbus > : > hierarchy. Rather than hardcoding [0xC .. 0x10> as the ISA > : > option > : > ROM memory range, it should be something like [isa_mem_base+0xC .. > : > isa_mem_base + 0x10> or even [isa_rom_base .. isa_rom_base + > : > 0x4>. > : > : That might certainly be a reasonable IVAR for isab(4) to provide to isa(4): > a > : ROM base. However, orm(4) should be enabled for all ISA bridges assuming > : that is fixed. OTOH, the way many bus drivers I've seen handle this so far > : is to change the base address of SYS_RES_MEMORY objects as they pass > through > : the relevant bridge so that the actual memory address is properly adjusted > : when it gets to the equivalent of the nexus. This is how many of the > : Foo->PCI bridges in arm that I've looked at work, and I think this is more > : inline with Warner's original patch which is to allow the various > : platform-specific ISA bridge drivers reject memory ranges they do not > decode > : and provide any needed adjustments to ranges they do decode to transform > them > : into suitable resources for their parent. Then orm(4) would just see it's > : attempts to do bus_alloc_resource() fail and end up DTRT. Given that, I do > : think this logic belongs in the ISA bridge drivers rather than in > individual > : ISA drivers. We don't make ISA peripheral drivers add an 'isa_mem_base' or > : equivalent to their I/O resources, and in terms of I/O resources, orm(4) is > : just a special blackhole device (much like the ACPI or PnPBIOS system > : resource devices, or the ram0 or apic0 devices on x86). > > This is exactly what I've been trying to say: the memory addresses > that orm is using are ISA BUS addresses. These just happen to map 1:1 > on x86, but will map to something else on other platforms. But our > kernel API is that the driver requests the bus address, and that any > necessary translation happen in the bus_space layer. > > I disagree that it belongs entirely in the isa bridge drivers. They > may communicate information to the bus_space implementation, but it is > bus_space that ultimately does this translation. I think it actually depends on the platform as to where it belongs. If you have some Foo->ISA bridge that uses a window on the Foo bus to map ISA space, then I think it makes sense to handle that in the Foo->ISA bridge, especially if it is a relocatable window. If the ISA bus is instead assigned a fixed range in the system address space then that probably belongs in the bus_space support. -- John Baldwin ___ svn-src-all@freebsd.org mailing list http://li
Re: svn commit: r197969 - head/sys/conf
In message: <200910150833.54252@freebsd.org> John Baldwin writes: : On Wednesday 14 October 2009 6:11:15 pm M. Warner Losh wrote: : > In message: <200910141738.43910@freebsd.org> : > John Baldwin writes: : > : On Wednesday 14 October 2009 5:20:38 pm Marcel Moolenaar wrote: : > : > : > : > On Oct 14, 2009, at 1:45 PM, John Baldwin wrote: : > : > : > : > > On Wednesday 14 October 2009 2:35:16 pm Marcel Moolenaar wrote: : > : > >> On Oct 14, 2009, at 10:39 AM, Warner Losh wrote: : > : > >>> : > : > >>> I can't be more clear than this. You keep ignoring me, and it is : > : > >>> very : > : > >>> frustrating. : > : > >> : > : > >> I'm not ignoring you. I'm still talking. You simply haven't convinced : > : > >> me. While it's possible (likely?) that I don't understand the issues, : > : > >> all you've achieved so far is that I'm more convinced that limiting : > : > >> orm(4) to i386 and amd64 is the right thing, because the alternative : > : > >> is not at all appealing. : > : > >> : > : > >>> The problem is that the : > : > >>> powerpc and itanium isa modules allow memory ranges that shouldn't : > : > >>> be : > : > >>> allowed. That's the platform specific code that needs to be fixed. : > : > >> : > : > >> isa_set_resource() is MI code and it happily adds whatever resources : > : > >> a driver wants. The only chance MD code has is to fail the : > : > >> allocation, : > : > >> but since the whole ISA code bypasses the newbus hierarchy, there's : > : > >> no way we know in the isa MD code what is valid and what isn't unless : > : > >> we add kluges to platform code. : > : > >> : > : > >> If you want to fix it for real, does that mean fix it for real or : > : > >> does that mean add kluges to platform code? : > : > >> : > : > >> Shouldn't we have ISA bridges obtain the set of valid resources : > : > >> from their parent in the newbus hierarchy? : > : > > : > : > > Hmm, can we even know that? PCI-ISA bridges in x86 at least don't : > : > > have any : > : > > I/O limit registers like PCI-PCI bridges, instead they are : > : > > subtractively : > : > > decoded, i.e. they "eat" any memory request that no one else claims. : > : > : > : > The key here being requests that reach the PCI-ISA bridge. It's entirely : > : > platform specific which I/O memory addresses generated by the CPU gets : > : > decoded and forwarded in such a way that it's visible to the PCI-ISA : > : > bridge. This is what needs to be obtained from the parent in the newbus : > : > hierarchy. Rather than hardcoding [0xC .. 0x10> as the ISA : > : > option : > : > ROM memory range, it should be something like [isa_mem_base+0xC .. : > : > isa_mem_base + 0x10> or even [isa_rom_base .. isa_rom_base + : > : > 0x4>. : > : : > : That might certainly be a reasonable IVAR for isab(4) to provide to isa(4): a : > : ROM base. However, orm(4) should be enabled for all ISA bridges assuming : > : that is fixed. OTOH, the way many bus drivers I've seen handle this so far : > : is to change the base address of SYS_RES_MEMORY objects as they pass through : > : the relevant bridge so that the actual memory address is properly adjusted : > : when it gets to the equivalent of the nexus. This is how many of the : > : Foo->PCI bridges in arm that I've looked at work, and I think this is more : > : inline with Warner's original patch which is to allow the various : > : platform-specific ISA bridge drivers reject memory ranges they do not decode : > : and provide any needed adjustments to ranges they do decode to transform them : > : into suitable resources for their parent. Then orm(4) would just see it's : > : attempts to do bus_alloc_resource() fail and end up DTRT. Given that, I do : > : think this logic belongs in the ISA bridge drivers rather than in individual : > : ISA drivers. We don't make ISA peripheral drivers add an 'isa_mem_base' or : > : equivalent to their I/O resources, and in terms of I/O resources, orm(4) is : > : just a special blackhole device (much like the ACPI or PnPBIOS system : > : resource devices, or the ram0 or apic0 devices on x86). : > : > This is exactly what I've been trying to say: the memory addresses : > that orm is using are ISA BUS addresses. These just happen to map 1:1 : > on x86, but will map to something else on other platforms. But our : > kernel API is that the driver requests the bus address, and that any : > necessary translation happen in the bus_space layer. : > : > I disagree that it belongs entirely in the isa bridge drivers. They : > may communicate information to the bus_space implementation, but it is : > bus_space that ultimately does this translation. : : I think it actually depends on the platform as to where it belongs. If you : have some Foo->ISA bridge that uses a window on the Foo bus to map ISA space, : then I think it makes sense to handle that in the Foo->ISA bridge, especially : if it is a relocatable
Re: svn commit: r197969 - head/sys/conf
On Thursday 15 October 2009 10:59:10 am M. Warner Losh wrote: > In message: <200910150833.54252@freebsd.org> > John Baldwin writes: > : On Wednesday 14 October 2009 6:11:15 pm M. Warner Losh wrote: > : > In message: <200910141738.43910@freebsd.org> > : > John Baldwin writes: > : > : On Wednesday 14 October 2009 5:20:38 pm Marcel Moolenaar wrote: > : > : > > : > : > On Oct 14, 2009, at 1:45 PM, John Baldwin wrote: > : > : > > : > : > > On Wednesday 14 October 2009 2:35:16 pm Marcel Moolenaar wrote: > : > : > >> On Oct 14, 2009, at 10:39 AM, Warner Losh wrote: > : > : > >>> > : > : > >>> I can't be more clear than this. You keep ignoring me, and it is > : > : > >>> very > : > : > >>> frustrating. > : > : > >> > : > : > >> I'm not ignoring you. I'm still talking. You simply haven't convinced > : > : > >> me. While it's possible (likely?) that I don't understand the issues, > : > : > >> all you've achieved so far is that I'm more convinced that limiting > : > : > >> orm(4) to i386 and amd64 is the right thing, because the alternative > : > : > >> is not at all appealing. > : > : > >> > : > : > >>> The problem is that the > : > : > >>> powerpc and itanium isa modules allow memory ranges that shouldn't > : > : > >>> be > : > : > >>> allowed. That's the platform specific code that needs to be fixed. > : > : > >> > : > : > >> isa_set_resource() is MI code and it happily adds whatever resources > : > : > >> a driver wants. The only chance MD code has is to fail the > : > : > >> allocation, > : > : > >> but since the whole ISA code bypasses the newbus hierarchy, there's > : > : > >> no way we know in the isa MD code what is valid and what isn't unless > : > : > >> we add kluges to platform code. > : > : > >> > : > : > >> If you want to fix it for real, does that mean fix it for real or > : > : > >> does that mean add kluges to platform code? > : > : > >> > : > : > >> Shouldn't we have ISA bridges obtain the set of valid resources > : > : > >> from their parent in the newbus hierarchy? > : > : > > > : > : > > Hmm, can we even know that? PCI-ISA bridges in x86 at least don't > : > : > > have any > : > : > > I/O limit registers like PCI-PCI bridges, instead they are > : > : > > subtractively > : > : > > decoded, i.e. they "eat" any memory request that no one else claims. > : > : > > : > : > The key here being requests that reach the PCI-ISA bridge. It's entirely > : > : > platform specific which I/O memory addresses generated by the CPU gets > : > : > decoded and forwarded in such a way that it's visible to the PCI-ISA > : > : > bridge. This is what needs to be obtained from the parent in the newbus > : > : > hierarchy. Rather than hardcoding [0xC .. 0x10> as the ISA > : > : > option > : > : > ROM memory range, it should be something like [isa_mem_base+0xC .. > : > : > isa_mem_base + 0x10> or even [isa_rom_base .. isa_rom_base + > : > : > 0x4>. > : > : > : > : That might certainly be a reasonable IVAR for isab(4) to provide to isa(4): a > : > : ROM base. However, orm(4) should be enabled for all ISA bridges assuming > : > : that is fixed. OTOH, the way many bus drivers I've seen handle this so far > : > : is to change the base address of SYS_RES_MEMORY objects as they pass through > : > : the relevant bridge so that the actual memory address is properly adjusted > : > : when it gets to the equivalent of the nexus. This is how many of the > : > : Foo->PCI bridges in arm that I've looked at work, and I think this is more > : > : inline with Warner's original patch which is to allow the various > : > : platform-specific ISA bridge drivers reject memory ranges they do not decode > : > : and provide any needed adjustments to ranges they do decode to transform them > : > : into suitable resources for their parent. Then orm(4) would just see it's > : > : attempts to do bus_alloc_resource() fail and end up DTRT. Given that, I do > : > : think this logic belongs in the ISA bridge drivers rather than in individual > : > : ISA drivers. We don't make ISA peripheral drivers add an 'isa_mem_base' or > : > : equivalent to their I/O resources, and in terms of I/O resources, orm(4) is > : > : just a special blackhole device (much like the ACPI or PnPBIOS system > : > : resource devices, or the ram0 or apic0 devices on x86). > : > > : > This is exactly what I've been trying to say: the memory addresses > : > that orm is using are ISA BUS addresses. These just happen to map 1:1 > : > on x86, but will map to something else on other platforms. But our > : > kernel API is that the driver requests the bus address, and that any > : > necessary translation happen in the bus_space layer. > : > > : > I disagree that it belongs entirely in the isa bridge drivers. They > : > may communicate information to the bus_space implementation, but it is > : > bus_space that ultimately does this translation. > : > : I think it a
Re: svn commit: r197969 - head/sys/conf
On Thursday 15 October 2009 11:18 am, John Baldwin wrote: > On Thursday 15 October 2009 10:59:10 am M. Warner Losh wrote: > > In message: <200910150833.54252@freebsd.org> > > > > John Baldwin writes: > > : On Wednesday 14 October 2009 6:11:15 pm M. Warner Losh wrote: > > : > In message: <200910141738.43910@freebsd.org> > > : > > > : > John Baldwin writes: > > : > : On Wednesday 14 October 2009 5:20:38 pm Marcel Moolenaar wrote: > > : > : > On Oct 14, 2009, at 1:45 PM, John Baldwin wrote: > > : > : > > On Wednesday 14 October 2009 2:35:16 pm Marcel Moolenaar wrote: > > : > : > >> On Oct 14, 2009, at 10:39 AM, Warner Losh wrote: > > : > : > >>> I can't be more clear than this. You keep ignoring > > : > : > >>> me, and it > > is > > > : > : > >>> very > > : > : > >>> frustrating. > > : > : > >> > > : > : > >> I'm not ignoring you. I'm still talking. You simply > > : > : > >> haven't > > convinced > > > : > : > >> me. While it's possible (likely?) that I don't > > : > : > >> understand the > > issues, > > > : > : > >> all you've achieved so far is that I'm more convinced > > : > : > >> that > > limiting > > > : > : > >> orm(4) to i386 and amd64 is the right thing, because > > : > : > >> the > > alternative > > > : > : > >> is not at all appealing. > > : > : > >> > > : > : > >>> The problem is that the > > : > : > >>> powerpc and itanium isa modules allow memory ranges > > : > : > >>> that > > shouldn't > > > : > : > >>> be > > : > : > >>> allowed. That's the platform specific code that > > : > : > >>> needs to be > > fixed. > > > : > : > >> isa_set_resource() is MI code and it happily adds > > : > : > >> whatever > > resources > > > : > : > >> a driver wants. The only chance MD code has is to fail > > : > : > >> the allocation, > > : > : > >> but since the whole ISA code bypasses the newbus > > : > : > >> hierarchy, > > there's > > > : > : > >> no way we know in the isa MD code what is valid and > > : > : > >> what isn't > > unless > > > : > : > >> we add kluges to platform code. > > : > : > >> > > : > : > >> If you want to fix it for real, does that mean fix it > > : > : > >> for real or does that mean add kluges to platform > > : > : > >> code? > > : > : > >> > > : > : > >> Shouldn't we have ISA bridges obtain the set of valid > > : > : > >> resources from their parent in the newbus hierarchy? > > : > : > > > > : > : > > Hmm, can we even know that? PCI-ISA bridges in x86 at > > : > : > > least don't have any > > : > : > > I/O limit registers like PCI-PCI bridges, instead they > > : > : > > are subtractively > > : > : > > decoded, i.e. they "eat" any memory request that no one > > : > : > > else > > claims. > > > : > : > The key here being requests that reach the PCI-ISA > > : > : > bridge. It's > > entirely > > > : > : > platform specific which I/O memory addresses generated by > > : > : > the CPU > > gets > > > : > : > decoded and forwarded in such a way that it's visible to > > : > : > the PCI-ISA bridge. This is what needs to be obtained > > : > : > from the parent in the > > newbus > > > : > : > hierarchy. Rather than hardcoding [0xC .. 0x10> > > : > : > as the ISA option > > : > : > ROM memory range, it should be something like > > [isa_mem_base+0xC .. > > > : > : > isa_mem_base + 0x10> or even [isa_rom_base .. > > : > : > isa_rom_base + 0x4>. > > : > : > > : > : That might certainly be a reasonable IVAR for isab(4) to > > : > : provide to > > isa(4): a > > > : > : ROM base. However, orm(4) should be enabled for all ISA > > : > : bridges > > assuming > > > : > : that is fixed. OTOH, the way many bus drivers I've seen > > : > : handle this > > so far > > > : > : is to change the base address of SYS_RES_MEMORY objects as > > : > : they pass > > through > > > : > : the relevant bridge so that the actual memory address is > > : > : properly > > adjusted > > > : > : when it gets to the equivalent of the nexus. This is how > > : > : many of the Foo->PCI bridges in arm that I've looked at > > : > : work, and I think this is > > more > > > : > : inline with Warner's original patch which is to allow the > > : > : various platform-specific ISA bridge drivers reject memory > > : > : ranges they do not > > decode > > > : > : and provide any needed adjustments to ranges they do decode > > : > : to > > transform them > > > : > : into suitable resources for their parent. Then orm(4) > > : > : would just see > > it's > > > : > : attempts to do bus_alloc_resource() fail and end up DTRT. > > : > : Given that, > > I do > > > : > : think this logic belongs in the ISA bridge drivers rather > > : > : than in > > individual > > > : > : ISA drivers. We don't make ISA peripheral drivers add > > an 'isa_mem_base' or > > > : > : equivalent to their I/O resources, and in terms of I/O > > : > : resources, > > orm(4) is > > > : > : just a special blackhole device (much like the ACPI or > > : > : PnPBIOS system resource devices, or the ram0 or apic0 > > : > : devices on
Re: svn commit: r197969 - head/sys/conf
In message: <20091014185338.ga26...@alchemy.franken.de> Marius Strobl writes: : 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. driverata nodriver ata.isa would be nice.. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
