serial.sys support for m;ultiport UART, each with 16550 interface?

Charles_Gardiner · October 3, 2011, 10:20am

Hi,

I seem to be walking around in circles while searching for this on the microsoft
page / WDK Docu. Maybe somebody here knows the answer offhand.

In the WDK, I read the following as one of the features for serial.sys
* Supports an unlimited number of stand-alone serial ports, COM ports, and
multiport boards.

Does this mean I can do something like the following:
* put 12 16550 UARTS behind a single PCI device function in an FPGA

* identify the classcode as 0x07/0x02/0x00 (or is 0x07/0x00/0x03, 16550
compatable better)

* Expect each device to be accessed through (n * 8) + reg_no over the BAR0
resource, n being the UART index in the multiport device.

* write an *INF file for the device-ID /vendor-ID of my FPGA pointing to
serial.sys as the driver and specifying the number of UARTS so that I get the
following registry settings:

setting MultiportDevice to 1
setting ShareSystemInterrupt to 1
setting PortName to COMn for each device
maybe a few other bit-n-pieces

* not have to write my own driver at all

Regards,
Charles

David_R_Cattley · October 3, 2011, 11:09am

I suggest you look at the %windir%\inf\pnports.inf file and in particular the support built into the platform for “multi-port” *PNP502 devices.

If you want to use the inbox support (SERIAL.SYS) then you must conform to its expected model for multiport serial devices. If you do this, you may not need an INF at all.

Good Luck,
Dave Cattley

Charles_Gardiner · October 3, 2011, 1:10pm

Am 03.10.2011 17:08, schrieb Dave Cattley:

I suggest you look at the %windir%\inf\pnports.inf file and in particular the
support built into the platform for “multi-port” *PNP502 devices.

Sorry, can’t find pnports.inf on any of my systems (XP, 2k3, Win7). Searching for
PNP502 hasn’t been too successful either, apart form learning that ‘PNP’ is the
Microsoft ID.

If you want to use the inbox support (SERIAL.SYS) then you must conform to its
expected model for multiport serial devices. If you do this, you may not need an
INF at all.

This would indeed be the ideal case. Being an FPGA, I can make the PCI
config-space look whatever way is needed. Is there a spec for this somewhere? The
only thing I have dug up so far is
http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/pnpcom.rtf

with the title "Plug and Play External COM Device Specification [142 KB] " which
doesn’t quite sound right to me. Surely this is for modems and things that you
plug into a serial port?

Again, what I am looking to do is 12 UARTS on a pci-card, ideally with a standard
system driver.

Good Luck,
Dave Cattley

Thanks,
Charles

Pavel_A1 · October 3, 2011, 1:39pm

On 03-Oct-2011 17:08, Dave Cattley wrote:

I suggest you look at the %windir%\inf\pnports.inf file and in
particular the support built into the platform for “multi-port” *PNP502
devices.

A multiport is simpler than implementing 12 PCI functions in FPGA
(though our engineers say that isn’t very hard) and also easier to install.

But that’s is the gotcha… Seems that I gave a bad advice to the OP:
all in-box MultiportSerial drivers in XP are either not PCI - or have
custom drivers. I don’t understand why serial.sys could not handle at
least “plain serial” cards.
The goal is to avoid writing a driver (except maybe an INF, that refers
to in-box serial.sys).

Regards,
– pa

If you want to use the inbox support (SERIAL.SYS) then you must conform
to its expected model for multiport serial devices. If you do this, you
may not need an INF at all.

Good Luck,
Dave Cattley

Charles_Gardiner · October 3, 2011, 2:03pm

Am 03.10.2011 19:38, schrieb Pavel A:

On 03-Oct-2011 17:08, Dave Cattley wrote:
> I suggest you look at the %windir%\inf\pnports.inf file and in
> particular the support built into the platform for “multi-port” *PNP502
> devices.

A multiport is simpler than implementing 12 PCI functions in FPGA (though our
engineers say that isn’t very hard) and also easier to install.

This is exactly why I am interested in doing so. 12 PCI functions needs at least
two PCI devices (i.e. two cards or two devices behind a bridge on the same card)

But that’s is the gotcha… Seems that I gave a bad advice to the OP: all in-box
MultiportSerial drivers in XP are either not PCI - or have custom drivers. I don’t
understand why serial.sys could not handle at least “plain serial” cards.
The goal is to avoid writing a driver (except maybe an INF, that refers to in-box
serial.sys).

Again, true. But is there a spec to adhere to? I already have a single FPGA block
with a 16550 compatible register set. But what needs to be done to make sure
serial.sys will get involved here? (Certain classcode in Config space header,
probably?, INF file entries? Devices arranged as stack of n devices and accessible
through BAR0 resource?..)

Regards,
– pa

> If you want to use the inbox support (SERIAL.SYS) then you must conform
> to its expected model for multiport serial devices. If you do this, you
> may not need an INF at all.
>
> Good Luck,
> Dave Cattley
>

Thanks,
Charles

Doron_Holan · October 3, 2011, 2:08pm

What you want is a pci device that is multi function that you can load mf.sys on to split the functions apart. Each function will need to look like a 16550 uart (1 interrupt, 8 ports IIRC). you will run into PCI limitations in terms of the number of functions you can expose.

All of the pre pci isa based multiport serial port card stuff is non standardized vendor value add goo. Not fun stuff, you don’t want to depend on it.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A
Sent: Monday, October 03, 2011 10:39 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] serial.sys support for m;ultiport UART, each with 16550 interface?

