PCI Serial Driver - need help

I’ve been trying to get a driver running for a PCI serial card for quite
some time now, with no success. I’m getting the feeling that the route I’ve
chosen might not be the right one, maybe somebody here can point me in the
right direction.

The PCI device is FPGA based and contains 5 non-standard UARTS, ARINC 429
etc. What I’m trying to do is create a driver for each of the functions,
i.e. serial ports, ARINC 429 etc. all of which are linked as children to my
parent PCI driver. I must also emphasize that this is not for a commercial
product, it is what we use for testing, and there are only 5 of these cards
thus we cannot afford to spend much time or money on the driver.

Now the route I’ve chosen is to write a PCI driver (which works fine) and
create child devices for the serial ports (as per Walter Oney’s mulfunc
example) (which doesn’t work at all). I then removed the card and just
tried to to get the mulfunc example running and creating one child as a
serial port (using WINXPDDK serial.sys example). Once again no luck.

I don’t think I’m stupid but this seems a lot more difficult than it ought
to be. Does anybody have any ideas where to start and what direction to
take.

The PCI card has 10 functions so I must enumerate them manually, that’s why
I think child devices are the way to go. I can see the serial driver
creating the port in the registry, creating symbolic link etc. But when I
open it it says the device cannot be opened. I don’t get a create IRP in
either parent or child device when this happens.

Any help will be greatly appreciated.

Vis

‘Functions’ in PCI terminology refer to distinct addressable components on a
PCI bus that have a PCI config space region defined for them. PCI addresses
are bus/device/function tuples. A PCI-compliant multifunction device is a
descrete PCI component, for example a PCI card, that has one PCI bus/device
address and more than one PCI function address. I cannot tell from your post
if your hardware is a multifunction PCI device or a non-compliant PCI
device that has several ‘logical functions’ combined into one or more
addressable PCI functions.

Given that you claim to have 10 functions, and that the maximum number of
PCI addresable functions per PCI device is 8, I think you have some
combination of logical and addressable PCI functions. Each addressable PCI
function should be implemented with a standard PCI PnP Function Driver. If a
PCI function contains more than one logical function then it should be
implemented by providing PnP Bus Driver functionality for the corresponding
PCI Function Driver. You have two choices here: write your own bus driver,
or use the existing semi-documented Microsoft supplied MultiFunction Driver
(mf.sys). Given the complexities of writing a bus driver from scratch, I
strongly urge you to consider using mf.sys instead. Search this list and the
usenet groups for more information about mf.sys, as we have discussed the
pros and cons of this issue several times here.

I know from personal experience that using mf.sys to support logical serial
port functions on a PCI device works just fine, with the coding effort
reduced to one rather cryptic inf file and the usual testing.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Vis
Sent: Sunday, July 04, 2004 7:18 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] PCI Serial Driver - need help

I’ve been trying to get a driver running for a PCI serial
card for quite some time now, with no success. I’m getting
the feeling that the route I’ve chosen might not be the right
one, maybe somebody here can point me in the right direction.

The PCI device is FPGA based and contains 5 non-standard
UARTS, ARINC 429 etc. What I’m trying to do is create a
driver for each of the functions, i.e. serial ports, ARINC
429 etc. all of which are linked as children to my parent
PCI driver. I must also emphasize that this is not for a
commercial product, it is what we use for testing, and there
are only 5 of these cards thus we cannot afford to spend much
time or money on the driver.

Now the route I’ve chosen is to write a PCI driver (which
works fine) and create child devices for the serial ports (as
per Walter Oney’s mulfunc
example) (which doesn’t work at all). I then removed the
card and just tried to to get the mulfunc example running and
creating one child as a serial port (using WINXPDDK
serial.sys example). Once again no luck.

I don’t think I’m stupid but this seems a lot more difficult
than it ought to be. Does anybody have any ideas where to
start and what direction to take.

The PCI card has 10 functions so I must enumerate them
manually, that’s why I think child devices are the way to go.
I can see the serial driver creating the port in the
registry, creating symbolic link etc. But when I open it it
says the device cannot be opened. I don’t get a create IRP
in either parent or child device when this happens.

Any help will be greatly appreciated.

Vis


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as:
xxxxx@hollistech.com To unsubscribe send a blank email to
xxxxx@lists.osr.com

Thanks for the helpful reply.

I guess the following best describes what I have:

quoted from Microsoft WHDC :


