RE: [maemo-developers] DSP programming
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 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. 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 = 0x10, size = 0x20 mapping external memory: adr = 0x40, size = 0x18 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 Abcdefgg 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
Re: [maemo-developers] DSP programming
On 5/11/07, Simon Pickering [EMAIL PROTECTED] 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 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] DSP programming
Thanks for your thoughts about the IVA, over lunch I did some more googling and found a couple of non-authoritative posts about it. Looks like it might be a separate processor like the DSP, with its own kernel (not sure whether this is changeable). See: http://linux.omap.com/pipermail/linux-omap-open-source/2007-April/009494.html And: http://www.learn4good.com/jobs/language/english/search_resumes/computer/macedoni a/cv/108935/ (scroll down search for IVA) Still no idea where these people got their information from. Interestingly, I'd expected the Ti supplied kernel source to have more stuff related to the IVA in it, but there's not much at all other than some power management and clock setting code. I've not searched in it for the DSP, perhaps the kernel is relatively bare in terms of these peripherals, leaving that up to whomever decides to use it with Linux. 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. This is a good point and needs some testing. If the data are only sent one way (e.g. sound data processed then output directly) then this is not a major issue, depending on the rate at which it's processed vs. memory vs. transfer speed, etc., but if it's bi-directional then I agree, it might not be very useful. We'll have to test and see :) Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] DSP programming
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 = 0x80, 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 = 0x3, 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 = 0x00, len = 0x80
ROM: origin = 0x80, len = 0x80
}
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 = 0x01, size=0
.bss: adr = 0x01, size= 44 ... initialized.
.const : adr = 0x00024c, size= 126 ... initialized.
warning: found zero-sized cinit entry at 0x22
.cinit : adr = 0x00, size= 36 ... .bss variables are
initialized.
setting DSP reset vector to 0x00
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 0x00 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).
Cheers,
Simon
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
spam.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] DSP programming
I've been trying to get started with DSP programming, following the instructions summarised in this post. I just took a brief look at what is required for programming for the DSP in the 770. It seems that building your own modules is possible with publically awailable tools and documents. At least I got the demo_console from DSP gateway loaded and it seems to run OK. The following is what I did. Someone might be interested in testing the instructions and maybe polish these into a proper HOWTO to the maemo wiki. snip 3. 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. 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. Have other people seen this problem? Has anyone else tried? I'd specifically like to work out whether it's me making a mistake with coff_unresolve (as this step will certainly be necessary for dsp tasks which are built using more than one source file, as these can't be linked together without the dummy kernel (avs_kernel.obj)). Thanks, Simon P.S. The above steps are documented in the dsp_dld_spec13.pdf file from dspgateway, in Chapter 5., Building a DSP dynamic task module. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] DSP programming
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. 'killall dsp_dld' will also work without having to reboot. The dsme daemon will restart dsp_dld automagically. Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