On 03-Oct-2011 17:08, Dave Cattley wrote:

I suggest you look at the %windir%\inf\pnports.inf file and in
particular the support built into the platform for “multi-port”
*PNP502 devices.

A multiport is simpler than implementing 12 PCI functions in FPGA (though our engineers say that isn’t very hard) and also easier to install.

But that’s is the gotcha… Seems that I gave a bad advice to the OP:
all in-box MultiportSerial drivers in XP are either not PCI - or have custom drivers. I don’t understand why serial.sys could not handle at least “plain serial” cards.
The goal is to avoid writing a driver (except maybe an INF, that refers to in-box serial.sys).

Regards,
– pa

If you want to use the inbox support (SERIAL.SYS) then you must
conform to its expected model for multiport serial devices. If you do
this, you may not need an INF at all.

Good Luck,
Dave Cattley

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

Charles_Gardiner · October 3, 2011, 2:17pm

Am 03.10.2011 20:07, schrieb Doron Holan:

What you want is a pci device that is multi function that you can load mf.sys
on to split the functions apart. Each function will need to look like a 16550
uart (1 interrupt, 8 ports IIRC). you will run into PCI limitations in terms
of the number of functions you can expose.

So the following statement regarding serial.sys in the WDK does not apply to
multiport 16550s behind a single PCI device function?

“Supports an unlimited number of stand-alone serial ports, COM ports, and
multiport boards.”

I did see an older mail from you on this newsgroup from 2004 to that effect. I had
hoped windows had improved since then.

All of the pre pci isa based multiport serial port card stuff is non
standardized vendor value add goo. Not fun stuff, you don’t want to depend on
it.

d

-----Original Message----- From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A Sent: Monday,
October 03, 2011 10:39 AM To: Windows System Software Devs Interest List
Subject: Re:[ntdev] serial.sys support for m;ultiport UART, each with 16550
interface?

On 03-Oct-2011 17:08, Dave Cattley wrote:
> I suggest you look at the %windir%\inf\pnports.inf file and in particular the
> support built into the platform for “multi-port” *PNP502 devices.

A multiport is simpler than implementing 12 PCI functions in FPGA (though our
engineers say that isn’t very hard) and also easier to install.

But that’s is the gotcha… Seems that I gave a bad advice to the OP: all
in-box MultiportSerial drivers in XP are either not PCI - or have custom
drivers. I don’t understand why serial.sys could not handle at least “plain
serial” cards. The goal is to avoid writing a driver (except maybe an INF, that
refers to in-box serial.sys).

Regards, – pa

> If you want to use the inbox support (SERIAL.SYS) then you must conform to
> its expected model for multiport serial devices. If you do this, you may not
> need an INF at all.
>
> Good Luck, Dave Cattley
>

— 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

Doron_Holan · October 3, 2011, 2:22pm

Serial itself can load on as many serial port based devices that are presented to the system. Key word here is presented. The limitation is how they are exposed. This is a pci based limitation, it has nothing to with serial itself. This is nothing that windows could do to improve on, it is cooked in to the pci spec

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Charles
Sent: Monday, October 03, 2011 11:17 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] serial.sys support for m;ultiport UART, each with 16550 interface?

Am 03.10.2011 20:07, schrieb Doron Holan:

What you want is a pci device that is multi function that you can load
mf.sys on to split the functions apart. Each function will need to
look like a 16550 uart (1 interrupt, 8 ports IIRC). you will run into
PCI limitations in terms of the number of functions you can expose.

So the following statement regarding serial.sys in the WDK does not apply to multiport 16550s behind a single PCI device function?

“Supports an unlimited number of stand-alone serial ports, COM ports, and multiport boards.”

I did see an older mail from you on this newsgroup from 2004 to that effect. I had hoped windows had improved since then.

All of the pre pci isa based multiport serial port card stuff is non
standardized vendor value add goo. Not fun stuff, you don’t want to
depend on it.

d

-----Original Message----- From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A Sent:
Monday, October 03, 2011 10:39 AM To: Windows System Software Devs
Interest List
Subject: Re:[ntdev] serial.sys support for m;ultiport UART, each with
16550 interface?

On 03-Oct-2011 17:08, Dave Cattley wrote:
> I suggest you look at the %windir%\inf\pnports.inf file and in
> particular the support built into the platform for “multi-port” *PNP502 devices.

A multiport is simpler than implementing 12 PCI functions in FPGA
(though our engineers say that isn’t very hard) and also easier to install.

But that’s is the gotcha… Seems that I gave a bad advice to the OP:
all in-box MultiportSerial drivers in XP are either not PCI - or have
custom drivers. I don’t understand why serial.sys could not handle at
least “plain serial” cards. The goal is to avoid writing a driver
(except maybe an INF, that refers to in-box serial.sys).

Regards, – pa

> If you want to use the inbox support (SERIAL.SYS) then you must
> conform to its expected model for multiport serial devices. If you do
> this, you may not need an INF at all.
>
> Good Luck, Dave Cattley
>

— 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

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

Charles_Gardiner · October 3, 2011, 2:49pm

Am 03.10.2011 20:21, schrieb Doron Holan:

Serial itself can load on as many serial port based devices that are presented
to the system. Key word here is presented. The limitation is how they are
exposed. This is a pci based limitation, it has nothing to with serial itself.
This is nothing that windows could do to improve on, it is cooked in to the pci
spec

