On Wed, 8 Nov 2000, Warner Losh wrote:
In message [EMAIL PROTECTED] "Matthew N.
Dodd" writes:
: On Wed, 8 Nov 2000, Warner Losh wrote:
: The cardbus code, for example, will or in the RF_SHAREABLE bit when
: appropriate.
:
: Right, but the drivers that are consumers of the PCI or
On Thu, 9 Nov 2000, Peter Wemm wrote:
Do you want to know what is even funnier? One of my onboard ahc *PCI*
controllers (7895 based I think) also responds to the EISA probes if I
enable EISA.
What machine and what does the output from the probe/attach look like?
You'll fail the attach
What machine and what does the output from the probe/attach look like?
You'll fail the attach because the ID is not in the table of known
EISA IDs.
I forgot to mention that the probe will cause the aic78XX controller
to get very upset as you end up referencing a register that should
only be
On Thu, 9 Nov 2000, Justin T. Gibbs wrote:
You'll fail the attach because the ID is not in the table of known
EISA IDs. Joerg can probably give additional examples of this
problem. This is one reason we don't probe all 15 slots yet. If we
reserved the address space properly before doing the
What about EISA/VL or EISA/PCI systems?
What about them? PCI devices are supposed to be found via PCI configuration
space access. Even in these machines where a PCI card can be falsly
probed as an EISA card, the standard PCI configuration mechanism works
to correctly find PCI devices. VL
Humm... I had wondered why that was there. Is there a way to detect VLB
devices some other way?
This is specific to the aha2842 and is the only way I know of detecting
those boards.
I thought that there was a tricky way, which involved doing
the EISA non-destructive card identification,
On Thu, 9 Nov 2000, Terry Lambert wrote:
(I can't remember how, but the EISA BIOS knew not to treat these as
EISA cards).
Because the EISA Config Util. saves the config to the system NVRAM which
the EISA BIOS reads to get the configuration.
Using the EISA BIOS stuff might be the way to go.
What about EISA/VL or EISA/PCI systems?
What about them? PCI devices are supposed to be found via PCI configuration
space access. Even in these machines where a PCI card can be falsly
probed as an EISA card, the standard PCI configuration mechanism works
to correctly find PCI devices.
(I can't remember how, but the EISA BIOS knew not to treat these as
EISA cards).
Because the EISA Config Util. saves the config to the system NVRAM which
the EISA BIOS reads to get the configuration.
Yes, that was how, thanks for jogging my memory...
Using the EISA BIOS stuff might be
What about EISA/VL or EISA/PCI systems?
What about them? PCI devices are supposed to be found via PCI configuration
space access. Even in these machines where a PCI card can be falsly
probed as an EISA card, the standard PCI configuration mechanism works
to correctly find PCI devices.
How do we use the EISA BIOS on an Alpha or an SGI though?
I believe thorpej recently committed some code in NetBSD to do this
on the Alpha.
--
Justin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
As a backgrounder for other-than-Justin, Adaptec has a habit of
making multipurpose ROMs that sit on different types of devices,
so that they don't have to maintain multiple images. It's the
EISA stuff in these ROMs that causes a non-EISA BIOS based EISA
probe to incorrectly identify them
On Thu, 9 Nov 2000, Terry Lambert wrote:
At one (gross) time in history, Alphas included an x86 emulator in ROM
to facilitate this (and other BIOS POST initialization stuff, mostly).
Somehow I doubt I'll be able to make VM86 calls to BIOS interrupt services
on the Alpha.
--
| Matthew N. Dodd
In message [EMAIL PROTECTED] "Matthew N.
Dodd" writes:
: On Thu, 9 Nov 2000, Terry Lambert wrote:
: At one (gross) time in history, Alphas included an x86 emulator in ROM
: to facilitate this (and other BIOS POST initialization stuff, mostly).
:
: Somehow I doubt I'll be able to make VM86
At one (gross) time in history, Alphas included an x86 emulator
in ROM to facilitate this (and other BIOS POST initialization stuff,
mostly).
They still do.
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because
On Thu, 9 Nov 2000, Warner Losh wrote:
I think you are right. Even if the emulator ws there, it was only
used to run the ROM post code, not to be active any time after the
boot to use at randomly...
I looked at the NetBSD/Alpha EISA code. Looks like that does everything
we'll need.
--
|
The IRQ allocation needs the RF_SHAREABLE flag or it will blow up in
the case where the IRQ is shared with another device.
So the EISA attachment doesn't set RF_SHAREABLE if the system is
using a level sensitive interrupt?
--
Justin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
On Wed, 8 Nov 2000, Justin T. Gibbs wrote:
So the EISA attachment doesn't set RF_SHAREABLE if the system is using
a level sensitive interrupt?
The current EISA code isn't as smart as it should be.
I've got uncommitted code that ties it to the ELCR.
Bus front end code shouldn't have to know
On Wed, 8 Nov 2000, Justin T. Gibbs wrote:
So the EISA attachment doesn't set RF_SHAREABLE if the system is using
a level sensitive interrupt?
The current EISA code isn't as smart as it should be.
Speaking of that, I'd like to see the EISA code move to be
more like PCI. We should see if
In message [EMAIL PROTECTED] "Matthew N.
Dodd" writes:
: Bus front end code shouldn't have to know about level/edge triggered IRQs.
The cardbus code, for example, will or in the RF_SHAREABLE bit when
appropriate.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe
On Wed, 8 Nov 2000, Justin T. Gibbs wrote:
Speaking of that, I'd like to see the EISA code move to be
more like PCI. We should see if there is something at slot
0 and only then attempt to probe for sub-devices on the bus.
Humm... I've got EISA BIOS extension code that correctly returns IDs
On Wed, 8 Nov 2000, Warner Losh wrote:
The cardbus code, for example, will or in the RF_SHAREABLE bit when
appropriate.
Right, but the drivers that are consumers of the PCI or CARDBUS bus
interface shouldn't have to deal with RF_SHAREABLE; the bus driver should
do that. I grant you that this
In message [EMAIL PROTECTED] "Matthew N.
Dodd" writes:
: On Wed, 8 Nov 2000, Warner Losh wrote:
: The cardbus code, for example, will or in the RF_SHAREABLE bit when
: appropriate.
:
: Right, but the drivers that are consumers of the PCI or CARDBUS bus
: interface shouldn't have to deal with
The only reason this isn't done is because I, due to the
fledgling nature of the EISA code and the ahc VL card's
almost looking like EISA cards, did the wrong thing here.
We also need to be verifying that io ranges required to
probe for slots are not already claimed by other devices
before
On Wed, 8 Nov 2000, Justin T. Gibbs wrote:
Try ftp://ftp.jurai.net/users/winter/eisabook.zip
I can't seem to fetch it. Permission denied.
Damn firewall. Try with passive mode off.
--
| Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD |
| [EMAIL PROTECTED] | 2 x
The EISA code currently doesn't reserve resources for empty slots.
I'd like to make the bus driver reserve all EISA specific address space
though.
This would prevent an ISA card that just happens to use an EISA
like identification scheme from attaching after EISA. Unfortunately,
the
On Wed, 8 Nov 2000, Terry Lambert wrote:
Maybe it would be possible to have a separate "VLBus" bus that
went in before the EISA bus?
I'm still not clear as to why we need to differentiate them. There really
is no requirement that slot 0 be present (other than it being standard and
all.)
Can
I'm still not clear as to why we need to differentiate them. There really
is no requirement that slot 0 be present (other than it being standard and
all.)
Can we even tell if which EISA devices are really VL devices in disguise?
The only reason is to return the EISA probe to a read-only probe.
On Wed, 8 Nov 2000, Justin T. Gibbs wrote:
The only reason is to return the EISA probe to a read-only probe. The
ahc VL cards require that their ID0 register be written too prior to
reading the ID byte.
Humm... I had wondered why that was there. Is there a way to detect VLB
devices some
Humm... I had wondered why that was there. Is there a way to detect VLB
devices some other way?
This is specific to the aha2842 and is the only way I know of detecting
those boards.
--
Justin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of
"Matthew N. Dodd" wrote:
On Wed, 8 Nov 2000, Terry Lambert wrote:
Maybe it would be possible to have a separate "VLBus" bus that
went in before the EISA bus?
I'm still not clear as to why we need to differentiate them. There really
is no requirement that slot 0 be present (other than it
On Thu, 9 Nov 2000, Peter Wemm wrote:
Do you want to know what is even funnier? One of my onboard ahc *PCI*
controllers (7895 based I think) also responds to the EISA probes if I
enable EISA.
What machine and what does the output from the probe/attach look like?
--
| Matthew N. Dodd | '78
Someone (I can't find who in my records, please let me know if it was
you so I can credit you in the commit message) sent out patches to
make the vx driver not use the pci compat shims. I just found it in
my home directory, applied it, tweaked things very minorly and it
builds and boots.
Someone (I can't find who in my records, please let me know if it was
you so I can credit you in the commit message) sent out patches to
make the vx driver not use the pci compat shims. I just found it in
my home directory, applied it, tweaked things very minorly and it
builds and boots.
At Sun, 05 Nov 2000 01:26:42 -0700,
Warner Losh [EMAIL PROTECTED] wrote:
I think this means lnc is the last one in the tree, but I could be
wrong about that. I didn't do an actual grep...
# find /usr/src/sys -type f |xargs grep COMPAT_PCI_DRIVER
./dev/hea/eni.c:COMPAT_PCI_DRIVER (eni_pci,
There is a minor typo in the URL. The patches are at:
http://people.freebsd.org/~imp/if_vx.patch
Jim Bloom
[EMAIL PROTECTED]
Warner Losh wrote:
Someone (I can't find who in my records, please let me know if it was
you so I can credit you in the commit message) sent out patches to
36 matches
Mail list logo
