IUNIVERSAL derived makefile

Hi Flamingo,

If you are using IUNIVERSAL (that uses coded engine) you need to run your application on the ARM and just your algorithm in the DSP. Codec Engine takes care of the task handling in the DSP side - so you do not have the freedom to make your own tasks and mailboxes in the DSP side. (CORRECTION - yes you DO - see following posts)

So after you download the code at:

http://tiexpressdsp.com/index.php/Getting_started_with_IUNIVERSAL (read this page, install, read the release notes and build instructions)

You would put your algorithm in the files that are in the folder:

...\iuniversal_examples\packages\ti\sdo\algos

Then you can adapt your application at the ARM side in the folder

...\iuniversal_examples\packages\ti\sdo\apps

If you want to have more freedom in the DSP side, you would use DSPLINK without codec engine.  An example of how to do that will be ready soon.

My correspondance with my TI rep suggests that you and he disagree on this:

"When Engine is opened, the dsp image gets loaded and the DSP starts running. The Codec Engine remote server running on DSP waits for the ARM to instantiate a  codec instance  using _create(). You may however, create static DSP/BIOS Tasks on the dsp image which comes alive as soon as the DSP image gets loaded and runs."

Furthermore, Scott Specker (in my DaVinci Technology Workshop in Schaumburg, IL) suggested that a "solution" for me would be to add background tasks to a codec.

The plan was to have a task to drive the devices (a series of behaviors that collect multiple buffers of raw data: one of which can be as lengthy as 250 milliseconds of data), a task to perform the actual post-collection processing (which must complete before the next set of buffers is complete, but could take almost as long due to the complexity of the algorithms) , and a codec that just copies the most recently completed result data into the ARM9 memory space.

Early on I realized that my problem-space and the codec framework were not good matches, but when I suggested that I should just use DSPLink directly, I was told (by my TI rep), that DSPLink was not strongly supported on this platform and I would be working without a net.

"Yes- you can use dsplink to do address conversion on Cmem. However, if you choose to do  this, you are going down a path less travelled. There are only a few people at TI that understand the inner workings of dsplink  and it is going to be hard to get you any support. Typically, folks that do this are OS vendors that try to adapt codec engine to their OS. As you can imagine these are only a handful and they get directly supported by the dsplink experts. Scott forwarded me a response to your message on TTO training on dsplink  but unfortunately we don’t have this today (see attached email)."

Flamingo said:

"When Engine is opened, the dsp image gets loaded and the DSP starts running. The Codec Engine remote server running on DSP waits for the ARM to instantiate a  codec instance  using _create(). You may however, create static DSP/BIOS Tasks on the dsp image which comes alive as soon as the DSP image gets loaded and runs."

That is true, I had not thought of that possibility but it should work.

Flamingo said:

I can't find an example makefile that shows me how to combine the main and background tasks and the library (and the codec engine?) to make the DSP executable. Is that done on the Linux side? Or do I just combine everything into a single CCS project and build? If I do that, how do I link in the Codec Engine and any other framework components that I might need? The result of the combo project would no longer be a library, which seems to be what the Codec Engine expects.

Here's a path that may help you navigate:

1. Create an IUNIVERSAL algorithm library in CCS (it sounds like you've already done this)

2. Run the RTSC Codec Package Wizard (from ceutils) to create a codec package. The input to the RTSC Codec Package Wizard is only the library from step 1. If you use a recent version of ceutils, you'll find a Makefile in it - this allows you to start the wizard via "make genpackage" and to build the package by simply typing "make"

3. Run the RTSC Server Package Wizard ("make genserver") which takes the codec package you created in step 2 as input. Then build it by typing "make" again.

4. Now you have a simple DSP main (see your server package's main.c). You'll also find a server.cfg which shows the configuration of the framework components.

By finishing these steps you have a basic DSP executable that you can then modify.

You may find topic http://tiexpressdsp.com/index.php?title=Debugging_the_DSP_side_of_a_CE_application_on_DaVinci_using_CCS useful for debugging your application. It also applies to OMAP.

If you would like a custom Makefile for your codec package, server package and eventually for your ARM side application, then I suggest you review and then modify the IUNIVERSAL Examples Makefile. If may be useful to read http://tiexpressdsp.com/index.php/Config_bld_basics.

Flamingo said:

I am developing an IUNIVERSAL-derived codec for the OMAP-L137.

Sorry - didn't see you were using OMAPL137. Please use the codec server wizard that is packaged with the Codec Engine (since the RTSC Server Wizard from ceutils doesn't contain the OMAPL137 templates). This wizard at present does not contain a Makefile but it shouldn't be hard to modify the Makefile from ceutils for the same purpose. I have heard that a Makefile will be provided in future Codec Engine codec server wizards though.

Note that the RTSC codec package wizard is only available in ceutils, so you'll still need to use that to generate the codec package.

As I mentioned in my original post:

"I've copied all the files (including libraries, etc) from the Windows box to the Linux box. I've run the package wizard, although that may have been jumping the gun. I had thought that it might create a makefile, but it didn't."

I'm using ceutils v1.07, but I didn't get a makefile.

The LOG.txt file from the package wizard says the package was created successfully, that files were output (to the appropriate place), warns me that header files may need to be attached, and reports the worst case stack (= 0). Finally, it says that it can't locate object method "new" via package "XML::Parser" at XML/Simple.pm line 404.

I'm not sure about that last thing about XML, but I doubt that it would have prevented a makefile from being generated.

My package is generated in ~/examples. In addition to the sub-directory mycompany and its sub-directory vqm_results (the codec name), there are directories buildutils and ti. There are config.bld, user.bld, build_instructions.html, CodecEngine_ExampleFeatures_UsersGuide.pdf, LOG.txt (the output described above), xdcpaths.mak, and the xml output file from the package.

Any insights as to why I don't have a makefile output from the wizard?

The Makefile is not generated--it is supplied with ceutils. Please see ceutils_1_07/Makefile.

This last part is actually an error that occurs on some hosts resulting from the "perl to executable" change in CG XML (that is, CG XML is normally a set of perl scripts - but for ease, these were converted to both windows and linux executables so folks didn't have to download and install some XML packages for perl). If you have doubts on your stack size, a temporary work around would be to run the perl script call_graph.pl itself (instead of via the executable).  Search wiki.davincidsp.com for "call graph" and the few few links will be useful to you. Else simply input a large enough stack into your/package/path/codec_name/ce/codec_name.xs function getStackSize().

When I run the server wizard, I get an error that says that the module is not found in the location of my package. I see that my XDCPATH variable should include the location of my "packages" directory, but I don't have a "packages" directory. (I have a "package" directory.)

The module is defined in my package.xdc file.

When you said to run the server wizard instead of the package wizard, I copied everything into a directory called serverexamples. I added ~/serverexamples/mycompany/mycodecname to the XDCPATH, but did not suffix it with "/packages" because the directory does not exist. Should I add it anyway? If not, can you tell me what path to add that will prevent the error? (I get a similar error when I run the viddec_copy_packaged example, so I probably need to add something to XDCPATH for it also, but, again, it doesn't have a "packages" directory, as is suggested in the example for XDCPATH in the instructions.

If my package is called mycompany.myproject.mycodec, and I have the package.xdc in dir structure /home/user/workdir/mycompany/myproject/mycodec/package.xdc, then my "repository" (that is, a directory containing the package) is /home/user/workdir. Thus my XDCPATH should include /home/user/workdir.

In your case, make sure ~/serverexamples is on your XDCPATH. Similarly, if you want to rebuild the ceutils examples, add /home/user/ceutils_1_07/examples/viddec_copy_packaged to your XDCPATH.

Be sure to build your codec package before running the server wizard else it won't find it properly.

I have run ~/xdctools_3_10_03/xs ti.sdo.codecutils.genpackage -g.

I have entered all the fields and it completed. However, you said that it would not create a Makefile and that I should copy the one from ceutils.

I copied the Makefile and then edited it (to remove its definitiona of XDCPATH, since I already have the "correct" XDCPATH defined. (I hope.)

When I type "make" in the directory with the new Makefile, it says "Makefile:88: Your BIOS needs to be patched for SDSCM00004525!

Makefile:88: *** Please copy /packages/ti/rtdx/package_export.xdc to /packages/ti/rtdx/package.xdc. Stop.

I remember reading something about this, but since the source and destination files are the same (identity), I'm not sure how to continue.

If I skip the make and run genserver, I get the same XDCPATH error as before, even though I have edited as suggested.

That BIOS check was created to work around a defect in very early DVSDKs - so you'll be fine just commenting out those few lines in the Makefile. I have filed a bug against ceutils.

Again, to reiterate: you won't be able to properly generate the server if you haven't already built the codec package since the server wizard relies on metadata from the codec package.

Okay. I ran genpackage.

I ran make.

I run genserver, and it fails with the XDCPATH error.

My XDCPATH contains the repository as explained in your earlier reply.

What can I try next? I've read the info on the XDCPATH error, and I have a file named mycompany.codecname.sch in the package directory. I have a file called package.xdc with

"package mycompany.codecname [1,0,0] {

        module CODECNAME;

}"

When you say I have to build the codec package, is there more implied than my typing "make" after I run the package wizard? If so, what? If not, what files can I check into to find out why the wizard thinks the XDCPATH is wrong?

Assuming there were no build errors with your codec package, then you shouldn't have to do other than "make". It doesn't sound like your codec package build is complete (you should see errors on the build though) if you only see a single file in the package directory. You should probably see nearly a dozen files and a few directories in the package directory for a properly RTSC built codec.

It'd probably help others provide debug hints if you provided the exact error log.

In the serverexamples directory, I see

mycompany (dir), buildutils (dir), config.bld, user.bld, build_instructions.html, Makefile, LG.txt, xdcpaths.mak, mycompany_vqm_results_unitserver_evmomapl137_wizard.xml, mycompany_vqm_results_wizard.xml

In the mycompany directory, I see

vqm_results (dir)

In vqm_results directory, I see

ce (dir), lib (dir), package (dir), pjt (dir), package.bld, package.xdc, package.xs, VQM_RESULTS.cdc, link.xdt, package.mak, vqm_results.qti, VQM_RESULTS.version.0.0.1.wizardversion.0.5.3

In package directory, I see

cfg (dir), external (dir), internal (dir), lib (dir), rel (dir), mycompany.vqm_results.ccs, package.defs.h, package_mycompany.vqm_results.c, mycompany.vqm_results.sch, build.cfg. package.rel.dot, package.xdc.dep, package.xdc.inc, package.bld.xml, package.doc.xml, package.ext.xml, package.rel.xml

In rel directory, I see

mycompany_vqm_results.xdc.inc

I don't think that's enough information to debug your problem. You need to confirm whether or not there are any errors during your build. If there are, then you need to post the exact log. If there are no errors in your build, then just post the exact error message you get on running the server (along with exactly which commands you used to cause the error). Also specify the exact tool versions, etc that you're using, else even folks who want to help are probably unable.

Sorry. I didn't mean to imply that the directory list and file list were sufficient. You had suggested that an incomplete build would result in missing files. I was letting you know which files were there in the hopes that you could see if any were missing.

Here is the output of my make followed by the genserver (on a command line to let all interested parties know what my entries are). The genserver error is at the end. I don't see any other errors, but maybe I'm missing something.

--------------------------------------------------------start of output---------------------------------------------------------

myusername@myusername-linux:~/serverexamples$ make
/home/myusername/xdctools_3_10_03/xdc XDCARGS="release """ -PR /home/myusername/serverexamples
making all: Wed Jun 3 12:36:53 MDT 2009 ...
======== .interfaces [/home/myusername/serverexamples/mycompany/vqm_results] ========
#
# making package.mak (because of package.bld) ...
/home/myusername/xdctools_3_10_03/tconf  -Dxdc.path="^;/home/myusername/xdctools_3_10_03;/home/myusername/xdctools_3_10_03/packages;../.." -Dxdc.root=/home/myusername/xdctools_3_10_03 -Dxdc.hostOS=Linux -Dconfig.importPath=".;../..;/home/myusername/xdctools_3_10_03;/home/myusername/xdctools_3_10_03/packages;../..;/home/myusername/xdctools_3_10_03;/home/myusername/xdctools_3_10_03/etc" -Dxdc.bld.targets="" -DTOOLS=   /home/myusername/xdctools_3_10_03/packages/xdc/bld/bld.js ../../config.bld package.bld package.mak release
config.bld: Running the version from /home/myusername/serverexamples.
config.bld: loading user build configuration file /home/myusername/serverexamples/user.bld
#
# generating interfaces for package mycompany.vqm_results (because package/package.xdc.inc is older than package.xdc) ...
/home/myusername/xdctools_3_10_03/xs -Dxdc.path="^;/home/myusername/xdctools_3_10_03;/home/myusername/xdctools_3_10_03/packages;../.." -Dxdc.root=/home/myusername/xdctools_3_10_03 -Dxdc.hostOS=Linux -Dconfig.importPath=".;../..;/home/myusername/xdctools_3_10_03;/home/myusername/xdctools_3_10_03/packages;../..;/home/myusername/xdctools_3_10_03;/home/myusername/xdctools_3_10_03/etc" -Dxdc.bld.targets="" -DTOOLS=  -f xdc/services/intern/cmd/build.xs  -m package/package.xdc.dep -i package/package.xdc.inc package.xdc
    translating VQM_RESULTS
======== .interfaces [/home/myusername/serverexamples/mycompany/vqm_results/ce] ========
#
# making package.mak (because of package.bld) ...
/home/myusername/xdctools_3_10_03/tconf  -Dxdc.path="^;/home/myusername/xdctools_3_10_03;/home/myusername/xdctools_3_10_03/packages;../../.." -Dxdc.root=/home/myusername/xdctools_3_10_03 -Dxdc.hostOS=Linux -Dconfig.importPath=".;../../..;/home/myusername/xdctools_3_10_03;/home/myusername/xdctools_3_10_03/packages;../../..;/home/myusername/xdctools_3_10_03;/home/myusername/xdctools_3_10_03/etc" -Dxdc.bld.targets="" -DTOOLS=   /home/myusername/xdctools_3_10_03/packages/xdc/bld/bld.js ../../../config.bld package.bld package.mak release
config.bld: Running the version from /home/myusername/serverexamples.
config.bld: loading user build configuration file /home/myusername/serverexamples/user.bld
#
# generating interfaces for package mycompany.vqm_results.ce (because package/package.xdc.inc is older than package.xdc) ...
/home/myusername/xdctools_3_10_03/xs -Dxdc.path="^;/home/myusername/xdctools_3_10_03;/home/myusername/xdctools_3_10_03/packages;../../.." -Dxdc.root=/home/myusername/xdctools_3_10_03 -Dxdc.hostOS=Linux -Dconfig.importPath=".;../../..;/home/myusername/xdctools_3_10_03;/home/myusername/xdctools_3_10_03/packages;../../..;/home/myusername/xdctools_3_10_03;/home/myusername/xdctools_3_10_03/etc" -Dxdc.bld.targets="" -DTOOLS=  -f xdc/services/intern/cmd/build.xs  -m package/package.xdc.dep -i package/package.xdc.inc package.xdc
    translating VQM_RESULTS
.interfaces files complete: Wed Jun 3 12:37:03 MDT 2009.
======== .libraries [/home/myusername/serverexamples/mycompany/vqm_results] ========
======== .libraries [/home/myusername/serverexamples/mycompany/vqm_results/ce] ========
.libraries files complete: Wed Jun 3 12:37:03 MDT 2009.
======== .dlls [/home/myusername/serverexamples/mycompany/vqm_results] ========
======== .dlls [/home/myusername/serverexamples/mycompany/vqm_results/ce] ========
.dlls files complete: Wed Jun 3 12:37:03 MDT 2009.
======== .executables [/home/myusername/serverexamples/mycompany/vqm_results] ========
======== .executables [/home/myusername/serverexamples/mycompany/vqm_results/ce] ========
.executables files complete: Wed Jun 3 12:37:03 MDT 2009.
======== all [/home/myusername/serverexamples/mycompany/vqm_results] ========
#
# all files complete.
======== all [/home/myusername/serverexamples/mycompany/vqm_results/ce] ========
#
# all files complete.
all files complete: Wed Jun 3 12:37:03 MDT 2009.
myusername@myusername-linux:~/serverexamples$ /home/myusername/xdctools_3_10_03/xs ti.sdo.codecutils.genserver -i=mycompany.vqm_results -p=ti.platforms.evmOMAPL137 -o=/home/myusername/serverexamples -n=mycompany.vqm_results -m=VQM_RESULTS
**** warning: package xdc.tools.sg.linux_swt depends on the
Mozilla browser for some functionality. Your environment doesn't
currently point to Mozilla, so some XDC graphical tools may fail.
To prevent this, please set up the following in your environment:

 - set the MOZILLA_FIVE_HOME environment variable. Its value
   should be the directory that contains the file run-mozilla.sh,
   which you can find using the command:
       locate run-mozilla.sh
 - include $MOZILLA_FIVE_HOME and $MOZILLA_FIVE_HOME/plugins on
   the LD_LIBARARY_PATH, for example using bash syntax:
       export LD_LIBRARY_PATH="$MOZILLA_FIVE_HOME:$LD_LIBRARY_PATH"
       export LD_LIBRARY_PATH="$MOZILLA_FIVE_HOME/plugins:$LD_LIBRARY_PATH"


Starting Command Line RTSC Server Wizard now...

Error: Package, mycompany.vqm_results, not found with module VQM_RESULTS... modify your XDCPATH to include the package's repository.
RTSC Server wizard exiting now.

Error message: xdc.services.global.XDCException: xdc.PACKAGE_NOT_FOUND: can't locate the package 'mycompany.vqm_results' along the path: '/home/myusername/xdctools_3_10_03/packages;'. Ensure that the package path is set correctly.
myusername@myusername-linux:~/serverexamples$
------------------------------------------------------end of output--------------------------------------------------------------------

Flamingo said:

Error: Package, mycompany.vqm_results, not found with module VQM_RESULTS... modify your XDCPATH to include the package's repository.
RTSC Server wizard exiting now.

Error message: xdc.services.global.XDCException: xdc.PACKAGE_NOT_FOUND: can't locate the package 'mycompany.vqm_results' along the path: '/home/myusername/xdctools_3_10_03/packages;'. Ensure that the package path is set correctly.

This means that /home/myusername/serverexamples is not on your XDCPATH--currently the only path on your XDCPATH is your xdctools/packages (which is added by default). I suggest you carefully examine how you've setup your XDCPATH in the makefile - i.e. make sure you're pointing to a reasonable Rules.make, and that your CODEC_INSTALL_DIR is actually pointing to ~/serverexamples.

I've set XDCPATH in my .bashrc file. When I echo it, it says

/home/myusername/serverexamples;/home/myusername/OMAPL137_arm_1_00_00_07/codec_engine_2_22/packages;/home/myusername/ceutils/packages;/home/myusername/OMAPL137_arm_1_00_00_07/xdais_6_22_01/packages

To address your comment, I've added the same information to both Makefile and Rules.make. (Makefile says "include ../Rules.make". Rules.make is in /home/myusername directory.)

I did a "make clean" followed by a "make".

I get the same error when I run genserver. (Identical: that is, /home/myusername/xdctools_3_10_03/packages is identical. None of the other directories appear in the error message.

Obviously you're still not picking up the XDCPATH correctly. A simple debug step is to add a line to echo your XDCPATH in the Makefile. So before even trying to run the genserver, make sure you've got the right XDCPATH.

Please very carefully look at your Rules.make and the Makefile - the Makefile sets the XDCPATH based on variables like CE_INSTALL_DIR, etc, thus if these are not defined in your Rules.make, the XDCPATH won't be generated correctly.

An examples Rules.make looks something like below. Make sure yours looks similar.

PLATFORM = omapl137
DVSDK_INSTALL_DIR = /home/user/OMAPL137_arm_1_00_00_07
XDC_INSTALL_DIR = /library/xdc/xdctools_3_10_03
BIOS_INSTALL_DIR = /home/user/bios_5_33_03
LINUXKERNEL_INSTALL_DIR = /library/psp/OMAP35x_SDK_1.0.2/src/linux/kernel_org/2.6_kernel
CE_INSTALL_DIR = $(DVSDK_INSTALL_DIR)/codec_engine_2_22
FC_INSTALL_DIR = $(DVSDK_INSTALL_DIR)/framework_components_2_22_01
LINK_INSTALL_DIR = $(DVSDK_INSTALL_DIR)/dsplink-1_61-prebuilt
XDAIS_INSTALL_DIR = $(DVSDK_INSTALL_DIR)/xdais_6_22_01
CMEM_INSTALL_DIR = $(DVSDK_INSTALL_DIR)/linuxutils_2_22_01
BIOSUTILS_INSTALL_DIR = $(DVSDK_INSTALL_DIR)/biosutils_1_02_01
CODEC_INSTALL_DIR = /home/user/mycodecdir
LPM_INSTALL_DIR =
EDMA3_LLD_ROOT =
EXEC_DIR = /targethomes/user/$(PLATFORM)/test

Alternatively try to export your XDCPATH within the Makefile or try variations related to how you invoke make. I don't know which shell you are using or how your system is setup but google is your friend to understand makefiles/shells/env vars/etc. For this reason, I strongly recommend following the Rules.make approach.

I had been using a Rules.make derived from other TI packages, but none of them looked like yours, so I re-did that. It didn't help, but I finally got XDCPATH defined in a way in the Makefile that worked. So, I have successfully run "make genpackage, "make", and "make genserver".

I allowed the RTSC server wizard to name the server directory, so it is called "vqm_results_unitserver_evmomapl137". My package directory was "vqm_results", so now I have two parallel directories.

Anyway, when I run "make" again, it just says everything is up to date.

I tried to run "make genserver" again, this time changing the default name to vqm_results (the package directory. When I run "make", it remade package.mak (because of package.xdc) and it generated interfaces for the package (because package/package.xdc.inc is older than package.xdc). Everything else was up to date.

I have no main.c and no server.cfg. Earlier mail said that I would be able to edit these, so I'm assuming something is still wrong.

Can you verify that you are running the Codec Engine combo wizard... the unitserver part sounds suspiciously like you're using the server wizard from ceutils which would explain why you see no main.c and server.cfg (since OMAPL137 is not supported by ceutils).

KatieRoberts-Hoffman said:

Please use the codec server wizard that is packaged with the Codec Engine (since the RTSC Server Wizard from ceutils doesn't contain the OMAPL137 templates).

The server wizard I was using does know about OMAPL137, because I am choosing that when I run. Still, the Makefile said "$(XDC_INSTALL_DIR)/xs ti.sdo.codecutils.genserver -g" which I changed to "$(XDC_INSTALL_DIR)/xs ti.sdo.ce.wizards.genserver -g". The "-g" didn't work, so I took it away.

Now I'm back where I was: "An error occured while searching for platforms on the XDC Path: javaException: xdc.services.spec.SessionRuntimeException: mycompanyname.vqm_results.ce: can't resolve name mycompanyname.vqm_results.VQM_RESULTS

Please check your XDC Path and restart the GUI RTSC Codec Server Wizard"

My XDCPATH var as printed in the makefile (and exported in the makefile) has my /home/username/serverexamples as the first entry. It has no spaces and is followed by a semicolon. It worked for the other server wizard.

This is definitely a different server wizard, but I'm not sure that it is a "combo" wizard. Is this the one you meant? I have about 8 directories on my system called genserver, so I've renamed all of them except the one in ~/OMAPL137_arm_1_00_00_07/codec_engine_2_22/packages/ti/sdo/ce/wizards". (There was at least one other (in xdctools_3_10_03) that might have been hit with "ti.sdo.ce.wizards.genserver".) There is no genpackage in the same place, so maybe it is a combo wizard. Should I rerun the package wizard? If so, what is the correct command for the makefile? It currently uses "xs ti.sdo.codecutils.genpackage -g".

The server wizard (from ceutils) lists all of the platforms it fines on your XDCPATH. The reason behind this is that this wizard allows you to add additional templates for other platforms. This is discussed in the wizard's FAQ. If you look in ceutils/packages/ti/sdo/codecutils/genserver/templates, you'll see that there are no default templates for OMAPL137. On the other hand, if you look at codec_engine_2_23/packages/ti/sdo/ce/wizards/genserver/templates, you'll see OMAPL137.

The wizard from codec engine (invoked by xs ti.sdo.ce.wizards.genserver) is referred to as the "combo wizard" since it is capable of making codec combos (i.e. having more than one codec in a single executable) vs the ceutils (invoked by xs ti.sdo.ceutils.genserver) which is a "unitserver" wizard - meaning it creates DSP executables with exactly one codec.

Both the combo wizard and the unitserver wizard take codec packages (generated by the codec package wizard - only available in ceutils). So if you've already got a built codec package (sounds like you already have this part fine) then there's no reason to rerun the package wizard.

In the makefile, you can explicitly tell the XDCTools which XDCPATH to use by doing this:  $(XDC_INSTALL_DIR)/xs --xdcpath=$(XDCPATH) ti.sdo.ce.wizards.genserver

When I type the command with "--xdcpath=$(XDCPATH) " added in the command line, I get "Script, capsule, module or package must be supplied as an argument, or interactive mode (-i) must be selected." followed by Options, etc, including info that if none of the script, capsule, module, etc are included, that I need to include a module named Main that defines a main() function.

I decided to try interactive mode by typing the command with "--xdcpath=$(XDCPATH) -i " added in the command line, but that failed in the same way.

Then I tried adding a "-m VQM_RESULTS " to it, since it said it needed a module name. That failed the same way.

When I type the command with "--xdcpath=/home/username/serverexamples " added in the command line, I get the same error I had before (module not resolved).

The first 3 paragraphs seem to suggest that the xdcpath option does not want a string with multiple paths. The last one seems to suggest that using the option didn't fix the problem.

Oh, I forgot to mention that when I tried "--xdcpath=/home/username/serverexamples", the first error was that it couldn't find ti.sdo.ce.wizards.genserver, so I copied that whole tree into serverexamples. Now it finds it, but gets the unresolved error.

Flamingo said:

I tried "--xdcpath=/home/username/serverexamples",

I suggest you don't modify the Makefile's XDCPATH which already defined (and is already known to work). You'll need a lot more than a single path on your XDCPATH as indicated in the wizard docs - i.e. something like:

XDCPATH = ^;$(CURDIR)/packages;$(CODEC_INSTALL_DIR);$(CODEC_INSTALL_DIR)/packages;$(FC_INSTALL_DIR)/packages;$(XDAIS_INSTALL_DIR)/packages;$(FC_INSTALL_DIR)/fctools/packages;$(BIOS_INSTALL_DIR)/packages;$(BIOSUTILS_INSTALL_DIR)/packages;$(CMEM_INSTALL_DIR)/packages;$(LINK_INSTALL_DIR)/packages;$(CE_INSTALL_DIR)/packages;$(BIOSUTILS_INSTALL_DIR)/packages;$(LPM_INSTALL_DIR)/packages

There's no need to copy the wizards from one directory to another if you correctly setup your XDCPATH.

As I said, when I used the full $(XDCPATH) setting in the --xdcpath argument, the wizard failed with what looks like a format error. Note that in the output below, the first XDCPATH = ... is the output of my echo command (added at your suggestion: thanks). I've put "***" between that and the rest of the output to make it easier for you to read. Below the output from RTSC, find the Makefile and Rules.make.

-------------------------------------------------------start of output-----------------------------------------------------------------

RTSC Package Wizard user: You can ignore any warnings below about Mozilla this or that missing.
XDCPATH = ^;/home/username/serverexamples/packages;/home/username/serverexamples;/home/username/serverexamples/packages;/home/username/OMAPL137_arm_1_00_00_07/framework_components_2_22_01/packages;/home/username/OMAPL137_arm_1_00_00_07/xdais_6_22_01/packages;/home/username/OMAPL137_arm_1_00_00_07/framework_components_2_22_01/fctools/packages;/home/username/bios_5_33_03/packages;/home/username/OMAPL137_arm_1_00_00_07/biosutils_1_02_01/packages;/home/username/OMAPL137_arm_1_00_00_07/linuxutils_2_22_01/packages;/home/username/OMAPL137_arm_1_00_00_07/dsplink-1_61-prebuilt/packages;/home/username/OMAPL137_arm_1_00_00_07/codec_engine_2_22/packages;/home/username/OMAPL137_arm_1_00_00_07/biosutils_1_02_01/packages;/packages; before genserver

****

/home/username/xdctools_3_10_03/xs --xdcpath=^;/home/username/serverexamples;/home/username/serverexamples/packages;/home/username/serverexamples;/home/username/serverexamples/packages;/home/username/OMAPL137_arm_1_00_00_07/framework_components_2_22_01/packages;/home/username/OMAPL137_arm_1_00_00_07/xdais_6_22_01/packages;/home/username/OMAPL137_arm_1_00_00_07/framework_components_2_22_01/fctools/packages;/home/username/bios_5_33_03/packages;/home/username/OMAPL137_arm_1_00_00_07/biosutils_1_02_01/packages;/home/username/OMAPL137_arm_1_00_00_07/linuxutils_2_22_01/packages;/home/username/OMAPL137_arm_1_00_00_07/dsplink-1_61-prebuilt/packages;/home/username/OMAPL137_arm_1_00_00_07/codec_engine_2_22/packages;/home/username/OMAPL137_arm_1_00_00_07/biosutils_1_02_01/packages;/packages; ti.sdo.ce.wizards.genserver
Script, capsule, module or package must be supplied as an argument,
or interactive mode (-i) must be selected.
Usage: xs [options] [<script> | <capsule> | <module> | <package>] [args]
Options:
  -h, --help        Print this message and exit
  -v, --version        Print the version and exit
  @opts-file        Read the specified file and include its contents as
            arguments to xs
  -i            Run in interactive mode
  --xdcpath PATH, or
  --xdcpath=PATH    Add PATH to the beginning of the package path
  -D<name>=<val>    Add the "name=value" definition to the XDC
            Script environment
  -g[=<opts>]        use graphical debugger to run script, and
            optionally pass <opts> to debugger
            This option must be last in [options].

  -m            Specifies that the next argument is the name of
            a module. The module must define a main() function.
            This option must be last in [options].
  -f            Specifies that the next argument is the name of
            a script. This option must be last in [options].
  -c            Specifies that the next argument is the name of
            a capsule. The module must define a main() function.
            This option must be last in [options].

  If none of the options '-m', '-f', and '-c' is specified,
  the argument given to xs after [options] is assumed to
  be a package name. This package must have a module named
  Main that defines a main() function.

Graphical Debugger Options:
  -i            break at the first line of the startup script

/bin/sh: /home/username/serverexamples: Permission denied
/bin/sh: /home/username/serverexamples/packages: not found
/bin/sh: /home/username/serverexamples: Permission denied
/bin/sh: /home/username/serverexamples/packages: not found
/bin/sh: /home/username/OMAPL137_arm_1_00_00_07/framework_components_2_22_01/packages: Permission denied
/bin/sh: /home/username/OMAPL137_arm_1_00_00_07/xdais_6_22_01/packages: Permission denied
/bin/sh: /home/username/OMAPL137_arm_1_00_00_07/framework_components_2_22_01/fctools/packages: Permission denied
/bin/sh: /home/username/bios_5_33_03/packages: Permission denied
/bin/sh: /home/username/OMAPL137_arm_1_00_00_07/biosutils_1_02_01/packages: Permission denied
/bin/sh: /home/username/OMAPL137_arm_1_00_00_07/linuxutils_2_22_01/packages: Permission denied
/bin/sh: /home/username/OMAPL137_arm_1_00_00_07/dsplink-1_61-prebuilt/packages: Permission denied
/bin/sh: /home/username/OMAPL137_arm_1_00_00_07/codec_engine_2_22/packages: Permission denied
/bin/sh: /home/username/OMAPL137_arm_1_00_00_07/biosutils_1_02_01/packages: Permission denied
/bin/sh: /packages: not found
/bin/sh: ti.sdo.ce.wizards.genserver: not found
make: *** [genserver] Error 127

-------------------------------------------------end of output--------------------------------------------------------------------------------------

----------my makefile---------------------

#
#  ======== Makefile ========
#  This makefile is optional - you can use all of it or none of it.
#  Its purpose is to save time/typing when used from the context of the DVSDK.
#  All of the paths are preset in the $(DVSDK_INSTALL_DIR)/Rules.make. The wizards
#  (particularly the server wizard) requires many of these paths hence by setting 
#  the XDCPATH here we save the user some typing and package-path setup.
#  Commands (make goals): -
#  - Start the codec packaging wizard
#  [>] make genpackage
#  - Start the server wizard
#  [>] make genserver 
#  - Clean the codecs/server packages
#  [>] make clean
#  - Build the codecs/server packages
#  [>] make
#  - Release the codecs/server packages (generate tarballs)
#  [>] make release
#  Note : if your codec/server packages are in a different location outside 
#  the DVSDK simply override the CODEC_INSTALL_DIR on the cmd line via e.g. 
#  [>] make CODEC_INSTALL_DIR="/home/user/mycodecs"
#  Note : if using the wizard standalone outside of the DVSDK you can still
#  leverage this makefile by modifying the include Import Tools Path below 
#  to point to your DVSDK Rules.make
#  [>] make CODEC_INSTALL_DIR="/home/user/mycodecs" SERVERNAME="decode"
#  - Creates a DSP Server named decode.x64P
#
# Import Tools Path from Rules.make
include ../Rules.make
 
# Set location of xdc executable
XDC_INSTALL_DIR= /home/username/xdctools_3_10_03
CODEC_INSTALL_DIR = /home/username/serverexamples
XDC = $(XDC_INSTALL_DIR)/xdc

# Set XDCPATH to contain necessary repositories.
# Note that we put specify both CODEC_INSTALL_DIR and CODEC_INSTALL_DIR/packages
# since our config.bld is typically in CODEC_INSTALL_DIR.
XDCPATH = ^;$(CURDIR)/packages;$(CODEC_INSTALL_DIR);$(CODEC_INSTALL_DIR)/packages;$(FC_INSTALL_DIR)/packages;$(XDAIS_INSTALL_DIR)/packages;$(FC_INSTALL_DIR)/fctools/packages;$(BIOS_INSTALL_DIR)/packages;$(BIOSUTILS_INSTALL_DIR)/packages;$(CMEM_INSTALL_DIR)/packages;$(LINK_INSTALL_DIR)/packages;$(CE_INSTALL_DIR)/packages;$(BIOSUTILS_INSTALL_DIR)/packages;$(LPM_INSTALL_DIR)/packages;
 
# Conditionally, you can create verbose build output
XDCOPTIONS=v
 
# Select the combo build type , either debug or release
XDCARGS="release"
 
export XDCOPTIONS
export XDCPATH
export XDCARGS
 
########################################################
## Shouldn't have to modify anything be low this line ##
########################################################
SERVERNAME = ""
 
all: .all-packages
 
# This recursively locates all packages in the specified directory, builds
# and releases them
.all-packages:
    $(XDC) XDCARGS="release $(SERVERNAME)" -PR $(CODEC_INSTALL_DIR)
 
# This recursively cleans all packages in the specified directory
clean: clean-packages
 
clean-packages:
    $(XDC) clean -PR $(CODEC_INSTALL_DIR)
 
# This recursively releases all packages in the specified directory
release: release-packages
 
release-packages:
    $(XDC) release -PR $(CODEC_INSTALL_DIR)
 
genpackage:
    @echo "RTSC Package Wizard user: You can ignore any warnings below about Mozilla this or that missing."
    $(XDC_INSTALL_DIR)/xs ti.sdo.codecutils.genpackage -g
 
genserver:
    @echo "RTSC Package Wizard user: You can ignore any warnings below about Mozilla this or that missing."
    @echo "XDCPATH = $(XDCPATH) before genserver"

    /home/username/xdctools_3_10_03/xs --xdcpath=$(XDCPATH) ti.sdo.ce.wizards.genserver
 
# This ensures that the BIOS you're using has been patched for SDSCM00004525.
# Specifically, the fix is to rename
# $(BIOS_INSTALL_DIR)/packages/ti/rtdx/package_export.xdc to package.xdc
#.check-BIOS : $(BIOS_INSTALL_DIR)/packages/ti/rtdx/package.xdc
 
    $(everything for check-BIOS is skipped.)
--------------end of makefile-------------------------------------

---------------------------------------------------start of Rules.make-----------------------------------------------

PLATFORM = omapl137
DVSDK_INSTALL_DIR = /home/username/OMAPL137_arm_1_00_00_07
XDC_INSTALL_DIR = /home/username/xdctools_3_10_03
BIOS_INSTALL_DIR = /home/username/bios_5_33_03
LINUXKERNEL_INSTALL_DIR = /home/username/linux-2.6.18_pro500/arch/arm/kernel
CE_INSTALL_DIR = $(DVSDK_INSTALL_DIR)/codec_engine_2_22
FC_INSTALL_DIR = $(DVSDK_INSTALL_DIR)/framework_components_2_22_01
LINK_INSTALL_DIR = $(DVSDK_INSTALL_DIR)/dsplink-1_61-prebuilt
XDAIS_INSTALL_DIR = $(DVSDK_INSTALL_DIR)/xdais_6_22_01
CMEM_INSTALL_DIR = $(DVSDK_INSTALL_DIR)/linuxutils_2_22_01
BIOSUTILS_INSTALL_DIR = $(DVSDK_INSTALL_DIR)/biosutils_1_02_01
CODEC_INSTALL_DIR = /home/username/serverexamples
LPM_INSTALL_DIR =
EDMA3_LLD_ROOT =
EXEC_DIR = /home/username/workdir/filesys/opt
@echo "XDCPATH = $(XDCPATH) in Rules.make"

---------------------------------------------------end of Rules.make-----------------------------------------------

The ^ in the XDCPATH should be evaluated out by the XDCTools into your current directory but this doesn't appear to be done... try putting quotes around your XDCPATH and see if you have different results. I have seen discrepencies between Windows and Linux on things like this.

Putting quotes around the XDCPATH definition did nothing, so I put them around the --xdcpath assignment.

Now it runs (see output below), but reports the same error (that it can't resolve name..., also below).
----------------output on console--------------------
RTSC Package Wizard user: You can ignore any warnings below about Mozilla this or that missing.
XDCPATH = ^;/home/psandt/serverexamples/packages;/home/psandt/serverexamples;/home/psandt/serverexamples/packages;/home/psandt/OMAPL137_arm_1_00_00_07/framework_components_2_22_01/packages;/home/psandt/OMAPL137_arm_1_00_00_07/xdais_6_22_01/packages;/home/psandt/OMAPL137_arm_1_00_00_07/framework_components_2_22_01/fctools/packages;/home/psandt/bios_5_33_03/packages;/home/psandt/OMAPL137_arm_1_00_00_07/biosutils_1_02_01/packages;/home/psandt/OMAPL137_arm_1_00_00_07/linuxutils_2_22_01/packages;/home/psandt/OMAPL137_arm_1_00_00_07/dsplink-1_61-prebuilt/packages;/home/psandt/OMAPL137_arm_1_00_00_07/codec_engine_2_22/packages;/home/psandt/OMAPL137_arm_1_00_00_07/biosutils_1_02_01/packages;/packages before genserver
/home/psandt/xdctools_3_10_03/xs --xdcpath="^;/home/psandt/serverexamples/packages;/home/psandt/serverexamples;/home/psandt/serverexamples/packages;/home/psandt/OMAPL137_arm_1_00_00_07/framework_components_2_22_01/packages;/home/psandt/OMAPL137_arm_1_00_00_07/xdais_6_22_01/packages;/home/psandt/OMAPL137_arm_1_00_00_07/framework_components_2_22_01/fctools/packages;/home/psandt/bios_5_33_03/packages;/home/psandt/OMAPL137_arm_1_00_00_07/biosutils_1_02_01/packages;/home/psandt/OMAPL137_arm_1_00_00_07/linuxutils_2_22_01/packages;/home/psandt/OMAPL137_arm_1_00_00_07/dsplink-1_61-prebuilt/packages;/home/psandt/OMAPL137_arm_1_00_00_07/codec_engine_2_22/packages;/home/psandt/OMAPL137_arm_1_00_00_07/biosutils_1_02_01/packages;/packages" ti.sdo.ce.wizards.genserver
**** warning: package xdc.tools.sg.linux_swt depends on the
Mozilla browser for some functionality. Your environment doesn't
currently point to Mozilla, so some XDC graphical tools may fail.
To prevent this, please set up the following in your environment:

 - set the MOZILLA_FIVE_HOME environment variable. Its value
   should be the directory that contains the file run-mozilla.sh,
   which you can find using the command:
       locate run-mozilla.sh
 - include $MOZILLA_FIVE_HOME and $MOZILLA_FIVE_HOME/plugins on
   the LD_LIBARARY_PATH, for example using bash syntax:
       export LD_LIBRARY_PATH="$MOZILLA_FIVE_HOME:$LD_LIBRARY_PATH"
       export LD_LIBRARY_PATH="$MOZILLA_FIVE_HOME/plugins:$LD_LIBRARY_PATH"


Starting GUI RTSC Codec Server Wizard now...
RTSC GUI Codec Server Wizard user:
You can ignore any warnings below about Mozilla this or that missing.
----------------------end of console output-------------------------
------------RTSC Server Wizard error message------------------------
An error occured while searching for platforms on the XDC Path: javaException: xdc.services.spec.SessionRuntimeException: mycompany.vqm_reslts.ce: can't resolve name mycompany.vqm_results.VQM_RESULTS
Please check your XDC Path and restart the GUI RTSC Codec Server Wizard
-----------end of RTSC Server Wizard error message----------------------

Flamingo said:

can't resolve name mycompany.vqm_results.VQM_RESULTS

This typically implies that the XDCTools can't determine what "mycompany.vqm_results.VQM_RESULTS" is - i.e. is it a package, module, etc. If you search around the wizard source for the "An error occured while searching platforms on your XDC Path" you'll see that the wizard is looping through every package on your XDCPATH trying to find all of the platforms (i.e. ti.platforms.evmDM6467, ti.platforms.evmOMAPL137, etc) to populate the list. So it seems like your codec package is somehow incorrect.

I would suggets you build both the codec package and the server package for a "known good" - i.e. you can try to rebuild the IUNIVERSAL Examples codec + server using the wizard (since this was originally how they were generated) or the viddec_copy example included in ceutils (generated by codec and server wizards in ceutils).

I finally gave up and just deleted everything and I'm starting over.

As you mentioned in the past, the package generator does not know about the OMAP-L137, so I'd have to create my own makefiles for each of the example packages. Since I can't debug my own, I doubt that I can debug one for code I didn't write. I don't have xml files for the inputs like I do with the example viddec_copy.

In the past I have built all the examples, but it didn't involve package generation/server generation, Makefile creation, etc. It was a simple gmake clean, gmake.

I finally got the package generator to run on universal_copy, but I didn't realixze that it was supposed to create a Makefile and I was supposed to run make, so I didn't realize that the package generation was not complete. (It took a long time just to get through the generator without failing.)

I suppose the good news is that I got through the post-genpackage make.

No response needed.