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
