• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 764 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

"Detected alias with VirtualCopy." message when I call Buffer_create()

Peter Ladanyi
Intellectual 570 points
Other Parts Discussed in Thread: OMAP3530



Hello,


I use DVSDK on WinCE6, and I am working with DM6446.
When I allocate a buffer using Buffer_create() or BufTabCreate() function using DMAI, I got a strange message in WinCE Debug log:

"1449592 PID:400002 TID:45a000a Detected alias with VirtualCopy. Callers are responsible for data consistency in cache."

I know, the cache-management is one of my task (or DMAI's).
I handle cache, but can I avoid this message or I have to do something?
Is it an error, a warning or just an info message?


Peter



1449581 PID:459000a TID:45a000a @1467,737,000us: [+2 T:0x045a000a S:0x1c01f6b8] ti.sdo.dmai - [BufTab] Allocating BufTab for 1 buffers
1449582 PID:459000a TID:45a000a @1467,741,000us: [+0 T:0x045a000a S:0x1c01f618] OM - Memory_alloc> Enter(0xa2280)
1449583 PID:459000a TID:45a000a @1467,743,000us: [+0 T:0x045a000a S:0x1c01f570] OM - Memory_contigAlloc> Enter(size=664192, align=128, cached=TRUE, heap=FALSE)
1449584 PID:459000a TID:45a000a @1467,745,000us: [+6 T:0x045a000a S:0x1c01f570] OM - Memory_contigAlloc> Warning: non-default alignment not supported for pool-based allocations, using default #x.
1449592 PID:400002 TID:45a000a Detected alias with VirtualCopy. Callers are responsible for data consistency in cache.
1449612 PID:459000a TID:45a000a @1467,801,000us: [+4 T:0x045a000a S:0x1c01f570] OM - Memory_contigAlloc> CMEM_alloc(664192) = 0x1c230000.
1449613 PID:459000a TID:45a000a @1467,803,000us: [+4 T:0x045a000a S:0x1c01f570] OM - Memory_contigAlloc> CMEM_getPhys(0x1c230000) = 0x885a0000.
1449615 PID:459000a TID:45a000a @1467,805,000us: [+1 T:0x045a000a S:0x1c01f4ac] OM - Memory__addContigBuf> Enter(virtAddr=0x1c230000, size=664192, physAddr=0x885a0000)
1449616 PID:459000a TID:45a000a @1467,809,000us: [+1 T:0x045a000a S:0x1c01f4ac] OM - Memory__addContigBuf> creating new contigBuf object
1449617 PID:459000a TID:45a000a @1467,811,000us: [+0 T:0x045a000a S:0x1c01f468] OM - Memory_alloc> Enter(0x10)
1449618 PID:459000a TID:45a000a @1467,813,000us: [+0 T:0x045a000a S:0x1c01f468] OM - Memory_alloc> return (0x1c022f40)
1449619 PID:459000a TID:45a000a @1467,815,000us: [+1 T:0x045a000a S:0x1c01f4ac] OM - Memory__addContigBuf> returning: cb->phys=0x885a0000, cb->size=664192, cb->virt=0x1c230000
1449620 PID:459000a TID:45a000a @1467,817,000us: [+0 T:0x045a000a S:0x1c01f570] OM - Memory_contigAlloc> return (0x1c230000)
1449621 PID:459000a TID:45a000a @1467,819,000us: [+0 T:0x045a000a S:0x1c01f618] OM - Memory_alloc> return (0x1c230000)
1449623 PID:459000a TID:45a000a @1467,821,000us: [+0 T:0x045a000a S:0x1c01f5f8] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x1c230000, size=4)
1449624 PID:459000a TID:45a000a @1467,825,000us: [+1 T:0x045a000a S:0x1c01f590] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x1c230000, size=4)
1449625 PID:459000a TID:45a000a @1467,827,000us: [+1 T:0x045a000a S:0x1c01f590] OM - Memory__getPhysicalAddress> found in cb(Sc=0x1c230000, Ec=0x1c2d2280, Ss=0x1c230000, Es=0x1c230004, PSc=0x885a0000)
1449626 PID:459000a TID:45a000a @1467,829,000us: [+1 T:0x045a000a S:0x1c01f590] OM - Memory__getPhysicalAddress> returning physAddr=0x885a0000
1449627 PID:459000a TID:45a000a @1467,831,000us: [+0 T:0x045a000a S:0x1c01f5f8] OM - Memory_getBufferPhysicalAddress> return (0x885a0000)
1449628 PID:459000a TID:45a000a @1467,833,000us: [+2 T:0x045a000a S:0x1c01f65c] ti.sdo.dmai - [Buffer] Alloc Buffer of size 664192 at 0x1c230000 (0x885a0000 phys)

  • 0
    TI__Genius 9185 points

    Can you clarify where you downloaded the DVSDK for DM6446? If it was from a TI 3rd party you will have to direct your support questions to them. Please refer to the following post for this forum's scope http://e2e.ti.com/support/embedded/f/353/t/37895.aspx

     

     

  • 0 in reply to Jatin Jain
    Intellectual 570 points

     

     

    Dear Jatin,

     

    Thank you for your response.

    This DVSDK is not from a 3rd party, because I've ported the OMAP3530 DVSDK to DM6446 (DVSDK is came from TI).
    So, I think, there is no 3rd party in this case...

    Otherwise, DVSDK is working fine on DM6446 (I almost finished) just I wanted to know if this message is normally or not.
    I know (according to XDAIS DMA rule 7), caller/application have to manage cached buffers (writing back and invalidating).

    Sorry, my original question is continuously open...

    Peter

     

  • 0 in reply to Peter Ladanyi
    TI__Expert 5320 points

    Peter

    Did you have to turn on special debugzones/flags to see this error? We havent seen this error on OMAP3530 DVSDK so far in retail build. Since this message is coming from the kernel, I would suggest posting this on msdn forum and see if they can provide you with more details on the severity of this message.

    -Madhvi

  • 0 in reply to Madhvi
    Intellectual 570 points

     

     

    Dear Madhvi,

     

    Thank you for your answer (sorry for delay but I was too busy, recently).

    >Did you have to turn on special debugzones/flags to see this error?
    Nothing special, only I built a debug build for some debugging.

    > We havent seen this error on OMAP3530 DVSDK so far in retail build.
    Of course, because there are no WinCE debug messages in retail build...  ;)
    Have you ever tried it in a debug build of OMAP353 DVSDK?

     

    Peter