PCI CONFADD to register number mapping

NTDEV
1

Hi,

Note sure this is the right forum to ask this question. Its more of a
hardware related question. But, I’m going to give it a try…

This is regarding mapping PCI CONFADD DWORD value to register number
mapping. I tried to folllow the datasheet but when I saw an example, I
couldn’t correlate the datasheet specification to the example.

Here is an example of a CONFADD to register number mapping, I saw in a
sample code

ULONG confaddr=(1<<31) | (0 << 16) | ((ULONG)11 << 11) | (0 << 8) | (0x0C);

and according to the code it maps to register number 0xd for master latency
timer.

How can be so? According to the datasheet (82434LX/82434NX PCI, CACHE AND
MEMORY CONTROLLER) the register number is calculated as from bit 7-2 of
CONFADDR DWORD and by that logic the register number should 3.

Specifically, 0x0C <==> 00001100 in binary and bit 7-2 correspond to 000011
<==> 3.

So the register number should be 3 not 0xd. Can someone explain that?

Thanks,

Chandra

2

00001100 is 0xc, and you probably have 00001101 which is 0xd

The junior 1 probably means “read a single byte, not the whole 32bit word”.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

“chandra97 97” wrote in message news:xxxxx@ntdev…
Hi,

Note sure this is the right forum to ask this question. Its more of a hardware related question. But, I’m going to give it a try…

This is regarding mapping PCI CONFADD DWORD value to register number mapping. I tried to folllow the datasheet but when I saw an example, I couldn’t correlate the datasheet specification to the example.

Here is an example of a CONFADD to register number mapping, I saw in a sample code
ULONG confaddr=(1<<31) | (0 << 16) | ((ULONG)11 << 11) | (0 << 8) | (0x0C);

and according to the code it maps to register number 0xd for master latency timer.

How can be so? According to the datasheet (82434LX/82434NX PCI, CACHE AND MEMORY CONTROLLER) the register number is calculated as from bit 7-2 of CONFADDR DWORD and by that logic the register number should 3.

Specifically, 0x0C <==> 00001100 in binary and bit 7-2 correspond to 000011 <==> 3.

So the register number should be 3 not 0xd. Can someone explain that?

Thanks,

Chandra

3

Sorry Maxim, I couldn’t quite follow what you said. As I indicated CONFADD
looks like

ULONG confaddr=(1<<31) | (0 << 16) | ((ULONG)11 << 11) | (0 << 8) | (0x0C);

and the least significant byte (LSB) is 0xC and not 0xd and register number
as per the datasheet is calculated from bits 7:2 of LSB, which in the above
example is comes to 0x3.

On Mon, Apr 27, 2009 at 3:19 AM, Maxim S. Shatskih
wrote:

> 00001100 is 0xc, and you probably have 00001101 which is 0xd
>
> The junior 1 probably means “read a single byte, not the whole 32bit
> word”.
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> “chandra97 97” wrote in message news:xxxxx@ntdev…
> Hi,
>
> Note sure this is the right forum to ask this question. Its more of a
> hardware related question. But, I’m going to give it a try…
>
> This is regarding mapping PCI CONFADD DWORD value to register number
> mapping. I tried to folllow the datasheet but when I saw an example, I
> couldn’t correlate the datasheet specification to the example.
>
> Here is an example of a CONFADD to register number mapping, I saw in a
> sample code
>
> ULONG confaddr=(1<<31) | (0 << 16) | ((ULONG)11 << 11) | (0 << 8) | (0x0C);
>
> and according to the code it maps to register number 0xd for master
> latency timer.
>
> How can be so? According to the datasheet (82434LX/82434NX PCI, CACHE AND
> MEMORY CONTROLLER) the register number is calculated as from bit 7-2 of
> CONFADDR DWORD and by that logic the register number should 3.
>
> Specifically, 0x0C <==> 00001100 in binary and bit 7-2 correspond to 000011
> <==> 3.
>
> So the register number should be 3 not 0xd. Can someone explain that?
>
> Thanks,
>
> Chandra
>
>
>
>
> —
> 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
>

4

Why are you looking at this and how do you expect to use this info with
Windows?

