locating base address of PCI Parallel port

[jacks]

Hi all,

I'm developing an application for DOS. I need to communicate via parallel port.

Currently I'm stuck at how can I determine which of the PCI function's BAR(Base address registers) contain the base address(ie data port address) for that parallel port?

Precisely, is there a industry convention or standard or de-facto standard that a particular BAR will always contain the base address for that parallel port ?

If not, then how can I determine the base address for that PCI parallel port(whether on pci expansion card or integrated on mobo)?

Thanks

[turdus]

Hi all,

I'm developing an application for DOS. I need to communicate via parallel port.

Currently I'm stuck at how can I determine which of the PCI function's BAR(Base address registers) contain the base address(ie data port address) for that parallel port?

Precisely, is there a industry convention or standard or de-facto standard that a particular BAR will always contain the base address for that parallel port ?

If not, then how can I determine the base address for that PCI parallel port(whether on pci expansion card or integrated on mobo)?

Thanks

Since you're in real mode with BIOS support, you should simply read the base port from bios structures: http://pierrelib.pagesperso-orange.fr/h ... _Area.html
It's only one memory read instruction to get it, no need to use PCI BAR. Also read about how to communicate with the chip that keeps paralell port running: http://www.lvr.com/files/ibmlpt.txt

[jacks]

Since you're in real mode with BIOS support, you should simply read the base port from bios structures: http://pierrelib.pagesperso-orange.fr/h ... _Area.html
It's only one memory read instruction to get it, no need to use PCI BAR. Also read about how to communicate with the chip that keeps paralell port running: http://www.lvr.com/files/ibmlpt.txt

Thanks for the info. Actually I'm concerned with parallel ports on PCI expansion cards. AFAIK, BIOS doesn't know about these. BIOS will only allocate resources to the pci card(s) and that's it. So, there might not be the entries for such parallel ports in BDA, as BIOS manufacturer knows only about ALL the devices their mobo has.For eg, say on a PC, I installed 4 parallel ports on pci expansion card(s) , and there is 1 parallel port integrated\embedded on mobo. Now where does the entry for other 2 parallel ports go?

That's why it seems that the BIOS has entries only for three parallel ports integrated \ embedded on chipset or motherboard. So, I think we must read PCI BARs to get the base address for any parallel port on pci expansion card installed on mobo.

[sounds]

What is the vendor and device ID of the card you are working with?

How many parallel ports does it have? Even if you only intend to use 1 of them, to get the card to work you have to be aware of all of them.

The card probably also has serial ports. How many serial ports does it have? The same logic applies - to get the card to work you'll probably have to deal with them at least minimally.

[jacks]

What is the vendor and device ID of the card you are working with?

Well, I'm talking about of a generic PCI parallel port card. If I were to do this stuff with a known specific pci card, then there might be a possibility to have datasheet for the controller, if publicly available, and datasheet will have the info on which of the 6 BARs have base address of PP.

Since we are in DOS, we don't have the luxury of having manufacturer provided drivers that take care of this stuff.

I'm talking about something like we have PCI IDE controller spec. You don't need to know vendor ID and device ID of the pci ide controller, before starting to communicate with hard drive.

How many parallel ports does it have? Even if you only intend to use 1 of them, to get the card to work you have to be aware of all of them.

The card probably also has serial ports. How many serial ports does it have? The same logic applies - to get the card to work you'll probably have to deal with them at least minimally.

Yes, that's why Bios data area will not be of much help, as we still need to communicate with all of the Parallel ports available on a PC, to find which PP is actually in use.

Thanks.

[sounds]

Ok, thanks for explaining a little more.

I'm going to be annoying to attempt to explain PCI Parallel ports, but always take it with a grain of salt.

PCI Parallel port cards do not follow a set PCI standard like IDE controllers. So they most definitely do NOT use the same BAR. Here are some example cards:

• 1 port on BAR 3
• 1 port on BAR 2
• 1 port on BAR 0
• 2 ports, BAR 0 and 2
• 1 port on BAR 1
• 2 ports, BAR 1 and 3
• 1 port on BAR 4

Note that ECP and EPP ports are not accessed using this BAR, though I suspect you are not yet implementing ECP/EPP support. For that you'll need to identify another BAR.

How will you know which BAR to use? I still think you have no other choice but to get the Vendor and Device IDs. Without those I can't tell you any more about your card.

[jacks]

How will you know which BAR to use? I still think you have no other choice but to get the Vendor and Device IDs.

Well, that is the main issue. There must be some way to probe and determine the existence of Data port, status port, and control port. We must probe each bar with same method to determine the base address.

