Ryan, Good to know, but you shouldn't modify that file, since it's a generated file which will get overwritten when you rebuild. You'd be better off finding the source of the rogue DDR symbol and fixing that.
~roger -----Original Message----- From: Ryan Talbot [mailto:[email protected]] Sent: 12 February 2009 21:30 To: Monk, Roger; David Chan Cc: [email protected] Subject: RE: Dsplink.dsp? 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
