IO bus address spaces

NTDEV
1

From http://www.wd-3.com/archive/PioAccess.htm Mark Roddy Author.

  1. What`s the difference between REGISTER address space and PORT address
    space.

Register address : is it only memory access (LOAD, STORE instruction?)

PORT address : it uses the instructions IN,OUT…?

I’m confused between READ_or_WRITE_REGISTER_XX and READ_or_WRITE_PORT_XX
functions.

  1. The difference between RAW and TRANSLATED resources.

Christian

2

> -----Original Message-----

From: Christian Grenier [mailto:xxxxx@mcdi.com]
Sent: Friday, October 17, 2003 4:47 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] IO bus address spaces

From http://www.wd-3.com/archive/PioAccess.htm Mark Roddy Author.

  1. What`s the difference between REGISTER address space and
    PORT address space.

The DDK docs attempt to use the terms REGISTER address space for Memory
registers and PORT address space for IO registers. They are trying to avoid
the confusion of having two address spaces one of which is commonly referred
to as ‘Memory space’ while the other is ‘IO space’ and both are used to do
device ‘IO’. Unfortunately they overloaded the term ‘register’ which has its
own set of meanings. Oh well…

Register address : is it only memory access (LOAD, STORE instruction?)

Yes, but be careful here. The article is about how this can change. It
doesn’t ever change for REGISTER space on any platform NT runs on.

PORT address : it uses the instructions IN,OUT…?

Yes, but see above, and in the case of PORT addresses, NT, on some
platforms, provides access to these PORTs through REGISTER space operations.

I’m confused between READ_or_WRITE_REGISTER_XX and
READ_or_WRITE_PORT_XX functions.

These are the HAL functions that provide platform independent and correct
access to device registers in either REGISTER space (memory) or PORT space
(IO.)

  1. The difference between RAW and TRANSLATED resources.

The raw resources are the resources as defined on the hardware, for example
a PCI device has a BAR in IO space and its config space indicates that this
BAR is allocated IO addresses 400-43F. The NT raw resource would be a PORT
resource with length 40 and address 400.

The translated resources are how the OS has mapped the raw resources into
the platfrom’s bus access architecture. For example on a platform that does
not support native IO operations, our raw IO resource might be translated
into a memory resource. The NT translated resource might be a REGISTER
resource with a logical address of FFFF0400 and a length of 40.

As my article indicates, you use the translated resource address space to
decide which set of the READ/WRITE_REGISTER/PORT* functions you should use
to access the register.

=====================
Mark Roddy

3

Thanks for your help Mark, on a platform that does not support native IO
operations, the PnP manager has to translate the IO address space into
memory space. I think that the Pnp Manager must query the HAL in order to
know more about the platform (supports or not IO) before to translate raw IO
resources to memory resources. Is that right?

Christian

----- Original Message -----
From: “Roddy, Mark”
To: “Windows System Software Devs Interest List”
Sent: Friday, October 17, 2003 5:08 PM
Subject: [ntdev] RE: IO bus address spaces

