[maemo-developers] [maemo-developers] DSP programming

[From: Larry Battraw]

On 5/11/07, Simon Pickering <S.G.Pickering at bath.ac.uk> wrote:
> Hi All,
>
> I've had some time and have picked up where I left off, but this time using my
> N800. The result is good news :) (but a rather long and meandering email). The
> DSP seems very well behaved (no resets leading to reboots) and the couple of
> demos I've tried worked fine. I was quite surprised after the hassles I had with
> the 770. I don't know whether I've done something different or whether the setup
> on the N800 (hardware/software) has helped.

I've often wondered the same.  With the 770 being essentially the
first off the line for the series if there weren't a fair number of
internal errata pages on hardware issues (internally) I'd be
surprised.  The n800 has been so much more stable compared to it's
predecessor it does make you wonder.how many things did get fixed.


> Anyway, instructions largely as before, Ti toolchain all the same, etc.
>
> I tested the demo_console and test7 demos, both worked fine.
>
> I made my own Makefiles pointing to the locations of my toolchain. These are
> available in the tarballs of the DSP code directories I've placed at
> http://people.bath.ac.uk/enpsgp/nokia770/dsp/. They are copies of the ones from
> the DSP_Gateway33_spec.pdf document. The code was also copied from here, but
> it's available in the dspgw-3.3-dsp.tar.gz tarball from the DSP Gateway page.
> You'll also need the ARM-side code which is in dspgw-3.3-arm.tar.gz.
>
> A couple of notes at this point (about copying from the pdfs from the DSP
> Gateway site): Any \ characters appears as a ¥ in the pdfs and the " sometimes
> comes out as a different character (smart quote) so make sure you check your
> code if you start getting weird errors (the last one had me scratching my head
> for a while as they look pretty much the same in my editor).
>
> You'll also need to remove references to the <asm/arch/omapdsp.h> include file.
> I don't have this, the tarball demos don't have this line either (and are
> otherwise identical to the pdfs). No idea what it's for.

It might be handy to have-- are the register names, configuration
register bits, etc. defined somewhere else?  That'd be my guess right
off the bat.

> After compiling your code, you'll need to place the DSP-side object file (*.o)
> in /lib/dsp/modules/, you'll also need to make an entry in the
> /lib/dsp/dsp_dld_avs.conf file.
>
> My addition lines looks like this:
>
> demo_console    _task_demo_console      1       /lib/dsp/modules/demo_console.o
> test7           _task_test7             1       /lib/dsp/modules/test7.o
>

(snip)

> I'm going to look at using the DSP with Octave (via oct files) for doing fast
> ffts, etc. I'd also like to see whether it might help with speeding up JPEG
> decoding, which leads me rather obliquely onto the IVA.
>
> I've tried searching for this, but all I seem to get are promo. pdfs about how
> it's included in various OMAPs, and how wonderful it is, but nothing about what
> it actually is. For example, is it like the DSP, where it runs its own kernel,
> or is it a chip with set functionality that would have a limited set of function
> calls, etc.? Is there some technical documentation available for it anywhere? I
> suppose this question may be better asked on the linux-omap-open-source mailing
> list as some people there have been/are working on a DSP-IVA task bridge (e.g.
> see http://komalshah.blogspot.com/), but I thought I'd tack it on here and see
> whether anyone has run across anything.

Nothing but the literature you've seen.  Companies seem to love to
hoard information and charge a hefty entrance fee for a peek.  Once
again, shooting from the hip I would imagine it would be a overlay on
top of the existing MCU core, much like MMX1 is/was.  Sharing/reusing
registers would make for a smaller footprint in silicon, and the IVA
functions would remain quiescent until invoked by specific
instructions/mode changes.  The tricky part (and likely why Nokia
hasn't touched it yet) would be cleanly running that type of code
without hurting performance for the rest of the "normal" code that
needed to be able to switch out of the "Uber-IVA" mode, save registers
and extra state information, and then get back to business once more
when the IVA-specific code comes up again in the task queue.  That,
and the small detail of the GPL, since somehow both the kernel,
compiler, and applications that use the functionality would need to be
aware of the their part in how it functions.  Give it a miss, unless
TI and so forth are willing to open up a bit.

 Thanks for your continued efforts in the DSP hacking.  The more we
know, the more fun we can with specific codecs and other projects,
although it sounds as if the latency in pushing the data back and
forth to the DSP can be a limiting factor.

Larry