device driver needs to DMA from RTP task - VxWorks

This is a discussion on device driver needs to DMA from RTP task - VxWorks ; Hi, I have a device driver that needs to set up DMA transactions. I'm using Vxworks 6.3, Workbench 2.5, and the MV2700 BSP. For kernel mode applications, this is easy as the memory address is the same in the application ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: device driver needs to DMA from RTP task

  1. device driver needs to DMA from RTP task

    Hi,

    I have a device driver that needs to set up DMA transactions. I'm using
    Vxworks 6.3, Workbench 2.5, and the MV2700 BSP.

    For kernel mode applications, this is easy as the memory address is the
    same in the application and in the driver. But, in an RTP, the memory
    address is not the same as the physical address. It is something like
    0x20XXXXXX. The first thing I tried was to mask off the high order
    nible but it wasn't that easy. I tried the CACHE_DMA_VIRT_TO_PHYS()
    macro and the vmTranslate() function with no sucess.

    My best guess is the vmTranslate function should work but the address
    it gives me is the same that I give it. This may be because the
    function requires a VM_CONTEXT_ID * as the first parameter or NULL if
    the current context. I don't know where to get the VM_CONTEXT_ID so I
    use NULL. I've done as much reading as I can. The "book" says the
    driver has access to the RTP memory context unitl the system call
    returns. Any help from someone who has gone through this before would
    be greatly appreciated. There was a simular thread to this in April
    2006 but the answer was never posted.

    TIA,

    Rick Hunnicutt
    Software Engineer
    GET Engineering Corp.
    www.getntds.com


  2. Re: device driver needs to DMA from RTP task



    On Jan 26, 10:04 am, rhunnic...@hotmail.com wrote:
    > Hi,
    >
    > I have a device driver that needs to set up DMA transactions. I'm using
    > Vxworks 6.3, Workbench 2.5, and the MV2700 BSP.


    It would help if you told us what kind of device your driver is for
    (network, graphics, disk, etc...).

    > For kernel mode applications, this is easy as the memory address is the
    > same in the application and in the driver. But, in an RTP, the memory
    > address is not the same as the physical address. It is something like
    > 0x20XXXXXX. The first thing I tried was to mask off the high order
    > nible but it wasn't that easy. I tried the CACHE_DMA_VIRT_TO_PHYS()
    > macro and the vmTranslate() function with no sucess.


    My understanding is that with RTPs, you don't have full blown virtual
    memory (in the 'virtual address is different from physical address'
    sense). You still have the same address space as before. The difference
    is that each RTP is assigned a chunk of the address space, and when you
    context switch into a task that's part of an RTP, the MMU is set up so
    that access to any memory outside the RTP mapped space is marked
    protected, so that any out of bounds accesses will cause a trap.

    So I don't think you need to translate addresses. However, gainging
    access to another RTP's pages is another issue.

    > My best guess is the vmTranslate function should work but the address
    > it gives me is the same that I give it. This may be because the
    > function requires a VM_CONTEXT_ID * as the first parameter or NULL if
    > the current context. I don't know where to get the VM_CONTEXT_ID so I
    > use NULL. I've done as much reading as I can. The "book" says the
    > driver has access to the RTP memory context unitl the system call
    > returns. Any help from someone who has gone through this before would
    > be greatly appreciated. There was a simular thread to this in April
    > 2006 but the answer was never posted.


    For system calls (ioctl(), read(), write()), a routine called
    scMemValidate() is used by the kernel to obtain access to memory
    belonging to other RTPs. Internally, I think it uses mmanLib, which
    implements the mmap()/munmap() API. If you want to share pages between
    RTPs, I think mmap()/munmap() is the way. I haven't tried this
    personally, however. I do mainly network drivers, and with networking,
    data is moved in and out of kernel context using socket syscalls, which
    copy the data from application buffers (temporarily mapped with
    scMemValidate()) to kernel buffers. You could probably use the same
    approach, though depending on the application, directly mapping the
    application buffers might be preferable.

    -Bill

    > TIA,
    >
    > Rick Hunnicutt
    > Software Engineer
    > GET Engineering Corp.www.getntds.com



  3. Re: device driver needs to DMA from RTP task



    On Jan 26, 2:36 pm, "Bill" wrote:
    > On Jan 26, 10:04 am, rhunnic...@hotmail.com wrote:
    >
    > > Hi,

    >
    > > I have a device driver that needs to set up DMA transactions. I'm using
    > > Vxworks 6.3, Workbench 2.5, and the MV2700 BSP.It would help if you told us what kind of device your driver is for

    > (network, graphics, disk, etc...).
    >
    > > For kernel mode applications, this is easy as the memory address is the
    > > same in the application and in the driver. But, in an RTP, the memory
    > > address is not the same as the physical address. It is something like
    > > 0x20XXXXXX. The first thing I tried was to mask off the high order
    > > nible but it wasn't that easy. I tried the CACHE_DMA_VIRT_TO_PHYS()
    > > macro and the vmTranslate() function with no sucess.My understanding is that with RTPs, you don't have full blown virtual

    > memory (in the 'virtual address is different from physical address'
    > sense). You still have the same address space as before. The difference
    > is that each RTP is assigned a chunk of the address space, and when you
    > context switch into a task that's part of an RTP, the MMU is set up so
    > that access to any memory outside the RTP mapped space is marked
    > protected, so that any out of bounds accesses will cause a trap.
    >
    > So I don't think you need to translate addresses. However, gainging
    > access to another RTP's pages is another issue.
    >
    > > My best guess is the vmTranslate function should work but the address
    > > it gives me is the same that I give it. This may be because the
    > > function requires a VM_CONTEXT_ID * as the first parameter or NULL if
    > > the current context. I don't know where to get the VM_CONTEXT_ID so I
    > > use NULL. I've done as much reading as I can. The "book" says the
    > > driver has access to the RTP memory context unitl the system call
    > > returns. Any help from someone who has gone through this before would
    > > be greatly appreciated. There was a simular thread to this in April
    > > 2006 but the answer was never posted.For system calls (ioctl(), read(), write()), a routine called

    > scMemValidate() is used by the kernel to obtain access to memory
    > belonging to other RTPs. Internally, I think it uses mmanLib, which
    > implements the mmap()/munmap() API. If you want to share pages between
    > RTPs, I think mmap()/munmap() is the way. I haven't tried this
    > personally, however. I do mainly network drivers, and with networking,
    > data is moved in and out of kernel context using socket syscalls, which
    > copy the data from application buffers (temporarily mapped with
    > scMemValidate()) to kernel buffers. You could probably use the same
    > approach, though depending on the application, directly mapping the
    > application buffers might be preferable.
    >
    > -Bill
    >
    >
    >
    > > TIA,


    Bill,

    Thanks for the response. As far as I can tell from what I read and
    from
    the results I get, scMemValidate() tells you if you have access to the
    buffer or not
    but doesn't give you access per say. This call does suceed and I can
    access the
    buffers through the driver but I need the physical address (or bus
    address if that
    is more correct) to give to the device to allow it to DMA the data.
    Otherwise,
    I'm stuck coping the data to a kernel buffer which I don't want to do
    for
    performance reasons unless I have to.

    The driver is for a communications adaptor. It's a character device
    which can have
    variable size buffers.

    Any other ideas or anyone else chime in please.

    Thanks,
    Rick



+ Reply to Thread