DSPLink Instructions

[ravishi]

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:

http://ossie.wireless.vt.edu/trac/wiki/BeagleBoard_CodecEngine
(Recommended)
http://ossie.wireless.vt.edu/trac/wiki/BeagleBoard_DSPLink

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.

[Jason D]

Ravishi,

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?

[Jason D]

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.

[Koen Kooi]

Op 30 jul 2009, om 22:15 heeft Jason D het volgende geschreven:

> 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.

no, just do 'bitbake ti-codec-engine -c compile -f'

regards,

Koen

[Philip Balister]

On Thu, Jul 30, 2009 at 4:15 PM, Jason D<jdid...@gmail.com> wrote:
> 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.

This is on my list, but my list is very long.

Philip

[ravishi]

Jason,

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.

Ravi

On Jul 30, 4:15 pm, Jason D <jdidon...@gmail.com> wrote:
> 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.
>

> On Thu, Jul 30, 2009 at 11:41 AM, Jason D <jdidon...@gmail.com> wrote:
> > Ravishi,
>
> > 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?
>

[Philip Balister]

On Thu, Jul 30, 2009 at 5:31 PM, ravishi<ravi...@gmail.com> wrote:
>
> Jason,
>
> 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 :)

Philip

[Jason D]

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.

[Philip Balister]

On Thu, Jul 30, 2009 at 5:58 PM, Jason D<jdid...@gmail.com> wrote:
>
> 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.

Try using top to see what is going on ....

Philip

[Jason D]

It is sitting at the task: ti-codec-engine_2.21.bb, do_compile

Using "top" I can see it bouncing around between the following:

xs.x86U
tconf.x86U
asm6x
cg6x

Currently it has run about 3x as long as my first
bitbake ti-codec-engine. I'm getting the feeling that it
is going nowhere.

[Philip Balister]

On Thu, Jul 30, 2009 at 6:18 PM, Jason D<jdid...@gmail.com> wrote:
>
> It is sitting at the task: ti-codec-engine_2.21.bb, do_compile
>
> Using "top" I can see it bouncing around between the following:
>
> xs.x86U
> tconf.x86U
> asm6x
> cg6x
>
> Currently it has run about 3x as long as my first
> bitbake ti-codec-engine. I'm getting the feeling that it
> is going nowhere.

Are they using CPU time?

I still like the idea of creating something that looks like this:

message/dsp
message/gpp

We can help you create a bb file to build this.

:)

[Jason D]

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.

[Philip Balister]

On Thu, Jul 30, 2009 at 6:27 PM, Jason D<jdid...@gmail.com> wrote:
>
> 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.

[Jason D]

Ok, I will pursue that approach. Thanks for responding

-Jason

[ravishi]

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.

This seems to be what I have already been doing. The instructions for
compiling applications using OE tools are at the bottom of the
instructions. http://ossie.wireless.vt.edu/trac/wiki/BeagleBoard_CodecEngine#CompilingGPPandDSPApplications
It is very fast as each application can be compiled separately.

On Jul 30, 6:51 pm, Jason D <jdidon...@gmail.com> wrote:
> Ok, I will pursue that approach. Thanks for responding
>
> -Jason
>
> On Thu, Jul 30, 2009 at 3:32 PM, Philip Balister

> <philip.balis...@gmail.com>wrote:

>
>
>
> > On Thu, Jul 30, 2009 at 6:27 PM, Jason D<jdidon...@gmail.com> wrote:
>
> > > 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.
>
> > Philip
>
> > > On Thu, Jul 30, 2009 at 3:20 PM, Philip Balister <

> > philip.balis...@gmail.com>
> > > wrote:

>
> > >> On Thu, Jul 30, 2009 at 6:18 PM, Jason D<jdidon...@gmail.com> wrote:
>
> > >> > It is sitting at the task: ti-codec-engine_2.21.bb, do_compile
>
> > >> > Using "top" I can see it bouncing around between the following:
>
> > >> > xs.x86U
> > >> > tconf.x86U
> > >> > asm6x
> > >> > cg6x
>
> > >> > Currently it has run about 3x as long as my first
> > >> > bitbake ti-codec-engine. I'm getting the feeling that it
> > >> > is going nowhere.
>
> > >> Are they using CPU time?
>
> > >> I still like the idea of creating something that looks like this:
>
> > >> message/dsp
> > >> message/gpp
>
> > >> We can help you create a bb file to build this.
>
> > >> :)
>
> > >> Philip
>
> > >> > On Thu, Jul 30, 2009 at 3:02 PM, Philip Balister

