none
Using 32-bit DMA under 64-bit Windows RRS feed

  • Question

  • HI:

    We have one old PCI device. It has a bus master DMA, but only support 32bit addressing.
    Now we want to write a driver for 64-bit Windows 7.

    I studied "Handling DMA Operations in Framework-Based Drivers" of KMDF.
    I have two questions.
    First:
    WdfDmaEnablerCreate() can specify the type of bus-master DMA operation.
    Should i specify its DMA operation type with WdfDmaProfilePacket (using 32 bit addressing), not WdfDmaProfilePacket64?

    Second:
    Assume that i specify WdfDmaProfilePacket for this device.
    I create and initialize a DMA Transaction by WdfDmaTransactionInitializeUsingRequest() or WdfDmaTransactionInitialize().
    And This DMA Transaction has a transfer buffer that is 64-bit addressing.
    Does the driver framework handle a translation from 64 bit addressing to 32 bit addressing?
    Or the driver framework create a new buffer below 32 bit address space and copy transfer buffer to that?

    Wednesday, April 15, 2015 10:24 AM

Answers

  • > Should i specify its DMA operation type with WdfDmaProfilePacket (using 32 bit addressing), not
    > WdfDmaProfilePacket64?

    Correct. The "64" there refers to 64-bit physical addresses, which your device is not capable of. 

    > I create and initialize a DMA Transaction by WdfDmaTransactionInitializeUsingRequest() or
    > WdfDmaTransactionInitialize().
    And This DMA Transaction has a transfer buffer that is 64-bit addressing.

    You're referring to the VirtualAddress argument to WdfDmaTransactionInitialize? Yes, in 64-bit Windows that will be a 64-bit address. But that's a virtual address. 

    > Does the driver framework handle a translation from 64 bit addressing to 32 bit addressing?

    To put it briefly, yes. It also handles many other aspects of the DMA device's compatibility with the platform. 

    A DMA device is concerned with physical addresses, not virtual. When the framework calls your EvtProgramDma routine for any type of DMA driver, it will pass you a scatter-gather list that will be suitable for your device. In this case, "suitable" means there will just be one array element (since you said "packet", not "scatter-gather") and its physical address will fit in 32 bits (even though it will occupy 64 bits in the structure). To do this the framework has to copy the app's buffer through what is called a "bounce buffer" that is automatically set up. The "bounce buffer" will be physically contiguous and will reside below the 4 GB RAM address boundary. 

    To avoid using bounce buffers your DMA hardware would have to be both 64-bit-capable and scatter-gather capable.

    It is always important to keep in mind the difference between virtual and physical (RAM) addresses and be aware of which type of address you're dealing with. If you can use an address as an ordinary pointer in your C code (assuming correct process context), it's a virtual address. DMA devices in common Windows platforms deal exclusively with physical (RAM) addresses. The relationship between the two, assuming no bounce buffers are in use, is held in page tables maintained by the memory manager. If bounce buffers are needed then the framework (actually the I/O manager as called by the framework; this stuff was happening long before WDF existed) copies data between them and the pages that represent the requester's original buffer. 

    Wednesday, April 15, 2015 8:18 PM

