• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 103 subscribers
  • Views 3418 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CE examples combined with HDVICP firmware running

Joern
Genius 3055 points

The question is reloaded from this question of mine. The answer by Chris (together with some other reading here in the forum) encouraged me to assume that this problem should be solveable, and so I postponed the solution for a while.

And somewhat I hoped for improved CE examples within the next EZSDK - but now, with EZSDK 5.05.01.04, the status concerning that problem has not changed. And still the hint from the TI wiki is valid: call "/etc/init.d/load-hd-firmware.sh stop" before running the CE samples.

At least this way the problem can easily be reconstructed.

Now, before I start trying around and searching through all the memory map configuration places, I wanted to ask: Is there any concrete hint what and where to be changed to get the problem solved?

  • I have a CE server running on DSP side. Regarding this I have a serverplatforms.xs with lots of memory concerning settings, much of them got from default settings in ti modules.
  • I assume that I have to change as well within the firmware loader, that means within EZSDK/board-support/media-controller-utils_3_00_00_05/src/firmware_loader/memsegdef_default.c
  • Will I have to change also within the memory map binary EZSDK/board-support/media-controller-utils_2_02_00_08/src/mm_host_util? As here is written "Firmware loader load the Dynamically configurable Memory Section info from firmware_loader/src/memsegdef_default.c to MEMCFG_SPACE before loading slave binaries. " - which sounds for me that all needed for the M3 firmwarebinaries is done by the firmware loader, it seems for me as if I wouldn't have to care about that memory map binary - or am I wrong concerning that?
  • As afterwards I want to use OMX modules as well, of course I would have to change in ti/omx/memcfg/memtbl_cfg.h as well.

Without any change and without having stopped the M3 firmware parts, while loading/starting my CE server at least this process freezes (the system sooner or later, too).

I was happy if anyone would have concrete hints concerning the needed changes, as the settings are so widespread and samples and documention differ heavily from each other.

