Trouble with mf.sys

Shane_Corbin · January 7, 2013, 7:46pm

I must be overlooking something and could use some help.

I’m writing drivers for PCI device as follows.

VendorID: xxxx DeviceID: yyyyy
BAR0: multiple serial uarts
BAR1: some other feature that will have a driver all its own

I’ve got a top-level INF for xxxx&yyyy that does this using mf.sys:
HKR, Child0000, HardwareID, MF\uarts
HKR, Child0000, ResourceMap,1,00,08 ; Resources 00 (BAR0), 08 (INT)
HKR, Child0001, HardwareID, MF\other
HKR, Child0001, ResourceMap,1,02,08 ; Resources 02 (BAR1), 08 (INT)

I then have another INF for mf\uarts that does this using mf.sys:
HKR, Child0000, HardwareID, MF\serial
HKR, Child0000, VaryingResourceMap,1,00, 00,00,00,00, 20,00,00,00
HKR, Child0000, ResourceMap,1,01
HKR, Child0001, HardwareID, MF\serial
HKR, Child0001, VaryingResourceMap,1,00, 20,00,00,00, 20,00,00,00
HKR, Child0001, ResourceMap,1,01
HKR, Child0002, HardwareID, MF\serial
HKR, Child0002, VaryingResourceMap,1,00, 40,00,00,00, 20,00,00,00
HKR, Child0002, ResourceMap,1,01
HKR, Child0003, HardwareID, MF\serial
HKR, Child0003, VaryingResourceMap,1,00, 60,00,00,00, 20,00,00,00
HKR, Child0003, ResourceMap,1,01

Lastly, I have an INF for MF\serial that installs the serial driver for each uart. During installation the device manager complains that the device can’t find enough free resources to use. I’m expecting each com port to get the resources that I specified for each MF\serial.

If I remove the top-level INF that splits out each BAR it works just fine. In that case the INF above specifying the varyingresourcemap’s targets the xxxx&yyyy hardware ID instead of mf\uarts.

Any ideas?

Pavel_A1 · January 9, 2013, 2:21pm

I don’t have my old examlpes handy but IIRC the child devices should not be
defined in two INFs.
So, keep only the INF where MF\serial are defined, and remove the other
where MF\uarts is defined.
– pa

wrote in message news:xxxxx@ntdev…
> I must be overlooking something and could use some help.
>
> I’m writing drivers for PCI device as follows.
>
> VendorID: xxxx DeviceID: yyyyy
> BAR0: multiple serial uarts
> BAR1: some other feature that will have a driver all its own
>
> I’ve got a top-level INF for xxxx&yyyy that does this using mf.sys:
> HKR, Child0000, HardwareID, MF\uarts
> HKR, Child0000, ResourceMap,1,00,08 ; Resources 00 (BAR0), 08 (INT)
> HKR, Child0001, HardwareID, MF\other
> HKR, Child0001, ResourceMap,1,02,08 ; Resources 02 (BAR1), 08 (INT)
>
> I then have another INF for mf\uarts that does this using mf.sys:
> HKR, Child0000, HardwareID, MF\serial
> HKR, Child0000, VaryingResourceMap,1,00, 00,00,00,00, 20,00,00,00
> HKR, Child0000, ResourceMap,1,01
> HKR, Child0001, HardwareID, MF\serial
> HKR, Child0001, VaryingResourceMap,1,00, 20,00,00,00, 20,00,00,00
> HKR, Child0001, ResourceMap,1,01
> HKR, Child0002, HardwareID, MF\serial
> HKR, Child0002, VaryingResourceMap,1,00, 40,00,00,00, 20,00,00,00
> HKR, Child0002, ResourceMap,1,01
> HKR, Child0003, HardwareID, MF\serial
> HKR, Child0003, VaryingResourceMap,1,00, 60,00,00,00, 20,00,00,00
> HKR, Child0003, ResourceMap,1,01
>
> Lastly, I have an INF for MF\serial that installs the serial driver for
> each uart. During installation the device manager complains that the
> device can’t find enough free resources to use. I’m expecting each com
> port to get the resources that I specified for each MF\serial.
>
> If I remove the top-level INF that splits out each BAR it works just fine.
> In that case the INF above specifying the varyingresourcemap’s targets the
> xxxx&yyyy hardware ID instead of mf\uarts.
>
> Any ideas?
>

Doron_Holan · January 9, 2013, 2:28pm

If I read the infs correctly I think he trying to create a two level deep mf stack, loading mf on a child enumerated by mf. I have never heard of doing that, I think it is not supported

d

debt from my phone

From: Pavel A.
Sent: 1/9/2013 11:22 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Trouble with mf.sys

I don’t have my old examlpes handy but IIRC the child devices should not be
defined in two INFs.
So, keep only the INF where MF\serial are defined, and remove the other
where MF\uarts is defined.
– pa