>
> > -----Original Message-----
> > From: Christian Grenier [mailto:xxxxx@mcdi.com]
> > Sent: Friday, October 17, 2003 4:47 PM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] IO bus address spaces
> >
> >
> > From http://www.wd-3.com/archive/PioAccess.htm Mark Roddy Author.
> >
> > 1. What`s the difference between REGISTER address space and
> > PORT address space.
> >
>
> The DDK docs attempt to use the terms REGISTER address space for Memory
> registers and PORT address space for IO registers. They are trying to
avoid
> the confusion of having two address spaces one of which is commonly
referred
> to as ‘Memory space’ while the other is ‘IO space’ and both are used to do
> device ‘IO’. Unfortunately they overloaded the term ‘register’ which has
its
> own set of meanings. Oh well…
>
> > Register address : is it only memory access (LOAD, STORE instruction?)
>
> Yes, but be careful here. The article is about how this can change. It
> doesn’t ever change for REGISTER space on any platform NT runs on.
>
> >
> > PORT address : it uses the instructions IN,OUT…?
> >
>
> Yes, but see above, and in the case of PORT addresses, NT, on some
> platforms, provides access to these PORTs through REGISTER space
operations.
>
> > I’m confused between READ_or_WRITE_REGISTER_XX and
> > READ_or_WRITE_PORT_XX functions.
> >
>
> These are the HAL functions that provide platform independent and correct
> access to device registers in either REGISTER space (memory) or PORT space
> (IO.)
>
> >
> >
> > 2. The difference between RAW and TRANSLATED resources.
>
> The raw resources are the resources as defined on the hardware, for
example
> a PCI device has a BAR in IO space and its config space indicates that
this
> BAR is allocated IO addresses 400-43F. The NT raw resource would be a PORT
> resource with length 40 and address 400.
>
> The translated resources are how the OS has mapped the raw resources into
> the platfrom’s bus access architecture. For example on a platform that
does
> not support native IO operations, our raw IO resource might be translated
> into a memory resource. The NT translated resource might be a REGISTER
> resource with a logical address of FFFF0400 and a length of 40.
>
> As my article indicates, you use the translated resource address space to
> decide which set of the READ/WRITE_REGISTER/PORT* functions you should use
> to access the register.
>
> =====================
> Mark Roddy
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@mcdi.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

4

Actually it is up to the driver writer to use the proper REGISTER or PORT routine.

Use the REGISTER routines to access your device if it has BARS marked as type memory. Use the PORT routines to access your device if it has BARS marked as type IO port. This holds whether or not your processor truly supports in/out instructions or not (e.g. IA64)). The underlying routines will do the correct thing for the processor architecture.

Normally, if a device has a BAR of type IO port there is another BAR that is of type memory that maps the same set of registers (ie. you can get to the device registers using either the REGISTER or PORT routines, but you must use the addresses associated with the proper BAR with the proper access routine). There was a requirement in the PCI spec compliance that if you had registers in the IO port space that you also had to have aliases in the memory map space (i.e. you needed at least two BARS in you used PORT space). However, not all devices are compliant.

Most modern devices only have BARS of type memory, since the memory mapped address space is very large, whereas the PORT address space is very small. Large SMP boxes, can’t support many PCI devices if they all require a large PORT address space, therefore most devices should just be using memory type BARS (unless of course there is some legacy reason to have PORT address space (aka video)).

Duane.

-----Original Message-----
From: Christian Grenier [mailto:xxxxx@mcdi.com]
Sent: Friday, October 17, 2003 5:43 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] RE: IO bus address spaces

Thanks for your help Mark, on a platform that does not support native IO
operations, the PnP manager has to translate the IO address space into
memory space. I think that the Pnp Manager must query the HAL in order to
know more about the platform (supports or not IO) before to translate raw IO
resources to memory resources. Is that right?

Christian

----- Original Message -----
From: “Roddy, Mark”
To: “Windows System Software Devs Interest List”
Sent: Friday, October 17, 2003 5:08 PM
Subject: [ntdev] RE: IO bus address spaces

>
> > -----Original Message-----
> > From: Christian Grenier [mailto:xxxxx@mcdi.com]
> > Sent: Friday, October 17, 2003 4:47 PM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] IO bus address spaces
> >
> >
> > From http://www.wd-3.com/archive/PioAccess.htm Mark Roddy Author.
> >
> > 1. What`s the difference between REGISTER address space and
> > PORT address space.
> >
>
> The DDK docs attempt to use the terms REGISTER address space for Memory
> registers and PORT address space for IO registers. They are trying to
avoid
> the confusion of having two address spaces one of which is commonly
referred
> to as ‘Memory space’ while the other is ‘IO space’ and both are used to do
> device ‘IO’. Unfortunately they overloaded the term ‘register’ which has
its
> own set of meanings. Oh well…
>
> > Register address : is it only memory access (LOAD, STORE instruction?)
>
> Yes, but be careful here. The article is about how this can change. It
> doesn’t ever change for REGISTER space on any platform NT runs on.
>
> >
> > PORT address : it uses the instructions IN,OUT…?
> >
>
> Yes, but see above, and in the case of PORT addresses, NT, on some
> platforms, provides access to these PORTs through REGISTER space
operations.
>
> > I’m confused between READ_or_WRITE_REGISTER_XX and
> > READ_or_WRITE_PORT_XX functions.
> >
>
> These are the HAL functions that provide platform independent and correct
> access to device registers in either REGISTER space (memory) or PORT space
> (IO.)
>
> >
> >
> > 2. The difference between RAW and TRANSLATED resources.
>
> The raw resources are the resources as defined on the hardware, for
example
> a PCI device has a BAR in IO space and its config space indicates that
this
> BAR is allocated IO addresses 400-43F. The NT raw resource would be a PORT
> resource with length 40 and address 400.
>
> The translated resources are how the OS has mapped the raw resources into
> the platfrom’s bus access architecture. For example on a platform that
does
> not support native IO operations, our raw IO resource might be translated
> into a memory resource. The NT translated resource might be a REGISTER
> resource with a logical address of FFFF0400 and a length of 40.
>
> As my article indicates, you use the translated resource address space to
> decide which set of the READ/WRITE_REGISTER/PORT* functions you should use
> to access the register.
>
> =====================
> Mark Roddy
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@mcdi.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@infiniconsys.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

