New DSP-Link tutorial?

Hello everybody.

As some might have read in my previous posts, I am trying to get the
DSP toolchain for the beagleboard to work.
It is really frustrating.
This took just too much time, so I am looking for a tutorial which is
not "outdated" or simply not working because so many things have
changed since the tutorial was written. Without tutorials,
rocketscience is easier than setting up this toolchain.
Trying to get this to work took too much time by now. Normally setting
up a DSP toolchain is done in less than 10 minutes. (e.G. CCS or
Visual DSP++)
I think the toolchain should be as easy to install as possible. This
is just a tool and nothing a DSP developper should have to worry
about. (There are much more important problems and tasks for DSP
developpers)
So I think a new tutorial is needed.

Can anyone explain step by step how to get a working DSP toolchain and
how to compile self-written code with it?
(I don't need help with the DSP code).
Let's assume that only the angstrom setup script is there and nothing
more. The computer is running on ubuntu 10.04 or 9.10, (installed just
a few minutes ago).

I had the following ideas:

1st step for me is always:
1) Change gcc from 4.4.x to 4.3.x as the qemu package won't compile
with 4.4.x

2) bitbake ti-dsplink
-> First problem: Not all TI tools can be downloaded during the build
process. Where can the paths to already installed tools like dsp-link,
dspbios, xdctools and the code generation tools be set?
So the build process doesn't interrupt with errors.
I just copied the tools to the directories where bitbake looked for
the tools but that is only a bad workaround.

3) After the build, there should be a working DSP toolchain for the
gpp and dsp side.
--> How to use it manually without OE
--> How to use it with a recipe / How to write a recipe for self
written code

Kind regards,
Sven Wilksen

I would also welcome information on this. I'm only starting out with
the beagle but I also want to program and control the DSP from linux.

We share your views on the subject that the setting up (and even
getting started with the DSP/Link) is far more troublesome than it
should be right now. Hence there is a project called C6Run in the
works for DSP ease-of-development. Check it out at
https://gforge.ti.com/gf/project/dspeasy/ or my blog at
maltanar.blogspot.com for posts on things like building DSP/Link and
some insight into how C6Run works, as well as the recent developments
for DSP->GPP RPC calls, which is my GSoC project :slight_smile:

Kind regards,
Yaman

For me there are three main things holding me back:
(a) Difficulty in reliably building DSP code
(b) Getting the code into the DSP and running it (including data IO)
(c) Debugging/tracing

My ideal situation would be:
(a) gcc for compiling C to DSP instruction set [1].
(b) Reliable and well documented linux userspace tools for loading,
running, unloading DSP code.
(c) QEMU simulator of the chip on which to run and debug the actual
code that executes on the OMAP (linux and DSP code, plus the bridge).

[1] codesourcery are porting gcc to C6000 instruction set. The first
cores they are targeting are the TMS320C64x used in the OMAP35x. I'd
much prefer to see the C6000 gcc port used instead of the proprietary
TI tools.

http://www.codesourcery.com/news/press_releases/gnu_toolchain_for_c6000_press_release.html
http://www.linux-c6x.org/about/

Richard Andrews wrote:

For me there are three main things holding me back:
  (a) Difficulty in reliably building DSP code
  (b) Getting the code into the DSP and running it (including data IO)
  (c) Debugging/tracing

My ideal situation would be:
  (a) gcc for compiling C to DSP instruction set [1].

why does it have to be gcc? TI offers a dsp compiler that you can use.
it has much better chances of producing somewhat optimized code for
the C64x..

  (b) Reliable and well documented linux userspace tools for loading,
running, unloading DSP code.

dsplink?

Beagle is an open platform. Openness is important to me and I think it
should extend to the toolchain. I want to be able to learn down to the
lowest layers. I want to be sure that this ability cannot be revoked
because it is no longer profitable.

Vladimir Pantelic wrote:

Richard Andrews wrote:

My ideal situation would be:
  (a) gcc for compiling C to DSP instruction set [1].

why does it have to be gcc? TI offers a dsp compiler that you can use.
it has much better chances of producing somewhat optimized code for
the C64x..

100% Agreed. I know quite a bit about the gcc internals and about the
C64x+ architecture, and they just don't fit together.. I'm sure
CodeSourcery will be able to build a compiler-backend for the
architecture, but out of the guts I'd expect it at least three times
slower than the free compiler from TI.

From what I've read the idea behind all this is to get linux running on
the DSP, and they need a compiler that understands all the gcc specific
hacks in the kernel.

Honestly, the DSP compiler works well. It's the dsplink and DspBios
configuration/setup that makes things so complicated. Otoh if you just
do what's written in the documentation of DspLink and DspBios you get a
working toolchain. It's not that hard, it's just lots of work to put all
the pieces together.

Nils

Splendid conclusion to arrive at, really. C6Run is not for overcoming
difficulties of compiling DSP/Link, it's probably just as hard to
build at the moment, although an OE recipe will eventually be in
place.

Yaman

