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

[From: Simon Pickering]

Not sure whether anyone is particularly interested in this stuff, but here
goes.

> After building the dsp side of the demos (demo_console or demo_fb), 
> the next step should be to run coff_unresolve on the resultant .out 
> file, to remove the dummy kernel, which has been linked in. So 
> something like the following:
> 
> # create the dummy kernel
> gen_dummy_kernel avs_kernel.out -o avs_kernel.obj
> 
> # Run make for the dsp demo in question # (compiles source and 
> statically links in # the avs_kernel.obj dummy kernel) make
> 
> # remove the dummy kernel
> coff_unresolve -s .tinkernel demo_console.out
> 
> Unfortunately, the code produced using this technique doesn't run. It 
> results in the eventual error message:
> 
> open: Device or resource busy
> 
> This is the same message as is received if you actually forget to run 
> coff_unresolve on the demo_console.out dsp task.
> 
> What does work, however, is simply renaming the unlinked 
> demo_console.obj file and placing that in the /lib/dsp/modules/ 
> directory.

I've tried this with the hellotimer demo from the dsp_dld_spec13.pdf
document. I think I've narrowed my issues down to the particular memory
region I'm trying to use (i.e. it overlaps with something already there), as
well as the slight confusion about which .cmd file it reads its memory
location from.

In the case of the hellotimer demo, the linking stage is required as
otherwise there's no way to get the memory location information into the
task. The plain demo_console presumably doesn't use local variables so
doesn't need this information and can run from an unlinked object file. My
previous problems may have been caused by my trying to give it a memory
address that I'd not mapped, and that I couldn't map as it overlapped.

I get the following output from the linked hellotimer task:

# ./hellotimer 5
Cannot open /dev/dsptask/hellotimer

# dspctl start hellotimer.out
Loading hellotimer.out...
.text : adr = 0x800000, size= 331 ...initialization failed!!
Can't determine reset vector address

This is a bit confusing as in the hellotimer.cmd file the MEMORY section
states:

MEMORY {
EXRAM_HELLO: origin = 0x30000, len = 0x1000 } SECTIONS { .text {} >
EXRAM_HELLO }

But the output of "dspctl start" seems to indicate that it's trying to place
it at the ROM location (as specified in the dummy.cmd file, which is also
linked in - I'll try removing this to see if it helps):

MEMORY {
RAM: origin = 0x000000, len = 0x800000
ROM: origin = 0x800000, len = 0x800000
}

(note the sections must be named with MEMORY in capitals otherwise it gets
confused, this is not the case in the .pdf file).

I think this address is already used (perhaps by the DSP ROM mapping, though
that may not actually be the case for the 770) and so if I do as the FAQ
suggests (http://dspgateway.sourceforge.net/pub/index.php?Page=FAQ#Q7) and
map some memory at this address (using "dspctl exmap 800000 100000" for
example), the dsp decides it's had enough and causes a reset. 

One addition point for anyone compiling these examples is that the clk.a55l
library specified in the Makefile is not present in the Linux Ti toolchain.
I'm guessing that this is a packaging error (as the header file exists) and
will contact Ti to query this omission (it's already in the avs_kernel.out
so I'm hoping it won't make any difference as I hope I won't need to link in
the additional libraries in this case). I also note that the Makefile
specifies the libraries with an 'l' (little 'L') on the end (meaning large
memory model), while in a case-sensitive Linux filesystem they actually
appear with 'L' (large 'L') so the Makefile won't find them.

Time to look at "dmesg" and "/sys/device/platform/dsp/mmu" to see if I can
work out whether my memory location is at fault.

Cheers,


Simon