Hi,
I've got a new toy in my computer :
02:09.0 Network controller: Unknown device 1638:1100 (rev 02)
Subsystem: Unknown device 1638:1100
Flags: medium devsel, IRQ 9
I/O ports at d800 [disabled] [size=128]
Memory at d5800000 (32-bit, non-prefetchable) [disabled] [size=4K]
I/O ports at d400 [disabled] [size=64]
Device itself says :
WL11000P
It's a PCMCIA bridge, with one big IC : Manufacturer : PLX , type PCI9052
No idea why the PCI type ID says it's a network controller, it certainly
isn't. The whole package is sold as a Dynalink wireless LAN L11H, a PCI
PCICIA controller with one slot and a PCMCIA card based on a PrismII
chipset.
I'm gonna plug the PCMCIA card in my notebook, see what it doesn. It it
does work, the problem is the PCMCIA card bot been supported. Else I'v got
a big problem :)
Igmar
--
Igmar Palsenberg
JDI Media Solutions
Boulevard Heuvelink 102
6828 KT Arnhem
The Netherlands
mailto: [email protected]
PGP/GPG key : http://www.jdimedia.nl/formulier/pgp/igmar
> 02:09.0 Network controller: Unknown device 1638:1100 (rev 02)
> Subsystem: Unknown device 1638:1100
> Flags: medium devsel, IRQ 9
> I/O ports at d800 [disabled] [size=128]
> Memory at d5800000 (32-bit, non-prefetchable) [disabled] [size=4K]
> I/O ports at d400 [disabled] [size=64]
>
Vendor : Eumitcom Technology Inc
Device : WL11000P
Remark : Actually a PLX Tech PCI9052 wires to 802.11 PCICIA card
controller
Igmar
--
Igmar Palsenberg
JDI Media Solutions
Boulevard Heuvelink 102
6828 KT Arnhem
The Netherlands
mailto: [email protected]
PGP/GPG key : http://www.jdimedia.nl/formulier/pgp/igmar
On Sat, Jul 21, Igmar Palsenberg wrote:
>
> Hi,
>
> I've got a new toy in my computer :
>
> 02:09.0 Network controller: Unknown device 1638:1100 (rev 02)
> Subsystem: Unknown device 1638:1100
> Flags: medium devsel, IRQ 9
> I/O ports at d800 [disabled] [size=128]
> Memory at d5800000 (32-bit, non-prefetchable) [disabled] [size=4K]
> I/O ports at d400 [disabled] [size=64]
>
> Device itself says :
>
> WL11000P
> It's a PCMCIA bridge, with one big IC : Manufacturer : PLX , type PCI9052
The PLX PCI9052 is a generic bridge chip used by a lot of manufactures for
many different cards. What the card does is determined by other chips on
the board not the PCI interface. We use the PLX PCI9052 to build multiport
intelligent synchronous comms cards that are reported as "Communication
controller". The PLX chip does not determine the type of device.
> No idea why the PCI type ID says it's a network controller, it certainly
> isn't. The whole package is sold as a Dynalink wireless LAN L11H, a PCI
> PCICIA controller with one slot and a PCMCIA card based on a PrismII
> chipset.
Well the manufacturer ID 0x1638 belongs to Eumitcom Technology Inc and
their website (http://www.eumitcom.com/) shows the WL11000P combo to be a
IEEE 802.11b compliant wireless card. That's my definition of a Network
controller.
> I'm gonna plug the PCMCIA card in my notebook, see what it doesn. It it
> does work, the problem is the PCMCIA card bot been supported. Else I'v got
> a big problem :)
They say they have Linux support but no indication of which version. Don't
see drivers in the standard kernel so I guess they must be supplying it
as a patch. See http://www.eumitcom.com/html/wlan3.htm for download.
HTH
--
Bob Dunlop FarSite Communications
[email protected] [email protected]
http://www.xyzzy.clara.co.uk http://www.farsite.co.uk
On Sun, 22 Jul 2001, Robert J.Dunlop wrote:
> On Sat, Jul 21, Igmar Palsenberg wrote:
> >
> > Hi,
> >
> > I've got a new toy in my computer :
> >
> > 02:09.0 Network controller: Unknown device 1638:1100 (rev 02)
> > Subsystem: Unknown device 1638:1100
> > Flags: medium devsel, IRQ 9
> > I/O ports at d800 [disabled] [size=128]
> > Memory at d5800000 (32-bit, non-prefetchable) [disabled] [size=4K]
> > I/O ports at d400 [disabled] [size=64]
> >
> > Device itself says :
> >
> > WL11000P
> > It's a PCMCIA bridge, with one big IC : Manufacturer : PLX , type PCI9052
>
> The PLX PCI9052 is a generic bridge chip used by a lot of manufactures for
> many different cards. What the card does is determined by other chips on
> the board not the PCI interface. We use the PLX PCI9052 to build multiport
> intelligent synchronous comms cards that are reported as "Communication
> controller". The PLX chip does not determine the type of device.
I've got hold of the datasheet. It's a generic PCI to ISA bridge indeed.
> > No idea why the PCI type ID says it's a network controller, it certainly
> > isn't. The whole package is sold as a Dynalink wireless LAN L11H, a PCI
> > PCICIA controller with one slot and a PCMCIA card based on a PrismII
> > chipset.
>
> Well the manufacturer ID 0x1638 belongs to Eumitcom Technology Inc and
> their website (http://www.eumitcom.com/) shows the WL11000P combo to be a
> IEEE 802.11b compliant wireless card. That's my definition of a Network
> controller.
I'm still thinking about what driver to create.. A driver that
emulates a PCMCIA controller is a knightmare, but so is an ethernet driver
for this setup.
The 2.4.x kernel has support for the wireless card itself, but in a PCMCIA
context. Creating a ethernet driver creates a lot of duplicate code.
> > I'm gonna plug the PCMCIA card in my notebook, see what it doesn. It it
> > does work, the problem is the PCMCIA card bot been supported. Else I'v got
> > a big problem :)
>
> They say they have Linux support but no indication of which version. Don't
> see drivers in the standard kernel so I guess they must be supplying it
> as a patch. See http://www.eumitcom.com/html/wlan3.htm for download.
I don't call it support. The drivers are ancient, pcmcia-cs on their site
is a 1.5 year old version, and the driver itself doesn't work. Making it
work would require a large amount of code change to their driver, so it's
better to start from scratch.
> HTH
Igmar (who is confused about what to do)
--
Igmar Palsenberg
JDI Media Solutions
Boulevard Heuvelink 102
6828 KT Arnhem
The Netherlands
mailto: [email protected]
PGP/GPG key : http://www.jdimedia.nl/formulier/pgp/igmar
>
>I'm still thinking about what driver to create.. A driver that
>emulates a PCMCIA controller is a knightmare, but so is an ethernet driver
>for this setup.
I didn't follow closely, but Imy understanding is that the prismII is
not removable on the PCI card, that's it ? The PLX chip is probably
used to bridge the 16 bits PIO prism device, It doesn't make much sense
to emulate PCMCIA.
>The 2.4.x kernel has support for the wireless card itself, but in a PCMCIA
>context. Creating a ethernet driver creates a lot of duplicate code.
First, get a recent 2.4.x, 2.4.6 should you give you the latest version.
The kernel driver for those chipsets is designed in a way that should allow
you to easily add new interface types. Look at what's in drivers/net/wireless,
more specifically the files hermes.c, orinoco.c, orinoco_cs.c and airport.c.
The drivers's layout is basically;
- hermes : low level routines for talking to the controller,
you initialize this layer by passing it an IO base
for use with inx/outx routines. You shouldn't have
to modify it.
- orinoco : core driver. Implements the interface to the kernel
network stack, the wireless interface, etc...
You shouldn't need to change it neither
Now are the bus interfaces :
- orinoco_cs : PCMCIA interface
- airport : Apple "Airport" interface
What you have to do is basically add a module for your card. You should
write a basic PCI driver that mostly does what airport does (except
the powermac specific stuffs , mostly calls to feature_xxx() functions,
just ignore them). That is get the card's IO base address and request
an interrupt, implement open() and close() wrappers, and that's it.
HOWEVER, the low-level hermes layer can only do PIO for now (inx/outx).
If you card requires MMIO, then it will not be that simple. You'll probably
have to work on the hermes layer to provide 2 implementations, a PIO one
and an MMIO one.
For the Airport driver, which is MMIO based, we can "fake" this because
the Airport interface exist only on PowerMacs, and on PPC, PIO is actually
MMIO in a specific address range.
I don't know if the PLX bridge provides anything like GPIOs and/or if
there's a separate PLD on your card. In these cases, it's possible that
some card-specific IO magic be needed to properly initialize the prism.
That's the case with Apple airport on which you have to "emulate" some
PCMCIA stuffs for powering it up and resetting the chip.
So if you have problems getting the chip up, you may have to ask the
card manufacturer for some specs.
Ben.
> >I'm still thinking about what driver to create.. A driver that
> >emulates a PCMCIA controller is a knightmare, but so is an ethernet driver
> >for this setup.
>
> I didn't follow closely, but Imy understanding is that the prismII is
> not removable on the PCI card, that's it ? The PLX chip is probably
> used to bridge the 16 bits PIO prism device, It doesn't make much sense
> to emulate PCMCIA.
The PLX hardware the PCMCIA interface in the card. This means that it maps
IO and memory directly into PCI space.
> >The 2.4.x kernel has support for the wireless card itself, but in a PCMCIA
> >context. Creating a ethernet driver creates a lot of duplicate code.
>
> First, get a recent 2.4.x, 2.4.6 should you give you the latest version.
>
> The kernel driver for those chipsets is designed in a way that should allow
> you to easily add new interface types. Look at what's in drivers/net/wireless,
> more specifically the files hermes.c, orinoco.c, orinoco_cs.c and airport.c.
>
> The drivers's layout is basically;
>
> - hermes : low level routines for talking to the controller,
> you initialize this layer by passing it an IO base
> for use with inx/outx routines. You shouldn't have
> to modify it.
>
> - orinoco : core driver. Implements the interface to the kernel
> network stack, the wireless interface, etc...
> You shouldn't need to change it neither
>
> Now are the bus interfaces :
>
> - orinoco_cs : PCMCIA interface
> - airport : Apple "Airport" interface
>
> What you have to do is basically add a module for your card. You should
> write a basic PCI driver that mostly does what airport does (except
> the powermac specific stuffs , mostly calls to feature_xxx() functions,
> just ignore them). That is get the card's IO base address and request
> an interrupt, implement open() and close() wrappers, and that's it.
I missed the bus interface when looking at the code.
> HOWEVER, the low-level hermes layer can only do PIO for now (inx/outx).
> If you card requires MMIO, then it will not be that simple. You'll probably
> have to work on the hermes layer to provide 2 implementations, a PIO one
> and an MMIO one.
Is far as I can tell, it does need the MMIO. I'm looking at how the old
driver does the mapping.
> For the Airport driver, which is MMIO based, we can "fake" this because
> the Airport interface exist only on PowerMacs, and on PPC, PIO is actually
> MMIO in a specific address range.
>
> I don't know if the PLX bridge provides anything like GPIOs and/or if
> there's a separate PLD on your card. In these cases, it's possible that
> some card-specific IO magic be needed to properly initialize the prism.
> That's the case with Apple airport on which you have to "emulate" some
> PCMCIA stuffs for powering it up and resetting the chip.
As far as I can tell, the PCICIA IO and memory space are simply mapped
into PCI space.
> So if you have problems getting the chip up, you may have to ask the
> card manufacturer for some specs.
I've got specs on the card. I'm figuring out now how the thing is wired.
> Ben.
Igmar
--
Igmar Palsenberg
JDI Media Solutions
Boulevard Heuvelink 102
6828 KT Arnhem
The Netherlands
mailto: [email protected]
PGP/GPG key : http://www.jdimedia.nl/formulier/pgp/igmar