MMU in vxWroks 6.2 issues - VxWorks

This is a discussion on MMU in vxWroks 6.2 issues - VxWorks ; Hello all I wrote a driver in kernel space in vxWorks 6.2. The driver is a DMA driver that receives a src and a dst address, and copies from src to dst. The src and dst are allocated in RTP ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: MMU in vxWroks 6.2 issues

  1. MMU in vxWroks 6.2 issues

    Hello all

    I wrote a driver in kernel space in vxWorks 6.2. The driver is a DMA
    driver that receives a src and a dst address, and copies from src to
    dst.

    The src and dst are allocated in RTP space (user space) (pointers
    having addresses of 0xA0034000 e.g.).

    The DMA fails on transfer error when trying to perform the transaction.

    AFAIK, in vxWorks 6.2 the address space is flat, so there should be a
    one-to-one correspondence between virtual-physical addresses.

    >From what I see, the pointer values i get from memalign are too large

    to be physical (see above), I tried converting from virtual to
    physical, but there seems to be no such function implemented in
    vxWorks.

    Any help would be appreciated..
    Sinan.


  2. Re: MMU in vxWroks 6.2 issues

    "sinan" wrote:

    >Hello all
    >
    >I wrote a driver in kernel space in vxWorks 6.2. The driver is a DMA
    >driver that receives a src and a dst address, and copies from src to
    >dst.
    >
    >The src and dst are allocated in RTP space (user space) (pointers
    >having addresses of 0xA0034000 e.g.).
    >
    >The DMA fails on transfer error when trying to perform the transaction.
    >
    >AFAIK, in vxWorks 6.2 the address space is flat, so there should be a
    >one-to-one correspondence between virtual-physical addresses.
    >


    Kernel address space is flat, RTP address space is not flat. Your driver
    needs to call cacheDrvVirtToPhys, or similar depending on the platform,
    for a physical address.


    >>From what I see, the pointer values i get from memalign are too large

    >to be physical (see above), I tried converting from virtual to
    >physical, but there seems to be no such function implemented in
    >vxWorks.
    >
    >Any help would be appreciated..
    >Sinan.



  3. Re: MMU in vxWroks 6.2 issues

    1. The function needs a parameter of type CACHE_FUNCS, have no idea
    what to give it (found dmaCacheFuncs structure, but the virtToPhys func
    there is NULL)
    What should I give it as CACHE_FUNCS ?!

    2. I tried vmTranslate also, by calling it from the kernel with the
    kernels context, it returns NULL.

    3. Tried also somehow to extract the rtpId from a TCB, and try to
    access the poolMgr object inside, no use and it's too hard.

    Thanks in advance.


  4. Re: MMU in vxWroks 6.2 issues

    "sinan" wrote:

    Which platform?

    >1. The function needs a parameter of type CACHE_FUNCS, have no idea
    >what to give it (found dmaCacheFuncs structure, but the virtToPhys func
    >there is NULL)
    >What should I give it as CACHE_FUNCS ?!
    >
    >2. I tried vmTranslate also, by calling it from the kernel with the
    >kernels context, it returns NULL.
    >
    >3. Tried also somehow to extract the rtpId from a TCB, and try to
    >access the poolMgr object inside, no use and it's too hard.
    >
    >Thanks in advance.



  5. Re: MMU in vxWroks 6.2 issues

    "sinan" wrote:

    >1. The function needs a parameter of type CACHE_FUNCS, have no idea
    >what to give it (found dmaCacheFuncs structure, but the virtToPhys func
    >there is NULL)
    >What should I give it as CACHE_FUNCS ?!
    >
    >2. I tried vmTranslate also, by calling it from the kernel with the
    >kernels context, it returns NULL.
    >
    >3. Tried also somehow to extract the rtpId from a TCB, and try to
    >access the poolMgr object inside, no use and it's too hard.
    >
    >Thanks in advance.


    Sorry, try vmTranslate.


  6. Re: MMU in vxWroks 6.2 issues

    Tried it.
    I'm running vxWorks 6.2, on MPC8349.
    WindRiver seems to forgot to supply a translation function for this
    platform, since the cahceLib struct holds NULL instead of the
    translation function.

    Any other ideas?
    Thanks


  7. Re: MMU in vxWroks 6.2 issues

    "sinan" wrote:

    >Tried it.
    >I'm running vxWorks 6.2, on MPC8349.
    >WindRiver seems to forgot to supply a translation function for this
    >platform, since the cahceLib struct holds NULL instead of the
    >translation function.
    >
    >Any other ideas?
    >Thanks


    It doesn't need a cacheLib because cache snooping is enabled.
    vmTranslate is not associated with cache, it's an MMU function,
    so it should be working.

  8. Re: MMU in vxWroks 6.2 issues

    Well, right and wrong..

    when I said "cacheLib" I didn't mean the cacheLib library, but instead
    the cacheDmaFuncs mapping, MMU translation functions are also
    referenced in this "cacheLib" struct. Anyway, cache snooping is NOT on
    by default.

    The MMU functions need a context as the first argument to translate
    addresses, since the address I'm trying to translate is inside an RTP,
    I need the RTP vm context, which I have no way to extract.

    When using vmTranslate in the target shell, I get a NULL in the address
    that it translated to, which is wierd.

    I've used vmTranslate also inside the kernel, the return value of the
    function is OK, but the physical address returned is NULL. Looked into
    mmuPpcLib.c, it appears to be implemented. (mmuPpcTranslate).

    I've opened a TSR at windriver, the person there is SOO off that he is
    saying that RTPs do not use virtual addressing..

    Any other ideas are most welcome.
    Sinan.


+ Reply to Thread