Codec Server project CCSv4 build error dsplink.dsp incomplete

Todd,

As kind as it is for you to refer me to those things, it frustrates me horribly.  I've already referred to those things and have been unable to glean from the ability to get this job done.  A more specific answer to my question would be greatly appreciated.  The references you [don't] cite are full of omissions, descriptions of Linux instead of Windows/CCS platform, and in some cases incorrect info.

May I please ask you, for example, to suggest a specific link and specific content to get me at least one step further in building the codec server, which is where I left off on this thread.

Thanks very much,

Helmut

Helmut,

The way the forums are currently set up, there is an email generated when a post occurs. The email contains the post. However, when a post is edited, there is no additional email. When I supplied an answer, I was not aware that you knew the these documents existed. I've raised the lack of additional emails for an edit to the forums support team.

What is your current status on rebuilding the DSP side of DSPLink? After setting up the environment (section 9.2.2), I was able to run the "perl dsplink\config\bin\dsplinkcfg.pl" script for DAVINCIHD (with the options you had specified). Note: I'm running the script on Windows.

Todd

Todd,

Yep, I was aware of the risk with the edit not spitting out emails.  I didn't know if folks relied on the email or always visited the post.  I likewise didn't want to spin off 50 emails as I edited the post.  (Perhaps in the future, I'll edit to hearts delight, then when I quit work for the evening, post a single 'note edits above' post.)

Anyway, thanks for following up.  I'm still unable to build XYZ.  Exactly what XYZ is uncertain!  Under CCSv4 GenServer created a project named like mycompany.mygroup.server.servercom.  When I try to build this project from within CCSv4, I get the error at the beginning of this post in bold, suggesting dsplink.dsp is not fully built.

Now, when I want to try to fully build dsplink.dsp, I find myself totally ignorant.  I still have not the slightest clue of what I'm supposed to do in order to build this fellow.  None of the doc has helped.  You can deduce from my posts above that I searched the C:\Program Files\Texas Instruments\dsplink_1_64 folder, found a makefile, and tried to make it.  This led to all kinds of problems, enumerated above.  People keep saying to "install" or "build" dsplink.  But what does this really mean?????????  I've gotten past this type of stumbling block on this project before, but not this block.  Remember, I have CCSv4/WindowsXP(MachineB) which is where the built dsplink needs to end up.  I also have Ubuntu/VMware/WindowsXP(MachineA) as a resource.  Both have the DVSDK "on them".  It's been "made" on Ubuntu.  For CCSv4/WindowsXP(MachineB), it's actually on a mapped network drive to WindowsXP(MachineA) and it's never been "made".  Actual tools and such are directly on MachineB under C:\Program Files\Texas Instruments.

Thanks,

Helmut

fyi, reread the last sentence of your post, Todd.  Looking to analyze what you had success with, why I didn't, and your 9.2.2 reference...

As a sanity check, within your $(DSPLINK_INSTALL_DIR), do you have a directory named 'dsplink/dsp/packages'?  That's a dir filled with files generated by the DSP Link build.  If you don't have that dir, but think you've built DSP Link, you may need to take the steps described here:

http://processors.wiki.ti.com/index.php/Building_DSPLink#Enabling_XDC-based_integration

If you do have that 'packages/' dir, make sure (on your Windows box, where you're trying to build the Server), that you're pointing at the _built_ DSP Link on your Linux box, not the [likely unbuilt] copy on your Windows box.

Chris

Answers/Questions relating to both Todd & Chris...

RE Todd, the best I can figure is your "9.2.2" reference corresponds to the DSP Link InstallGuide.  Following this thought leads me to a mile long blind alley, that I'm afraid to enter for worry of a total waste of time.  Specifically, I downloaded the ."DSPLink 1.64 porting kit"from http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/DSPLink/1_64/index_FDS.html .  I extract it.and find dsplink_1_64\dsplink\doc contains many PDFs.  Nothing for Windows or DM6467T.  The closest is InstallGuide_WinCE_DM6446.pdf.  Why am I seeing WinCE here?  Then, reading this pdf, it says I need Visual Studio 2005 and Platform Builder.  Huh, what!  While I have indeed had VS2005 on MachineA for five years, why is this suddenly brought up?  Finally, I find a section 9.2.2.  It says to use Platform Builder.  This is the blind alley I'm afraid to enter.

RE Chris, please note that there's an alphabet soup of env vars.  Many docs refer to different spellings.  I can't recall why, but I have actually added "DSPLINK" to MachineB env vars, but not "DSPLINK_INSTALL_DIR".  Note I have not noticed any errors suggesting I need "DSPLINK_INSTALL_DIR".  Anyway, DSPLINK="C:\Program Files\Texas Instruments\dsplink_1_64\dsplink".  There's no packages folder anywhere in this (humongous) subtree.  

RE Chris, finally, if I eventually end up with a packages dir, you lose me when you write "make sure (on your Windows box, where you're trying to build the Server), that you're pointing at the _built_ DSP Link on your Linux box".  To me, that means WindowsXP(MachineB) points to Ubuntu/VMware/WindowsXP(MachineA), and I haven't shared such folders from Ubuntu yet.  In addition, exactly what constitutes "point"!  That is, with the alphabet soup of env vars, plus seeming env vars in CCSv4, plus my total confusion at this point...

Thanks,

Helmut

Helmut,

In the dsplink\docs\UserGuide.doc (1.64, Nov 13, 2009), there is a chapter called Build Procedure. Is was referring to a section in this document (9.2.2 "Windows Development Host").

Let's step back and make sure everyone is on the same page. DSPLink is a software package that supplies source code for both the DSP and Arm (generally called GPP, General Purpose Processor). The libraries include modules for interprocessor communication and for loading/starting the DSP. Since DSPLink supports many different platforms and operating system/operating system versions, the package does not include the libraries. Users must build these libraries.

CE (Codec Engine) uses DSPLink. For versioning reasons, CE does not include DSPLink libraries.

You need to build the DSPLink GPP libraries on Linux. You can build the DSPLink DSP libraries on Linux or Windows. I generally prefer to do both on Linux. It's much easier to keep things consistent then.

Where do you want to build your DSPLink DSP libraries?

Todd

Todd,

OK, I see 9.2.2 of the UserGuide.doc.  Amongst hundreds of wiki pages and posts, plus two dozen pdfs buried in this folder, I never noticed UserGuide.doc.  I'll move forward now with your question, but may return to read this doc.

I'm not qualified to best choose which operating system on which to build the DSPLink DSP libraries.  However, here's what I think.  I think I'm supposed to build a codec server, and I have a project in CCSv4 for doing this.  Building the project generated the error complaining in the first place.  SO LET'S BUILD ON WINDOWSXP(DOS).

Thanks,

Helmut

I get to section 9.1.1 (EDIT, was erroneously "9.11") and decide I need a lineup card (baseball reference I think), aka GLOSSARY.  Who the h*ll is who!  I may have figured this part out, and it has an impact on what I've been doing before:

GLOSSARY:

platform = ARM(GPP) or DSP because DM6467T has ARM and DSP

OS = Linux because DM6467T EVM is running Arago Linux.  This is NOT to be confused with development host operating system.

Development Host = WindowsXP.

I may have been confused at many points in the past where instructions were unclear about Linux who, EVM or development host.  And part of my dev hosting is Ubuntu and part WindowsXP.  

I'm continuing to read and will EDIT this post.  Rather than trusting your email copy of this post, please reload the thread to see my edits...

EDIT: Already, here we go.  Scn 9.1.1. suggests I find $(DSPLINK)/make/Linux/davinci_mvlpro5.0.mk, but I have no "Linux" folder in this tree.  Aha!  Glossary!  I downloaded 'DSPLink 1.64 porting kit" instead of "DSPLink 1.64 for Linux" because I'm using a Windows development host.  But maybe the "Linux" part there refers to the Arago Linux on the target.  Note I did download "DSPLink 1.64 for Linux" to my Ubuntu/VMware/WindowsXP because both host and target are then Linux.  Just checked.  Ubuntu/VMware/WindowsXP does have this "Linux" folder and .mk file.  If need be, I can delete $(DSPLINK) folders from CCSv4/WindowsXP(MachineB) and copy them from Ubuntu/VMware/WindowsXP(MachineA). Then my windows dev host will have the file to which Scn 9.1.1 refers. 

EDIT: I realize it's not for everyone.  But for my purposes, I'd go through all the wikis and all the forums (Casablanca?) as well as all the other downloads and filenames and everything, totally REMOVING the word Linux and replacing it with either Ubuntu or Arago.  Then there'd be no confusion about host vs target.

Reading further...

Do you mean section 9.1.1?

DSPLINK generics uses the term "GPP" to denote the master General Purpuse Processor on a device. For your case, this is an Arm and it runs Linux.

Platform is the device/board you are using. So it is DM6467T.

Todd

Yes, "9.11" meant "9.1.1"

Note, regarding a few posts back when I didn't know why WinCE was mentioned, this goes back to GLOSSARY.  That WinCE was a target OS, not a host OS.

I've never been confused by GPP vs ARM, fortunately.

I've never been confused by "Platform".  "DAVINCIHD" for me.  I was confused by "Platform-OS", thinking it was more like "target-host" combination.  Now I realize it was target-hardware-target-os combination, because this UserGuide is much more verbose and better organized than anything I've seen so far.  It then follows on to talk about building with various host environs.  It led me to "GLOSSARY" above realization.

I'm still reading and will continue edits on my prior post above here, above yours.

-Helmut

P.S. If you want to get yourself confused, look at the Spectrum Digital doc for the EVM.  It's a "1080P HD EVM", not a "DM6467T EVM".  I've got that glossary translation down now.

And now the circle comes back to confusion again.  I've downloaded and put "DSPLink 1.64 for Linux" on my CCSv4/WindowsXP(MachineB).  I've extracted it.  Per C:\Program Files\Texas Instruments\dsplink_linux_1_64\dsplink\doc\UserGuilde.pdf section 9.1.1 "The distribution file for the DSP-side for the Davinci platform for Linux is $(DSPLINK)/make/DspBios/c64xxp_5.xx_linux.mk".  

I have found C:\Program Files\Texas Instruments\dsplink_linux_1_64\dsplink\make\DspBios\c64xxp_5.xx_linux.mk.  

Inside I find on line 65 "BASE_INSTALL    := /opt/ti-tools" as a default value.  I power up my DM6467T EVM, the one with target operating system Arago Linux.  I have an /opt folder but no /ti-tools subfolder, only a dvsdk subfolder.  I find the same situation looking at the NFS being served up by my Ubuntu/VMware/WindowsXP(MachineB), and this was created following instructions...

But what's bad is I then find in c64xxp_5.xx_linux.mk line 78 "XDCTOOLS_DIR    := $(BASE_SABIOS)/xdctools".  Aren't XDC tools supposed to be strictly on the HOST, not the TARGET?  But I have a Windows host.

Now I don't know what "Linux" means anymore.  Ubuntu or Arago.  

Time for dinner.  I'll sleep on it and pick up reading the UserGuide.pdf.

Dinner done.  no sleep.

If you get this in email, check back for EDITs to this post item.

...maybe the line 65 "BASE_INSTALL    := /opt/ti-tools" default value in UserGuide.pdf is that way because it defaults to assuming a Linux development host.  That is, I want the target's DSP side when the target is running Arago Linux, and therefore I've chosen this c64xxp_5.xx_linux.mk file, where "linux" here is Arago.  However, once selecting that file, it needs to know where to find tools on the development host. The default would work for my Ubuntu Linux host.  It won't work for my WindowsXP host.

I need to provide TI_TOOLS_BASE_DIR to kick off this process, and the others seem to derive from there.  Same for others.  They are, along with my guess for value

TI_TOOLS_BASE_DIR= (What's a TI_TOOL or TI_TOOL_BASE?)

XDC_INSTALL_DIR=C:\Program Files\Texas Instruments\xdctools_3_16_02_32  (WHY??? SAME AS XDCTOOLS)

CODEGEN_INSTALL_DIR=C:\Program Files\Texas Instruments\C6000 Code Generation Tools 7.0.1

XDCTOOLS_DIR=C:\Program Files\Texas Instruments\xdctools_3_16_02_32

Regarding TI_TOOLS_BASE_DIR, c64xxp_5.xx_linux.mk suggests it's figuring out "Base directory for the DSP OS".  This sounds like it should be in my NFS served folder on my Ubuntu/VMware/WindowsXP(MachineA) so that the DSP runtime stuff can be put there, later to appear on the target.  But the target is the DM6467T EVM that's already got an encodedecode demo on it.  Surely it's already needing ARM/DSP communication.  And isn't that what DSP Link is all about?  So the EVM should ALREADY have such on its HDD FS.  But I find no /opt/ti-tools existing on it.  So what value do I need for this env var?

Regarding XDC_INSTALL_DIR, why do I have both an install dir and a tools.  Might help to know what the heck XDC is in the first place.  OK.  Read some doc.  XDCTools build RTSC components.  I think the "XDC_INSTALL_DIR" is a misnomer and really means the folder on the target where the RTSC components are installed.  This is akin to my understanding that the TI_TOOLS_BASE_DIR refers to another folder on the target.   This resolves the duplication question between XDC_INSTALL_DIR and XDCTOOLS, because the first is on the target and the second is on the host.  And by "on the target", I actually mean on the NFS served file system that in my case is neither host nor target, but ("auxiliary host" perhaps) Ubuntu/VMware/WindowsXP(MachineA).  Perhaps completely similar for TI_TOOLS_BASE_DIR vs CODEGEN_INSTALL_DIR.

If I'm correct, please notice this inconsistency.  CODEGEN_INSTALL_DIR refers to installation on the host, while XDC_INSTALL_DIR refers to installation destined for the target.  See how confusing this is?

How about somebody just tell me exactly what values I need for these four env vars?

more edits coming...

EDIT: Darn.  in c64xxp_5.xx_linux.mk, the defaults show something.  BASE_CGTOOLS comes from CODEGEN_INSTALL_DIR, but the default comes from BASE_INSTALL.  BASE_INSTALL in turn comes from TI_TOOLS_BASE_DIR.  This implies CODEGEN_INSTALL_DIR and TI_TOOLS_BASE_DIR refer to the same file system.  If one refers to my host, then both must.  At least, it.

I'm lost.  How about somebody just tell me exactly what values I need for these four env vars?  I've rambled on enough about my environment, that all the info ought to be present.

EDIT:  Searched forum.  found http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/p/6485/24615.aspx#24615.  It implied and I found C:\Program Files\Texas Instruments\dsplink_linux_1_64\dsplink\doc\InstallGuide_Linux_DM6446_DM6467_DM6467T.pdf.  Search PDF contains mentions of "Windows development host".  Maybe this will be the read that answers the question.

EDIT: Note the word "install" is a *** stepchild of confusion.  We install the tool, then run the tool to install the thing the tool makes, but in both cases doc uses expressions like "install DSP Link".

EDIT: InstallGuide_Linux_DM6446_DM6467_DM6467T.pdf page 10 figure 1 suggests "c:\ti-tools" corresponds to my "c:\Program Files\Texas Instruments" and therefore that TI_TOOLS_BASE_DIR=c:\Program Files\Texas Instruments is appropriate.  Yet page 8 section 5.1 paragraph 2 implies I'm better off copying it all to c:\ti-tools rather than trying to get it working where it is.  I especially think this given the spaces in the pathname.  We'll see.

EDIT: Come on guys...  Page 11, "Workstation".  What's a "workstation"?  I've got half a dozen things in my office that could be called a workstation.  Is it the target?  The host?  Breakfast at Tiffany's?

Helmut

I apologize for the time taken to build DSPLink.

You have run into several problems here :(

1) Picked up a different tar ball than what is required.

DSPLink ships with 2 tar balls for different customers.

1) BSD licensed package dsplink_1_64.tar.gz, suitable for usage with non-Linux OSes, and for porting to a different OS.  This is the reason why you do not see DAVINCIHD here as it is not supported. Also, this contains references to WinCE as it is a non Linux OS.
2) Linux package dsplink_linux_1_64.tar.gz with GPL v2 licensed GPP kernel-side, with other code BSD licensed, for usage with Linux on GPP. This is the package to be picked up for a Linux build. Please note the embedded _linux in the package name.

2) Building DSPLink in an environment where the path contains a mix of Windows style and Linux style
DSPLink make based build system does not support a build environment where the path contains a mix of Windows style and Linux style for e.g. Cygwin. The workaround that we suggest is remove the utility which is causing the path to have different directory slahes in the path

3) Space in the path of the Code gen installations. To ensure a build the docs refer to a default installation at c:\ti-tools on a Windows host machine and /opt/ti-tools on Linux host.

4) Different env variables in different docs/wikis etc. Also there seems to be a CCS project in the picture as well.


I see on another post on which you have built DSPLink but just to re-iterate.

DSPLink dsp side can be built on a Windows or a Linux host or work station i.e. either Machine A or B for you. The dsp side build of DSPLink needs a DSP/BIOS installation and a Code gen tool installation. The xdc tools are part of the Bios installation for Bios 5.xx series. Another thing to note is that the DSP/BIOS installation and a Code gen tool installers are different for Windows and Linux. From your text, it is on Machine B.
So the quickest way would be to ensure that there is no space in the path where Bios and code gen tools are installed, 1) Set DSPLINK env variable to <dsplink_linux_1_64\dsplink_linux_1_63\dsplink?
2)edit $DSPLINK/make/DspBios/c64xxp_5.xx_windows.mk
BASE_SABIOS     := <Path_to_Bios_install>
BASE_CGTOOLS    := <Path_to_cgtools_install>
3) After this doing a build from $DSPLINK\dsp\src
cd $DSPLINK\dsp\src
make -s

DSPLink gpp side can be built on Machine A (which you have) or in a Cygwin like environment on the host.

