device driver needs to DMA from RTP task
rhunn...@hotmail.com
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
Bill
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
rhunn...@hotmail.com
On Jan 26, 2:36 pm, "Bill" <w...@magnesium.net> 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