"Problem Design 2: Single Base Address Register for Multiple Functions
A device of this type has a single configuration space with a unique device
ID, but the configuration space is overloaded to the point that a single
base address register represents resources for more than one functional
unit, each unit using a portion of the resource range represented by that
BAR.

Writing a driver to compensate for this design is highly complex, because
support differs for each version of the Windows operating system. It would
require a bus driver that can correctly handle its own device relations,
manage power, and coordinate resource use among its children. Developing
such a driver usually results in large, long-term support and development
costs for the vendor, and is not recommended. "


In retrospect it would have been better to design the hardware correctly
(According to PCI multifunction standard), to have independent resources for
all functions etc… The resources are however shared between all functions.
The device has the following functions: 5 * RS232/485, 4 * ARINC429 TX and
RX, 1 * ARINC717, Some Discrete I/O etc. As far as I understand mf.sys is
not going to work with these overlapped resources.

Now most of this is not a problem to me as I just use IOCTRLs (on the main
function driver for the PCI card) and write a user mode DLL to provide an
API to control these functions. The problem is with the serial ports which
must appear as standard ports. I must be able to open them from
HyperTerminal or other applications, so I cannot write my own interface to
them. My thinking was to do all the processing, reading, writing etc to the
ports in the main function driver, but to load a serial driver (Modified DDK
example) to look like a serial port and just pass the messages through to
the actual function driver which would control the actual hardware interface
(kind of like a virtual serial port but with actual hardware underneath it).

What I’m struggling with is to enumerate these serial devices manually from
the main function driver. From what you said it sounds as if I’m sort of on
the right track, although using mf.sys is actually the right way to go, if
the card could support it (i.e. multifunction standard) ?

“Mark Roddy” wrote in message news:xxxxx@ntdev…
> ‘Functions’ in PCI terminology refer to distinct addressable components on
a
> PCI bus that have a PCI config space region defined for them. PCI
addresses
> are bus/device/function tuples. A PCI-compliant multifunction device is a
> descrete PCI component, for example a PCI card, that has one PCI
bus/device
> address and more than one PCI function address. I cannot tell from your
post
> if your hardware is a multifunction PCI device or a non-compliant PCI
> device that has several ‘logical functions’ combined into one or more
> addressable PCI functions.
>
> Given that you claim to have 10 functions, and that the maximum number of
> PCI addresable functions per PCI device is 8, I think you have some
> combination of logical and addressable PCI functions. Each addressable PCI
> function should be implemented with a standard PCI PnP Function Driver. If
a
> PCI function contains more than one logical function then it should be
> implemented by providing PnP Bus Driver functionality for the
corresponding
> PCI Function Driver. You have two choices here: write your own bus driver,
> or use the existing semi-documented Microsoft supplied MultiFunction
Driver
> (mf.sys). Given the complexities of writing a bus driver from scratch, I
> strongly urge you to consider using mf.sys instead. Search this list and
the
> usenet groups for more information about mf.sys, as we have discussed the
> pros and cons of this issue several times here.
>
> I know from personal experience that using mf.sys to support logical
serial
> port functions on a PCI device works just fine, with the coding effort
> reduced to one rather cryptic inf file and the usual testing.
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Vis
> > Sent: Sunday, July 04, 2004 7:18 AM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] PCI Serial Driver - need help
> >
> > I’ve been trying to get a driver running for a PCI serial
> > card for quite some time now, with no success. I’m getting
> > the feeling that the route I’ve chosen might not be the right
> > one, maybe somebody here can point me in the right direction.
> >
> > The PCI device is FPGA based and contains 5 non-standard
> > UARTS, ARINC 429 etc. What I’m trying to do is create a
> > driver for each of the functions, i.e. serial ports, ARINC
> > 429 etc. all of which are linked as children to my parent
> > PCI driver. I must also emphasize that this is not for a
> > commercial product, it is what we use for testing, and there
> > are only 5 of these cards thus we cannot afford to spend much
> > time or money on the driver.
> >
> > Now the route I’ve chosen is to write a PCI driver (which
> > works fine) and create child devices for the serial ports (as
> > per Walter Oney’s mulfunc
> > example) (which doesn’t work at all). I then removed the
> > card and just tried to to get the mulfunc example running and
> > creating one child as a serial port (using WINXPDDK
> > serial.sys example). Once again no luck.
> >
> > I don’t think I’m stupid but this seems a lot more difficult
> > than it ought to be. Does anybody have any ideas where to
> > start and what direction to take.
> >
> > The PCI card has 10 functions so I must enumerate them
> > manually, that’s why I think child devices are the way to go.
> > I can see the serial driver creating the port in the
> > registry, creating symbolic link etc. But when I open it it
> > says the device cannot be opened. I don’t get a create IRP
> > in either parent or child device when this happens.
> >
> > Any help will be greatly appreciated.
> >
> > Vis
> >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> > xxxxx@hollistech.com To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
>
>
>
>