> > >> > <philip.balis...@gmail.com>
> > >> > wrote:

>
> > >> >> On Thu, Jul 30, 2009 at 5:58 PM, Jason D<jdidon...@gmail.com> wrote:
>
> > >> >> > 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.
>
> > >> >> Try using top to see what is going on ....
>
> > >> >> Philip
>
> > >> >> > On Thu, Jul 30, 2009 at 2:36 PM, Philip Balister

> > >> >> > <philip.balis...@gmail.com>
> > >> >> > wrote:
>
> > >> >> >> On Thu, Jul 30, 2009 at 5:31 PM, ravishi<ravish...@gmail.com>

[Philip Balister]

On Thu, Jul 30, 2009 at 7:58 PM, ravishi<ravi...@gmail.com> wrote:
>
> 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.
>
> This seems to be what I have already been doing.  The instructions for
> compiling applications using OE tools are at the bottom of the
> instructions.  http://ossie.wireless.vt.edu/trac/wiki/BeagleBoard_CodecEngine#CompilingGPPandDSPApplications
> It is very fast as each application can be compiled separately.

This is as much for TI people reading as anyone :)

We don't want to build inside the dsplink tree.

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.

Philip

[Philip Balister]

Koen reminded me of the link to the TI example for the L137 that
should be adaptable to the OMAP3:

http://tiexpressdsp.com/index.php/Example_application_using_DSP_Link_on_OMAPL1x

Something like this for the Beagle would be great (I really should
look at it before saying this :)

Philip

[Koen Kooi]

And if you want an example of how to use the iUniversal API: https://gstreamer.ti.com/gf/project/bitblit

regards,

Koen

[Ravi Mehra]

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.

See http://ossie.wireless.vt.edu/trac/wiki/BeagleBoard#SimpleBuildSystemforDSPLink
for the file.

Additionally, below that information is a separate application using
DSPLIB. More information on DSPLIB and the application is found at
the same wiki. http://ossie.wireless.vt.edu/trac/wiki/BeagleBoard#SampleAplicationusingDSPLIB

On Jul 31, 8:04 am, Koen Kooi <k...@beagleboard.org> wrote:
> Op 31 jul 2009, om 13:51 heeft Philip Balister het volgende geschreven:
>
>
>
>
>
> > On Thu, Jul 30, 2009 at 8:20 PM, Philip

> > Balister<philip.balis...@gmail.com> wrote:

> >> On Thu, Jul 30, 2009 at 7:58 PM, ravishi<ravish...@gmail.com> wrote:
>
> >>> 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.
>
> >>> This seems to be what I have already been doing.  The instructions  
> >>> for
> >>> compiling applications using OE tools are at the bottom of the

> >>> instructions.  http://ossie.wireless.vt.edu/trac/wiki/BeagleBoard_CodecEngine#Compil...

> >>> It is very fast as each application can be compiled separately.
>
> >> This is as much for TI people reading as anyone :)
>
> >> We don't want to build inside the dsplink tree.
>
> >> 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:
>

> >http://tiexpressdsp.com/index.php/Example_application_using_DSP_Link_...

>
> > Something like this for the Beagle would be great (I really should
> > look at it before saying this :)
>
> And if you want an example of how to use the iUniversal API:https://gstreamer.ti.com/gf/project/bitblit
>
> regards,
>
> Koen
>

>  PGP.sig
> < 1KViewDownload

[rob]

Hi guys,

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.

Rob.

[Matthias Klostermann]

Here is, what works for me:

1. Build an SD-Card Image (stable) with the narcissus image builder: http://amethyst.openembedded.net/~koen/narcissus/
(A strike of genius, btw. Thanks Koen, this thing made my life a lot
easier ;-) ) Install it on an SD-Card and make sure it works fine.
2. Get ti-dsplink-module (http://www.angstrom-distribution.org/repo/?pkgname=ti-dsplink-module
) and ti-dsplink-apps (http://www.angstrom-distribution.org/repo/?pkgname=ti-dsplink-apps
) from the Angström Repo.
3. Install ti-dsplink-module with opkg.
4. Install ti-dsplink-apps with opkg.
5. depmod -r
6. cd /usr/share/ti-dsplink
7. Load the Modules: ./load-modules...sh (can't remember the exact
name of the Script, but it should be obvious)
8. Try: ./mpcsxfergpp mpcsxfer.out 1024 1000