For class-code/subclass/interface 0x07/0x00/0x03 (16550 compatible serial
controller), I can see your point. One UART per functions means a max of 8 devices
on a PCI card. That’s PCI.

But what about 0x07/0x02/0x00 (multi-port serial controller) is that not handled
by serial.sys using PnP mechanisms? I don’t think there would be too many
objections to assuming the 16550 register map as an “industry standard”, at least
for the default interface 0x00. ‘n’ functions could just be ‘n’ repetitions of the
16550 register map

d

-----Original Message----- From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Charles Sent: Monday,
October 03, 2011 11:17 AM To: Windows System Software Devs Interest List
Subject: Re:[ntdev] serial.sys support for m;ultiport UART, each with 16550
interface?

Am 03.10.2011 20:07, schrieb Doron Holan:
> What you want is a pci device that is multi function that you can load mf.sys
> on to split the functions apart. Each function will need to look like a 16550
> uart (1 interrupt, 8 ports IIRC). you will run into PCI limitations in terms
> of the number of functions you can expose.
>

So the following statement regarding serial.sys in the WDK does not apply to
multiport 16550s behind a single PCI device function?

“Supports an unlimited number of stand-alone serial ports, COM ports, and
multiport boards.”

I did see an older mail from you on this newsgroup from 2004 to that effect. I
had hoped windows had improved since then.

> All of the pre pci isa based multiport serial port card stuff is non
> standardized vendor value add goo. Not fun stuff, you don’t want to depend
> on it.
>
> d
>
> -----Original Message----- From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A Sent: Monday,
> October 03, 2011 10:39 AM To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] serial.sys support for m;ultiport UART, each with 16550
> interface?
>
> On 03-Oct-2011 17:08, Dave Cattley wrote:
>> I suggest you look at the %windir%\inf\pnports.inf file and in particular
>> the support built into the platform for “multi-port” *PNP502 devices.
>
> A multiport is simpler than implementing 12 PCI functions in FPGA (though our
> engineers say that isn’t very hard) and also easier to install.
>
> But that’s is the gotcha… Seems that I gave a bad advice to the OP: all
> in-box MultiportSerial drivers in XP are either not PCI - or have custom
> drivers. I don’t understand why serial.sys could not handle at least “plain
> serial” cards. The goal is to avoid writing a driver (except maybe an INF,
> that refers to in-box serial.sys).
>
> Regards, – pa
>
>> If you want to use the inbox support (SERIAL.SYS) then you must conform to
>> its expected model for multiport serial devices. If you do this, you may
>> not need an INF at all.
>>
>> Good Luck, Dave Cattley
>>
>
>
> — 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
>
>

— 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

Charles_Gardiner · October 3, 2011, 3:21pm

Am 03.10.2011 20:21, schrieb Doron Holan:

Serial itself can load on as many serial port based devices that are presented
to the system. Key word here is presented. The limitation is how they are
exposed. This is a pci based limitation, it has nothing to with serial itself.
This is nothing that windows could do to improve on, it is cooked in to the pci
spec

d

Refering to this page (and parts of my original question) on the MS website,
http://msdn.microsoft.com/en-us/library/windows/hardware/ff546972(v=vs.85).aspx

Does that not suggest that multiple 16550 compatible devices are supported behind
a single PCI function if I setup an INF file to create the required registry
settings and select serial.sys as the driver in the ‘copy’ section of the INF File?

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
This topic describes the registry settings that Serial uses as a function driver
for a Plug and Play serial device. Serial also uses these settings as a
lower-level device filter driver for a device that requires a 16550
UART-compatible interface.

Serial queries these registry entry values when it adds the device. If a
device-specific entry value is not present, Serial uses a Serial service value.

The following registry settings are under the Plug and Play registry key for a device.

PortName (REG_SZ)
Specifies the name of the device. The name of a device is typically COM,
where is a COM port number that the installer obtains from the COM port
database. However, the device can be set to any non-NULL string. If the device is
configured as a COM port, Serial uses the port name to create a symbolic link name
for the device. The default value of PortName is an empty string.

Identifier (REG_SZ)
Specifies the name of the device. The support for an Identifier entry value is
provided for compatibility with some legacy PCMCIA devices. The use of Identifier
is obsolete and should not be used with Microsoft Windows 2000 and later drivers.
For a description, see the PortName entry value.

MultiportDevice (REG_DWORD)
Specifies a Boolean flag that indicates whether a serial port is a device on a
multiport device. If MultiportDevice is 0x00000000, the serial port is a
stand-alone device; otherwise, the serial port is on a multiport device. The
default value of MultiportDevice is 0x00000000.

PortIndex (REG_DWORD)
Specifies the index number of a serial port on a multiport device. The Indexed
entry value specifies whether a port is bitmapped or indexed. The default value of
PortIndex is 0x00000000.

ClockRate (REG_DWORD)
Specifies the UART clock rate. The default value of ClockRate is 1843200 Hertz.

Indexed (REG_DWORD)
Specifies a Boolean flag that indicates whether a port on a multiport device
is bitmapped or indexed. If Indexed is nonzero, the port is indexed; otherwise,
the port is bitmapped. Indexed is used in conjunction with the PortIndex entry
value. The default value of Indexed is 0x00000000.