If the device supports memory space only, BARS decoding memory space, so the
device drivers dont have to use READ/WRITE_PORT_XX HAL routines. What happen if we call those routines? The HAL will use instead the MOV instruction? The driver developper as you said doesnt need to understand
everything, but i`m just curious you know :slight_smile:

The CPU initiates the transaction to the Host-PCI chipset. It decodes the
address and prepares the IO or memory transaction (Type-0 or Type-1) onto
PCI bus. The PCI device decodes the IO transaction by verifying the
address. The PCI device asserts DevSel# while the device is selected.

The Host-PCI chipset can map IO device space to system memory. While the
CPU supports only memory space, the host-pci chipset will be responsible to
convert the CPU transaction to IO space transaction for the PCI device. I
presume that the chipset has defined an area in the system memory space
reserved for IO address space.

I have to read more about Host-PCI chipset:)

----- Original Message -----
From: “McCrory, Duane”
To: “Windows System Software Devs Interest List”
Sent: Friday, October 17, 2003 7:50 PM
Subject: [ntdev] RE: IO bus address spaces

> Actually it is up to the driver writer to use the proper REGISTER or PORT
routine.
>
> Use the REGISTER routines to access your device if it has BARS marked as
type memory. Use the PORT routines to access your device if it has BARS
marked as type IO port. This holds whether or not your processor truly
supports in/out instructions or not (e.g. IA64)). The underlying routines
will do the correct thing for the processor architecture.
>
> Normally, if a device has a BAR of type IO port there is another BAR that
is of type memory that maps the same set of registers (ie. you can get to
the device registers using either the REGISTER or PORT routines, but you
must use the addresses associated with the proper BAR with the proper access
routine). There was a requirement in the PCI spec compliance that if you had
registers in the IO port space that you also had to have aliases in the
memory map space (i.e. you needed at least two BARS in you used PORT space).
However, not all devices are compliant.
>
> Most modern devices only have BARS of type memory, since the memory mapped
address space is very large, whereas the PORT address space is very small.
Large SMP boxes, can’t support many PCI devices if they all require a large
PORT address space, therefore most devices should just be using memory type
BARS (unless of course there is some legacy reason to have PORT address
space (aka video)).
>
> Duane.
>
> -----Original Message-----
> From: Christian Grenier [mailto:xxxxx@mcdi.com]
> Sent: Friday, October 17, 2003 5:43 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] RE: IO bus address spaces
>
>
> Thanks for your help Mark, on a platform that does not support native IO
> operations, the PnP manager has to translate the IO address space into
> memory space. I think that the Pnp Manager must query the HAL in order to
> know more about the platform (supports or not IO) before to translate raw
IO
> resources to memory resources. Is that right?
>
> Christian
>
>
>
> ----- Original Message -----
> From: “Roddy, Mark”
> To: “Windows System Software Devs Interest List”
> Sent: Friday, October 17, 2003 5:08 PM
> Subject: [ntdev] RE: IO bus address spaces
>
>
> >
> > > -----Original Message-----
> > > From: Christian Grenier [mailto:xxxxx@mcdi.com]
> > > Sent: Friday, October 17, 2003 4:47 PM
> > > To: Windows System Software Devs Interest List
> > > Subject: [ntdev] IO bus address spaces
> > >
> > >
> > > From http://www.wd-3.com/archive/PioAccess.htm Mark Roddy Author.
> > >
> > > 1. What`s the difference between REGISTER address space and
> > > PORT address space.
> > >
> >
> > The DDK docs attempt to use the terms REGISTER address space for Memory
> > registers and PORT address space for IO registers. They are trying to
> avoid
> > the confusion of having two address spaces one of which is commonly
> referred
> > to as ‘Memory space’ while the other is ‘IO space’ and both are used to
do
> > device ‘IO’. Unfortunately they overloaded the term ‘register’ which has
> its
> > own set of meanings. Oh well…
> >
> > > Register address : is it only memory access (LOAD, STORE instruction?)
> >
> > Yes, but be careful here. The article is about how this can change. It
> > doesn’t ever change for REGISTER space on any platform NT runs on.
> >
> > >
> > > PORT address : it uses the instructions IN,OUT…?
> > >
> >
> > Yes, but see above, and in the case of PORT addresses, NT, on some
> > platforms, provides access to these PORTs through REGISTER space
> operations.
> >
> > > I’m confused between READ_or_WRITE_REGISTER_XX and
> > > READ_or_WRITE_PORT_XX functions.
> > >
> >
> > These are the HAL functions that provide platform independent and
correct
> > access to device registers in either REGISTER space (memory) or PORT
space
> > (IO.)
> >
> > >
> > >
> > > 2. The difference between RAW and TRANSLATED resources.
> >
> > The raw resources are the resources as defined on the hardware, for
> example
> > a PCI device has a BAR in IO space and its config space indicates that
> this
> > BAR is allocated IO addresses 400-43F. The NT raw resource would be a
PORT
> > resource with length 40 and address 400.
> >
> > The translated resources are how the OS has mapped the raw resources
into
> > the platfrom’s bus access architecture. For example on a platform that
> does
> > not support native IO operations, our raw IO resource might be
translated
> > into a memory resource. The NT translated resource might be a REGISTER
> > resource with a logical address of FFFF0400 and a length of 40.
> >
> > As my article indicates, you use the translated resource address space
to
> > decide which set of the READ/WRITE_REGISTER/PORT* functions you should
use
> > to access the register.
> >
> > =====================
> > Mark Roddy
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@mcdi.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@infiniconsys.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@mcdi.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

6

Supposing the following scenario, the device has only one IO BAR register
(IO space) and the CPU supports only memory space (no IO instructions). How
the device driver can communicate with the PCI device?

