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.

So what's this all about?

My dear readers(-to-be), welcome once again to maltanar's scribbles. Aside from attempting a reclaim on the blogging world, this blog will also serve a more important purpose. Here will be my scribbles on my Google Summer of Code project, for the BeagleBoard, which was initially entitled, rather horrifically, RPC-Like POSIX Wrappers for DSPEasy. A better name is in the works, but in the meanwhile I'd like to tell you all what it's all about.

BeagleBoard is (and the Pandora will be) a powerhouse, thanks to its 3-core (a GPP - generic processing, a GPU - for graphics processing, and a DSP - for, let's say, heavy number crunching! the acronym itself means Digital Signal Processor) OMAP3530 system. Therefore laptop-like performance at handheld power levels is most certainly not a myth. But to be able to achieve true laptop-like performance, the power inside needs to be harnessed to the max.

Of course, thanks to the heterogenous multi-core architecture, there are quite a few different ways in which this power can be harnessed. What I'll be doing will be targeting the DSP. Or more accurately, I'll be doing something that targets (in a friendly way!) programmers that wish to develop for the DSP by doing their work easier.

Right now, making actual use of the DSP is rather cumbersome and even after once you've gotten started, the development cycle isn't exactly bliss: you can't just "printf" the results of your experimental FFT code to the screen, for example, since there is really none - you have to deal with the details of interprocessor communications to see what's going on inside the DSP, as well as put data inside.

My aim with this project will be to create a RPC (remote procedure call)-like framework, which can be used to call any GPP-side function from the DSP-side, and create a set of POSIX wrappers using this framework to make life easier for developers.

Actual status updates coming soon! :)