DisablePort (REG_DWORD)
Boolean flag that specifies whether to disable the device. If DisablePort is
nonzero, Serial disables the device; otherwise, the device is enabled. Use of the
DisablePort entry value is obsolete and should not be used with Windows 2000 and
later drivers. Windows 2000 provides a generic manual method through the GUI of
Device Manager to enable and disable devices. The default value of DisablePort is
0x00000000. Note that flagging a device as disabled does not mean that the device
does not exist. Serial still attempts to detect the presence of a disabled device.
If the device is specified as disabled, Serial returns STATUS_NO_SUCH_DEVICE in
response to an IRP_MN_START_DEVICE request. After the start request fails, the
Plug and Play manager sends a remove request.

ForceFifoEnable (REG_DWORD)
Specifies a Boolean flag that indicates whether to force Serial to use FIFOs.
If ForceFifoEnable is nonzero, FIFOs are used, regardless of whether Serial can
detect the presence of FIFOs. Otherwise, FIFOs are only used if Serial can detect
them. The default value of ForceFifoEnable is the value set for the Serial
service. (The default value for the Serial service is 0x00000001.)

RxFIFO (REG_DWORD)
Specifies the number of bytes in the receive FIFO that triggers a serial port
interrupt. For valid values, see the constants defined in serial.h. The default
value of RxFIFO is the value set for the Serial service. (The default value for
the Serial service is eight bytes.)

TxFIFO (REG_DWORD)
Specifies the number of bytes in the transmit FIFO that triggers a serial
device interrupt. For valid values, see the constants defined in serial.h. The
default value of TxFIFO is the value set for the Serial service. (The default
value for the Serial service is fourteen bytes.)

MaskInverted (REG_DWORD)
Specifies a Boolean flag that indicates whether the serial device hardware
inverts the contents of the interrupt status register. If MaskInverted is nonzero,
the interrupt status register is inverted; otherwise, the interrupt status
register is not inverted. The default value of MaskInverted is 0x00000000.

SerialSkipExternalNaming (REG_DWORD)
Specifies a Boolean flag that indicates whether Serial configures the device
as a COM port. If SerialSkipExternalNaming is set to 0x00000000, Serial configures
the device as a COM port; otherwise, Serial does not configure the device as a COM
port. The default value of SerialSkipExternalNaming is 0x00000000. For more
information about how Serial configures a device as a COM port, see External
Naming of COM Ports.

SerialRelinquishPowerPolicy (REG_DWORD)
Specifies a Boolean flag that indicates whether Serial is the power policy
owner for a serial device stack. If SerialRelinquishPowerPolicy is zero, Serial is
the power policy owner; otherwise, Serial is not the power policy owner. The
default value of SerialRelinquishPowerPolicy is 0x00000000.

Share System Interrupt (REG_DWORD)
Boolean flag that specifies whether to permit the system to share the
interrupt that the device uses. If Share System Interrupt is nonzero, the
interrupt can be shared; otherwise, the interrupt cannot be shared. The default
value of Share System Interrupt is the value set for the PermitShare entry value
for the Serial service. (The default service value for PermitShare is 0x00000000.)

SerialIoResourcesIndex (REG_DWORD)
Specifies the index of the partial resource descriptor that Serial uses to
determine the I/O addresses of the serial register set for the device. The default
value of SerialIoResourceIndex is 0x00000000.

David_R_Cattley · October 3, 2011, 7:56pm

Sorry. On Win7 it is named MSPORTS.INF. It was never named PNPORTS.INF
as that is a typo of PNPPORTS.INF which I cannot recall if that is the WinXP
name or where I pulled that out of.

Good Luck,
Dave Cattley

Jake_Oshins · October 4, 2011, 12:41am

The class code is essentially irrelevant, as there’s no PCI class code that
means “here’s the exact programming interface for this class code, and it’s
compatible with a 16550.”

Similarly, there’s no such thing as perfectly 16550-compatible on PCI,
because you may be forced to use your line-based interrupt instead of MSI,
and line-based interrupts are level-triggered and a 16550’s interrupts are
edge-triggered.

Furthermore, people have discovered over many years that amalgamating 12 or
more actual 16550’s on a single board would generate a truly astounding
number of interrupts. So almost everybody eventually decides to depart, at
least slightly, from the “just a bunch of UARTs” strategy. I encourage you
to depart from this, too.

And once you’ve departed from something that’s perfectly 16550 compatible,
you’re going to need a custom driver. Start with the sample. Go from
there.

Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group

This post implies no warranties and confers no rights.

“Charles” wrote in message news:xxxxx@ntdev…

Hi,

I seem to be walking around in circles while searching for this on the
microsoft
page / WDK Docu. Maybe somebody here knows the answer offhand.

In the WDK, I read the following as one of the features for serial.sys
* Supports an unlimited number of stand-alone serial ports, COM ports, and
multiport boards.

Does this mean I can do something like the following:
* put 12 16550 UARTS behind a single PCI device function in an FPGA

* identify the classcode as 0x07/0x02/0x00 (or is 0x07/0x00/0x03, 16550
compatable better)

* Expect each device to be accessed through (n * 8) + reg_no over the BAR0
resource, n being the UART index in the multiport device.

* write an *INF file for the device-ID /vendor-ID of my FPGA pointing to
serial.sys as the driver and specifying the number of UARTS so that I get
the
following registry settings:

setting MultiportDevice to 1
setting ShareSystemInterrupt to 1
setting PortName to COMn for each device
maybe a few other bit-n-pieces

