@Notaz:
You are right, the boot scripts would be the major obstacle. A "boot with 4MB cut for DSP" boot option, with the ability to select that as a default in U-Boot, could solve that issue.
Users that have their own boot scripts hopefully know what they are doing and would need to add the required options themselves. Since they've already figured out how to use custom boot scripts in the first place, that should not be an issue (it's a very simple modification, after all).
After reading that you might have seen something that would allow for such a fixed-address mapping, I took another look at "dma-mapping.h" and "dma-coherent.c". There is a function called "dma_declare_coherent_memory()" which looks like it could be used for this purpose. I tried it out, but it always results in a kernel oops (17) / "kernel NULL pointer dereference at virtual address 00000114". I tried the following: Passing NULL as device pointer (the "workaround" for the dma_alloc_coherent() call), Passing the actual struct device* (c64_device), passing 0 as bus address (does not make much sense, I know). All attempts resulted in a kernel crash.
Like mcobit said, sacrificing the 4 MBytes is probably hardly noticable and it is also the most realistic solution for now (unless someone volunteers to investigate why the kernel call mentioned above crashes and if it is even allowed to be called after the system has started up).
These 4 MBytes would not be lost after all: If the DSP is not used, the memory could still be used for applications, although there would be some special handling required (an extra mmap() call in the app., I could add that to the kernel module so the app. does not require root privileges).
Another idea, which would involve a bit more effort than just sacrificing the DSP memory, would be to use the 4 MBytes for the DSS framebuffers.
I.e. when the memory is needed for the DSP, the whole system would need to be locked, the page entries that refer to the old framebuffer address(es) would need to be updated, the current framebuffer contents would need to be copied to the new (physical) address, and finally the DSS registers would need to be updated accordingly. Again, I'm not sure that's worth the effort for just 4 MBytes.
@mcobit/all:
Regarding DSP codecs: ED told me that they are freely available from TI but cannot be included in the firmware because of patent issues (a well known problem that's not DSP specific). Maybe we could workaround that by adding a feature to the COFF loader (my task) that allows to load single code sections. In the long run, assuming that people will code for the DSP, it might be useful to have a standard/base DSP image in the firmware, which could then be extended by loading additional code sections (i.e. an additional DSP "overlay" image).
The TI codecs, last time I've seen them (but haven't done much with them except verifying that the MP4 codec works alongside the DSP code the company I'm working for created), are standard "XDAIS" algorithms. XDAIS is a rather lightweight interface that allows DSP software to specify their resource requirements (memory blocks, DMA, L1DSRAM, ..) and, in general, offers a "standard" interface to use the algorithm. In order to use an XDAIS algorithm, you have to query its resource requirements, allocate the resources, initialize the algorithm, and then you're ready to call its "process" function (or what it was called).
Since the gstreamer framework is built upon the CodecEngine framework, which is built upon DspLink, and, on the DSP-side, finally XDAIS, I do not think it's possible to use gstreamer (without modifications) with a "c64_tools" DSP image.
Therefore, someone with more intimite knowledge of video codecs and e.g. mplayer/VLC would be required to make this happen.
Regarding example code: The .tar.gz I released yesterday contains an example DSP project that can be openend and build with CodeComposerStudio.
This example project contains two example "components" -- A simple calculator ("demo_calc"), and a memory-checksum component ("demo_checksum").
While that's only a few lines of code, I think this should be enough to give devs an idea how to add their own components.
On the ARM side there is a test application ("c64_tc") which shows how to use aforementioned DSP components.
ah, and another thing: For some reason that I have not figured out, yet, it is necessary to reboot the Pandora when the DSP image has changed (loading the same DSP image multiple times works fine, though). It looks as if the DSP reset code (very similar to what Dsplink does, btw), does not work as expected and maybe the DSP is still executing code while the ARM updates the code sections.
Once I've added the "load overlay" (and "unload") feature to "c64_load", this issue can be worked-around by making sure that the DSP sits in its main dispatch loop while the code memory is being updated. For binary compatibility's sake I will also move the DSP-side component_register() function to its own section that will be located at a fixed size address.
p.s.: sorry for posting such a long message 