What you are looking at is the definition of the Config Address register,
I/O address CF8h, when using Configuration Mechanism 1 (the only one ever
implimented) to access Configuration space on a PC. Bit 31 enables the
access through the Config Data register, I/O address CFCh. Bits 16-23 are
the PCI bus number, bits 11-15 are the PCI Device number, and 8-10 are the
Function number. Bits 7-2 are bits 7-2 of the device’s register number.
The bottom two bits must be zero. All accesses are full DWORDs retrieved
by reading or writing the Config Data register. So in the example you
cite, you would write 0x800004C0C (Enable, bus 0, device 11, function 0,
register 0c-0f) to CF8h and read the DWORD from CF8h. Then you would
extract the second byte from that DWORD, bits 8-15, to see the Latency
Timer.

Ref. PCI Local Bus Specification 3.0, 3.2.2.3.2, Software Generation of
Configuration Transactions

Do not use this under Windows; access to the CF8/CFC registers needs to be
coordinates and there are no methods to do so. You will hose Windows.

But playing with them under MS-DOS is OK.

chandra97 97
Sent by: xxxxx@lists.osr.com
04/27/2009 10:08 AM
Please respond to
“Windows System Software Devs Interest List”

To
“Windows System Software Devs Interest List”
cc

Subject
Re: [ntdev] PCI CONFADD to register number mapping

Sorry Maxim, I couldn’t quite follow what you said. As I indicated CONFADD
looks like

ULONG confaddr=(1<<31) | (0 << 16) | ((ULONG)11 << 11) | (0 << 8) |
(0x0C);

and the least significant byte (LSB) is 0xC and not 0xd and register
number as per the datasheet is calculated from bits 7:2 of LSB, which in
the above example is comes to 0x3.

On Mon, Apr 27, 2009 at 3:19 AM, Maxim S. Shatskih > wrote:
00001100 is 0xc, and you probably have 00001101 which is 0xd

The junior 1 probably means “read a single byte, not the whole 32bit
word”.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

“chandra97 97” wrote in message news:xxxxx@ntdev…
Hi,

Note sure this is the right forum to ask this question. Its more of a
hardware related question. But, I’m going to give it a try…

This is regarding mapping PCI CONFADD DWORD value to register number
mapping. I tried to folllow the datasheet but when I saw an example, I
couldn’t correlate the datasheet specification to the example.

Here is an example of a CONFADD to register number mapping, I saw in a
sample code
ULONG confaddr=(1<<31) | (0 << 16) | ((ULONG)11 << 11) | (0 << 8) |
(0x0C);
and according to the code it maps to register number 0xd for master
latency timer.
How can be so? According to the datasheet (82434LX/82434NX PCI, CACHE AND
MEMORY CONTROLLER) the register number is calculated as from bit 7-2 of
CONFADDR DWORD and by that logic the register number should 3.
Specifically, 0x0C <==> 00001100 in binary and bit 7-2 correspond to
000011 <==> 3.
So the register number should be 3 not 0xd. Can someone explain that?
Thanks,
Chandra

—
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

5

Thanks for clarifying.

Why are you looking at this and how do you expect to use this info with
Windows?
I was looking at a malware driver which is reading/writing to PCI
configuration space. I am not intending to use it.

On Mon, Apr 27, 2009 at 2:16 PM, wrote:

>
> Why are you looking at this and how do you expect to use this info with
> Windows?
>
> What you are looking at is the definition of the Config Address register,
> I/O address CF8h, when using Configuration Mechanism 1 (the only one ever
> implimented) to access Configuration space on a PC. Bit 31 enables the
> access through the Config Data register, I/O address CFCh. Bits 16-23 are
> the PCI bus number, bits 11-15 are the PCI Device number, and 8-10 are the
> Function number. Bits 7-2 are bits 7-2 of the device’s register number.
> The bottom two bits must be zero. All accesses are full DWORDs retrieved
> by reading or writing the Config Data register. So in the example you cite,
> you would write 0x800004C0C (Enable, bus 0, device 11, function 0, register
> 0c-0f) to CF8h and read the DWORD from CF8h. Then you would extract the
> second byte from that DWORD, bits 8-15, to see the Latency Timer.
>
> Ref. PCI Local Bus Specification 3.0, 3.2.2.3.2, Software Generation of
> Configuration Transactions
>
> Do not use this under Windows; access to the CF8/CFC registers needs to be
> coordinates and there are no methods to do so. You will hose Windows.
>
> But playing with them under MS-DOS is OK.
>
>
>
>
> chandra97 97
> Sent by: xxxxx@lists.osr.com
>
> 04/27/2009 10:08 AM
> Please respond to
> “Windows System Software Devs Interest List”
>
> To
> “Windows System Software Devs Interest List” cc
> Subject
> Re: [ntdev] PCI CONFADD to register number mapping
>
>
>
>
> Sorry Maxim, I couldn’t quite follow what you said. As I indicated CONFADD
> looks like
>
> ULONG confaddr=(1<<31) | (0 << 16) | ((ULONG)11 << 11) | (0 << 8) | (0x0C);
>
> and the least significant byte (LSB) is 0xC and not 0xd and register number
> as per the datasheet is calculated from bits 7:2 of LSB, which in the above
> example is comes to 0x3.
>
>
> On Mon, Apr 27, 2009 at 3:19 AM, Maxim S. Shatskih <
> xxxxx@storagecraft.com > wrote:
> 00001100 is 0xc, and you probably have 00001101 which is 0xd
>
> The junior 1 probably means “read a single byte, not the whole 32bit
> word”.
>
> –
> Maxim S. Shatskih
> Windows DDK MVP*
> xxxxx@storagecraft.com *
>* http://www.storagecraft.com* http:</http:>
>
> “chandra97 97” <xxxxx@gmail.com > wrote in
> message news:xxxxx@ntdev news:xxxxx…
> Hi,
>
> Note sure this is the right forum to ask this question. Its more of a
> hardware related question. But, I’m going to give it a try…
>
> This is regarding mapping PCI CONFADD DWORD value to register number
> mapping. I tried to folllow the datasheet but when I saw an example, I
> couldn’t correlate the datasheet specification to the example.
>
> Here is an example of a CONFADD to register number mapping, I saw in a
> sample code
>
> ULONG confaddr=(1<<31) | (0 << 16) | ((ULONG)11 << 11) | (0 << 8) | (0x0C);
>
> and according to the code it maps to register number 0xd for master
> latency timer.
>
> How can be so? According to the datasheet (82434LX/82434NX PCI, CACHE AND
> MEMORY CONTROLLER) the register number is calculated as from bit 7-2 of
> CONFADDR DWORD and by that logic the register number should 3.
>
> Specifically, 0x0C <==> 00001100 in binary and bit 7-2 correspond to 000011
> <==> 3.
>
> So the register number should be 3 not 0xd. Can someone explain that?
>
> Thanks,
>
> Chandra
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit: *
> *http://www.osr.com/seminars http:
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServerhttp:
>
> — 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
></http:></http:></news:xxxxx>

6

> ULONG confaddr=(1<<31) | (0 << 16) | ((ULONG)11 << 11) | (0 << 8) | (0x0C);

I just love left-shifting zero in the above “masterpiece” - apparently, the code author believes it may produce anything other than zero…

Anton Bassov

7

xxxxx@hotmail.com wrote:

> ULONG confaddr=(1<<31) | (0 << 16) | ((ULONG)11 << 11) | (0 << 8) | (0x0C);
>

I just love left-shifting zero in the above “masterpiece” - apparently, the code author believes it may produce anything other than zero…

Come on. You’re being entirely unfair here. It’s not hard to imagine
that this was expanded from a macro that accepted the various fields as
parameters.

Further, depending on the environment, something like that is much more
self-documenting than a raw constant of 0x8000580C, and the compiler
will compile them to the exact same code.

There is nothing wrong with writing it that way.

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

8

The question is do we need those { (0 << 16), ( 0 << 8 ) } masterpieces ?
Sounds like one from “10 things one can do for job security” !

-pro

On Tue, Apr 28, 2009 at 9:45 AM, Tim Roberts wrote:

> xxxxx@hotmail.com wrote:
> >> ULONG confaddr=(1<<31) | (0 << 16) | ((ULONG)11 << 11) | (0 << 8) |
> (0x0C);
> >>
> >
> > I just love left-shifting zero in the above “masterpiece” - apparently,
> the code author believes it may produce anything other than zero…
> >
>
> Come on. You’re being entirely unfair here. It’s not hard to imagine
> that this was expanded from a macro that accepted the various fields as
> parameters.
>
> Further, depending on the environment, something like that is much more
> self-documenting than a raw constant of 0x8000580C, and the compiler
> will compile them to the exact same code.
>
> There is nothing wrong with writing it that way.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> 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
>