I think getting the existing tools to work is much more urgent than
implementing DSP commands with the gcc toolchain.
Also, the DSP side compilation is rather easy.
The real big problem is the arm side toolchain. First, a working
tutorial is needed.
The turoial should start from scratch, assuming that only the Ångström
setup script (oebb.sh) is working.
Nothing installed before, nothing was downloaded etc.
Recipes might also be a good idea but without a good tutorial all
those hints won't work for beginners.

DSP development does not begin with building the toolchain, this is
not the DSP developpers job (no, it really isn't in my eyes).

A good starting point would be a sample recipe for compiling DSP code,
both for the ARM and the DSP side.
Does someone have such a recipe and would like to share it with us?

Furthermore a installation guide for DSPLink (and Ångström build with
oebb.sh) is simply missing.
This guide here looks good: http://processors.wiki.ti.com/index.php/Building_DSPLink
Can someone "translate" this to Beagleboard hardware and Ångström
build with OE and oebb.sh with default settings.

Building dsplink is easy. You only need to manually download the cgt .bin, put that in the download dir and do 'bitbake ti-dsplink'

regards,

Koen

Koen Kooi wrote:

Building dsplink is easy. You only need to manually download the cgt .bin, put that in the download dir and do 'bitbake ti-dsplink'
  
*agreed* it is not rocket-science...

A different way is to download DspLink, The Dsp-Cpmpiler and have your
kernel source on your harddisk.

Afterwards adjust the paths to the kernel, compiler and set the name of
the compiler in the DspLink makefile (exact details *are* documented)
and call make in the top-directory...

You'll end up with a kernel-module that is ready to be loaded and a
bunch of executables including dsp and gpp binaries..

I don't like the way the DspLink build-system works at all, and I would
never base a project on it, but it is easy enough to understand and to
tailor to your needs..

Cheers,
  Nils

Nils Pipenbrinck wrote:

Koen Kooi wrote:

Building dsplink is easy. You only need to manually download the cgt .bin, put that in the download dir and do 'bitbake ti-dsplink'

*agreed* it is not rocket-science...

A different way is to download DspLink, The Dsp-Cpmpiler and have your
kernel source on your harddisk.

Afterwards adjust the paths to the kernel, compiler and set the name of
the compiler in the DspLink makefile (exact details *are* documented)
and call make in the top-directory...

You'll end up with a kernel-module that is ready to be loaded and a
bunch of executables including dsp and gpp binaries..

yep, same here, not "nice" but quite doable.

I don't like the way the DspLink build-system works at all, and I would
never base a project on it, but it is easy enough to understand and to
tailor to your needs..

agreed

Hello,
me and my coworker Nicola Bettin have written a complete tutorial on
setting up the DSP Toolchain on the Beagleboard.
The work has been completed with the support of Marco Benocci (DEIS -
MICREL LAB) at the University of Bologna.
The guide covers setup with DSPLINK 1.61.03 and C64x+ DSPLIB.
A setup guide and slides are available at this link:
http://www-micrel.deis.unibo.it/~benocci/projects.htm
Source code for an example audio streaming application will be
uploaded soon.

Thanks for your attention and regards,
Valerio Cambareri

Valerio Cambareri wrote:

Hello,
me and my coworker Nicola Bettin have written a complete tutorial on
setting up the DSP Toolchain on the Beagleboard.
The work has been completed with the support of Marco Benocci (DEIS -
MICREL LAB) at the University of Bologna.
The guide covers setup with DSPLINK 1.61.03 and C64x+ DSPLIB.
A setup guide and slides are available at this link:
http://www-micrel.deis.unibo.it/~benocci/projects.htm

it's encrypted :slight_smile:

I'll tell our host :slight_smile: in the meantime you may browse my personal
Google Site for the guide.
http://sites.google.com/site/vcambareri/files-and-code
It's written in italian but you can guess what we're doing from the
shell commands :slight_smile:
I'll update this thread as soon as the official site is not encrypted.

Hi Valerio

Can you please tell approximately after how much time you will upload
the source code for audio streaming ?

Regards

Hi Valerio,

first of all thanks for uploading some step by step manual for
implementing DSPlink on beagleboard.

I was following your manual until I am stucked by 1 problem.

During the execution of command

"make -s debug "

in 4.5.1, pg 15, i got the following error.

Fetching the configuration file CFG_OMAP3530_SHMEM.c ...
Fetching the configuration file CFG_Linux.c ...
Fetching the configuration file CFG_ARM.c ...
Compiling CFG_system.c...
make[1]: /home/adnan/omap3530/arm-2008q1/bin/arm-none-linux-gnueabi-
gcc: Command not found
make[1]: *** [/home/adnan/TI/dsplink_1_61_03/dsplink/config/BUILD/
CFG_system.c.deb] Error 127
make: *** [objdeb] Error 2

Do you have an idea what I am missing ?

Regards

I'm on holiday right now so give me 1-2 weeks ok? :wink:

Probably some mispelled path to the arm-none-linux-gnueabi-gcc
compiler command. Always check (by copying it) if the paths returned
in error messages are actually there & contain what you expect / want
(in this case the compiler). That's No.1 Rule of setting up the
toolchain!

yeah Sure :slight_smile:

I will wait and thanks for helping even in your holiday :slight_smile:

Can you tell just 1 more thing ? Did you use linux-omap PSP ? if yes
then which version ?

Regards