wrote in message news:xxxxx@ntdev…
> I must be overlooking something and could use some help.
>
> I’m writing drivers for PCI device as follows.
>
> VendorID: xxxx DeviceID: yyyyy
> BAR0: multiple serial uarts
> BAR1: some other feature that will have a driver all its own
>
> I’ve got a top-level INF for xxxx&yyyy that does this using mf.sys:
> HKR, Child0000, HardwareID, MF\uarts
> HKR, Child0000, ResourceMap,1,00,08 ; Resources 00 (BAR0), 08 (INT)
> HKR, Child0001, HardwareID, MF\other
> HKR, Child0001, ResourceMap,1,02,08 ; Resources 02 (BAR1), 08 (INT)
>
> I then have another INF for mf\uarts that does this using mf.sys:
> HKR, Child0000, HardwareID, MF\serial
> HKR, Child0000, VaryingResourceMap,1,00, 00,00,00,00, 20,00,00,00
> HKR, Child0000, ResourceMap,1,01
> HKR, Child0001, HardwareID, MF\serial
> HKR, Child0001, VaryingResourceMap,1,00, 20,00,00,00, 20,00,00,00
> HKR, Child0001, ResourceMap,1,01
> HKR, Child0002, HardwareID, MF\serial
> HKR, Child0002, VaryingResourceMap,1,00, 40,00,00,00, 20,00,00,00
> HKR, Child0002, ResourceMap,1,01
> HKR, Child0003, HardwareID, MF\serial
> HKR, Child0003, VaryingResourceMap,1,00, 60,00,00,00, 20,00,00,00
> HKR, Child0003, ResourceMap,1,01
>
> Lastly, I have an INF for MF\serial that installs the serial driver for
> each uart. During installation the device manager complains that the
> device can’t find enough free resources to use. I’m expecting each com
> port to get the resources that I specified for each MF\serial.
>
> If I remove the top-level INF that splits out each BAR it works just fine.
> In that case the INF above specifying the varyingresourcemap’s targets the
> xxxx&yyyy hardware ID instead of mf\uarts.
>
> Any ideas?
>

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Tim_Roberts · January 9, 2013, 2:29pm

Pavel A. wrote:

I don’t have my old examlpes handy but IIRC the child devices should not be
defined in two INFs.
So, keep only the INF where MF\serial are defined, and remove the other
where MF\uarts is defined.

I think you’ve misread his intentions. He has one PCI device subdivided
using MF.SYS. He is then re-subdividing one of those child devices into
another set of children, again using MF.SYS.

±- MF/serial
±- MF/serial
± MF/uarts --±- MF/serial
PCI -| ±- MF/serial
|
± MF/other

I don’t know whether that can be made to work at all (as I recall,
MF.SYS is somewhat finicky), but if it can, two INFs would be required.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Shane_Corbin · January 9, 2013, 2:50pm

Doron and Tim are correct. That is exactly what I’m “trying” to do. It makes sense theoretically (to me), but I’m not sure of the limitations of mf.sys.

If in fact mf.sys doesn’t allow recursive enumeration in this way it seems I would be better suited to write a simple bus driver for the MF/uarts device that does nothing more than create the appropriate number of MF/serial children as illustrated by Tim. It’s unfortunate because it doesn’t provide any additional functionality and would otherwise be a perfect candidate for mf.sys.

Doron_Holan · January 9, 2013, 2:59pm

Why can’t you flatten the hierarchy and just enumerate the com ports at children of the hw. If you write your own bus driver you will not be able to directly assign HW resources to the child stacks

d

From: xxxxx@hotmail.com mailto:xxxxx
Sent: ?1/?9/?2013 11:50 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Trouble with mf.sys

Doron and Tim are correct. That is exactly what I’m “trying” to do. It makes sense theoretically (to me), but I’m not sure of the limitations of mf.sys.

If in fact mf.sys doesn’t allow recursive enumeration in this way it seems I would be better suited to write a simple bus driver for the MF/uarts device that does nothing more than create the appropriate number of MF/serial children as illustrated by Tim. It’s unfortunate because it doesn’t provide any additional functionality and would otherwise be a perfect candidate for mf.sys.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>

Shane_Corbin · January 9, 2013, 3:28pm

I can, and I probably will for this instance. I was trying to modularize the subfunctions of this device such that reuse in other devices would be straightforward. Visually here’s what I was going for:

Available components: PCI Device#1 PCI Device#2 PCI Device#3

uarts BAR0:uarts BAR0:widgets BAR0:monkeytails
widgets BAR1:monkeytails BAR1:thingamajigs BAR1:widgets
thingamajigs BAR2:uarts
monkeytails

It probably doesn’t buy me as much flexibility as I was originally envisioning.

Pavel_A1 · January 9, 2013, 4:12pm

wrote in message news:xxxxx@ntdev…
> I can, and I probably will for this instance. I was trying to modularize
> the subfunctions of this device such that reuse in other devices would be
> straightforward. Visually here’s what I was going for:
>
> Available components: PCI Device#1 PCI Device#2
> PCI Device#3
> -------------------------- ---------------- ---------------
> ----------------
> uarts BAR0:uarts
> BAR0:widgets BAR0:monkeytails
> widgets BAR1:monkeytails
> BAR1:thingamajigs BAR1:widgets
> thingamajigs
> BAR2:uarts
> monkeytails
>
> It probably doesn’t buy me as much flexibility as I was originally
> envisioning.

Yes. Simplicity is a virtue.
– pa

Shane_Corbin · January 9, 2013, 4:18pm

Well that didn’t format like I was expecting.