Thanks in advance,
Joern.

  • 0
    Genius 3055 points

    What we've tried is to get the Codec Engine test program "image1_copy" (to produce comparable results) running concurrently to H.264 encoding program. Both are working well as standalone versions, with hd-firmware loaded for the H.264 encoder, and not resp. unloaded for the Codec Engine example.

    We focused on making the shared memory settings consitencely, done for
    • Codec Engine server (serverplatforms.xs and corresponding .cfg)
    • OMX modules (omx_05_02_00_46/src/ti/omx/memcfg/memtbl_cfg.h)
    • firmware loader called in load-hd-firmware.sh

    For the firmware loader it is not yet clear where the settings actually should be done - where within memsegdef_default.c, or instead/also by generating a memory map file? And do the hd-firmware binaries actually gettheir settings dynamically, or are there some constraints?

    Until now the "concurrency issue" exists: starting image1_copy with loaded hd-firmware makes the system frozen.

    Thanks in advance for any hint,
    Joern.

  • 0 in reply to Joern
    TI__Prodigy 505 points

    Joern,

    The reason for concurrency not working with CE (Codec Engine)examples and firmware binaries are due to the mismatch in memory map between CE examples and firmware binaries. Since Codec Engine supports multiple platforms, it has chosen a generic memory map, whereas firmware binaries use customized memory map optimized for OMX use cases. Please check the link http://processors.wiki.ti.com/index.php/EZSDK_Memory_Map for more details about EZSDK memory map.

    If the memory map of CE example could be modified accordingly to the EZSDK memory map, then we can run both OMX usecases and CE examples concurrently. Apart from this, there is a known issue where concurrent use of  OMX and CE examples failed on multiple iterations, the fix is already available in the latest CE release. Please let me know if you need any support regarding CE Memory map changes, I can help you with.

    Regards

    Ansari

  • 0 in reply to Ansari
    Genius 3055 points

    Ansari,

    thanks a lot for your response!

    Concerning the known CE issue you write about, so I should actually change from the CE coming with EZSDK 5.05.01.04 (3.22.01.06) to the most current 3.23.00.07?

    Concerning my memory map experiments now I'll focus on the CE settings in serverplatforms.xs only, but I fear that concerning this I already all had tried - either the issue you spoke about yet made problems, or I was missing a setting.

    I'll go through that carefully again, and then post my results (maybe I'll have enough time only in next Monday).

    Kind regards,
    Joern.

  • 0 in reply to Joern
    Genius 3055 points

    Hi Ansari,

    in the meanwhile I could continue testing. I switched to using CE 3.23.00.07, and I tested with the example ex01_universalcopy_remote from there.

    Still it does not work when /etc/init.d/load-hd-firmware.sh was enabled and so the firmware of the video subsystem has been started. But from your answer and also from that thread I get the hope, that in principle it actually will be possible.

    The current failure message looks like:

    root@dm814x-evm:/opt/yat# ./universal_copy_remote.xv5T
    [t=0x00000005] [tid=0x40053000] xdc.runtime.Main: main> ti.sdo.ce.examples.apps.universal_copy
    [t=0x0000071e] [tid=0x40053000] xdc.runtime.Main: [+1] App-> Application started.engineName remote_copy_dsp input-file ./in.dat output-file ./out.dat.

    (here the app waits for a longer while)

    App-> ERROR: can't open engine remote_copy_dsp
    [t=0x046139d4] [tid=0x40053000] xdc.runtime.Main: [+1] app done.

    So obviously I didn't get all memory settings being set right.

    What I've done is:

    • Changed /work/ce/ex01_universalcopy_remote/shared/_config.bld to:

    var Build = xdc.useModule('xdc.bld.BuildEnvironment');

    var DM8148_DSP_ExtMemMap = {
                DDR3_HOST: {
                    comment: "DDR3 Memory reserved for use by the A8",
                    name: "DDR3_HOST",
                    base: 0x80000000,
                    len:  0x0B000000    /* 176 MB */
                },
                DDR3_DSP: {
                    comment: "DDR3 Memory reserved for use by the C674",
                    name: "DDR3_DSP",
                    base: 0x99500000,
                    len:  0x00C00000    /* 12 MB */
                },
                DDRALGHEAP: {
                    comment: "DDR3 Memory reserved for use by algorithms on the C674",
                    name: "DDRALGHEAP",
                    base: 0x98000000,
                    len:  0x01400000    /* 20 MB */
                },
                DDR3_SR1: {
                    comment: "DDR3 Memory reserved for use by SharedRegion 1",
                    name: "DDR3_SR1",
                    base: 0x99400000,
                    len:  0x00100000    /* 1 MB */
                },
                DDR3_SR0: {
                    comment: "DDR3 Memory reserved for use by SharedRegion 0",
                    name: "DDR3_SR0",
                    base: 0x9F700000,
                    len:  0x00200000    /* 2 MB */
                },
    };

    /* platform instances used by this package */
    Build.platformTable["ti.platforms.evmTI814X:DSP"] = {
        externalMemoryMap: [
            [ "DDR3_DSP",   DM8148_DSP_ExtMemMap.DDR3_DSP ],
            [ "DDRALGHEAP", DM8148_DSP_ExtMemMap.DDRALGHEAP ],
            [ "DDR3_SR1",   DM8148_DSP_ExtMemMap.DDR3_SR1 ],
            [ "DDR3_SR0",   DM8148_DSP_ExtMemMap.DDR3_SR0 ]
        ],
        codeMemory: "DDR3_DSP",
        dataMemory: "DDR3_DSP",
        stackMemory: "DDR3_DSP"
    };

    (I left out the memory maps for the M3 parts, as I built only for the DSP and ARM side - was that wrong?)

    • Furthermore I changed the CMEM setting within my loadmodules.sh: 

    #!/bin/sh

    CMEM_MODPARAMS="phys_start=0x96C00000 phys_end=0x97ffffff pools=20x4096,10x131072,1x4147456"

    if [ -e syslink.ko ]
        then
            insmod syslink.ko TRACE=1 TRACEFAILURE=1 TRACEENTER=0 TRACECLASS=3
        else
            modprobe syslink TRACE=1 TRACEFAILURE=1 TRACEENTER=0 TRACECLASS=3
    fi

    if [ -e /dev/syslinkipc ]
        then
            for dev in `ls /dev/syslinkipc`; do
                chmod 666 /dev/syslinkipc/$dev
            done
    fi

    if [ -e cmemk.ko ]
        then
            insmod cmemk.ko $CMEM_MODPARAMS
        else
            modprobe cmemk $CMEM_MODPARAMS
    fi

    if [ -e /dev/cmem ]
        then
            chmod 666 /dev/cmem
    fi

    Which other settings yet should be checked? Or did I some stupid error above?

    Thanks in advance,
    Joern.

  • 0 in reply to Joern
    Guru 10685 points

    Hi Joern, while I don't claim to be hot on this subject, I'm doing exactly the same thing as you. As far as I can tell, you've used the wrong segment for DD3_SR1. You should be using "0x9A100000". This is called "IPC_SR_MC_HDVICP2_HDVPSS" in http://processors.wiki.ti.com/index.php/EZSDK_Memory_Map.

    Of course, it's unclear from the documentation which address you should be using so it's no surprise you had an incorrect address. There are more "shared regions" than you can shake a stick at on the afforementioned webpage.

    Ralph

  • 0 in reply to _Ralph_
    Genius 3055 points

    Ralph, thanks a lot,

    your hint finally solved the problem.

    Obviously when setting DDR3_SR1 my decision between IPC_SR_HOST_DSP and IPC_SR_MC_HDVICP2_HDVPSS from the memory map was wrong. And yes, it's a lack of documentation.

    A colleague of mine yet observed an issue when restarting the universal_copy example multiple times while h.264 encoding is running, but that still needs more investigation and will lead into a new thread, if necessary.

    Thanks again, also to you, Ansari,
    kind regards,
    Joern.

  • 0 in reply to Joern
    Genius 3055 points

    Postscript

    Joern said:
    A colleague of mine yet observed an issue when restarting the universal_copy example multiple times while h.264 encoding is running, but that still needs more investigation and will lead into a new thread, if necessary.

    This above named issue still has not been solved, we described it a bit more concretely within that new thread. Thanks in advance for any hint,

    Joern.

  • 0 in reply to _Ralph_
    Prodigy 30 points

    _Ralph_ said:
    As far as I can tell, you've used the wrong segment for DD3_SR1. You should be using "0x9A100000". This is called "IPC_SR_MC_HDVICP2_HDVPSS" in http://processors.wiki.ti.com/index.php/EZSDK_Memory_Map.

    Thank you very much for advice. It is so unobvious that I would never get in mind that IPC_HOST_DSP is not right memory region.

  • 0 in reply to Pavel Savygin
    Guru 10685 points

    My pain is our collective gain. :-D

  • 0 in reply to _Ralph_
    Prodigy 30 points

    _Ralph_ said:
    My pain is our collective gain

    After such a pains  I feel  yearning to put TI engineers into the hell made of TI's docs, build systems and configs outside of TI office.


    For now I'm using different gcc versions for kernel and middlware, one more compiler for DSP, three different build systems (one is based on EZSDK makefile, second is javascript xdctools mess,  and another to build codec engine compatible application). Besides I have to use CCS based on crappy eclipse.


    I can not imagine novice that can light up all this stuff.

  • 0 in reply to Pavel Savygin
    Guru 10685 points

    It's terrible isn't it? This has been the first major SDK for a chip that I've worked on and unfortunately has given me the impression that all SDKs are as incoherent as this one. On the plus side, I suppose if I can handle the EZSDK then I can probably handle anything!

    Yes, I totally hate XDC too. ;-)