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.
--
|
> 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 peo
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
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. Dod
> >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 identi
>
>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
>> >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
> > (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 mi
> >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 devic
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.
> >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 identifica
>
>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
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
>>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, 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 atta
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
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 | '
"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
>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 t
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 o
>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 pr
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
> >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. Unfortunatel
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] |
>> 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
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 wi
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
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 ID
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 freebs
>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 i
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
>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 "unsub
> 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
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
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
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. Trouble
36 matches
Mail list logo
