I am required to dump encoder reconstructed buffer. Memory to this buffer is supplied by DSP using memTab to codec. Pointer to this buffer is provided in outArgs.reconBufs.bufDesc.buf. I am able to get valid buffer pointer if I access outargs from DSP side. If I try to access the buffer from ARM side, I get NULL buffer pointer.
Any idea why ???
I am using CE version 2_10_02. Platform is DM6467.
Couple more details... this is a IVIDENC1-codec?
Assuming 'yes', your comment about the reconBufs are memTab-allocated is a bit concerning... in general, the ARM can only see buffers it allocates. The IVIDENC1 interface defines that the reconBufs are provided by the app (via the outBufs[1-3]) for exactly this reason. See the details about the reconBufs field here:
Yes, this is IVIDENC1-codec. Since the buffers are provided to codec using memTab, ARM has no way to see the buffer pointer??? Is there any workaround??
If I understand the issue correctly, this codec violates the IVIDENC1
XDM spec. :( So any workaround would be codec specific... but we can
discuss options. At the end of the day, the codec should be fixed.
the DM6467 doesn't have a DSP-side MMU, the physical addresses are the
same from both processors. So if you can find the location of the DSP-side
memTab dynamically allocated to the codec for its reconstruction buffers, your
ARM-side app could mmap() that physical buffer into its virtual address space
(likely non-cached so as not to introduce Linux-side cache coherency issues) and
then access the memory from the ARM.
How can you get this address? You could define a
custom control() cmd id and update the codec to return the memTab's physical address value (via extended Status struct) when it receives this new control() cmd. Or if the codec is always provided the same block of memory, you could hard-code it
into your Linux-side app.
Others on this forum may be able to
provide the usermode code necessary to map physical memory into a
processes virtual address space.
These complexities are precisely
why the interface was designed the way it was... and is why the ultimate
fix is to make the codec comply with the IVIDENC1 spec.
Thanks for suggestion!
ARM is seeing DDR address as 0x41xxxxxx while DSP see address as 0x8xxxxxxx. I tried the workaround by allocating reconbuf memory from ARM9 side. I used XDM_GETBUFINFO and XDM_SETBUFINFO for that. Codec is providing back application the pointer to reconstructed frame in outArgs.reconBuf.bufDesc. Application is still seeing the reconbuf pointer value as NULL. Other paramters like size and pitch are fine. I have verified the codec is writing pointers correctly and it is also seen correctly by VIDENC1_process() call in videnc1.c file.
Any clue further???
For completeness, this issue was resolved off thread, and I'll post the general resolution here.
The root cause was that the codec was returning a buffer (base + size) that was outside the range of the buffer provided by the ARM - and therefore, the ARM-side address translation of DSP-side phys to ARM-side virt address was failing. This was detected using the Memory_dumpKnownContigBufsList() API, and observing that the base + size of the codec-returned reconstruction buffer was not completely within the range of any 'known contiguous buffers'.
In this case, the actual data _was_ within a known contig buffer, but the buffer the codec was returning was larger than the data - something like this:
ARM-provided buffer-to-fill: [ ]DSP-returned buffer ('X' is data): [XXXXXXX ]
Once the DSP-side codec was modified to [correctly] return a buffer that was within a valid range - i.e., within the range of the buffer sent by the ARM - these address translations could succeed... something like this:
DSP-returned buffer ('X' is data): [XXXXXXX]
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.