----- Original Message -----
From: “Christian Grenier”
To: “Windows System Software Devs Interest List”
Sent: Friday, October 17, 2003 10:15 PM
Subject: [ntdev] RE: IO bus address spaces

> If the device supports memory space only, BARS decoding memory space, so
the
> device drivers dont have to use READ/WRITE_PORT_XX HAL routines. What<br>&gt; happen if we call those routines? The HAL will use instead the MOV<br>&gt; instruction? The driver developper as you said doesnt need to understand
> everything, but im just curious you know :)<br>&gt;<br>&gt; The CPU initiates the transaction to the Host-PCI chipset. It decodes the<br>&gt; address and prepares the IO or memory transaction (Type-0 or Type-1) onto<br>&gt; PCI bus. The PCI device decodes the IO transaction by verifying the<br>&gt; address. The PCI device asserts DevSel# while the device is selected.<br>&gt;<br>&gt; The Host-PCI chipset can map IO device space to system memory. While the<br>&gt; CPU supports only memory space, the host-pci chipset will be responsible<br>to<br>&gt; convert the CPU transaction to IO space transaction for the PCI device. I<br>&gt; presume that the chipset has defined an area in the system memory space<br>&gt; reserved for IO address space.<br>&gt;<br>&gt; I have to read more about Host-PCI chipset:)<br>&gt;<br>&gt;<br>&gt;<br>&gt;<br>&gt;<br>&gt;<br>&gt;<br>&gt;<br>&gt; ----- Original Message -----<br>&gt; From: "McCrory, Duane" <xxxxx><br>&gt; To: "Windows System Software Devs Interest List" <xxxxx><br>&gt; Sent: Friday, October 17, 2003 7:50 PM<br>&gt; Subject: [ntdev] RE: IO bus address spaces<br>&gt;<br>&gt;<br>&gt; &gt; Actually it is up to the driver writer to use the proper REGISTER or<br>PORT<br>&gt; routine.<br>&gt; &gt;<br>&gt; &gt; Use the REGISTER routines to access your device if it has BARS marked as<br>&gt; type memory. Use the PORT routines to access your device if it has BARS<br>&gt; marked as type IO port. This holds whether or not your processor truly<br>&gt; supports in/out instructions or not (e.g. IA64)). The underlying routines<br>&gt; will do the correct thing for the processor architecture.<br>&gt; &gt;<br>&gt; &gt; Normally, if a device has a BAR of type IO port there is another BAR<br>that<br>&gt; is of type memory that maps the same set of registers (ie. you can get to<br>&gt; the device registers using either the REGISTER or PORT routines, but you<br>&gt; must use the addresses associated with the proper BAR with the proper<br>access<br>&gt; routine). There was a requirement in the PCI spec compliance that if you<br>had<br>&gt; registers in the IO port space that you also had to have aliases in the<br>&gt; memory map space (i.e. you needed at least two BARS in you used PORT<br>space).<br>&gt; However, not all devices are compliant.<br>&gt; &gt;<br>&gt; &gt; Most modern devices only have BARS of type memory, since the memory<br>mapped<br>&gt; address space is very large, whereas the PORT address space is very small.<br>&gt; Large SMP boxes, can't support many PCI devices if they all require a<br>large<br>&gt; PORT address space, therefore most devices should just be using memory<br>type<br>&gt; BARS (unless of course there is some legacy reason to have PORT address<br>&gt; space (aka video)).<br>&gt; &gt;<br>&gt; &gt; Duane.<br>&gt; &gt;<br>&gt; &gt; -----Original Message-----<br>&gt; &gt; From: Christian Grenier [mailto:xxxxx@mcdi.com]<br>&gt; &gt; Sent: Friday, October 17, 2003 5:43 PM<br>&gt; &gt; To: Windows System Software Devs Interest List<br>&gt; &gt; Subject: [ntdev] RE: IO bus address spaces<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt; Thanks for your help Mark, on a platform that does not support native<br>IO<br>&gt; &gt; operations, the PnP manager has to translate the IO address space into<br>&gt; &gt; memory space. I think that the Pnp Manager must query the HAL in order<br>to<br>&gt; &gt; know more about the platform (supports or not IO) before to translate<br>raw<br>&gt; IO<br>&gt; &gt; resources to memory resources. Is that right?<br>&gt; &gt;<br>&gt; &gt; Christian<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt; ----- Original Message -----<br>&gt; &gt; From: "Roddy, Mark" <xxxxx><br>&gt; &gt; To: "Windows System Software Devs Interest List" <xxxxx><br>&gt; &gt; Sent: Friday, October 17, 2003 5:08 PM<br>&gt; &gt; Subject: [ntdev] RE: IO bus address spaces<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt; &gt;<br>&gt; &gt; &gt; &gt; -----Original Message-----<br>&gt; &gt; &gt; &gt; From: Christian Grenier [mailto:xxxxx@mcdi.com]<br>&gt; &gt; &gt; &gt; Sent: Friday, October 17, 2003 4:47 PM<br>&gt; &gt; &gt; &gt; To: Windows System Software Devs Interest List<br>&gt; &gt; &gt; &gt; Subject: [ntdev] IO bus address spaces<br>&gt; &gt; &gt; &gt;<br>&gt; &gt; &gt; &gt;<br>&gt; &gt; &gt; &gt; From http://www.wd-3.com/archive/PioAccess.htm Mark Roddy Author.<br>&gt; &gt; &gt; &gt;<br>&gt; &gt; &gt; &gt; 1. Whats the difference between REGISTER address space and
> > > > PORT address space.
> > > >
> > >
> > > The DDK docs attempt to use the terms REGISTER address space for
Memory
> > > registers and PORT address space for IO registers. They are trying to
> > avoid
> > > the confusion of having two address spaces one of which is commonly
> > referred
> > > to as ‘Memory space’ while the other is ‘IO space’ and both are used
to
> do
> > > device ‘IO’. Unfortunately they overloaded the term ‘register’ which
has
> > its
> > > own set of meanings. Oh well…
> > >
> > > > Register address : is it only memory access (LOAD, STORE
instruction?)
> > >
> > > Yes, but be careful here. The article is about how this can change. It
> > > doesn’t ever change for REGISTER space on any platform NT runs on.
> > >
> > > >
> > > > PORT address : it uses the instructions IN,OUT…?
> > > >
> > >
> > > Yes, but see above, and in the case of PORT addresses, NT, on some
> > > platforms, provides access to these PORTs through REGISTER space
> > operations.
> > >
> > > > I’m confused between READ_or_WRITE_REGISTER_XX and
> > > > READ_or_WRITE_PORT_XX functions.
> > > >
> > >
> > > These are the HAL functions that provide platform independent and
> correct
> > > access to device registers in either REGISTER space (memory) or PORT
> space
> > > (IO.)
> > >
> > > >
> > > >
> > > > 2. The difference between RAW and TRANSLATED resources.
> > >
> > > The raw resources are the resources as defined on the hardware, for
> > example
> > > a PCI device has a BAR in IO space and its config space indicates that
> > this
> > > BAR is allocated IO addresses 400-43F. The NT raw resource would be a
> PORT
> > > resource with length 40 and address 400.
> > >
> > > The translated resources are how the OS has mapped the raw resources
> into
> > > the platfrom’s bus access architecture. For example on a platform that
> > does
> > > not support native IO operations, our raw IO resource might be
> translated
> > > into a memory resource. The NT translated resource might be a REGISTER
> > > resource with a logical address of FFFF0400 and a length of 40.
> > >
> > > As my article indicates, you use the translated resource address space
> to
> > > decide which set of the READ/WRITE_REGISTER/PORT* functions you should
> use
> > > to access the register.
> > >
> > > =====================
> > > Mark Roddy
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@mcdi.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@infiniconsys.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@mcdi.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@mcdi.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