I’m not sure that mf.sys won’t work for you. You should look carefully at
the ddk docs for ‘varying resource maps’. Mf (in XP and later) allows both
shared resources (such as interrupts) and partitioned resources (pieces of
bars.) This actually ought to cover your case. You could of course convince
yourself that w2k is a requirement, and then indeed you would have to write
a bus driver.

Mf.sys ought to allow you to assign the non-serial port resources to your
current function driver, and the serial port resources to standard serial
port drivers, which is exactly what you want. You would continue to access
all of your non-standard functionality through your existing IOCTL
interface.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Vis
Sent: Sunday, July 04, 2004 6:25 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] PCI Serial Driver - need help

Thanks for the helpful reply.

I guess the following best describes what I have:

quoted from Microsoft WHDC :


"Problem Design 2: Single Base Address Register for Multiple
Functions A device of this type has a single configuration
space with a unique device ID, but the configuration space is
overloaded to the point that a single base address register
represents resources for more than one functional unit, each
unit using a portion of the resource range represented by that BAR.

Writing a driver to compensate for this design is highly
complex, because support differs for each version of the
Windows operating system. It would require a bus driver that
can correctly handle its own device relations, manage power,
and coordinate resource use among its children. Developing
such a driver usually results in large, long-term support and
development costs for the vendor, and is not recommended. "


In retrospect it would have been better to design the
hardware correctly (According to PCI multifunction standard),
to have independent resources for all functions etc… The
resources are however shared between all functions.
The device has the following functions: 5 * RS232/485, 4 *
ARINC429 TX and RX, 1 * ARINC717, Some Discrete I/O etc. As
far as I understand mf.sys is not going to work with these
overlapped resources.

Now most of this is not a problem to me as I just use IOCTRLs
(on the main function driver for the PCI card) and write a
user mode DLL to provide an API to control these functions.
The problem is with the serial ports which must appear as
standard ports. I must be able to open them from
HyperTerminal or other applications, so I cannot write my own
interface to them. My thinking was to do all the processing,
reading, writing etc to the ports in the main function
driver, but to load a serial driver (Modified DDK
example) to look like a serial port and just pass the
messages through to the actual function driver which would
control the actual hardware interface (kind of like a virtual
serial port but with actual hardware underneath it).

What I’m struggling with is to enumerate these serial devices
manually from the main function driver. From what you said it
sounds as if I’m sort of on the right track, although using
mf.sys is actually the right way to go, if the card could
support it (i.e. multifunction standard) ?