* not have to write my own driver at all

Regards,
Charles

Pavel_A1 · October 4, 2011, 5:39am

On 03-Oct-2011 20:21, Doron Holan wrote:

Serial itself can load on as many serial port based devices that are presented to the system. Key word here is presented. The limitation is how they are exposed. This is a pci based limitation, it has nothing to with serial itself. This is nothing that windows could do to improve on, it is cooked in to the pci spec

d

Doron,

So, does mf.sys support pci devices? Can what the OP wants be done
only with WinXP mf.sys and in-box (or slightly hacked) serial.sys?
(as “fast and dirty” approach, delaying the interrupt
performance concerns mentioned by Jake O.?)

Thanks,
– pa

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Charles
Sent: Monday, October 03, 2011 11:17 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] serial.sys support for m;ultiport UART, each with 16550 interface?

Am 03.10.2011 20:07, schrieb Doron Holan:
> What you want is a pci device that is multi function that you can load
> mf.sys on to split the functions apart. Each function will need to
> look like a 16550 uart (1 interrupt, 8 ports IIRC). you will run into
> PCI limitations in terms of the number of functions you can expose.
>

So the following statement regarding serial.sys in the WDK does not apply to multiport 16550s behind a single PCI device function?

“Supports an unlimited number of stand-alone serial ports, COM ports, and multiport boards.”

I did see an older mail from you on this newsgroup from 2004 to that effect. I had hoped windows had improved since then.

> All of the pre pci isa based multiport serial port card stuff is non
> standardized vendor value add goo. Not fun stuff, you don’t want to
> depend on it.
>
> d
>
> -----Original Message----- From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A Sent:
> Monday, October 03, 2011 10:39 AM To: Windows System Software Devs
> Interest List
> Subject: Re:[ntdev] serial.sys support for m;ultiport UART, each with
> 16550 interface?
>
> On 03-Oct-2011 17:08, Dave Cattley wrote:
>> I suggest you look at the %windir%\inf\pnports.inf file and in
>> particular the support built into the platform for “multi-port” *PNP502 devices.
>
> A multiport is simpler than implementing 12 PCI functions in FPGA
> (though our engineers say that isn’t very hard) and also easier to install.
>
> But that’s is the gotcha… Seems that I gave a bad advice to the OP:
> all in-box MultiportSerial drivers in XP are either not PCI - or have
> custom drivers. I don’t understand why serial.sys could not handle at
> least “plain serial” cards. The goal is to avoid writing a driver
> (except maybe an INF, that refers to in-box serial.sys).
>
> Regards, – pa
>
>> If you want to use the inbox support (SERIAL.SYS) then you must
>> conform to its expected model for multiport serial devices. If you do
>> this, you may not need an INF at all.
>>
>> Good Luck, Dave Cattley
>>

Doron_Holan · October 4, 2011, 10:12am

Mf.sys exists purely to split apart functions on a PCI device, it does nothing else. If you hijack serial.sys with your own version, you don’t need mf.sys anymore because your hijacked version can use a private interface to query for resource assignment from your custom bus driver that replaces mf.sys in this particular scenario

d

debt from my phone

From: Pavel A
Sent: 10/4/2011 2:40 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] serial.sys support for m;ultiport UART, each with 16550 interface?

On 03-Oct-2011 20:21, Doron Holan wrote:

Serial itself can load on as many serial port based devices that are presented to the system. Key word here is presented. The limitation is how they are exposed. This is a pci based limitation, it has nothing to with serial itself. This is nothing that windows could do to improve on, it is cooked in to the pci spec

d

Doron,

So, does mf.sys support pci devices? Can what the OP wants be done
only with WinXP mf.sys and in-box (or slightly hacked) serial.sys?
(as “fast and dirty” approach, delaying the interrupt
performance concerns mentioned by Jake O.?)

Thanks,
– pa

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Charles
Sent: Monday, October 03, 2011 11:17 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] serial.sys support for m;ultiport UART, each with 16550 interface?

Am 03.10.2011 20:07, schrieb Doron Holan:
> What you want is a pci device that is multi function that you can load
> mf.sys on to split the functions apart. Each function will need to
> look like a 16550 uart (1 interrupt, 8 ports IIRC). you will run into
> PCI limitations in terms of the number of functions you can expose.
>

So the following statement regarding serial.sys in the WDK does not apply to multiport 16550s behind a single PCI device function?

“Supports an unlimited number of stand-alone serial ports, COM ports, and multiport boards.”

I did see an older mail from you on this newsgroup from 2004 to that effect. I had hoped windows had improved since then.

> All of the pre pci isa based multiport serial port card stuff is non
> standardized vendor value add goo. Not fun stuff, you don’t want to
> depend on it.
>
> d
>
> -----Original Message----- From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A Sent:
> Monday, October 03, 2011 10:39 AM To: Windows System Software Devs
> Interest List
> Subject: Re:[ntdev] serial.sys support for m;ultiport UART, each with
> 16550 interface?
>
> On 03-Oct-2011 17:08, Dave Cattley wrote:
>> I suggest you look at the %windir%\inf\pnports.inf file and in
>> particular the support built into the platform for “multi-port” *PNP502 devices.
>
> A multiport is simpler than implementing 12 PCI functions in FPGA
> (though our engineers say that isn’t very hard) and also easier to install.
>
> But that’s is the gotcha… Seems that I gave a bad advice to the OP:
> all in-box MultiportSerial drivers in XP are either not PCI - or have
> custom drivers. I don’t understand why serial.sys could not handle at
> least “plain serial” cards. The goal is to avoid writing a driver
> (except maybe an INF, that refers to in-box serial.sys).
>
> Regards, – pa
>
>> If you want to use the inbox support (SERIAL.SYS) then you must
>> conform to its expected model for multiport serial devices. If you do
>> this, you may not need an INF at all.
>>
>> Good Luck, Dave Cattley
>>

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

