Get use of a CE codec compiled into an existing GNUmake project...

Janet,

thanks for your hints, that helped me to get this sample built now (for ti.platforms.evmTI816X), as a base for a GNUmake interface to our own codec.

The missing underscore in CONFIG_BLD I already had found myself, but I was happier if I would know the rules, the intentions behind this underscore... as I am very often missing an explained intention within the wood of configuration possibilities (all roads lead to rome - but why sometimes this, othertimes that way?) However, I don't need nothing but to get our codec compiled by that RTSC framework for our current platform and to get a simple interface to GMUmake projects. This now seems solveable for me, in a more clean way than before, thanks.

One open point remains: the file linker.cmd, generated by the configuro tool, contains this line:

INSERT BEFORE .gnu.attributes

Currently I have to delete this line manually, otherwise the linkage of "configured_CE_subsystem" fails, with this error message:

arm-none-linux-gnueabi-ld: .gnu.attributes not found for insert

I assume, that somewhere an configuration entry should be done - maybe you've a hint for concerning this?

Thanks in advance,

Joern.

Joern,
which compiler and which version of it are you using? We need that line to be able to specify sections allocations in addition to the ones from the default linker script. The GNU compilers we tested always define the section .gnu.attributes, but we might have missed some that don't.

There is no configuration parameter that would remove that line, but we can come up with some solution so you don't need to remove that line every time. You'll probably see some increase in the size of your executable image as a consequence of removing that line.

Sasha,

I'm using the CodeSourcery G++ Lite, the compiler and linker versions are:

arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2009q1-203) 4.3.3
GNU ld (Sourcery G++ Lite 2009q1-203) 2.19.51.20090205

The error message of arm-none-linux-gnueabi-ld seems to occur after one of the most recent EZSDK updates, Google deliveres some TI forum entries when looking for ".gnu.attributes not found for insert"...

The application is built for ARM, so soft-float only is available - maybe this leads to the lack of the .gnu.attributes section? Maybe there is a gcc option missing? 

Best regards,
Joern.

PS:

Might the reason for the following error message be affecting the .gnu.attributes lack?

ti.sdo.fc.ecpy.getLibs(): Can't find suffix for GCArmv5T target

Thanks in advance,
Joern.

Janet,

I always prefer it to know the intention behind notations, so thank you very much for the explanation concerning "_config.bld". Maybe I would tend to choose a name being more talkatively, like CEmain_config.bld or CEroot_config.bld or ce_config.bld in this case, but however, to make a difference in naming is good for being sure to catch the right config file...

Concerning "INSERT BEFORE .gnu.attributes" it might be a question of tools version, I am using the most current EZSDK 5.01 from June 1th. And maybe a question of platform target as well, as I found something concerning soft- and hard-float decision when lookin for the .gnu.attributes section...

Sasha,

thank you very much, you made my day, the option -T did it. But in detail:

The original makefile from

/somewhere/codec-engine_3_21_00_13_eng/examples/ti/sdo/ce/examples/apps/video_copy/dualcpu_separateconfig/configured_CE_subsystem/

contained this:

configured_CE_subsystem.o: ceapp.o $(LINKER_FILE)
    $(LD) -r -o $@ $^

where LINKER_FILE contained the complete path of linker.cmd, and LD was containing in the end this:

/somewhere/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi-ld

The latter makes that the option -Wl is not needed here; we call the linker directly. But '-T' actually is needed. In the beginning for a short time I thought of this direct use of the linker.cmd script at an object files position and was wondering about, but then I loosed the track of that.

Now I changed the linker call within the makefile like this:

configured_CE_subsystem.o: ceapp.o $(LINKER_FILE)
    $(LD) -T $(LINKER_FILE) -r -o $@ ceapp.o

and all works fine for the moment, not to forget the changes above, suggested by Janet.

Thanks again, Sasha!

(Should be changed for the next EZSDK version, if possible!)

Janet,

as a "keep hands off" rule it makes sense to me to spend those leading underscores, somewhat like "hidden" global variable names in C often got a leading '_' in the same manner. It's not perfect, but makes sense to me (the more if it was fixed as rule somewhere...) The somewhat increased safety (not to point to the wrong config.bld) I would see more as a side effect. Thanks for your explanation.

