Modifying the DSP/Link examples and utilizing OE toolchains outside OE

Now that we got OE to build the DSP/Link kernel module and examples for us, we'll probably want to do some tinkering with the sample applications to feel more comfortable with DSP/Link - one may just as well start from scratch, but it definitely won't be as easy as modifying the existing examples.

You should be able to find the dsplink source tree at

~/oe/setup-scripts/build/tmp-angstrom_2008_1/sysroots/beagleboard-angstrom-linux-gnueabi/usr/share/ti/ti-dsplink-tree/packages/dsplink

and under this directory, you'll find the two directories for the sample sources, namely gpp/src/samples for the GPP-side code of the samples, and dsp/src/samples for the DSP-side. The source codes found in these directories themselves is quite interesting to study to learn how DSP/Link and its components are used, and I've heard that actually tinkering with things allows you to learn much faster *wink wink*.

The thing is, once you have modified the sources, it's not very straightforward to re-compile them as they're part of the DSP/Link make system. Here one can utilize OpenEmbedded's environment to make this go a bit more smoothly.

The ti-devshell recipe generates a shell script which you can run to become bitbake. Well, maybe not become bitbake, but it'll export all the related environment variables for you once you run it, which will make life much easier. One thing before baking the actual recipe that you may want to do is, check the ti-devshell.bb recipe file and see if it contains this line:

PACKAGE_ARCH = "${MACHINE_ARCH}"

if it doesn't, you can just add it somewhere near the top - it'll be generating incorrect paths for the ti- thingies otherwise. Koen mentioned that this is needed due to some hack the ti- recipes are using.

After bitbake ti-devshell you'll end up with a shell script in the OE deploy/addons directory. Try running this script and typing in env to get an idea how much it does for you :)

The part that comes now was inspired by how the ti-dsplink.bb recipe does things - it's highly recommended that you examine the file yourself.

Next, go into the dsplink source directory by issuing cd $LINK_INSTALL_DIR. There's one particular environment variable that the script doesn't set, so export DSPLINK=$LINK_INSTALL_DIR/dsplink. Find the config script under config/bin in the dsplink directory, and execute this to configure the DSP/Link make system:

perl dsplinkcfg.pl --platform=OMAP3530 --nodsp=1 --dspcfg_0=OMAP3530SHMEM --dspos_0=DSPBIOS5XX --gppos=OMAPLSP --comps=ponslrmc

What was that bunch of parameters? You can run the script without any arguments and it'll describe each of them for you, along with the choices you have. Following the default settings (ie the ones I mention above) is highly recommended though.

Just two steps away from completion...there's some more bitbake-inspired environment variables to be set - beware that these represent my particular paths with the OE root located at ~/oe.

export TARGET_PREFIX=arm-angstrom-linux-gnueabi-

export TOOLCHAIN_PATH=~/oe/setup-scripts/build/tmp-angstrom_2008_1/cross/armv7a

export TARGET_SYS=arm-angstrom-linux-gnueabi

export STAGING_KERNEL_DIR=~/oe/setup-scripts/build/tmp-angstrom_2008_1/sysroots/beagleboard-angstrom-linux-gnueabi/kernel

Finally, go into the gpp/src/samples directory and...

make BASE_TOOLCHAIN="${TOOLCHAIN_PATH}" BASE_CGTOOLS="${BASE_TOOLCHAIN}/bin" OSINC_PLATFORM="${TOOLCHAIN_PATH}/lib/gcc/${TARGET_SYS}/$(${TARGET_PREFIX}gcc -dumpversion)/include" OSINC_TARGET="${BASE_TOOLCHAIN}/target/usr/include" CROSS_COMPILE="${TARGET_PREFIX}" CC="${TOOLCHAIN_PATH}/bin/${TARGET_PREFIX}gcc" LD="${TOOLCHAIN_PATH}/bin/${TARGET_PREFIX}gcc" AR="${TOOLCHAIN_PATH}/bin/${TARGET_PREFIX}ar" COMPILER="${TOOLCHAIN_PATH}/bin/${TARGET_PREFIX}gcc" LINKER="${TOOLCHAIN_PATH}/bin/${TARGET_PREFIX}gcc" ARCHIVER="${TOOLCHAIN_PATH}/bin/${TARGET_PREFIX}ar" KERNEL_DIR="${STAGING_KERNEL_DIR}" all

it's just ripped off from the OE dsp/link recipe, it should be just fine to copy-paste it into your terminal as it's pretty neutral with a lot of environment variables (which we already defined in the previous step). You can repeat the same make comand in dsp/src/samples to build the DSP-side code as well, all of which will end up in the gpp/BUILD and dsp/BUILD directories.

Building DSP/Link with OpenEmbedded

I'll be shortly making a post about how the traditional DSP development cycle with DSP/Link works to further emphasize why C6Run and DSP-RPC-POSIX (that'd be my GSoC project's name :)) are needed. But before that, I though I'd talk a little about setting up DSP/Link -which is a vital component for doing DSP development on OMAP3530 in the preferred way- using OpenEmbedded.

Start off by building the ti-dsplink recipe:

bitbake ti-dsplink

(if, for some reason, you want only the kernel module for dsplink, you can use the ti-dsplink-module recipe instead - the ti-dsplink recipe contains both the module and the samples)

This should result in several package files in your OE deployment directory (something like ~/oe/setup-scripts/build/tmp-angstrom_2008_1/deploy/glibc/ipk), which can be transferred to your Beagle (by directly copying them to the SD, by networking, by nfs...the options are endless - I personally mount the beagle via sshfs on my host machine) and then installed with opkg install . 

That's all there is to building and install DSP/Link, really! You can invoke the provided examples by cd'ing into /usr/share/ti/ti-dsplink-examples and then:

1. ./ti-dsplink-examples-loadmodules.sh to load the kernel modules. Note that you should have your bootargs configured to leave several megabytes of memory to the DSP/Link module. You may get a warning on the newer Beagles with 256 megs of RAM even if your bootargs are configured correctly, since the script just checks if you have more than 126 megs allocated for the kernel, so no panic.
2. ./ti-dsplink-examples-run.sh to run all the examples with some default parameters - you can examine the contents of this file to see how particular examples are invoked. Aside from the second parameter (which is the DSP executable name) and the last (which is the DSP ID), playing around with the parameters should be safe.
3. ./ti-dsplink-examples-unloadmodules.sh to optionally unload the modules once you're done.