Charles_Gardiner · October 4, 2011, 12:28pm

Am 04.10.2011 06:40, schrieb Jake Oshins:

The class code is essentially irrelevant, as there’s no PCI class code that means
“here’s the exact programming interface for this class code, and it’s compatible
with a 16550.”

Well I’ll have to disagree with you on that point. PCI Local Bus version 3.0, page
300 clearly says, class/subclass/interface 0x07/0x00/0x02 means “16550 compatible
serial controller”. Of course I assume only the programming interface is
considered. Level/Edge signalled interrupts and possibly even features like FIFO
depth are not necessarily implied. Let’s just say the programming model is ‘close
enough to be usable in most cases’

Similarly, there’s no such thing as perfectly 16550-compatible on PCI, because you
may be forced to use your line-based interrupt instead of MSI, and line-based
interrupts are level-triggered and a 16550’s interrupts are edge-triggered.

Furthermore, people have discovered over many years that amalgamating 12 or more
actual 16550’s on a single board would generate a truly astounding number of
interrupts. So almost everybody eventually decides to depart, at least slightly,
from the “just a bunch of UARTs” strategy. I encourage you to depart from this, too.

I’ll agree 100% on this. But Microsoft issuing statements like
“Supports an unlimited number of stand-alone serial ports, COM ports, and
multiport boards.” as I’ve quoted in the other part of this thread doesn’t help.

My customer reads things like that (or has somebody who reads things like that)
and takes them for something close to trivial to implement. Firstly, I just need
to get a demo up and running on an FPGA board. Preferably with some flashing
lights or something like that (maybe I can get it to make a few noises as well)
and then when I explain the problems and can back up them up with something like
80% system activity on the task manager I can probably convince him to go a DMA
route with custom driver and less interrupt activity. i.e. first give him what he
wants and then what he needs (hope he’s not listening)

And once you’ve departed from something that’s perfectly 16550 compatible, you’re
going to need a custom driver. Start with the sample. Go from there.

Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group

This post implies no warranties and confers no rights.

Doron_Holan · October 4, 2011, 12:36pm

> Supports an unlimited number of stand-alone serial ports, COM ports, and multiport boards." as I’ve quoted in the other part of this thread doesn’t help.

This is purely misunderstand what this statement intends to say. I explained in my previous reply what the intent was. This statement in no way implies anything or says anything about the underlying hardare (pci, isa, usb, whatever) that exposes the com port and any issues associated with that, rather it is just saying that there are no hard coded max values in the serial driver

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Charles
Sent: Tuesday, October 04, 2011 9:28 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] serial.sys support for m;ultiport UART, each with 16550 interface?

Am 04.10.2011 06:40, schrieb Jake Oshins:

The class code is essentially irrelevant, as there’s no PCI class code
that means “here’s the exact programming interface for this class
code, and it’s compatible with a 16550.”

Well I’ll have to disagree with you on that point. PCI Local Bus version 3.0, page
300 clearly says, class/subclass/interface 0x07/0x00/0x02 means “16550 compatible serial controller”. Of course I assume only the programming interface is considered. Level/Edge signalled interrupts and possibly even features like FIFO depth are not necessarily implied. Let’s just say the programming model is ‘close enough to be usable in most cases’

Similarly, there’s no such thing as perfectly 16550-compatible on PCI,
because you may be forced to use your line-based interrupt instead of
MSI, and line-based interrupts are level-triggered and a 16550’s interrupts are edge-triggered.

Furthermore, people have discovered over many years that amalgamating
12 or more actual 16550’s on a single board would generate a truly
astounding number of interrupts. So almost everybody eventually
decides to depart, at least slightly, from the “just a bunch of UARTs” strategy. I encourage you to depart from this, too.

I’ll agree 100% on this. But Microsoft issuing statements like “Supports an unlimited number of stand-alone serial ports, COM ports, and multiport boards.” as I’ve quoted in the other part of this thread doesn’t help.

My customer reads things like that (or has somebody who reads things like that) and takes them for something close to trivial to implement. Firstly, I just need to get a demo up and running on an FPGA board. Preferably with some flashing lights or something like that (maybe I can get it to make a few noises as well) and then when I explain the problems and can back up them up with something like 80% system activity on the task manager I can probably convince him to go a DMA route with custom driver and less interrupt activity. i.e. first give him what he wants and then what he needs (hope he’s not listening)

And once you’ve departed from something that’s perfectly 16550
compatible, you’re going to need a custom driver. Start with the sample. Go from there.

Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group

This post implies no warranties and confers no rights.

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

Pavel_A1 · October 4, 2011, 1:36pm

“Doron Holan” wrote in message
news:xxxxx@ntdev…
> Mf.sys exists purely to split apart functions on a PCI device, it does
> nothing else. If you hijack serial.sys with your own version, you don’t
> need mf.sys anymore because your hijacked version can use a private
> interface to query for resource assignment from your custom bus driver
> that replaces mf.sys in this particular scenario
>
> d
>
> debt from my phone