Would you like to have a call since you have spent a lot of time on this issue?

Deepali

Deepali,

Thanks very much for the call offer.  I was planning on taking you up on it today, but resolved my problem yesterday (MLK holiday).  

I might post back here again in the future, however, asking for a call if I may, if I hit another tough roadblock like that.

-Helmut

Deepali,

I'm totally overwhelmed.  Can you or someone please call me at 678-919-1093.  Your assistance is greatly appreciated.

-Helmut

Deepali,

I'm totally overwhelmed.  Can you or someone please call me at 678-919-1093.  Your assistance is greatly appreciated.

-Helmut

Helmut

If you will be integrating DSPLink into your system using XDCtools-based configuration (e.g. using Codec Engine), there are 2 more steps required before the Build Configuration step is complete.

cd into the $(DSPLINK)/dsp directory and run:

$ $(XDC_INSTALL_DIR)/xdc clean
$ $(XDC_INSTALL_DIR)/xdc .interfaces

cd into the $(DPLINK)/gpp directory and run:

$ $(XDC_INSTALL_DIR)/xdc clean
$ $(XDC_INSTALL_DIR)/xdc .interfaces

These two steps prepare the dsplink.dsp and dsplink.gpp XDC packages for consumption by the XDC config tooling.

The XDC tool is present in the Bios Installation

Deepali

Thanks, Deepali.  I did already do those two things.  In fact, I did finally get the build working.  My request for a call was in hopes of getting some help with the umpteenth roadblock I've hit, most recently described at http://e2e.ti.com/support/embedded/f/354/p/89419/310240.aspx#310240

-Helmut