64-bit Basics

NTDEV
1

Lets say I have a PCI card in a 32-bit PCI bus on a 64-bit AMD machine
(running 64-bit Windows).

I get the resources and discover the base address register(s) for the memory
regions implemented on the card and map these into memory.

Perhaps:

PULONG Bar = MmMapIoSpace (phys_addr, len, flag)

Suppose I wanted the 3rd memory location:

PULONG MyRegisterPtr = (PULONG) &Bar[2]

If I use READ_REGISTER_ULONG (MyRegisterPtr), what do I get? Is it the 32
bits from the memory location on the PCI card or 64 bits containing the 32 I
wanted plus in the upper 32 bits?

This of course brings up issues around writing 32 bits…

Mickey.

2

You will get 32 bits. You will write 32 bits for similar write access. This
is because the size of ULONG is still 32 bits.

-----Original Message-----
From: Charles Lane [mailto:xxxxx@earthlink.net]
Sent: Thursday, April 15, 2004 4:41 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] 64-bit Basics

Lets say I have a PCI card in a 32-bit PCI bus on a 64-bit AMD machine
(running 64-bit Windows).

I get the resources and discover the base address register(s) for the memory
regions implemented on the card and map these into memory.

Perhaps:

PULONG Bar = MmMapIoSpace (phys_addr, len, flag)

Suppose I wanted the 3rd memory location:

PULONG MyRegisterPtr = (PULONG) &Bar[2]

If I use READ_REGISTER_ULONG (MyRegisterPtr), what do I get? Is it the 32
bits from the memory location on the PCI card or 64 bits containing the 32 I
wanted plus in the upper 32 bits?

This of course brings up issues around writing 32 bits…

Mickey.

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

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

3

Don’t do this. The BAR registers will NOT be memory addresses on all
possible hardware implementations! Use the translated resources.

I know of at least one 64 bit platform where the bus addresses are 64 bit
quantities, and the values in the card BARs are simply tokens that feed into
a hash map on the bus to translate to the real addresses. There is
literally no way that a driver, examining just the card hardware, can even
begin to deduce the memory address that will correspond to any card BAR.
Even knowing how one BAR on a single card maps to memory will not give you a
hint on how another memory bar ON THE SAME CARD will map to memory.

Loren

----- Original Message -----
From: “Charles Lane”
To: “Windows System Software Devs Interest List”
Sent: Thursday, April 15, 2004 1:40 PM
Subject: [ntdev] 64-bit Basics

> Lets say I have a PCI card in a 32-bit PCI bus on a 64-bit AMD machine
> (running 64-bit Windows).
>
> I get the resources and discover the base address register(s) for the
memory
> regions implemented on the card and map these into memory.
>
> Perhaps:
>
> PULONG Bar = MmMapIoSpace (phys_addr, len, flag)
>
> Suppose I wanted the 3rd memory location:
>
> PULONG MyRegisterPtr = (PULONG) &Bar[2]
>
> If I use READ_REGISTER_ULONG (MyRegisterPtr), what do I get? Is it the 32
> bits from the memory location on the PCI card or 64 bits containing the 32
I
> wanted plus in the upper 32 bits?
>
> This of course brings up issues around writing 32 bits…
>
> Mickey.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@earthlink.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

4

Loren Wilton writes:

Don’t do this. The BAR registers will NOT be memory addresses on all
possible hardware implementations! Use the translated resources.

Good point!

I do use the translated resources. The problem here was in my choice of
words. I should have said the regions pointed to by the BARs and perhaps
some other variable name for the 1st address of the region.

Mickey.