All replies

  • You mean more particularly the logic on the peripheral uses 32-bit pointers.

    more specifics about the hardware would be helpful, like the registers on it etc

    This can be tricky but the idea I would consider is 32-bit addressing and map that into a 64-bit container elsewhere

    this would get around being stuck in 32-bit lala land

    64-bit drivers need to be signed as well which adds to the work



    MSFT Signature

    Place your rig specifics into your signature like I have, makes it 100x easier!

    Hardcore Games Legendary is the Only Way to Play!
    Vegan Advocate How can you be an environmentalist and still eat meat?

    Wednesday, April 15, 2015 12:30 PM
  • > Should i specify its DMA operation type with WdfDmaProfilePacket (using 32 bit addressing), not
    > WdfDmaProfilePacket64?

    Correct. The "64" there refers to 64-bit physical addresses, which your device is not capable of. 

    > I create and initialize a DMA Transaction by WdfDmaTransactionInitializeUsingRequest() or
    > WdfDmaTransactionInitialize().
    And This DMA Transaction has a transfer buffer that is 64-bit addressing.

    You're referring to the VirtualAddress argument to WdfDmaTransactionInitialize? Yes, in 64-bit Windows that will be a 64-bit address. But that's a virtual address. 

    > Does the driver framework handle a translation from 64 bit addressing to 32 bit addressing?

    To put it briefly, yes. It also handles many other aspects of the DMA device's compatibility with the platform. 

    A DMA device is concerned with physical addresses, not virtual. When the framework calls your EvtProgramDma routine for any type of DMA driver, it will pass you a scatter-gather list that will be suitable for your device. In this case, "suitable" means there will just be one array element (since you said "packet", not "scatter-gather") and its physical address will fit in 32 bits (even though it will occupy 64 bits in the structure). To do this the framework has to copy the app's buffer through what is called a "bounce buffer" that is automatically set up. The "bounce buffer" will be physically contiguous and will reside below the 4 GB RAM address boundary. 

    To avoid using bounce buffers your DMA hardware would have to be both 64-bit-capable and scatter-gather capable.

    It is always important to keep in mind the difference between virtual and physical (RAM) addresses and be aware of which type of address you're dealing with. If you can use an address as an ordinary pointer in your C code (assuming correct process context), it's a virtual address. DMA devices in common Windows platforms deal exclusively with physical (RAM) addresses. The relationship between the two, assuming no bounce buffers are in use, is held in page tables maintained by the memory manager. If bounce buffers are needed then the framework (actually the I/O manager as called by the framework; this stuff was happening long before WDF existed) copies data between them and the pages that represent the requester's original buffer. 

    Wednesday, April 15, 2015 8:18 PM
  • There is a example controller - USB EHCI Host Controller.

    But this Controller has not 64-bit capability.

    It has one data structure - Queue Element Transfer Descriptor.

    Driver use this structure to do data transfer between host and device.

    This structure is designed for scatter-gather DMA transcation. The sturcture is following.

        ULONG   NextLinkPointer;

        ULONG   AlternateNextLinkPointer;

        ULONG   TokenStatus;

        ULONG   BufferPhysicalPageAddress[5];   this include Offset into the first page address.

    The Physical Page is 32bit addressing.

    Assume there is a USB Storage device on host.

    and the user do some file control operation on it, like copy files.

    At App layer, the data of files is 64-bit virtial address and its physical address may be over 4G address. So the data from App layer pass down to the EHCI Driver.

    But This EHCI Controller has no 64-bit scatter-gather DMA.

    Therefore, There must be a role that is responsible for the translation form 64 bit addressing to 32 bit address. This behavior likes "thruck".

    Jamie Hanrahan points this called "bounce buffer".

     

     

    Thursday, April 16, 2015 7:30 AM
  • Very Thanks. Now I know.
    Thursday, April 16, 2015 7:30 AM
  • Very Thanks. Now I know.

    Now that I see more specifics I can suggest there are samples in the DDK for exactly this type of project. I suggest taking a closer look at them for more ideas in how to get your project working as desired.

    USB and EHCI are both in the samples



    MSFT Signature

    Place your rig specifics into your signature like I have, makes it 100x easier!

    Hardcore Games Legendary is the Only Way to Play!
    Vegan Advocate How can you be an environmentalist and still eat meat?

    Thursday, April 16, 2015 10:23 AM
  • Do you means that there are samples for EHCI in the DDK?

    I also have the DDK with version 2600.1106.

    But i can not find any EHCI's example in it.

    Can you tell me where to find them?

    Friday, April 17, 2015 2:44 AM
  • I found some on MSDN some time ago, might not be there anymore

    look for windows driver kit for the older versions of windows, forget which dvd has what off hand

    think it was the windows 7 dvd had a bunch of samples



    MSFT Signature

    Place your rig specifics into your signature like I have, makes it 100x easier!

    Hardcore Games Legendary is the Only Way to Play!
    Vegan Advocate How can you be an environmentalist and still eat meat?

    Friday, April 17, 2015 3:01 AM