“Mark Roddy” wrote in message
> news:xxxxx@ntdev…
> > ‘Functions’ in PCI terminology refer to distinct addressable
> > components on
> a
> > PCI bus that have a PCI config space region defined for them. PCI
> addresses
> > are bus/device/function tuples. A PCI-compliant
> multifunction device
> > is a descrete PCI component, for example a PCI card, that
> has one PCI
> bus/device
> > address and more than one PCI function address. I cannot tell from
> > your
> post
> > if your hardware is a multifunction PCI device or a
> non-compliant PCI
> > device that has several ‘logical functions’ combined into
> one or more
> > addressable PCI functions.
> >
> > Given that you claim to have 10 functions, and that the
> maximum number
> > of PCI addresable functions per PCI device is 8, I think
> you have some
> > combination of logical and addressable PCI functions. Each
> addressable
> > PCI function should be implemented with a standard PCI PnP Function
> > Driver. If
> a
> > PCI function contains more than one logical function then
> it should be
> > implemented by providing PnP Bus Driver functionality for the
> corresponding
> > PCI Function Driver. You have two choices here: write your own bus
> > driver, or use the existing semi-documented Microsoft supplied
> > MultiFunction
> Driver
> > (mf.sys). Given the complexities of writing a bus driver
> from scratch,
> > I strongly urge you to consider using mf.sys instead.
> Search this list
> > and
> the
> > usenet groups for more information about mf.sys, as we have
> discussed
> > the pros and cons of this issue several times here.
> >
> > I know from personal experience that using mf.sys to support logical
> serial
> > port functions on a PCI device works just fine, with the
> coding effort
> > reduced to one rather cryptic inf file and the usual testing.
> >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of Vis
> > > Sent: Sunday, July 04, 2004 7:18 AM
> > > To: Windows System Software Devs Interest List
> > > Subject: [ntdev] PCI Serial Driver - need help
> > >
> > > I’ve been trying to get a driver running for a PCI serial
> card for
> > > quite some time now, with no success. I’m getting the
> feeling that
> > > the route I’ve chosen might not be the right one, maybe somebody
> > > here can point me in the right direction.
> > >
> > > The PCI device is FPGA based and contains 5 non-standard UARTS,
> > > ARINC 429 etc. What I’m trying to do is create a driver
> for each of
> > > the functions, i.e. serial ports, ARINC
> > > 429 etc. all of which are linked as children to my parent PCI
> > > driver. I must also emphasize that this is not for a commercial
> > > product, it is what we use for testing, and there are only 5 of
> > > these cards thus we cannot afford to spend much time or
> money on the
> > > driver.
> > >
> > > Now the route I’ve chosen is to write a PCI driver (which works
> > > fine) and create child devices for the serial ports (as
> per Walter
> > > Oney’s mulfunc
> > > example) (which doesn’t work at all). I then removed the
> card and
> > > just tried to to get the mulfunc example running and creating one
> > > child as a serial port (using WINXPDDK serial.sys example). Once
> > > again no luck.
> > >
> > > I don’t think I’m stupid but this seems a lot more
> difficult than it
> > > ought to be. Does anybody have any ideas where to start and what
> > > direction to take.
> > >
> > > The PCI card has 10 functions so I must enumerate them manually,
> > > that’s why I think child devices are the way to go.
> > > I can see the serial driver creating the port in the registry,
> > > creating symbolic link etc. But when I open it it says
> the device
> > > cannot be opened. I don’t get a create IRP in either parent or
> > > child device when this happens.
> > >
> > > Any help will be greatly appreciated.
> > >
> > > Vis
> > >
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as:
> > > xxxxx@hollistech.com To unsubscribe send a blank email to
> > > xxxxx@lists.osr.com
> > >
> >
> >
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@hollistech.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>

You’ve slightly misunderstoond both Mark and the purpose of mf.sys. If your
device is a PCI multifunction device (per the PCI spec) then PCI.sys is your
bus driver and you don’t need mf.sys. If your device is a single PCI
function and it is internally split into several logical devices, then you
may be able to use mf.sys, as long as the registers for the logical devices
are completely disjoint and they don’t change relative to the start of the
Base Address Register. This is the purpose of mf.sys.


Jake Oshins
Windows Kernel Group

This posting is provided “AS IS” with no warranties, and confers no rights.