Best regards,

Joern.

Just as a late supplement, now regarding EZSDK 5.03 - just as some help for those starters which have discovered the dualcpu_separateconfig sample and so arrived at this thread:

• All the hints by Jane from above seem to have been applicated now, within the delivered sample sources.
• The above change, adding -T, yet is missing and must be done to get configured_CE_subsystem.o linked

Currently I am building for DM8148 (instead of DM6467), so I had to change some other points below configured_CE_subsystem directory:

• within ceapp.cfg:

from
    serverName = "bin/" + platBinName + "/all_DSP.x64P";
to
    serverName = "bin/" + platBinName + "/all_DSP.xe674";

• within makefile I changed for consistency (don't know why the old value had been okay for DM6467):

from
    XDCPLATFORM = ti.platforms.evm3530
to
    XDCPLATFORM = ti.platforms.evmDM8148

And as I had commented out all non-used codecs from the *.cfg files of the all_codecs server (and so VIDENC_copy and VIDDEC_copy, which I only needed now because of again checking around this sample here), so of course functions provided by these codecs had not been linked into configured_CE_subsystem.o and that lead to an linker error when building the enduser_app. Adding the missed codecs again to the all_codecs server removed this little self-made problem, too.

Regards,
Joern.

Thanks for the feedback, Joern.

We're planning to review and clean up the CE examples in the next few months, so we'll take your feedback into account.

Chris

Just another point which somewhat concerns this, to build a CE API into a single object file which may easily be combined with existing, GNUmake based projects...

I've implemented such an API for a codec  server containing (until now) just one single codec, based on the universal_copy sample. I can access the codec functions (running on DSP side) from an ARM side application, by use of my little CE API.

Now I added a library to my codec. FYI, it is a C wrapper around some C++ code (which is provided as a rtsc package then, for howto see here). I did this by using the API header of my small C wrapper and by adding a 'require' statement for theC wrapper package into package.xdc of the xDAIS codec package, where also I am calling the functions provided by this C wrapper.

That works, the functionality implemented within C++, provided by the C wrapper, can be used within the now enhanced xDAIS codec, the ICodec package around and the codec server package are built without problems. If I acess the codec functions with my unchainged application, then I see the enhanced results from the enhanced xDAIS codec.

The remaining problem is: if I want to link my little CE API concerning the new codec server, then the build process crys for an ARM version of my C wrapper library. Which I might build and provide, too, but there is actual no need, because in the end I never want to call the xDAIS codec's functions locally, always I want to call them remotely, from ARM side, but running on DSP side (and this obviously already is working). In this context I found, that there seems to be a linkage with the ARM version of my xDAIS codec, as well (wich might be the only reason for the cry for my C wrapper, but is obsolete, because I don't need nor use it on ARM side).

It seems for me that within the configuration of the xDAIS / ICodec / codec server packages I have somehow to restrict the build to the DSP platform, so that the linkage with the codec engine stuff for the ARM side does no longer include the ARM side versions of the codec... But how? Or have I to provide a dummy ARM version of my C wrapper?

Thanks in advance,
Joern.

Obviously our posts have crossed :-) - but nevertheless thanks a lot for throwing additional light upon this.

Especially thanks for your hint concerning conditional loadPackage() - this way seems nicer for me than my solution, because condition and the library load are directly combined this way.

Nevertheless, additionally I have to prevent the build of the codec for other platforms - like I did within package.bld. But maybe also this should better be done as well by not requiring the xDAIS codec within the ICodec package for all platforms, but by a conditional load within the package.xs there... I will try that out, thanks again.

P.S.

It works, now I have excluded all unwanted package loads from within package.xs, there close(). Helpful concerning this: xdc.IPackage. Especially note the notes there containing this:

if (xdc.om.$name == "cfg") 
{
 print(Program.build.target.name); 
}

This value can be used for target-specific decisions concerning loading or not loading a package...

Regards,
Joern.

hi

Joern

can you give me the whole codes of  the "dualcpu_separateconfig",or anothe good examples.and tell me  how to build this.

my email is lbm9527@126.com.

Regards,
LEE.