7

> Supposing the following scenario, the device has only one IO BAR register

(IO space) and the CPU supports only memory space (no IO instructions).
How
the device driver can communicate with the PCI device?

It can’t, unless the hardware platform the OS is running on somehow maps IO
space to memory space. Which it very well might do (and probably would in
that case).

The HAL for that machine would have to know about this implicit translation
process, and provide appropriate code in the HAL for the read/write_port_xxx
calls.

Note you can actually get a case on a large SMP Intel server where you have
cards with IO space that are inaccessible. If the host supports IO space,
and doesn’t provide a mapping of IO space to memory space, then it is very
easy to run out of IO space if you have any significant number of PCI
busses. This can result in cards that are physically present but
inaccessible, because the BIOS (or ACPI) was unable to map IO space to those
cards, it all having been used on other busses.

Loren

8

> It can’t, unless the hardware platform the OS is running on somehow maps
IO

space to memory space. Which it very well might do (and probably would in
that case).

For example, the BAR is defined in memory area :BAR0 : 0xFFC00000. the BIOS
reads it and saves it in the system memory space (within the host-pci
chipset?). After, the PnP Manager must read the raw resources, it queries
information from the HAL. The HAL reads information in physical memory to
gather device resources (supplied by the BIOS?). Pnp Manager will know
about each PCI device and it will translate resources for the OS.
Therefore, the BAR0, it is a memory space mapped to IO space. The device
driver calls READ/WRITE_PORT_XX(0xFFC00000) HAL routines being the
translated resources to access to the device registers. Is this scenario
can be true?

The HAL for that machine would have to know about this implicit
translation
process, and provide appropriate code in the HAL for the
read/write_port_xxx
calls.

Note you can actually get a case on a large SMP Intel server where you
have
cards with IO space that are inaccessible. If the host supports IO space,
and doesn’t provide a mapping of IO space to memory space, then it is very
easy to run out of IO space if you have any significant number of PCI
busses. This can result in cards that are physically present but
inaccessible, because the BIOS (or ACPI) was unable to map IO space to
those
cards, it all having been used on other busses.

Loren

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

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

