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
