DSP Programming =============== These are rough notes from which I created (then lost) a wiki page on the Maemo wiki. I'll sort out this document and try to fix the Maemo wiki page asap. General information ------------------- http://www.ti.com/sc/docs/psheets/man_dsp.htm - site listing all docs about Ti DSPs, do a search down the page for things with c55 in the description to get the the documents that are of interest. DSP Gateway project - http://dspgateway.sourceforge.net/pub/index.php This is used by the Nokia 770 and N800 to interface with the DSP. Setup the toolchain ------------------- (Parts from http://www.gossamer-threads.com/lists/maemo/developers/3938) Download the toolchain from https://www-a.ti.com/downloads/sds_support/targetcontent/LinuxDspTools/index.html (you need a free registration to access this page). The download page has a link to a "Getting Started" PDF which has instructions for installing. The install instruct start at page 11, chapter 2.3.1. The download package is an ELF-executable but fortunately it just unpacks the main package. The package seems to require java - at least it prints out "Searching for Java(tm) Virtual Machine". For other pre-requirements see chapter 2.1, but note that not all of the listed things are strictly required. Installing pdksh might be a good idea if one does not want to go changing the scripts written for ksh. For easily installing the unpacked subpackages one can use the supplied expect script. Naturally this requires having expect installed. Alternatively one can simply unpack the tarballs one by one. It is probably a good idea to use the same directory names as the ones used in the instructions in order to minimize needed chages to DSP gateway makefiles. The instructions starting from chapter 3 seem to be MontaVista and dsplink specific. If one wants to use the dsp gateway there's no need to follow those. Compiling a program ------------------- Get dsp gateway from http://dspgateway.sourceforge.net/pub/index.php Get both the arm side package (dspgw-3.3-arm.tar.bz2) and the dsp side package (dspgw-3.3-dsp.tar.bz2). No need to go patching the 770 kernel or rebuilding it. Unpack the tarballs. Go to dspgw-3.3-arm/host_utils/mod_utils and build the coff_unresolve and gen_dummy_kernel tools. Simple make should be sufficient. Either copy these tools to your path or adjust dspgw-3.3-dsp/apps/demo_mod/Makefile to use the tools from the directory where they are. Also build the arm side of the demo console in dspgw-3.3-arm/apps/demo with "make demo_console". You may need to adjust CC to point to your arm cross compiler, e.g. /scratchbox/compilers/arm-gcc-3.3.4-glibc-2.3.2/bin/arm-linux-gcc if you have scratchbox installed. Get the avs_kernel.out from your 770 The dynamically loaded DSP modules are linked against a dummy kernel object generated from the actual kernel. The DSP kernel is in /etc/dsp directory. Just copy it to your host and adjust dspgw-3.3-dsp/apps/demo_mod/Makefile to use the 770 avs_kernel.out to generate the dummy_kernel.obj instead of using the default tinkernel.out. Now you should be able to build the DSP side of the demo console with simple make. 4. Install demo_console In order to make the DSP gateway dynamic loader to load the DSP side of the demo, we need to add a line to the /etc/dsp/dsp_dld_avs.conf file. So e.g. # cp -i /media/mmc1/demo_console.o /etc/dsp/modules # echo "demo_console _task_demo_console 1 /etc/dsp/modules/demo_console.o" \ >> /etc/dsp/dsp_dld_avs.conf I was not able to restart the DSP gateway dynamic loader (there is an init script for dld) so I just rebooted my 770. After boot there should be a /dev/dsptask/demo_console if the dld managed to load the module. Now just run the arm side demo_console. You should see some praise :-) 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. 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 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. 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 I didn't add the name of any cmd files to the last column in the conf file (though this is shown in the pdf instructions), mainly because it said it's optional, and because I didn't have one (or the source for one, etc.). I need to clarify just how these are optional, and what they achieve when they are listed in the conf file. Possibly overrides to the settings in the module itself? You'll then want to run "dsp_dld" to reload the module list, but this will complain that it can't find the conf file: Nokia-N800-10:~# dsp_dld sending SIGBUS signal to all task users... killing pid 832. killing pid 827. killing pid 1582. Can't open /lib/dsp/dsp_dld.conf So you need to create a symlink from the actual file dsp_dld_avs.conf, to the one it expects dsp_dld.conf (both in the /lib/dsp/ directory). Then try again and you'll see something like this: Nokia-N800-10:~# dsp_dld sending SIGBUS signal to all task users... killing pid 4234. killing pid 4236. killing pid 4235. mapping external memory: adr = 0x028000, size = 0x1000 mapping external memory: adr = 0x100000, size = 0x200000 mapping external memory: adr = 0x400000, size = 0x180000 detected binary version 3.3.0.0 setting DSP reset vector to 0x10389e releasing DSP reset DSP configuration ... succeeded. Then run the ARM-side binaries and see results. E.g.: Nokia-N800-10:~# ./test7 32 bytes written 32 bytes read Aaaaabbbbbcccccdddddeeeeefffffgg If you see a message like this: Nokia-N800-10:~# ./demo_console open: No such file or directory It means you've either not added the module to the /lib/dsp/dsp_dld_avs.conf file, or you've not run dsp_dld to refresh the DSP. I also built the demo_fb demo, but couldn't get it to do anything as I couldn't share the framebuffer. Using "dspctl fbexport" produces an error (better than the resets of old), and there's no /proc/dsp/ or /sys/devices/platform/dsp/mmu or mem entries to look at anymore to see whether my choice of address is wrong. Obviously something's changed. There are also no longer any dsp tasks that access the framebuffer. Perhaps this functionality has been disabled? Anyway, the fact the demos work means that people can now happily experiment with the DSP. It would be nice if Nokia could release a header file for any sound related functions contained in the avs_kernel, so that we can link into those rather than having to fiddle about and re-write a codec for the audio hardware (though there is a demo on the Ti website that might be a good start - DSP OGG sink on the DSP anyone?). Is this possible (releasing the header file) - it may not be if this code belongs to a subcontractor, could we know one way or the other? 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. Steps forward ------------- Trying to get audio out - Don't think it's possible to add in a new mini-driver without re-compiling the DSP kernel (avs_kernel.out) - reference to comment about registering the driver. Disassemble pcm2.o DSP module. Look at the following documents: spru374g - DSP assembly code memonics spru281f - c/c++ calling conventionsspru371f - cpu/register info Things wanted ------------- Header file (and if possible example code snippets) for interface to audio driver I.e. functions: _EAP_CC_Mute _EAP_CC_RemoveStream _EAP_CC_RequestStream _EAP_CC_SetPanning _EAP_CC_SetVolume _EAP_CC_UnMute _EAP_clock _EAP_getTicks