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

From: Simon Pickering S.G.Pickering at bath.ac.uk
Date: Mon Jan 22 19:41:43 EET 2007
> 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:
> 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):
> RAM: origin = 0x000000, len = 0x800000
> ROM: origin = 0x800000, len = 0x800000
> }

Okay, so removing the dummy.cmd file (the linker command file) removes this
issue and I get the following:

Nokia770-39:/home/user# dspctl start hellotimer.out
loading hellotimer.out...
.text           : adr = 0x000100, size=  331  ... initialized.
.data           : adr = 0x010000, size=    0
.bss            : adr = 0x010000, size=   44  ... initialized.
.const          : adr = 0x00024c, size=  126  ... initialized.
warning: found zero-sized cinit entry at 0x22
.cinit          : adr = 0x000000, size=   36   ... .bss variables are
setting DSP reset vector to 0x000000
releasing DSP reset
DSP configuration ... failed
Device or resource busy

Then a lifeguard reset.

So still some issue, but at least the memory thing looks just about okay.
Not sure the reset vector should be 0x000000 though. 

The dsplink examples generally include both the tokliBIOS.cmd and
tokliBIOScfg.cmd linker command files. I think the latter corresponds to the
avs_kernelcfg.cmd file which is found in /lib/dsp/ (and should also
correspond to the stripped down dummy.cmd file, which caused some issues
above, according to one of the dsplink examples). If this is the case, I
wonder why both are needed (as the avs_kernelcfg.cmd file contains all of
the contents of the tokliBIOS.cmd file, just with differing values).
Presumably this would be different had I just built the kernel from the
source code, or perhaps the avs_kernelcfg.cmd file has had everything added
to it for convenience? 

Linking with the avs_kernelcfg.cmd file produces lots of warnings, as I have
to comment out at least the clk.a55L library as it's not present in the Ti
DSP toolchain for Linux (any pointers to a location for this file
appreciated), and other than that, and the fact that coff_unresolve -s
.tinkernel hellotimer.o leaves lots of extra sections behind, the behaviour
is the same as the previous one:

Anyone have any ideas as to what is causing the reset? How can I query the
DSP to find out what's wrong (other than a very quick 'cat
/sys/devices/platform/dsp/err' iirc)? I hope I'm not chasing the wrong thing
here, fiddling about with the avs_kernelcfg.cmd file, and that there's not
something more fundamental (and probably simple) wrong.

Any Ti gurus out there know how much of the avs_kernelcfg.cmd file is
required (or what extra)? I need to read-up on the reset vector.

Another aside, I find it interesting/odd that the demo_console.o file (this
is an unlinked object file) is able to run quite happily when called from
the arm binary, but that it can't be loaded using "dspctl start". 

Nokia770-39:/home/user# dspctl start demo_console.out
loading demo_console.out...
Can't determine reset vector address

When linked it isn't interested (so something wrong with my linking commands
- I'll concentrate solely on this example now to save muddying the waters by
introducing new code). 



P.S. Anyone know how I should contact Ti about the missing library? The
toolchain download page points to the Yahoo omap group (to which I've posted
a question), but the mailing list on that group appears to contain only

More information about the maemo-developers mailing list