9

Here are the simple rules.

  1. If you are accessing a register that is mapped using an IO port BAR use the PORT routines.
  2. If you are accessing a register that is mapped using a Memory type BAR use the REGISTER routines.

Also, do not use a REGISTER routine where you should have used a PORT routine and vice-versa.

For most modern devices you will just be using the REGISTER routines.

If your machine does not native support for in/out instructions the underlying h/w chipset will normally have a way to generate IO cycles down the PCI device. The HAL will know how to do this translation (similar to the sideband method of generating PCI configuration cycles, since PCI configuration cycles aren’t native to any CPU architecture either).

Duane.

-----Original Message-----
From: Christian Grenier [mailto:xxxxx@mcdi.com]
Sent: Saturday, October 18, 2003 7:33 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] RE: IO bus address spaces

It can’t, unless the hardware platform the OS is running on somehow maps
IO
space to memory space. Which it very well might do (and probably would in
that case).

For example, the BAR is defined in memory area :BAR0 : 0xFFC00000. the BIOS
reads it and saves it in the system memory space (within the host-pci
chipset?). After, the PnP Manager must read the raw resources, it queries
information from the HAL. The HAL reads information in physical memory to
gather device resources (supplied by the BIOS?). Pnp Manager will know
about each PCI device and it will translate resources for the OS.
Therefore, the BAR0, it is a memory space mapped to IO space. The device
driver calls READ/WRITE_PORT_XX(0xFFC00000) HAL routines being the
translated resources to access to the device registers. Is this scenario
can be true?

The HAL for that machine would have to know about this implicit
translation
process, and provide appropriate code in the HAL for the
read/write_port_xxx
calls.

Note you can actually get a case on a large SMP Intel server where you
have
cards with IO space that are inaccessible. If the host supports IO space,
and doesn’t provide a mapping of IO space to memory space, then it is very
easy to run out of IO space if you have any significant number of PCI
busses. This can result in cards that are physically present but
inaccessible, because the BIOS (or ACPI) was unable to map IO space to
those
cards, it all having been used on other busses.

Loren

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

You are currently subscribed to ntdev as: xxxxx@mcdi.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@infiniconsys.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

10

“McCrory, Duane” wrote:

Here are the simple rules.

  1. If you are accessing a register that is mapped using an IO port BAR use the PORT routines.
  2. If you are accessing a register that is mapped using a Memory type BAR use the REGISTER routines.

Sadly, this simple rule is no longer valid. Read Mark Roddy’s article
about it at http://www.wd-3.com/archive/PioAccess.htm.

–
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

11

> Register address : is it only memory access (LOAD, STORE instruction?)

Yes.

PORT address : it uses the instructions IN,OUT…?

Yes.

  1. The difference between RAW and TRANSLATED resources.

NT4 required you to call HalTranslateBusAddress for memory and ports and
HalGetInterruptVector for IRQs after you have passed them via arbiter
(IoAssignResources). This is called “translation”, from bus-relative address to
CPU-relative address.

w2k+ does this for you inside the PnP manager.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

12

> memory space. I think that the Pnp Manager must query the HAL in order to

know more about the platform (supports or not IO) before to translate raw IO

Yes, but the details of this process is not documented. The PnP manager takes
your response to MN_FILTER/MN_QUERY_RESOURCE_REQUIREMENTS, passes them via
arbiters and translators, and thus obtains the resources to send to you in
MN_START_DEVICE IRP.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

13

>

Actually it is up to the driver writer to use the proper
REGISTER or PORT routine.

Use the REGISTER routines to access your device if it has
BARS marked as type memory. Use the PORT routines to access
your device if it has BARS marked as type IO port. This holds
whether or not your processor truly supports in/out
instructions or not (e.g. IA64)). The underlying routines
will do the correct thing for the processor architecture.

Well no, that is not correct. Drivers should not ‘look at the bars’. Instead
the driver should look at the translated resource, which will indicate how
to access this resouce on this platform correctly, by indicating if the
translated resource is a Memory or Io (REGISTER or PORT) resource.

Normally, if a device has a BAR of type IO port there is
another BAR that is of type memory that maps the same set of
registers (ie. you can get to the device registers using
either the REGISTER or PORT routines, but you must use the
addresses associated with the proper BAR with the proper
access routine). There was a requirement in the PCI spec
compliance that if you had registers in the IO port space
that you also had to have aliases in the memory map space
(i.e. you needed at least two BARS in you used PORT space).
However, not all devices are compliant.

Most modern devices only have BARS of type memory, since the
memory mapped address space is very large, whereas the PORT
address space is very small.

I only wish this were true. Many recent vintage PCI devices continue to
support IO space resources for a variety of reasons, however your point
about address space size is correct.

=====================
Mark Roddy

14

The following example verifies the PartialDescriptors[0].Flags to
specify if the device is accessed in memory address space? If so, we
call MmMapIoSpace to map IO to virtual memory space. I don’t understand
why we use READ/ WRITE_PORT_UCHAR if the IO space is mapped to memory
space? Shouldn’t we use READ / WRITE_REGISTER_UCHAR in the case where
the IO is mapped to memory space?