Then, why a bus driver? one driver can register several COM ports as
“legacy” devices?

– pa

________________________________
> From: Pavel A
> Sent: 10/4/2011 2:40 AM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] serial.sys support for m;ultiport UART, each with
> 16550 interface?
>
> On 03-Oct-2011 20:21, Doron Holan wrote:
>> Serial itself can load on as many serial port based devices that are
>> presented to the system. Key word here is presented. The limitation is
>> how they are exposed. This is a pci based limitation, it has nothing to
>> with serial itself. This is nothing that windows could do to improve on,
>> it is cooked in to the pci spec
>>
>> d
>
> Doron,
>
> So, does mf.sys support pci devices? Can what the OP wants be done
> only with WinXP mf.sys and in-box (or slightly hacked) serial.sys?
> (as “fast and dirty” approach, delaying the interrupt
> performance concerns mentioned by Jake O.?)
>
> Thanks,
> – pa
>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Charles
>> Sent: Monday, October 03, 2011 11:17 AM
>> To: Windows System Software Devs Interest List
>> Subject: Re:[ntdev] serial.sys support for m;ultiport UART, each with
>> 16550 interface?
>>
>> Am 03.10.2011 20:07, schrieb Doron Holan:
>>> What you want is a pci device that is multi function that you can load
>>> mf.sys on to split the functions apart. Each function will need to
>>> look like a 16550 uart (1 interrupt, 8 ports IIRC). you will run into
>>> PCI limitations in terms of the number of functions you can expose.
>>>
>>
>> So the following statement regarding serial.sys in the WDK does not apply
>> to multiport 16550s behind a single PCI device function?
>>
>> “Supports an unlimited number of stand-alone serial ports, COM ports, and
>> multiport boards.”
>>
>> I did see an older mail from you on this newsgroup from 2004 to that
>> effect. I had hoped windows had improved since then.
>>
>>> All of the pre pci isa based multiport serial port card stuff is non
>>> standardized vendor value add goo. Not fun stuff, you don’t want to
>>> depend on it.
>>>
>>> d
>>>
>>> -----Original Message----- From: xxxxx@lists.osr.com
>>> [mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A Sent:
>>> Monday, October 03, 2011 10:39 AM To: Windows System Software Devs
>>> Interest List
>>> Subject: Re:[ntdev] serial.sys support for m;ultiport UART, each with
>>> 16550 interface?
>>>
>>> On 03-Oct-2011 17:08, Dave Cattley wrote:
>>>> I suggest you look at the %windir%\inf\pnports.inf file and in
>>>> particular the support built into the platform for “multi-port” *PNP502
>>>> devices.
>>>
>>> A multiport is simpler than implementing 12 PCI functions in FPGA
>>> (though our engineers say that isn’t very hard) and also easier to
>>> install.
>>>
>>> But that’s is the gotcha… Seems that I gave a bad advice to the OP:
>>> all in-box MultiportSerial drivers in XP are either not PCI - or have
>>> custom drivers. I don’t understand why serial.sys could not handle at
>>> least “plain serial” cards. The goal is to avoid writing a driver
>>> (except maybe an INF, that refers to in-box serial.sys).
>>>
>>> Regards, – pa
>>>
>>>> If you want to use the inbox support (SERIAL.SYS) then you must
>>>> conform to its expected model for multiport serial devices. If you do
>>>> this, you may not need an INF at all.
>>>>
>>>> Good Luck, Dave Cattley
>

Doron_Holan · October 4, 2011, 2:20pm

Serial.sys won’t do that. You could have a custom expose multiple com ports from one device object, but then you have to deal with device namespaces and multiple symlinks. Doable, but more complicated.

d

debt from my phone

From: Pavel A.
Sent: 10/4/2011 10:36 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] serial.sys support for m;ultiport UART, each with 16550 interface?

“Doron Holan” wrote in message
news:xxxxx@ntdev…
> Mf.sys exists purely to split apart functions on a PCI device, it does
> nothing else. If you hijack serial.sys with your own version, you don’t
> need mf.sys anymore because your hijacked version can use a private
> interface to query for resource assignment from your custom bus driver
> that replaces mf.sys in this particular scenario
>
> d
>
> debt from my phone

Then, why a bus driver? one driver can register several COM ports as
“legacy” devices?

– pa