9

Prokash Sinha wrote:

The question is do we need those { (0 << 16), ( 0 << 8 )
} masterpieces ?

Sounds like one from “10 things one can do for job security” !

I can’t believe you people are making fun of this! Don’t any of you
ever spend any time at all to make your code pretty and readable? How
do you go back to code you wrote 9 months ago and figure out what it does?

When you define your ioctl numbers, do you say this:

#define IOCTL_GET_THIS 0x00220004
#define IOCTL_GET_THAT 0x0022400d
#define IOCTL_PUT_THIS 0x00228014
#define IOCTL_RESET 0x0022001c

or do you say this:

#define IOCTL_GET_THIS CTL_CODE(FILE_DEVICE_UNKNOWN, 0x1,
FILE_ANY_ACCESS, METHOD_BUFFERED)
#define IOCTL_GET_THAT CTL_CODE(FILE_DEVICE_UNKNOWN, 0x3,
FILE_READ_ACCESS, METHOD_IN_DIRECT)
#define IOCTL_PUT_THIS CTL_CODE(FILE_DEVICE_UNKNOWN, 0x5,
FILE_ANY_ACCESS, METHOD_OUT_DIRECT)
#define IOCTL_RESET CTL_CODE(FILE_DEVICE_UNKNOWN, 0x7,
FILE_ANY_ACCESS, METHOD_BUFFERED)

This is EXACTLY the same thing as what the original poster has.
FILE_ANY ACCESS is 0, so three of those definitions include (0<<14).

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

10

On Tue, Apr 28, 2009 at 1:27 PM, Tim Roberts wrote:
> #define IOCTL_GET_THIS CTL_CODE(FILE_DEVICE_UNKNOWN, 0x1,
> FILE_ANY_ACCESS, METHOD_BUFFERED)

That is readable.

(0 << 16), ( 0 << 8 )

That is gibberish.

As an aside, I prefer my bits as explicit hex values rather than as
shifted constructs.

Mark Roddy

11

> I can’t believe you people are making fun of this! Don’t any of you ever spend any time at all to make

your code pretty and readable?

Actually, we do, and this is the only reason why we laugh - an extra meaningless no-op statement in a macro is not going to make your code either prettier or more readable, don’t you think…

Anyway, if you don’t mind even more unnecessary complication, I propose to replace (0 << 16) with
(((val<
Anton Bassov

12

I agree with Tim here. I wouldn’t do what this dev did personally, as it confuses me, but it’s
certainly a matter of preference.

mm

Tim Roberts wrote:

xxxxx@hotmail.com wrote:
>> ULONG confaddr=(1<<31) | (0 << 16) | ((ULONG)11 << 11) | (0 << 8) | (0x0C);
>>
> I just love left-shifting zero in the above “masterpiece” - apparently, the code author believes it may produce anything other than zero…
>

Come on. You’re being entirely unfair here. It’s not hard to imagine
that this was expanded from a macro that accepted the various fields as
parameters.

Further, depending on the environment, something like that is much more
self-documenting than a raw constant of 0x8000580C, and the compiler
will compile them to the exact same code.

There is nothing wrong with writing it that way.

13

> it’s certainly a matter of preference.

This is more of a matter of a reason, rather than preference. Quite often it happens to me that I write fairly complex code… and then realize that it is simply unreasonable , because I could have EXACTLY the same thing straightforward way, without any complications…

Anton Bassov

14

happens to me
I write
then [I] realize
I could

That sounds pretty personal to me.

mm

xxxxx@hotmail.com wrote:

> it’s certainly a matter of preference.

This is more of a matter of a reason, rather than preference.
> Quite often it happens to me that I write fairly complex code… and then realize that it is
simply unreasonable ,
>
because I could have EXACTLY the same thing straightforward way, without any complications…

Anton Bassov

15

> happens to me I write then [I] realize I could That sounds pretty personal to me.

Well, you seem to have a peculiar understanding of personal stuff, Martin …

Anton Bassov

16

Precisely.

mm

xxxxx@hotmail.com wrote:

> happens to me I write then [I] realize I could That sounds pretty personal to me.

Well, you seem to have a peculiar understanding of personal stuff, Martin …

Anton Bassov