if
(!IrpStack->Parameters.StartDevice.AllocatedResourcesTranslated->List->P
artialResourceList->PartialDescriptors[0].Flags) {
Base = MmMapIoSpace(BaseAddress,

REGISTER_ADDRESS_SIZE,
FALSE );

DebugPrint ((“Base %X, %X\n”,
Base,BaseAddress.LowPart));

} else {
Base = (PUCHAR)BaseAddress.LowPart;
}

// if error, just get out
if (Base == NULL) return FALSE;

icr = Base+offset+2;
lcr = Base+offset+3;

// causing spurious interrupts and trashing everything
KeRaiseIrql ((KIRQL)HIGH_LEVEL, &oldIrql);

// look for 95x UARTs
origLCR = READ_PORT_UCHAR (lcr); // save original
LCR
WRITE_PORT_UCHAR (lcr, 0x00);
id1 = READ_PORT_UCHAR (icr); // read id1

// restore the irql
KeLowerIrql (oldIrql);

Regards

Christian

15

The code sample is wrong. It will however work on most platforms.

=====================
Mark Roddy

-----Original Message-----
From: Christian Grenier [mailto:xxxxx@mcdi.com]
Sent: Monday, October 20, 2003 10:12 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] RE: IO bus address spaces

The following example verifies the
PartialDescriptors[0].Flags to specify if the device is
accessed in memory address space? If so, we call
MmMapIoSpace to map IO to virtual memory space. I don’t
understand why we use READ/ WRITE_PORT_UCHAR if the IO space
is mapped to memory space? Shouldn’t we use READ /
WRITE_REGISTER_UCHAR in the case where the IO is mapped to
memory space?

if
(!IrpStack->Parameters.StartDevice.AllocatedResourcesTranslate
d->List->P
artialResourceList->PartialDescriptors[0].Flags) {
Base = MmMapIoSpace(BaseAddress,

REGISTER_ADDRESS_SIZE,
FALSE );

DebugPrint ((“Base %X, %X\n”,
Base,BaseAddress.LowPart));

} else {
Base = (PUCHAR)BaseAddress.LowPart;
}

// if error, just get out
if (Base == NULL) return FALSE;

icr = Base+offset+2;
lcr = Base+offset+3;

// causing spurious interrupts and trashing everything
KeRaiseIrql ((KIRQL)HIGH_LEVEL, &oldIrql);

// look for 95x UARTs
origLCR = READ_PORT_UCHAR (lcr); // save original
LCR
WRITE_PORT_UCHAR (lcr, 0x00);
id1 = READ_PORT_UCHAR (icr); // read id1

// restore the irql
KeLowerIrql (oldIrql);

Regards

Christian

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

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

16

But it doesn’t work if the CPU is like PowerPC? Which no IO space is
available?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Monday, October 20, 2003 10:18 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] RE: IO bus address spaces

The code sample is wrong. It will however work on most platforms.

=====================
Mark Roddy

-----Original Message-----
From: Christian Grenier [mailto:xxxxx@mcdi.com]
Sent: Monday, October 20, 2003 10:12 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] RE: IO bus address spaces

The following example verifies the
PartialDescriptors[0].Flags to specify if the device is
accessed in memory address space? If so, we call
MmMapIoSpace to map IO to virtual memory space. I don’t
understand why we use READ/ WRITE_PORT_UCHAR if the IO space
is mapped to memory space? Shouldn’t we use READ /
WRITE_REGISTER_UCHAR in the case where the IO is mapped to
memory space?

if
(!IrpStack->Parameters.StartDevice.AllocatedResourcesTranslate
d->List->P
artialResourceList->PartialDescriptors[0].Flags) {
Base = MmMapIoSpace(BaseAddress,

REGISTER_ADDRESS_SIZE,
FALSE );

DebugPrint ((“Base %X, %X\n”,
Base,BaseAddress.LowPart));

} else {
Base = (PUCHAR)BaseAddress.LowPart;
}

// if error, just get out
if (Base == NULL) return FALSE;

icr = Base+offset+2;
lcr = Base+offset+3;

// causing spurious interrupts and trashing everything
KeRaiseIrql ((KIRQL)HIGH_LEVEL, &oldIrql);

// look for 95x UARTs
origLCR = READ_PORT_UCHAR (lcr); // save original
LCR
WRITE_PORT_UCHAR (lcr, 0x00);
id1 = READ_PORT_UCHAR (icr); // read id1

// restore the irql
KeLowerIrql (oldIrql);

Regards

Christian

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

You are currently subscribed to ntdev as: xxxxx@stratus.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@mcdi.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

17

>

But it doesn’t work if the CPU is like PowerPC? Which no IO
space is available?

No, interestingly enough this would work on a PPC. The screw case is an x86
platform with two top level PCI busses where one PCI bus supports IO access
using PORT IO while the other PCI bus supports IO access using REGISTER IO.