________________________________
> From: Pavel A
> Sent: 10/4/2011 2:40 AM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] serial.sys support for m;ultiport UART, each with
> 16550 interface?
>
> On 03-Oct-2011 20:21, Doron Holan wrote:
>> Serial itself can load on as many serial port based devices that are
>> presented to the system. Key word here is presented. The limitation is
>> how they are exposed. This is a pci based limitation, it has nothing to
>> with serial itself. This is nothing that windows could do to improve on,
>> it is cooked in to the pci spec
>>
>> d
>
> Doron,
>
> So, does mf.sys support pci devices? Can what the OP wants be done
> only with WinXP mf.sys and in-box (or slightly hacked) serial.sys?
> (as “fast and dirty” approach, delaying the interrupt
> performance concerns mentioned by Jake O.?)
>
> Thanks,
> – pa
>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Charles
>> Sent: Monday, October 03, 2011 11:17 AM
>> To: Windows System Software Devs Interest List
>> Subject: Re:[ntdev] serial.sys support for m;ultiport UART, each with
>> 16550 interface?
>>
>> Am 03.10.2011 20:07, schrieb Doron Holan:
>>> What you want is a pci device that is multi function that you can load
>>> mf.sys on to split the functions apart. Each function will need to
>>> look like a 16550 uart (1 interrupt, 8 ports IIRC). you will run into
>>> PCI limitations in terms of the number of functions you can expose.
>>>
>>
>> So the following statement regarding serial.sys in the WDK does not apply
>> to multiport 16550s behind a single PCI device function?
>>
>> “Supports an unlimited number of stand-alone serial ports, COM ports, and
>> multiport boards.”
>>
>> I did see an older mail from you on this newsgroup from 2004 to that
>> effect. I had hoped windows had improved since then.
>>
>>> All of the pre pci isa based multiport serial port card stuff is non
>>> standardized vendor value add goo. Not fun stuff, you don’t want to
>>> depend on it.
>>>
>>> d
>>>
>>> -----Original Message----- From: xxxxx@lists.osr.com
>>> [mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A Sent:
>>> Monday, October 03, 2011 10:39 AM To: Windows System Software Devs
>>> Interest List
>>> Subject: Re:[ntdev] serial.sys support for m;ultiport UART, each with
>>> 16550 interface?
>>>
>>> On 03-Oct-2011 17:08, Dave Cattley wrote:
>>>> I suggest you look at the %windir%\inf\pnports.inf file and in
>>>> particular the support built into the platform for “multi-port” *PNP502
>>>> devices.
>>>
>>> A multiport is simpler than implementing 12 PCI functions in FPGA
>>> (though our engineers say that isn’t very hard) and also easier to
>>> install.
>>>
>>> But that’s is the gotcha… Seems that I gave a bad advice to the OP:
>>> all in-box MultiportSerial drivers in XP are either not PCI - or have
>>> custom drivers. I don’t understand why serial.sys could not handle at
>>> least “plain serial” cards. The goal is to avoid writing a driver
>>> (except maybe an INF, that refers to in-box serial.sys).
>>>
>>> Regards, – pa
>>>
>>>> If you want to use the inbox support (SERIAL.SYS) then you must
>>>> conform to its expected model for multiport serial devices. If you do
>>>> this, you may not need an INF at all.
>>>>
>>>> Good Luck, Dave Cattley
>

—
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

Charles_Gardiner · October 4, 2011, 4:16pm

Am 04.10.2011 16:12, schrieb Doron Holan:

Mf.sys exists purely to split apart functions on a PCI device, it does nothing
else. If you hijack serial.sys with your own version, you don’t need mf.sys
anymore because your hijacked version can use a private interface to query for
resource assignment from your custom bus driver that replaces mf.sys in this
particular scenario

Doron,

if I come back to two phrases you have dropped on this thread

“bus driver” and
“Serial itself can load on as many serial port based devices that are presented
to the system”

would a solution like the following avoid the need for multi-function devices
(first question of course, would it work at all)

*) for namesake, identify my PCI device as class/sub-class/interface
0x06/0x80/0x00 (“Other bridge device”). All UARTS in the FPGA are connected to an
internal bus (wishbone, amba …)

*) write a bus-driver for this internal SoC bus. At first glance it looks as if
Oneys book has a chapter on this, although I would of course incline to a KMDF
solution

*) when this internal SoC bus is enunerated, successively return the individual
UARTS, identified as PNP502 devices

Will serial then load on each of these UARTs (assigning COM port numbers etc.) as
you mentioned in phrase 2) above?

Thanks,
Charles

Doron_Holan · October 4, 2011, 4:26pm

You should write your own bus driver with KMDF, anything else will be insanity. No, you won’t be able to get the in box serial driver to load. The ability to hand hardware resources (ports, interrupts, etc) to child device stacks is called resource arbitration. How to do resource arbitration is not documented, so only in box msft drivers can do it (pci, mf, acpi.sys primarily). If you create your own private version of serial.sys (it is an example in the wdk, so you have the full source to start from), you can get around this restriction by making a private interface between your custom serial.sys and your bus driver to query for the resources assigned to the port.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Charles
Sent: Tuesday, October 04, 2011 1:16 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] serial.sys support for m;ultiport UART, each with 16550 interface?

Am 04.10.2011 16:12, schrieb Doron Holan:

Mf.sys exists purely to split apart functions on a PCI device, it does
nothing else. If you hijack serial.sys with your own version, you
don’t need mf.sys anymore because your hijacked version can use a
private interface to query for resource assignment from your custom
bus driver that replaces mf.sys in this particular scenario

Doron,

if I come back to two phrases you have dropped on this thread

“bus driver” and
“Serial itself can load on as many serial port based devices that are presented to the system”

would a solution like the following avoid the need for multi-function devices (first question of course, would it work at all)

*) for namesake, identify my PCI device as class/sub-class/interface
0x06/0x80/0x00 (“Other bridge device”). All UARTS in the FPGA are connected to an internal bus (wishbone, amba …)

*) write a bus-driver for this internal SoC bus. At first glance it looks as if Oneys book has a chapter on this, although I would of course incline to a KMDF solution

*) when this internal SoC bus is enunerated, successively return the individual UARTS, identified as PNP502 devices

Will serial then load on each of these UARTs (assigning COM port numbers etc.) as you mentioned in phrase 2) above?

Thanks,
Charles

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