• State
  • Locked Locked
  • Replies 11 replies
  • Subscribers 103 subscribers
  • Views 1535 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.

DM3730 DMAI codec translation cache issue.

David Foringer
Prodigy 60 points
Other Parts Discussed in Thread: DM3730

5852.boot_args_startup.log1030.ce_debug_1.log7384.ce_debug_3.log

Hi all,

We are experiencing an error, that appears to be with CMEM and/or the codec engine.
 
The "Memory_getVirtualAddress> Error:...translation cache" returned from the CE_DEBUG results seems to be well documented on the boards, but I was unable to find a solution. (We seem to be having the same issue as ...) Perhaps it is CMEM??   
Fails for CMEM from linux utils 2.26.02.05 (which came with our board support package).
Fails for CMEM from linux utils 3.2.23.00.01 (which we downloaded from TI)
We see the errors with gstreamer and with the ti-dmai demo application (video_encode_io1_dm3730) when we specify the h264enc or mpeg4enc.  It seems that regardless of how we run this, the errors are coming from the codec engine.
I have attached boot log and dump of both CE_DEBUG outputs from the gstreamer scripts below. 
This issue seems to be related to an issue posted by  peng hong(e2e.ti.com/support/embedded/linux/f/354/t/151619.aspx)
 
OMAP Logic # run nfsboot
Booting from network using NFS rootfs...
Bootargs:
console=ttyO0,115200n8 root=/dev/nfs rw nfsroot=192.168.100.102:/home/logic/logic/Logic_BSPs/Linux_3.0/1022853_LogicPD_Linux_BSP_2.2-2/rootfs ip=192.168.100.101 display=720p-hdmi early_printk no_console_suspend mem=55M@0x80000000 mem=128M@0x88000000 vram=14M omapfb.vram=0:8M,1:3M,2:3M
 
CE_DEBUG=1 gst-launch -v videotestsrc num-buffers=10 ! 'video/x-raw-yuv,width=320,height=240,format=(fourcc)UYVY' ! TIVidenc1 framerate=15/1 codecName=h264enc engineName=codecServer contiguousInputFrame=TRUE ! testsink
CE_DEBUG=3 gst-launch -v videotestsrc num-buffers=10 ! 'video/x-raw-yuv,width=320,height=240,format=(fourcc)UYVY' ! TIVidenc1 framerate=15/1 codecName=h264enc engineName=codecServer contiguousInputFrame=TRUE ! testsink
 
 
Any advice would be appreciated.
Dave.
  • 0
    TI__Expert 7415 points

    Dave,

    Just as in the post you have linked to, it appears that codec is returning pointers to buffers that won't be accessible from the ARM-side. The messages are all w.r.t memory sections in the DDRALGHEAP section. 

    Please include details regarding codec version so we can bring it to the attention of the codec team. They might have more input.

    Thanks,

    Gunjan.

  • 0 in reply to Gunjan
    Prodigy 60 points

     

    Gunjan,

    Thanks for the quick response. The Codec h264enc is version 01.00.02.00.  From the codecs-omap3530_4_02_00_00  package from the DVSDK TI-DVSDK_dm3730-evm_04_03_00_06

    Is there an update available?

    Dave.

  • 0 in reply to David Foringer
    Prodigy 210 points

    Hi David,


    I remember having faced similar issue while migrating our codecs from CE2_21 to CE2_26 last year.
    We faced these issues in both mpeg4 and h264 encoder.


    I guess it is same issue as the buffer sizes reported in CE debug log seem to be loosely match recon size for target resolution.
    Here is a very similar issue reported in e2e forum when I did some research to investigate my issue back then.

    http://e2e.ti.com/support/embedded/linux/f/354/p/87684/304901.aspx#304901

    I have made some detailed observations on how these issues started showing in CE_2_26.
    @Gunjan, please correct me if I am wrong here (I am no CE expert but understand few internals)


    This issue is related to codec not setting reconBufs->numBufs to 0 and corresponding buffer descriptor (in IVIDENC1_OutArgs) when the recon is disabled (recon chroma format = XDM_CHROMA_NA)
    This never seemed to have issue in CE_2_21 as CE would not touch the buffer descriptors.

    In the newer version (referring to CE_2_26) there is no longer any automatic "registration" of buffers in the translation cache
    The CE does explicit address conversion of recon buffer descriptors (even if recon chroma format is XDM_CHROMA_NA) resulting in these errors.

    Back then we modified codecs to set reconBufs->numBufs to 0 and setting buffer descriptors to NULL and the issue was resolved.
    However I feel CE should not have unconditionally done the address translations. (when recon format is XDM_CHROMA_NA)

    For now we can give you updated codec with reconBufs->numBufs set to 0 and corresponding buffer descriptors set to NULL.
    But as I am on travel during this week and next week as well you can expect a drop only in 1st week of December.
    Is it ok with you ?

    I am not sure if there is a quick workaround that can be done outside the codec (CE or app) 
    I can only think of following options:
    [1] Set reocnBufs->numbufs to 0 and descriptors to NULL outside the codec.
    [2] The other option is to use older CE version until the new codec drop

    Regards,
    Jay




  • 0 in reply to Jay Shingala
    Prodigy 60 points

    Jay,

    If you could toss me the updated codec that would be fantastic.  

    Thanks,

    Dave.

  • 0 in reply to Jay Shingala
    Prodigy 50 points

    Jay,

    We are being affected by the same issue. Would you mind providing the codec with reconBufs->numbufs set to 0?

    Thanks,
    -Nate 

  • 0 in reply to Nate Weibley
    Intellectual 420 points

    I'm seeing these messages too. Could you send me a codec too?

  • 0 in reply to R1234
    Intellectual 420 points

    Can anyone comment please?

    Is there a working software workaround available or can this only be fixed with the new codec?

    Thanks.

  • 0 in reply to R1234
    TI__Intellectual 2790 points

       Have you or anyone attempted the workarounds suggested by Jay in his last post?

    [1] Set reocnBufs->numbufs to 0 and descriptors to NULL outside the codec.
    [2] The other option is to use older CE version until the new codec drop

    Regards,
    - Gil
  • 0 in reply to GAnthony
    Intellectual 420 points

    Hi All,

    I tried option 2 and it seems to work, the translation cache messages are gone.

    Unfortunately this was not our main problem since the codec still crashes/stops working.

    Thanks,

    Robin

  • 0 in reply to R1234
    Intellectual 420 points

    A new codec has been build by ittiam.

    That solves the translation cache messages, its in version H.264 encoder 01.00.03.01 released april 2013.

  • 0 in reply to R1234
    Prodigy 80 points

    I'm currently having the same issue with the translationcache error with a physaddr of 0x8eb03da0 located in the DDRALGHEAP (physAddr = 0x8eaff000, dspAddr = 0x8eaff000, size = 0x1000000)

    I'm building a firmware image based on the yocto project (http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-ti/codec-engine/ti-codecs-omap3530_4.00.00.00.bb?h=master). Not sure what version of the H.264 encoder that is, but as the file dates are all much older than april 2013, I guess it's not the mentioned one that already seemed to fixed this error. 

    This leads to the question where do we get the april 2013 version of the H264 encoder from?