Ahoy, all.
I’ve been trying to port a PCMCIA network driver to QNX RTP, with
moderate amounts of success (mostly, I’ve just become more educated about
how things work, but I’m going to call those successes 
.
My problem is that the example driver (devn-pcnet) doesn’t appear to
have anything in it explicitly for supporting PCMCIA. This, from what I can
tell, is for two reasons: first is that it just doesn’t exist as a PCMCIA
card (which I’m pretty sure it does). The more likely reason is that when
you’re loading a PCMCIA driver, it is handled by either pccard-launch or
enum-pccard (if somebody could explain the exact difference between the two,
that’d be great … or does enum-pccard launch pccard-launch?).
Basically, I’m looking to confirm that all I need to do is modify
/etc/system/enum/…/something and make it so my driver loads the card at
the IOPORT sent to it.
One thing that would really help would be the source to devn-ne2000,
since it’s got entries for it in the PCMCIA enum setup. Is this source
available?
OTOH, it is possible that none of that made any sense at all, and I
could be very very very wrong.
Eli
Eli Green <eli.green@codedogs.ca> wrote:
I’ve been trying to port a PCMCIA network driver to QNX RTP, with
moderate amounts of success (mostly, I’ve just become more educated about
how things work, but I’m going to call those successes > 
> .
This is a very good point. We are going to be releasing the source
to all of our drivers that are not encumbered with legal/contract
restrictions. However, that isn’t going to help you today.
You will find that things like devn-ne2000.so don’t actually have any
PCMCIA specific code in them. They are relying on the fact that
devp-pccard will map them into the “standard” ISA location for a
non-pcmcia card. Additionally, any pccard would show up as a device
on the pci bus and also would not need any pccard specific code (devices
like pcnet).
That being said, there is a standard set of pccard_*() API for attaching
to the server and asking it information about the devices that are
present in the system. This is a pretty low-level interface.
Are you looking at using this device in a specific system or to be released
to the public for use on RTP machines?
chris
\
cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Previously, Chris McKillop wrote in qdn.public.ddk.network:
You will find that things like devn-ne2000.so don’t actually have any
PCMCIA specific code in them.
Don’t you check each time you read control and status I/O
ports for 0xff to detect removal?
Mitchell Schoenbrun --------- maschoen@pobox.com
I’ve been trying to port a PCMCIA network driver to QNX RTP, with
moderate amounts of success (mostly, I’ve just become more educated
about
how things work, but I’m going to call those successes > > .
This is a very good point. We are going to be releasing the source
to all of our drivers that are not encumbered with legal/contract
restrictions. However, that isn’t going to help you today.
You will find that things like devn-ne2000.so don’t actually have any
PCMCIA specific code in them. They are relying on the fact that
devp-pccard will map them into the “standard” ISA location for a
non-pcmcia card. Additionally, any pccard would show up as a device
on the pci bus and also would not need any pccard specific code (devices
like pcnet).
That being said, there is a standard set of pccard_*() API for attaching
to the server and asking it information about the devices that are
present in the system. This is a pretty low-level interface.
Are you looking at using this device in a specific system or to be
released
to the public for use on RTP machines?
It’s hopefully going to be for public use on RTP machines - I’ll probably
even release the source under the OCL. I’m writing it because I happen to
have the card in my desktop machine, and it’s my only connection to
anywhere, so I have no problem with it helping other people.
Ok, so is there any chance you could explain the interaction between
enum-devices, devp-pccard, pccard-launch and assorted crew?
But if I’m understanding you, I just need to fill out a Nic_t with
nic_drvr_options(), then pci_attach myself to the card specified?
Mitchell Schoenbrun <maschoen@pobox.com> wrote:
Previously, Chris McKillop wrote in qdn.public.ddk.network:
You will find that things like devn-ne2000.so don’t actually have any
PCMCIA specific code in them.
Don’t you check each time you read control and status I/O
ports for 0xff to detect removal?
This is generally left to a higher level to stop the driver.
chris
–
cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Eli Green <eli.green@codedogs.ca> wrote:
Ok, so is there any chance you could explain the interaction between
enum-devices, devp-pccard, pccard-launch and assorted crew?
devp-ppcard is the service that maintains the pccard/pcmcia bus.
It allocates resources and configures the cards at the pcmcia level.
It is the guy that allows utilities like “pin” to function.
The whole enumeration scheme is just a way of having a database of devices
and a way to automagically start them all. Right now enum-pccard is
not finished.
But if I’m understanding you, I just need to fill out a Nic_t with
nic_drvr_options(), then pci_attach myself to the card specified?
This is a cardbus/pccard and not a pcmcia card then? If it is cardbus
then you should use the pci_*() commands to scan for your card and then
use the results from those calls to get io and irq information. The pcnet
driver shows how to do this in init.c. If you are a pcmcia card then
the simplist thing is to take the returned values from nic_drvr_options()
and bail if you don’t get an ioport and irq. You can also scan the
pccard bus if your device has a unique vendor and device id.
chris
–
cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
First off, thanks muchly for the prompt replies and helpful tips and stuff.
I’ll try to make as little a nuisance of myself as possible.
Second, I’ve had more moderate success! After a few entries in
/etc/system/enum/net, I was able to establish that it is, in fact, a PCMCIA
card, not a PCCard. Now it pleasantly loads the driver and points it to the
right IOPORT and IRQ. I should be able to leave you alone for a while from
here on out.
Is this the “correct” way to do things, given that it’s a PCMCIA card? I
can’t see any way of probing for them otherwise (this may explain why my
brilliant pciscan.c hack didn’t find the card…).
“Chris McKillop” <cdm@qnx.com> wrote in message
news:9h80ar$jrn$8@nntp.qnx.com…
Eli Green <> eli.green@codedogs.ca> > wrote:
Ok, so is there any chance you could explain the interaction between
enum-devices, devp-pccard, pccard-launch and assorted crew?
> devp-ppcard is the service that maintains the pccard/pcmcia bus.
It allocates resources and configures the cards at the pcmcia level.
It is the guy that allows utilities like “pin” to function.
The whole enumeration scheme is just a way of having a database of devices
and a way to automagically start them all. Right now enum-pccard is
not finished.
But if I’m understanding you, I just need to fill out a Nic_t with
nic_drvr_options(), then pci_attach myself to the card specified?
This is a cardbus/pccard and not a pcmcia card then? If it is cardbus
then you should use the pci_*() commands to scan for your card and then
use the results from those calls to get io and irq information. The pcnet
driver shows how to do this in init.c. If you are a pcmcia card then
the simplist thing is to take the returned values from nic_drvr_options()
and bail if you don’t get an ioport and irq. You can also scan the
pccard bus if your device has a unique vendor and device id.
chris
–
cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL