For people who are interested in utilizing the onboard DSP, I have
created a couple guides on how to install DSPLink. DSPLink is a more
preferred DSP interface over DSP Bridge. The two guides are located
at:
Please let me know if you encounter any errors with the installation
or have comments to improve it. See below for a summary of the two
different guides.
Introduction to DSPLink
There are multiple options of how to make use of the onboard TI
TMS320C64x+ DSP. The first step is to install the GPP/DSP interface.
Two of the more popular interface options are DSPBridge and DSPLink.
Both were developed by TI but DSPLink is still supported, which makes
DSPLink a more preferable option. After selecting DSPLink as the GPP/
DSP interface, you need to build DSPLink for your specific platform.
There are two options of doing this as well. Both of these options
will install DSPLink and also configure your host system so you can
compile your own GPP and DSP applications.
* Building DSPLink inside OpenEmbedded
This is generally the preferred method. DSPLink can be built
using the Codec Engine bitbake recipe. This will install a full
version of DSPLink 1.60 in the tmp/staging directory. It will also
creates packages to quickly install prebuilt DSPLink sample
applications. Further configuration allows you to compile GPP and DSP
code.
* Building DSPLink outside OpenEmbedded
This method installs DSPLink from source which can be downloaded
from TI. Version 1.61.03 is used in the guide. Use this option if you
need a newer version of DSPLink than 1.60. Following the steps creates
modules to install on the BeagleBoard along with setting up your host
system to compile GPP and DSP code.
Although the instructions written at this website were designed around
a BeagleBoard which has an OMAP3530 + TMS320C64x+ DSP, the
instructions should be compatible across a variety of platforms with
only a minimal number of changes.
First of all - Thanks for posting this. It is very helpful.
I have completed the build using the “Inside OE” approach,
and can run the messagegpp app.
Now I would like to play around with modifying the
messagegpp app source and rebuilding it. Can you tell me
where the source is, and after I modify it can I rebuild
it by simply running “bitbake ti-codec-engine” again?
Ok, looks like running “bitbake ti-codec-engine” again will not work,
I guess that even when using the Inside OE approach that it will be
necessary to manually run make.
Ok, looks like running "bitbake ti-codec-engine" again will not work,
I guess that even when using the Inside OE approach that it will be
necessary to manually run make.
What we need is "someone" to take the messagegpp code and extract it
from the dsplink build system. Then wrap some simplified makefiles
around it and work on getting that to build using the tool chains from
OE. The figure out how to create a bb file to build that.
This example could then be used to build new, more exciting code.
Also, TI has a "simple" example, but I've lost the url for it.
I haven't tried Koen's command yet but that may be an option. (I'm
trying it now but my computer is choking)
There is sample source code which is split up between the GPP and
DSP. You probably already found them, but they are located at:
GPP is $DSPLINK/gpp/src/samples
DSP is $DSPLINK/dsp/src/samples
In my testing, I have modified the loop sample on both the GPP side
and the DSP side. It takes a little time to grasp what TI's code
does, but most of it is the same from application to application. I
also linked to the DSPLIB libraries to perform an FFT on the DSP. I
plan on writing some instructions on how to do that next week.
I haven't tried Koen's command yet but that may be an option. (I'm
trying it now but my computer is choking)
The problem with Koen's approach is that is only really useful for
quick hacking. If you remove tmp or completely rebuild the recipe,
your changes will be erased. Anyway, all sane code development occurs
in SCM's
I am trying Koen's command now.... It seems to be taking a really long time
to finish.
My first bitbake was much faster - so, maybe something is wrong.
The cpu usage is pretty high. In particular xs.x86U seems to typically
be in the 90%+ range. I would appreciate any help, since I am very
unfamiliar with bitbake and OE.
I think I’m going to kill this build… I made 1 code change to a char
string in a file and it has been building for about 50 minutes. I could
never be productive like this.
The cpu usage is pretty high. In particular xs.x86U seems to typically
be in the 90%+ range. I would appreciate any help, since I am very
unfamiliar with bitbake and OE.
I think I'm going to kill this build..... I made 1 code change to a char
string in a file and it has been building for about 50 minutes. I could
never be productive like this.
My long term strategy would revolve around building outside OE, with
my paths set to use the cross compiler and libraries OE has in
tmp/cross and tmp/staging, and teh TI toolchains used to build
codec/dsplink. This should let you compile/link/test easily. Once a
piece of code is finished, then make a bb file to build it.
Yeah, it took my computer a very long time with Koen's command as
well. Like Philip said, it is probably not the best solution for
compiling. It took about 25 minutes but still too long for what we
needed it for.
My long term strategy would revolve around building outside OE, with
my paths set to use the cross compiler and libraries OE has in
tmp/cross and tmp/staging, and teh TI toolchains used to build
codec/dsplink. This should let you compile/link/test easily. Once a
piece of code is finished, then make a bb file to build it.
Yeah, it took my computer a very long time with Koen's command as
well. Like Philip said, it is probably not the best solution for
compiling. It took about 25 minutes but still too long for what we
needed it for.
My long term strategy would revolve around building outside OE, with
my paths set to use the cross compiler and libraries OE has in
tmp/cross and tmp/staging, and teh TI toolchains used to build
codec/dsplink. This should let you compile/link/test easily. Once a
piece of code is finished, then make a bb file to build it.
We want a small example that builds with the tool chain created during
the OE build (or pre-installed for non OE people).
What I read in your notes is building dsplink or rebuilding pieces of
it, which is not what we want to do. It is already built (and
hopefully all staged).
In other words, show me a tarball that is the smallest piece of gpp +
dsp code that can do something useful, assuming I already built
dsplink and have the toolchains and dsp libs available outside the
tarball. I really have the sense we are talking about two different
objectives.
Yeah, it took my computer a very long time with Koen's command as
well. Like Philip said, it is probably not the best solution for
compiling. It took about 25 minutes but still too long for what we
needed it for.
My long term strategy would revolve around building outside OE, with
my paths set to use the cross compiler and libraries OE has in
tmp/cross and tmp/staging, and teh TI toolchains used to build
codec/dsplink. This should let you compile/link/test easily. Once a
piece of code is finished, then make a bb file to build it.
We want a small example that builds with the tool chain created during
the OE build (or pre-installed for non OE people).
What I read in your notes is building dsplink or rebuilding pieces of
it, which is not what we want to do. It is already built (and
hopefully all staged).
In other words, show me a tarball that is the smallest piece of gpp +
dsp code that can do something useful, assuming I already built
dsplink and have the toolchains and dsp libs available outside the
tarball. I really have the sense we are talking about two different
objectives.
Koen reminded me of the link to the TI example for the L137 that
should be adaptable to the OMAP3:
This is a general update to the progress of DSPLink. I have posted a
simplified sample application that uses one makefile. It calls upon
the OE build of DSPLink and the associated tools. Some modifications
to the makefile may be necessary depending on where your TI tools are
located.
I've been trying to get DSPLink working on the BeagleBoard for a while
now with no success.
I keep getting a DSP_init status [0x80008008] error, (DSP_EFAIL from
messages.h) when I run the messagegpp sample. Has anybody got any
suggestions as to why this is occuring or what to try to solve it?
Here's a little background about what I've tried and my configuration.
I've made up an SD card using openembedded console-image (version
2.6.29-omap1), and then built the ti-cmem-module, ti-dsplink-module
and ti-lpm-module, which should have been built using that kernel. I
put them on the SD card under /lib/modules/2.6.29-omap1/kernel/drivers/
dsp. I boot up the BeagleBoard with mem=80M and load the modules
using modprobe, with cmem setting memory addresses and pools. They
all load fine. I've run the lpmON and lpmOFF tests, they seem to be
ok, no complaints. However running messagegpp causes the DSP_init
error.
I've also built this modules outside of openembedded, using all the
latest code, dsplink-1.61.03, cmem-2.24.02 (linuxutils), and
lpm-1.24. I got the same DSP_init error.
I've been through both of Ravishis' guides. I stepped the
openembedded ti-codec-engine build back to using 2.21 (rather than
2.23.01) however when it tries to build the SDMA module it fails due
to missing header files (/asm/arch/..).
Thanks in advance for any suggestions you may have.