“Vis” wrote in message news:xxxxx@ntdev…
> Thanks for the helpful reply.
>
> I guess the following best describes what I have:
>
> quoted from Microsoft WHDC :
>
> ---------------
> "Problem Design 2: Single Base Address Register for Multiple Functions
> A device of this type has a single configuration space with a unique
> device
> ID, but the configuration space is overloaded to the point that a single
> base address register represents resources for more than one functional
> unit, each unit using a portion of the resource range represented by that
> BAR.
>
> Writing a driver to compensate for this design is highly complex, because
> support differs for each version of the Windows operating system. It would
> require a bus driver that can correctly handle its own device relations,
> manage power, and coordinate resource use among its children. Developing
> such a driver usually results in large, long-term support and development
> costs for the vendor, and is not recommended. "
>
> ----------------
>
> In retrospect it would have been better to design the hardware correctly
> (According to PCI multifunction standard), to have independent resources
> for
> all functions etc… The resources are however shared between all
> functions.
> The device has the following functions: 5 * RS232/485, 4 * ARINC429 TX and
> RX, 1 * ARINC717, Some Discrete I/O etc. As far as I understand mf.sys is
> not going to work with these overlapped resources.
>
>
> Now most of this is not a problem to me as I just use IOCTRLs (on the main
> function driver for the PCI card) and write a user mode DLL to provide an
> API to control these functions. The problem is with the serial ports
> which
> must appear as standard ports. I must be able to open them from
> HyperTerminal or other applications, so I cannot write my own interface to
> them. My thinking was to do all the processing, reading, writing etc to
> the
> ports in the main function driver, but to load a serial driver (Modified
> DDK
> example) to look like a serial port and just pass the messages through to
> the actual function driver which would control the actual hardware
> interface
> (kind of like a virtual serial port but with actual hardware underneath
> it).
>
> What I’m struggling with is to enumerate these serial devices manually
> from
> the main function driver. From what you said it sounds as if I’m sort of
> on
> the right track, although using mf.sys is actually the right way to go, if
> the card could support it (i.e. multifunction standard) ?
>
>
>
>
>
>
>
> “Mark Roddy” wrote in message news:xxxxx@ntdev…
>> ‘Functions’ in PCI terminology refer to distinct addressable components
>> on
> a
>> PCI bus that have a PCI config space region defined for them. PCI
> addresses
>> are bus/device/function tuples. A PCI-compliant multifunction device is a
>> descrete PCI component, for example a PCI card, that has one PCI
> bus/device
>> address and more than one PCI function address. I cannot tell from your
> post
>> if your hardware is a multifunction PCI device or a non-compliant PCI
>> device that has several ‘logical functions’ combined into one or more
>> addressable PCI functions.
>>
>> Given that you claim to have 10 functions, and that the maximum number of
>> PCI addresable functions per PCI device is 8, I think you have some
>> combination of logical and addressable PCI functions. Each addressable
>> PCI
>> function should be implemented with a standard PCI PnP Function Driver.
>> If
> a
>> PCI function contains more than one logical function then it should be
>> implemented by providing PnP Bus Driver functionality for the
> corresponding
>> PCI Function Driver. You have two choices here: write your own bus
>> driver,
>> or use the existing semi-documented Microsoft supplied MultiFunction
> Driver
>> (mf.sys). Given the complexities of writing a bus driver from scratch, I
>> strongly urge you to consider using mf.sys instead. Search this list and
> the
>> usenet groups for more information about mf.sys, as we have discussed the
>> pros and cons of this issue several times here.
>>
>> I know from personal experience that using mf.sys to support logical
> serial
>> port functions on a PCI device works just fine, with the coding effort
>> reduced to one rather cryptic inf file and the usual testing.
>>
>> > -----Original Message-----
>> > From: xxxxx@lists.osr.com
>> > [mailto:xxxxx@lists.osr.com] On Behalf Of Vis
>> > Sent: Sunday, July 04, 2004 7:18 AM
>> > To: Windows System Software Devs Interest List
>> > Subject: [ntdev] PCI Serial Driver - need help
>> >
>> > I’ve been trying to get a driver running for a PCI serial
>> > card for quite some time now, with no success. I’m getting
>> > the feeling that the route I’ve chosen might not be the right
>> > one, maybe somebody here can point me in the right direction.
>> >
>> > The PCI device is FPGA based and contains 5 non-standard
>> > UARTS, ARINC 429 etc. What I’m trying to do is create a
>> > driver for each of the functions, i.e. serial ports, ARINC
>> > 429 etc. all of which are linked as children to my parent
>> > PCI driver. I must also emphasize that this is not for a
>> > commercial product, it is what we use for testing, and there
>> > are only 5 of these cards thus we cannot afford to spend much
>> > time or money on the driver.
>> >
>> > Now the route I’ve chosen is to write a PCI driver (which
>> > works fine) and create child devices for the serial ports (as
>> > per Walter Oney’s mulfunc
>> > example) (which doesn’t work at all). I then removed the
>> > card and just tried to to get the mulfunc example running and
>> > creating one child as a serial port (using WINXPDDK
>> > serial.sys example). Once again no luck.
>> >
>> > I don’t think I’m stupid but this seems a lot more difficult
>> > than it ought to be. Does anybody have any ideas where to
>> > start and what direction to take.
>> >
>> > The PCI card has 10 functions so I must enumerate them
>> > manually, that’s why I think child devices are the way to go.
>> > I can see the serial driver creating the port in the
>> > registry, creating symbolic link etc. But when I open it it
>> > says the device cannot be opened. I don’t get a create IRP
>> > in either parent or child device when this happens.
>> >
>> > Any help will be greatly appreciated.
>> >
>> > Vis
>> >
>> >
>> >
>> >
>> > —
>> > Questions? First check the Kernel Driver FAQ at
>> > http://www.osronline.com/article.cfm?id=256
>> >
>> > You are currently subscribed to ntdev as:
>> > xxxxx@hollistech.com To unsubscribe send a blank email to
>> > xxxxx@lists.osr.com
>> >
>>
>>
>>
>>
>
>
>

I have the solution, reply to me directly.

I’ve been trying to get a driver running for a PCI serial card for quite
some time now, with no success. I’m getting the feeling that the route
I’ve
chosen might not be the right one, maybe somebody here can point me in the
right direction.
[…]