I remember, some time ago, I installed a pci parallel port card(I can't recall the brand of card, nor I now have one.), but windows XP allocated the resources before prompting for drivers. When I checked the resources tab from device manager properties menu, the base address(of Parallel port) was assigned(located) without installing the driver. That means there must be some way to probe and identify, the existence of data, status and control ports.

[Owen]

Of course you can assign the base addresses before installing drivers. The BAR itself contains the size of the region...

[jacks]

Of course you can assign the base addresses before installing drivers. The BAR itself contains the size of the region...

sorry I should have made it more clear (now I cleared it in my previous post).

Actually the base address was visible in resources tab. Like this:

I/O Range : xx78 to xx7F (8 bytes)
I/O Range : yy78 to yy7F (8 bytes)

where, the first range is definitely PP(Parallel Port) Base address range ie base address is xx78. I can say this becoz, xx78 + 400h = yy78, for that parallel port, which is logical, since it was an ECP parallel port, and in pci parallel port extended registers are implemented usually via different BAR than the one with PP base address.

[Owen]

My bet is said card exposed the standard PCI parallel port class

[jacks]

My bet is said card exposed the standard PCI parallel port class

First, if it exposed standard parallel port(or even bidirectional), then why did there were two rows for I/O range in resource tab, with second row's base address at exactly base + 400h?. There should be only one, as windows doesn't know whether the card is of ECP type. How did windows identified it as an ECP?.

Second, even if the card exposed the standard parallel port class, the question is still same - how does windows sorted out which bar contained the base address of the parallel port?. The class the card exposes and the location of bar that contains the base address of parallel port are two different issues, - both vary with manufacturers.

[Brynet-Inc]

OpenBSD has a driver for PCI com/lpt devices named puc(4) - "PCI Universal Communications", glue for attaching MI com(4) and lpt(4) drivers.

There doesn't appear to be an actual standard for this though, it just so happens that generalizations could be made due to similarities.. from a comment in OpenBSD's driver:

* These devices could be (and some times are) described as
* communications/{serial,parallel}, etc. devices with known
* programming interfaces, but those programming interfaces (in
* particular the BAR assignments for devices, etc.) in fact are not
* particularly well defined.

OpenBSD's driver contains a hardcoded list of devices, register offsets, and other quirks in pucdata.c.

http://www.openbsd.org/cgi-bin/cvsweb/~ ... /pci/puc.c
http://www.openbsd.org/cgi-bin/cvsweb/~ ... /pucdata.c
http://www.openbsd.org/cgi-bin/cvsweb/~ ... i/pucvar.h
http://www.openbsd.org/cgi-bin/cvsweb/~ ... /lpt_puc.c
http://www.openbsd.org/cgi-bin/cvsweb/~ ... /com_puc.c

[Owen]

If you looked at the list I linked to, you would have seen one of the subclass devices is "ECP 1.X parallel port"

I imagine that single port cards use this class; and dual port cards probably implement it twice as two features. I imagine it's the 3+ cards where there is lots of variation

[jacks]

OpenBSD has a driver for PCI com/lpt devices named puc(4) - "PCI Universal Communications", glue for attaching MI com(4) and lpt(4) drivers.

There doesn't appear to be an actual standard for this though, it just so happens that generalizations could be made due to similarities.. from a comment in OpenBSD's driver:

Thank you for the links. I actually searched though linux kernel source code, before asking it here, but I didn't find anything similar, what I am trying to do. Maybe I have missed info. It is sad that there is no such standard.

BTW, I looked over these links. Can someone explain first two members - 'rval' and 'rmask' of struct puc_device_description structure? I didn't get them.
They are defined in <dev/pci/pucvar.h>

Code: Select all

 
struct puc_device_description {
	u_int16_t	rval[4];           // 4 vendor(or device) ids ????
	u_int16_t	rmask[4];        // why mask?
	struct {
		u_char	type;
		u_char	bar;
		u_short	offset;
	}			ports[PUC_MAX_PORTS];
};

It seems that 'rval' array contains PCI venid, PCI devid, PCI subsystem venid, PCI subsystem devid, in order. Am I right?
But why is 'rmask' used?

After reading the source code, I realized, that many such cards implement both parallel port and serial port in a single PCI function, and the base addresses of these parallel port and serial port are of course in different bars. But if there is more than one serial port on a single card, then in some cards, they all share a single BAR. One is at offset 0 and other is at offset 0x08 say, and so on.

I wonder, what is the Subclass code of such a PCI function? I guess it would be either 02h or 80h. If that is the case, then I can't search for all parallel ports present in the system by simply searching for a parallel port subclass. Can someone clarify?

[jacks]

If you looked at the list I linked to, you would have seen one of the subclass devices is "ECP 1.X parallel port"

I imagine that single port cards use this class; and dual port cards probably implement it twice as two features. I imagine it's the 3+ cards where there is lots of variation

Yes, I have seen that class. Dual port cards implement usually two PCI functions. I never tried cards with more than two ports. The card I mentioned was a single port card.

Thanks.