On PPC-type platforms (all IO access is memory mapped,) the HAL PORT
functions simply perform memory LOAD/STORE operations.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Monday, October 20, 2003 10:18 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] RE: IO bus address spaces

The code sample is wrong. It will however work on most platforms.

=====================
Mark Roddy

> -----Original Message-----
> From: Christian Grenier [mailto:xxxxx@mcdi.com]
> Sent: Monday, October 20, 2003 10:12 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] RE: IO bus address spaces
>
>
> The following example verifies the
> PartialDescriptors[0].Flags to specify if the device is
> accessed in memory address space? If so, we call
> MmMapIoSpace to map IO to virtual memory space. I don’t
> understand why we use READ/ WRITE_PORT_UCHAR if the IO space
> is mapped to memory space? Shouldn’t we use READ /
> WRITE_REGISTER_UCHAR in the case where the IO is mapped to
> memory space?
>
> if
> (!IrpStack->Parameters.StartDevice.AllocatedResourcesTranslate
> d->List->P
> artialResourceList->PartialDescriptors[0].Flags) {
> Base = MmMapIoSpace(BaseAddress,
>
> REGISTER_ADDRESS_SIZE,
> FALSE );
>
> DebugPrint ((“Base %X, %X\n”,
> Base,BaseAddress.LowPart));
>
> } else {
> Base = (PUCHAR)BaseAddress.LowPart;
> }
>
> // if error, just get out
> if (Base == NULL) return FALSE;
>
> icr = Base+offset+2;
> lcr = Base+offset+3;
>
> // causing spurious interrupts and trashing everything
> KeRaiseIrql ((KIRQL)HIGH_LEVEL, &oldIrql);
>
> // look for 95x UARTs
> origLCR = READ_PORT_UCHAR (lcr); // save original
> LCR
> WRITE_PORT_UCHAR (lcr, 0x00);
> id1 = READ_PORT_UCHAR (icr); // read id1
>
> // restore the irql
> KeLowerIrql (oldIrql);
>
>
> Regards
>
> Christian
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.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@mcdi.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@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

18

>>

>
> But it doesn’t work if the CPU is like PowerPC? Which no IO
> space is available?
>

No, interestingly enough this would work on a PPC. The screw case is an
x86
platform with two top level PCI busses where one PCI bus supports IO
access
using PORT IO while the other PCI bus supports IO access using REGISTER
IO.

I thought that the chipset can support transaction in IO or memory
space. You seem to say that it’s possible for architecture with 2
chipsets that one has only a memory space and the other one has only an
IO space?

19

> -----Original Message-----

From: Christian Grenier [mailto:xxxxx@mcdi.com]
Sent: Monday, October 20, 2003 11:34 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] RE: IO bus address spaces

>>
>>
>> But it doesn’t work if the CPU is like PowerPC? Which no IO
>> space is available?
>>

>No, interestingly enough this would work on a PPC. The screw
case is an
x86
>platform with two top level PCI busses where one PCI bus supports IO
access
>using PORT IO while the other PCI bus supports IO access
using REGISTER
IO.

I thought that the chipset can support transaction in IO or memory
space. You seem to say that it’s possible for architecture with 2
chipsets that one has only a memory space and the other one
has only an
IO space?

If I understand you correctly, sort of :slight_smile: One bus chipset supports both
memory and io space directly from the processor while the other bus chipset
supports only memory space directly, translating ‘special regions’ of memory
space into PCI IO transactions. They both directly support memory space
transactions, which seems to contradict what you are saying above.

20

I had understood that chipset can support both IO and memory space. The
problem could occur at the CPU level. In fact, the CPU supporting only
memory space should notify the chipset that the IO space must be mapped
to memory space in a “special regions” as you said (at the enumeration
time, or system boot?).

So, chipset can perform translation memory space into PCI IO
transaction.

In the case where the CPU supports IO and memory (like x86), the chipset
has no problem to translate any request from the CPU.

All chipset should translate Memory to IO space?

Regards

Christian

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Monday, October 20, 2003 11:46 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] RE: IO bus address spaces

-----Original Message-----
From: Christian Grenier [mailto:xxxxx@mcdi.com]
Sent: Monday, October 20, 2003 11:34 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] RE: IO bus address spaces

>>
>>
>> But it doesn’t work if the CPU is like PowerPC? Which no IO
>> space is available?
>>

>No, interestingly enough this would work on a PPC. The screw
case is an
x86
>platform with two top level PCI busses where one PCI bus supports IO
access
>using PORT IO while the other PCI bus supports IO access
using REGISTER
IO.

I thought that the chipset can support transaction in IO or memory
space. You seem to say that it’s possible for architecture with 2
chipsets that one has only a memory space and the other one
has only an
IO space?

If I understand you correctly, sort of :slight_smile: One bus chipset supports both
memory and io space directly from the processor while the other bus
chipset
supports only memory space directly, translating ‘special regions’ of
memory
space into PCI IO transactions. They both directly support memory space
transactions, which seems to contradict what you are saying above.

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

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