An additional note: When you write your own software, make sure you
a.) use the same Version of DSP-Link as the Kernel-Module and
b.) leave out the "c" in the --comps Option when you configure DSP-
Link with dsplinkcfg.pl (Reason: That Component is not compiled into
the Kernel Module. This caused me a long headache until I found it and
it made my Apps throw the DSP_EFAIL error.)

Regards,
Matthias

[Herbert]

Hi, Matthias,

 

  I followed your instruction to install dsplink, but I didn't even see /usr/share/ti-dsplink directory after install dsplink-module and dsplink-apps. Can you please tell me how /which options you chose when you build your SD-Card image using Koen's image builder?

 

  I also followed the Codec-engine instruction to build the eight modules, but no sucess either. When I run a sample code, it failed to start. Any advice?

 

Thanks

Lei Huang

[Rob]

Hi Matthias,

Thanks for that guide, I managed to get it working through following
it and tweaking it for my preferences. All the app samples worked,
though I had to reboot the BeagleBoard when switching between
different apps. However that may be due to not having the lpm stuff
to switch the DSP on and off.

Herbert,
heres the few tweaks I made to the build, they may help.
In the narcissus image builder, I choose:
a) regular (base-task)
b) udev
c) console only
d) I selected no development packages
e) Additional packages: I selected only 2 (All kernel modules,
Dropbear SSH server)

I needed Dropbear for copying stuff from my host PC to the BeagleBoard
using scp. I selected 'all kernel modules' so that I could get the
usb-ethernet driver that I need (mcs7830.ko). Those two options are
individual to me, however its possible that the 'all kernel modules'
selection has something that is needed to get it working correctly. I
never tried installing the module or apps, let alone running without
the 'all kernel modules' option.

I can't think how the opkg install ti-dsplink-apps wouldn't install
it, as its certainly in the ipk. My only suggestions are:
a) Have you enough disk space?
b) Is an environment variable installing it elsewhere?
c) Where the ipks fully downloaded correctly?
d) ...um perhaps someone might have better ideas than me...

Best of luck.
Rob.

[piecurus]

Hi all,
I tried the Matia's procedure and that explained in
http://ossie.wireless.vt.edu/trac/wiki/BeagleBoard_CodecEngine
but in both cases I get the error
"FATAL: Module dsplinkk not found."
Any idea?
Thankyou very much.

[Caner]

Hi,
I followed Matthias' path. I downloaded an image same as Rob
described. Then I went on following the remaining steps at Matthias'
list. When, I tried to install ti-dsplink-module with opkg, I got this
error message:

root@beagleboard:~# opkg install ti-dsplink-module_223-
r32.1_beagleboard.ipk
Installing ti-dsplink-module (223-r32.1) to root...
Configuring ti-dsplink-module
/etc/modutils/ipv6: line 1: ipv6: not found
Error while executing /etc/modutils/ipv6, aborting
update-modules: Illegal seek
WARNING: Couldn't open directory /lib/modules/2.6.28-omap1: No such
file or directory
FATAL: Could not open /lib/modules/2.6.28-omap1/modules.dep.temp for
writing: No such file or directory
depmod: Illegal seek

I checked /lib/module, I found 2.6.29-omap1. I created a softlink,
2.6.28-omap1->2.6.28-omap1. Then I retried, and I got:

root@beagleboard:~# opkg install ti-dsplink-module_223-
r32.1_beagleboard.ipk
Multiple packages (ti-dsplink-module and ti-dsplink-module) providing
same name marked HOLD or PREFER. Using latest.
Multiple packages (ti-dsplink-module and ti-dsplink-module) providing
same name marked HOLD or PREFER. Using latest.
Installing ti-dsplink-module (223-r32.1) to root...
Configuring ti-dsplink-module
/etc/modutils/ipv6: line 1: ipv6: not found
Error while executing /etc/modutils/ipv6, aborting
update-modules: Illegal seek


The file /etc/modutils/ipv6 exists and conaints only a string `ipv6´
at line 1.
Note that I also run `opkg update´.

Any idea?

Regards

Caner

[Caner]

Hi,
I removed (somewhere else on the disk) ipv6 file, and I retried to
install all packages. It worked that time. Just a little notification:
the line `modprobe dsplinkk´ in loadmodules-ti-dsplink-apps.sh did not
worked for me. We modified it as `modprobe -f dsplinkk´ to force it to
load the module. This also worked.
Now, sample binaries work alright. But I can only run a sample at
one session. I'm missing lmpON.x470uC and lmpOFF.x470uC files. I can't
find them, even with find command. So, what can be the problem? Is
there another way to load another DSP binary after a first one?

Regards

Caner