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.

C6Run framework dsp_libs build problem

Other Parts Discussed in Thread: SYSBIOS

Hi everyone,

since I stopped looking into OpenMax for now, due to execution problems, which I have not been able to resolve so far, I thought I would look into C6Run and C6accel, but
currently I encounter build problems.

My kernel is the current arago linux-omap3 ti81xx branch.

I use the following packages:

bios_6_32_03_43

C6Run_0_97_03_03 or
C6Run_0_98_00_00-beta or          
C6Run_0_98_00_00-beta250811
ipc_1_23_03_31
linuxutils_3_21_00_04
syslink_2_00_02_80

TI_CGT_C6000_7.3.0
xdctools_3_22_02_27

Here my errlog: 4578.error.log

I' m able to build gpp_libs, but not dsp_libs, as there are redefinitions in the C6..pe lib or object file of functions/types in the korresponding bios libs (error log).
I tried to find out where this libs will be supplied (link_partial.cmd generated from linkcmd.xdt in the corresponding bios DIR). But I can't find out where
the actual paramters are supplied. If I would try to link without them to resolve the problem, but they might still be needed due to other symbols.

I tried to build the older version of C6Run too, but then it misses some cargs.h header, which I think gives the position of the arguments supplied to the DSP main.

Any Ideas how to get it to work?

Thanks,

Markus

  • Ok, I still have the same issues when building the dsp_libs target.
    I can't find out where those references to the Sysbios files are generated, otherwise I could try to not include them to overcome the problem of multiple
    defined symbols.

    Is there anyone experiencing the same issues? Or has anyone managed to successfully build C6Run?

    Regards

    Markus

  • I have managed to exclude those libraries from linking. I don't know if that could have been done using xs' argument options.

    Here is the patch for build/perl/linker_cmd_prep.pl: 8816.linker_cmd_prep.txt

    This might not be needed in future versions and if someone finds out how to do the more elegant, please let us know.
    If you apply the patch under Linux/Unix convert the .pl file to unix format before otherwise the patch fails. Then the dsp_libs target is able to build. I have not tested the functionality yet.

    Regards Markus

  • Ok, now the examples /tests can't be build because some symbols are missing now, which are in these libraries or sources not copied into C6Run_pe674.c.

    Regards Markus

  • I'm not familiar with xdc, but is it correct that the  XS configuro step generates linker.cmd files as well as the C6Run .pe files?
    My next guess is that it copies all needed functions from the packages source (in this case (SYS)BIOS) into that file.

    Is that controlled by the usePackage command? Or how does XS select which packages to include in the .pe file?
    I think it would be necessary to include the missing symbols into that source too and remove all of the libraries above from the linker.cmd. I don't know if that is the best approach, but I guess not including anything in the .pe files and linking all library files will lead to much overhead as it might be the case that not all fucntions are needed by C6Run.

    I'm going to look into it for now and I let you know if I get any new results. I hope that this isn't some minor mistake of mine which costs me so much time :).

    Regards, Markus

  • UPDATE: As I see it in BIOS.xs the BIOS.c file is added to the source var which will be returned when requested. So, I don't know why BIOS_start for example, isn't included in C6Run_pe674.c or anywhere else. I'll have to look into this more tomorrow.

    Regards, Markus

  • Using the latest trunk of the C6Run repository, I have been able to replicate your issue.

     

    Component versions held constant:

    C6Run_trunk (equivalent to an unreleased 0.98.01.01), ipc_1_23_03_31, linuxutils_3_21_00_04, syslink_2_00_02_80, TI_CGT_C6000_7.3.0, CodeSourcery q12009

     

    Component versions that I varied:

    bios_6_32_01_38/bios_6_32_03_43 and xdctools_3_22_01_21/xdctools_3_22_02_27

     

    My results:

    bios_6_32_01_38 and xdctools_3_22_01_21 - PASS (no build issue)

    bios_6_32_03_43 and xdctools_3_22_01_21 - PASS (no build issue)

    bios_6_32_01_38 and xdctools_3_22_02_27 - FAIL (dsp build fails with similar error as your log)

    bios_6_32_03_43 and xdctools_3_22_02_27 - FAIL (dsp build fails with similar error as your log)

     

    This tells me that the xdctools version is causing the issue. For right now, I would recommend at least reverting the xdctools version you are using.  I think it would be even better to revert the bios6 and xdctools versions to the same ones that are included in the current EZSDK release (the 5.02.01.59 EZSDK release uses bios_6_32_01_38 and xdctools_3_22_01_21).

    I will try investigating why the change in the xdctools breaks the build.

    Regards, Daniel

  • Hi Daniel!

    Ok, thank you. As we don't have access to the current EZSDK for DM8148, I built my own from the available tools, until we have I'll revert to the xdc tools as suggested.
    My guess is that there is a bug with the useModules and the whole program debug option, as some of the useModules are ignored, i.e. are not copied into to ....../C6Run/package/cfg/C6Run_pe674.c, but as I understood either should have been copied there or should be done using linking the correct libs.

    Again thank you.

    Regards, Markus

  • The EZSDK early adopter releases were made a few days ago. 

    http://software-dl.ti.com/dsps/dsps_public_sw/ezsdk/latest/index_FDS.html

    Do you have access to the above link?  There is one release for DM816x and one for DM814x.

    Regards, Daniel

  • Yes, I have access. I'll try to download it tomorrow in our company. Might be the case that my account hasn't got the rights, but my superior should.

    Thanks and Regards, Markus