Ah, OK. This whole ordeal has been one big hack, admittedly. ATEME's build instructions involved adding some definitions to the command file already (which, yes, I did have to reenter every time I did a 'make' after a 'make clean'), and a support rep from TI recommended editing the command file, also, to fix the _DDR2 symbol issue. Your guys' solution definitely seems like the correct way to do things. I will be sure to go back and do that.
Is Rules.make deprecated?! Not sure if this was the right thing to do, either, but I had to modify xdctools_3_10_03/packages/gnu/targets/MVArm9.xdc, replace the "/bin/arm_v5t_le-gcc" strings with my compiler's invocation, and rebuild the package because MVTOOL_PREFIX was being ignored. I also could not get the build process to include FrameworkComponents in my XDCPATH I should maybe start a separate thread since this doesn't seem related to DSPLink, but it seems when the GPP demo app tries to link, a lot of symbols ended up missing. I compared the linker.cmd with the linker.cmd of the version that works (built against DVSDK 1.20), and noticed a lot of missing libraries. Just for grins, I patched in the filenames from the working linker.cmd. Turns out, none of those files exist: ce.a470MV, video.a470MV, osal_dsplink_linux.a470MV, node.a470MV, alg.a470MV, and gt.a470MV are all missing. The strange thing is, they exist for different targets, i.e. ce.a470uC, ce.a64P, ce.av5T, etc., are all there, but not the *.a470MV versions. Anybody have any idea what went wrong or how to fix it? Is there a "Getting TI's stuff to jive with something other than DVEVM hardware and MVPro4" guide that I missed? I feel like I'm missing something fundamental, here. I will be really glad when I get this board up and recording video. Thanks again, folks, you've been extremely helpful. Ryan > -----Original Message----- > From: David Chan [mailto:[email protected]] > Sent: Thursday, February 12, 2009 7:15 PM > To: Ryan Talbot > Cc: Monk, Roger; [email protected] > Subject: Re: Dsplink.dsp? > > Ryan > This is not the way to do it. You can't try to trick every time. > Like Roger said, you should open the link.xdt in the codec package. > It seems that this "DDR" is from that file. > Modify the "DDR" in that file to "DDR2". And rebuild the > codec package with following command: > > $XDC -PR [PATH TO THE CODEC] > > David > > On Feb 13, 2009, at 5:29 AM, Ryan Talbot wrote: > > > I opened my linker command file > > (package/cfg/xavsc_ateme_server_x64Pcfg.cmd) and added: > > > > _DDR2 = DDR; > > > > Under the OBJECT ALIASES section. That seems to have done > the trick. > > > > Thanks for your help, everyone. > > > > Ryan > > > >> -----Original Message----- > >> From: Monk, Roger [mailto:[email protected]] > >> Sent: Thursday, February 12, 2009 4:55 AM > >> To: David Chan; Ryan Talbot > >> Cc: [email protected] > >> Subject: RE: Dsplink.dsp? > >> > >> Ryan, > >> > >> I'd recommend looking inside the generated linker command file > >> contributions file > >> (package/cfg/xavsc_ateme_server_x64P.xdl) and searching > for 'DDR'. > >> This will tell you which contributing package(s) (likely a codec) > >> reference 'DDR', and you'll see something like this just above the > >> contribution :- > >> > >> /* Content from some.package.name (some/package/name/link.xdt): * > >> > >> Xxxxxx > DDR > >> > >> You can then go and look in this corresponding link.xdt file (from > >> the corresponding package) to see if there is a hardcoded > reference > >> to 'DDR' or whether this parameter can be configured using > a module > >> config parameter - if this is a well written package, > you'll be able > >> to change the name of the section easily in your server > config script > >> - if not, you'll need to modify the link.xdt manually (for > now) and > >> need to submit this as a bug to the package producer. > >> > >> Hope this helps, > >> ~Roger > >> > >> -----Original Message----- > >> From: [email protected] > >> [mailto:[email protected] > > ] On Behalf Of David Chan > >> Sent: 12 February 2009 07:27 > >> To: Ryan Talbot > >> Cc: [email protected] > >> Subject: Re: Dsplink.dsp? > >> > >> Ryan, > >> > >> What's your new failure log? > >> > >> David > >> On Feb 12, 2009, at 1:57 PM, Ryan Talbot wrote: > >> > >>> Well, I changed all occurrences of "DDR" to "DDR2" in app.tcf and > >>> app.cfg in my ateme/servers/xavsc_ateme_server directory. The > >>> "undefined symbol _DDR2" error went away, but it still > >> failed to link > >>> with: > >>> > >>> /home/rtalbot/dvevm_2_21/cg6x_6_0_16/bin/lnk6x -w -q -u > >> _c_int00 -s -l > >>> link.cmd -q -o xavsc_ateme_server.x64P > >>> package/cfg/xavsc_ateme_server/main.o64P > >>> package/cfg/xavsc_ateme_server_x64P.o64P > >>> package/cfg/xavsc_ateme_server_x64Pcfg.o64P > >>> package/cfg/xavsc_ateme_server_x64Pcfg_c.o64P > >>> package/cfg/xavsc_ateme_server_x64P.xdl -c -m > >>> package/cfg//xavsc_ateme_server.x64P.map -l > >>> /home/rtalbot/dvevm_2_21/cg6x_6_0_16/lib/rts64plus.lib > >>>>> warning: can't find a memory area named 'DDR' on page 0 for > >>> allocation of > >>> '.text:avsc_init' > >>>>> error: can't find any memory areas for allocation of > >>> '.text:avsc_init' > >>>>> error: can't allocate '.text:avsc_init' into 'DDR' (page 0) > >>>>> warning: can't find a memory area named 'DDR' on page 0 for > >>> allocation of > >>> '.text:avsc_pic' > >>>>> error: can't find any memory areas for allocation of > >>> '.text:avsc_pic' > >>>>> error: can't allocate '.text:avsc_pic' into 'DDR' (page 0) > >>>>> error: errors in input - xavsc_ateme_server.x64P not built > >>> gmake: *** [xavsc_ateme_server.x64P] Error 1 > >>> > >>> Was there a higher-level .tcf and .cfg file I needed to > modify? It > >>> seems like not all of the components got the memo... > >>> > >>> Thanks again for your help, guys, > >>> Ryan > >>> > >>>> -----Original Message----- > >>>> From: David Chan [mailto:[email protected]] > >>>> Sent: Wednesday, February 11, 2009 8:27 AM > >>>> To: Griffis, Brad > >>>> Cc: Ryan Talbot; [email protected] > >>>> Subject: Re: Dsplink.dsp? > >>>> > >>>> Hi guys, > >>>> > >>>> Don't guess anymore. I've built my own codec package tree > >> and codec > >>>> server tree. DDR is not the problem. From DSPLINK1.40. > >>>> DDR2 to is used to take the place of DDR. Just rename the > >> section DDR > >>>> to DDR2. and modify the correspond to DDR in the .cfg > >> file. It will > >>>> be compiled without any problem. But When the server run > >> your Linux > >>>> system will be crashed. I've check with TI, the problem > should be > >>>> from the codec himself. Codec is not compatible to Xdais 6.20 or > >>>> later, hence imcompatible to dsplink1.6. They send me a > >> mail, that > >>>> they've send me the new codec. But problem now is I > can't track my > >>>> package with Fedex. > >>>> Wish I can got them soon. > >>>> On Feb 11, 2009, at 9:15 PM, Griffis, Brad wrote: > >>>> > >>>>> I've run into similar issues in the past. In my case the error > >>>>> originated in the tcf file for the DSP. There seems to > >> be a little > >>>>> bit of inconsistency in the naming of the external > >> memory. I have > >>>>> seen some processors where it's called "DDR" and other > processors > >>>>> where it's called "DDR2". > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Ryan Talbot [mailto:[email protected]] > >>>>>> Sent: Wednesday, February 11, 2009 3:57 AM > >>>>>> To: David Chan > >>>>>> Cc: Griffis, Brad; > [email protected] > >>>>>> Subject: RE: Dsplink.dsp? > >>>>>> > >>>>>> Hey guys, > >>>>>> > >>>>>> I'm now getting a linker error while building the > >> server. It says > >>>>>> that > >>>>>> _DDR2 is an undefined symbol, coming from dsplink.lib. I > >>>> guess this > >>>>>> is because I am now using DSPLink 1.60 instead of 1.30, > >>>> but I can't > >>>>>> find any information on this _DDR2 symbol. Does anybody > >>>> know what it > >>>>>> means or what it should be? > >>>>>> > >>>>>> I also could not find the BIOSUtils package anywhere as a > >>>> standalone > >>>>>> download. I ended up creating a symbolic 'bios' link that > >>>> resides in > >>>>>> codec_engine_2_21/packages/ti that points to > >>>>>> codec_engine_2_21/cetools/packages/ti/bios, because > >> otherwise the > >>>>>> compilation would fail saying that it couldn't find > the package > >>>>>> ti.bios.utils. > >>>>>> > >>>>>> You guys have been a great help, thanks! > >>>>>> Ryan > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: David Chan [mailto:[email protected]] > >>>>>>> Sent: Tuesday, February 10, 2009 9:04 AM > >>>>>>> To: Ryan Talbot > >>>>>>> Cc: Griffis, Brad; > >> [email protected] > >>>>>>> Subject: Re: Dsplink.dsp? > >>>>>>> > >>>>>>> Ryan, > >>>>>>> > >>>>>>> It's seems that you are not using the DVSDK2.0EA > >> edition. I think > >>>>>>> that you will meet another roadblock as I have meet. > >>>>>>> > >>>>>>> If the codec is not developed by your own team, you will > >>>> find that > >>>>>>> the Codec is not compatible the dsplink 1.50 or later. > >>>>>>> (Video_copy can run, but the codec server from current > >>>> codecs will > >>>>>>> crashed the kernel! This is why my personal release of > >>>>>>> CE2.21 based on my toolchain is delayed) > >>>>>>> > >>>>>>> Just got the mail from TI, that new codecs are Fedexed to me. > >>>>>>> But until now, I don't know where are them. Trying > >> tracking them > >>>>>>> now! > >>>>>>> > >>>>>>> The best now seems to be dsplink1.4 with mv50 (or my > >>>>>>> toolchain) and new kernel . > >>>>>>> > >>>>>>> David > >>>>>>> On Feb 10, 2009, at 2:08 PM, Ryan Talbot wrote: > >>>>>>> > >>>>>>>> Thanks, Brad, that seems to have cleared that roadblock. > >>>> I hadn't > >>>>>>>> noticed that difference between the two releases... > >>>>>>> downloading each > >>>>>>>> component separately really is proving to be a pain. > >>>>>>>> > >>>>>>>> David, thanks again for your input earlier; I was in the > >>>> process of > >>>>>>>> implementing it when Brad's solution showed up in my inbox > >>>>>>> and did the > >>>>>>>> trick. > >>>>>>>> > >>>>>>>> Ryan > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: [email protected] > >>>>>>>>> > [mailto:[email protected] > >>>>>>>>> ] On Behalf Of Griffis, Brad > >>>>>>>>> Sent: Monday, February 09, 2009 10:06 PM > >>>>>>>>> To: Ryan Talbot; > >> [email protected] > >>>>>>>>> Subject: RE: Dsplink.dsp? > >>>>>>>>> > >>>>>>>>> This path is likely incorrect: > >>>>>>>>> > >>>>>>>>> /home/rtalbot/dvevm_2_21/dsplink_1_60/packages > >>>>>>>>> > >>>>>>>>> You need to do one of the following to fix it: > >>>>>>>>> > >>>>>>>>> 1) Root through the various makefiles to figure out > >> where they > >>>>>>>>> define XDCPATH and delete the extra "packages" they are > >>>>>>> appending to > >>>>>>>>> the dsplink path. > >>>>>>>>> > >>>>>>>>> - OR - > >>>>>>>>> > >>>>>>>>> 2) Add a "packages" folder in between the "dsplink_1_60" > >>>>>>>>> folder and the "dsplink" folder. (This is probably the > >>>>>>>>> quickest/easiest.) > >>>>>>>>> > >>>>>>>>> I think this all came about because there is a > >>>> CONVENTION at TI to > >>>>>>>>> put all the RTSC packages of a product into a > >> directory called > >>>>>>>>> "packages". DSPLink does not follow this convention > >>>> and the DVSDK > >>>>>>>>> tried to force the convention upon DSPLink. So in the > >>>> version of > >>>>>>>>> dsplink that is delivered with the DVSDK they created > >>>> that extra > >>>>>>>>> directory called "packages" so it would follow the same > >>>>>>> convention as > >>>>>>>>> everything else. It makes everything look uniform, but it > >>>>>>> can be a > >>>>>>>>> real pain in the rear if you try to use a freshly > >>>>>>> downloaded version > >>>>>>>>> of dsplink. > >>>>>>>>> > >>>>>>>>> Brad > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: > [email protected] > >>>>>>>>>> > >>>>>>> > >> [mailto:[email protected]] On > >>>>>>>>>> Behalf Of Ryan Talbot > >>>>>>>>>> Sent: Saturday, February 07, 2009 2:01 AM > >>>>>>>>>> To: [email protected] > >>>>>>>>>> Subject: Dsplink.dsp? > >>>>>>>>>> > >>>>>>>>>> Hi folks, > >>>>>>>>>> > >>>>>>>>>> I feel that I must have missed something simple, but I > >>>>>>>>> can't for the > >>>>>>>>>> life of me figure out what it was. I followed the > >>>>>>>>> directions to build > >>>>>>>>>> the DSP side of DSPLink that are outlined here: > >>>>>>>>>> > http://tiexpressdsp.com/wiki/index.php?title=Building_DSPLink > >>>>>>>>>> ...including the instructions for the XDC integration. > >>>>>>>>>> > >>>>>>>>>> I received no errors on build. However, when I got to > >>>>>>>>> building a 3rd > >>>>>>>>>> party server, I get the following error: > >>>>>>>>>> > >>>>>>>>>> js: > >>>>>>>>>> > >>>>>>>>> > >>>>>>> "/home/rtalbot/dvevm_2_21/xdctools_3_10_03/packages/xdc/cfg/ > >>>>>>> Main.xs", > >>>>>>>>>> line 201: xdc.services.global.XDCException: > >>>>>>>>>> xdc.PACKAGE_NOT_FOUND: > >>>>>>>>>> can't locate the package 'dsplink.dsp' along the path: > >>>>>>>>>> > >>>>>>>>> '/home/rtalbot/dvevm_2_21;/home/rtalbot/dvevm_2_21/ > >>>>>>>>> codec_servers_1_23/ > >>>>>>>>>> pa > >>>>>>>>>> > >>>>>>>>> > >>>> ckages;/home/rtalbot/dvevm_2_21/codec_engine_2_21/packages;/home/ > >>>>>>>>> rtalb > >>>>>>>>>> ot > >>>>>>>>>> > >>>>>>>>> /dvevm_2_21/dsplink_1_60/packages;/home/rtalbot/dvevm_2_21/ > >>>>>>>>> xdais_6_21/ > >>>>>>>>>> pa > >>>>>>>>>> > >>>>>>>>> > >> ckages;/home/rtalbot/dvevm_2_21/linuxutils_2_21/packages;/home/ > >>>>>>>>> rtalbot > >>>>>>>>>> /d > >>>>>>>>>> > >>>>>>>>> vevm_2_21/bios_5_33_02/packages;/home/rtalbot/dvevm_2_21/ > >>>>>>>>> framework_com > >>>>>>>>>> po > >>>>>>>>>> > >>>>>>>>> > nents_2_21/packages;/home/rtalbot/dvevm_2_21/xdctools_3_10_03/ > >>>>>>>>> packages;. > >>>>>>>>>> ./../..;'. Ensure that the package path is set correctly. > >>>>>>>>>> > >>>>>>>>>> I called the base directory 'dvevm_2_21' for lack of any > >>>>>>>>> better name > >>>>>>>>>> for the hodge-podge of components that works with > >>>>>>>>> CodecEngine 2.21. > >>>>>>>>>> These paths are all correct (at least, they all exist). > >>>>>>> The codec > >>>>>>>>>> build went fine, but this, the server build, is failing. > >>>>>>>>>> > >>>>>>>>>> I could build this 3rd party bundle (codec, server, > >> and example > >>>>>>>>>> program) just fine using dvevm_1_20 > >> (codec_engine_1_10_01 and > >>>>>>>>>> friends). There is no actual file called dsplink.dsp in > >>>>>>>>> either version. > >>>>>>>>>> > >>>>>>>>>> I wonder if this has to do with the 'config.bld' > file in my > >>>>>>>>>> 'codec_engine_2_21/packages' directory? There wasn't one > >>>>>>> included > >>>>>>>>>> like there was with the monolithic DVEVM/DVSDK releases, > >>>>>>> and it was > >>>>>>>>>> causing the 3rd party builds to do absolutely nothing. I > >>>>>>>>> copied the > >>>>>>>>>> one out of the codec_engine_2_00_01/packages directory that > >>>>>>>>> came with > >>>>>>>>>> DVSDK-1.30.01.41, which got my codec build working. > >>>>>>> Also, I built > >>>>>>>>>> DSPLink in its own directory (dsplink_1_60 in the above > >>>>>>> paths), not > >>>>>>>>>> within the cetools directory of CodecEngine... could > >>>> that be the > >>>>>>>>>> problem? > >>>>>>>>>> > >>>>>>>>>> Any help appreciated. This build system (actually, TI's > >>>>>>>>> hierarchy of > >>>>>>>>>> software in general) confuses the heck out of me. > >>>>>>>>>> > >>>>>>>>>> Ryan Talbot > >>>>>>>>>> [email protected] > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> Davinci-linux-open-source mailing list > >>>>>>>>>> [email protected] > >>>>>>>>>> > >>>>>>>>> > >> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open- > >>>>>>>>> source > >>>>>>>>> _______________________________________________ > >>>>>>>>> Davinci-linux-open-source mailing list > >>>>>>>>> [email protected] > >>>>>>>>> > >> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open- > >>>>>>>>> source > >>>>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>> > >>>> > >> > >> > >> _______________________________________________ > >> Davinci-linux-open-source mailing list > >> [email protected] > >> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open- > >> source > >> > > _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
