However, the problem for now is how to call into the
avs_kernel to send our decoded audio to the hardware. Since
there is no one at Nokia out there who would be willing to
give me the specifications, I kept on analysing their system.
I took the pcm2.o codec (because it's the simplest
If you want something free, I'd suggest using our speex
codec, which
is technically comparable, completely open, and has no known patent
issues. We don't have an omap dsp implementation, but it has been
ported to the various TI DSPs.
http://speex.org/
-r
I did quite a
As you may recall, I was considering this back in August/September.
I tried a few things, and reported some of my findings to this list.
The code for all that is still available here:
http://qstream.org/~krasic/770/dsp/
snip
2. Try using dsp tasks that already exist on the device
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.
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
I have not measured, but currently OS2007 feels somewhat
slower than 2006.
But this can simply be because currently most binaries are
the same that are used for N800. So, recompiling the whole
stack with different optimizations is likely to give us some
speed bonus... But that may wait
Conclusion:
It works but the cpu load is high. Vorbis decoding takes almost 80%
cpu. I also tried MPlayer 1.0rc1-maemo.8 which has the integer based
Tremor decoder codec [4] nicely integrated. Tremor needs around 12%
cpu for the same ogg file. (That is an expected scale up from the
Hi all,
I was mightily confused that I'd wake my N800 up from its keypad/screen
locked state and find that it was connected. I understand that this is a
feature, and in fact it is quite a useful feature, however there are some
caveats:
This feature is switched on by default - for those who don't
The idea is that N800 is connected all the time to known WLAN
access points so that your VoIP calls actually do come in. If
we go with any of your proposals this will not work, right?
Oh right, I see what you mean now.
You can turn it off from the connectivity settings in the
Connect
The idea is that N800 is connected all the time to known WLAN access
points so that your VoIP calls actually do come in. If we go with any
of your proposals this will not work, right?
Unfortunately, with default setup, you get an empty battery N800 if
you stay at home :
Hi
as far as I can tell the n800 with the OMAP2420 processor has a vfp
(vector floating point unit; see [1] ) Based on this I wanted to find
out if vorbis could take advantage of this unit by default.
To make it short: Yes it works - BUT it is just painful!
[...]
Conclusion:
Well, do you want direct access to DSP or do you want to use just
gstreamer?
I want to learn how to add new codecs to Maemo. So: Yes, I
want direct access to the DSP.
Basically, I'm asking for what Frantisek just described in
his message Maemo roadmap, SDK improvements... to this
2. Reliable information that is detailed enough for performing graphics
and audio output from DSP, see
http://maemo.org/pipermail/maemo-developers/2007-February/007949.html
Again throwing some options in the air
1. Dump DSP. If I remember the driver for the audio chip is
in the omap
I was very interesseted in the floating point copro in the
N800 cpu and did some tests with a progamm which calculates
the mandelbrod set and outputs it via SDL. I put this program
online on bomberman.garage.maemo.org. No installer, you have
to run the benchmarks on xterm or via ssh (so
The whetstone results were a little surprising, in that the vfp code
wasn't orders of magnitude faster than the softvfp code as expected,
however this is probably (as a guess) caused by libm not being compiled
for vfp.
snip
Duh, I was looking at the wrong results from
I did't rest before I got an answer
Thanks
[X] Sorry, not a good idea, we don't want to you to hack
the hardware
and will not provide direct access to the DSP. Please stay at the
application level when developing for Maemo devices.
You can use the information that is available
snip lots of gdb output
To get working backtrace on ARM you need to have either:
- debug symbols, or
- code compiled with -fno-omit-frame-pointer for *every*
binary/library you see in the backtrace, otherwise Gdb
reports bogus information for the backtrace. In this case
the libs would
I don't have much experience debugging segfaults and would appreciate
any pointers.
pun intended? ;-) C pointers and string operations are the
first place to start looking for segmentation faults.
:)
snip lots of gdp output
Hint std::string::compare ()
Hint std::operator char,
Hitting the Wishlist is almost only a matter of writing down
a sensible rationale. You can do it.
(..)
I will put USB host mode in the Wishlist. I plan to
update the roadmap page on Fridays (if we have stuff to update).
Wish #1:
I'd like to request PowerVR chipset support (kernel
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
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:
Hello all,
I've added this as a bug as it says on the Roadmap/wish list page (BUG #1592).
I'd like to add to the wish list my wish for a header file listing the EAP_*
(and any other) functions which wrap the audio codec driver and are contained in
the avs_kernel.out (DSP kernel). It would also
It's all in the archives of the maemo-developer list, try a search for PowerVR.
Could this be added to the wish list (do I need a bug tracker entry too)?
Thanks,
Simon
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Guard][an
Sent: 29 June 2007
Hi all,
Firstly my apologies for starting a new thread, I'm on webmail and the
previous emails are not available to me here to reply to.
Anyway, I was looking at the source code kindly provided in the
presentation by Sebastian Mancke.
I had a look around for some more information and found
The next question is how to implement the undefined instruction
exception handler. Is 0x0004 (or optionally 0x0004) writable (I
need to write some test code really) from a user program? Assuming it
is, then it should be reasonably straightforward to write an exception
handler and to
,
Simon
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Simon Pickering
Sent: 27 June 2007 11:54
To: maemo-developers@maemo.org
Subject: Wish list request for DSP EAP_* function header/information
Hello all,
I've added this as a bug
Hi all,
If this is all already known please let me know and I'll stop waffling,
but some Googling couldn't find anything, so I'll present what I've
found thus far.
I had a look around for some more information and found the patent
for Jazelle: US patent number 7089539.
Google link here
Hi Sebastian,
nice research !!! This seams easier (and more os independent) than my
thoughts with an interrupt in kernel mode. Although we can not say for
sure, that Jazelle is implemented the way, the patent describes, this is
a very good point to get a forthcome.
Thanks. I had also been
Hi all,
Sebastian, in this link:
You can find a small example in my jalimo slides from linuxtag2007
(slide 33ff).
http://www.jalimo.org/wiki/doku.php?id=news:linuxtag2007
(direct link:
http://www.jalimo.org/documents/jalimo-slides_english_linuxtag2007.pdf)
Did you make a typo in your
Not such good news.
I have learned alot about extended inline asm though.
Anyway, my final code is here:
http://people.bath.ac.uk/enpsgp/nokia770/jazelle/jazelle1.c
It's changed a fair bit from my first untested code and should now work
as planned. Unfortunately what happens is a segfault. So
Ah, looks like I spoke too soon.
My original branching code seems to have been misguided, hence the segfaults.
New improved code here:
http://people.bath.ac.uk/enpsgp/nokia770/jazelle/jazelle5.c
Now, when I call bxj r12, with r12 pointing to the handler code and r14
pointing to the Java code
New improved code here:
http://people.bath.ac.uk/enpsgp/nokia770/jazelle/jazelle5.c
Sorry, wrong file name, it should be
http://people.bath.ac.uk/enpsgp/nokia770/jazelle/test_jazelle5.c
Simon
___
maemo-developers mailing list
Did you make a typo in your declaration (on p34) of int code[]? Should
this not be unsigned char code[] as bytecodes are 1x byte not n x byte
long (I'm assuming you're running on a machine with sizeof(int)1)?
This is not a typo. I don't understand the reason, but it had only
worked with the
Hi Scott ( all),
The following describes an experiment I suggested:
Create an array with opcodes 204 to 255 in it. Create one handler for
all opcodes.
Set up R14 to point to opcode 204.
Set up R12 to your handler.
Push the address you want to return to onto the stack.
Write your handler
Hi Larry,
A couple thoughts from a former hardware hacker here: first, serial
ports are your friend so if you can find a sacrificial device that has
a cracked screen or some other serious but non- life-threatening
defect you should probably invest in a level-shifter chip and a DB-9
Hi Siarhei,
Does anyone know whether there are there any good docs/books on ARM asm
programming, telling people these sort of things? This is an interesting
(and hopefully useful) learning experience, but can be really frustrating
when I know what I want to do, and pretty much how to, but not
I've adjusted the code I wrote to test Scott Bambrough's suggestion
(see earlier in the thread). The name and URL is still the same:
http://people.bath.ac.uk/enpsgp/nokia770/jazelle/test_jazelle7.c
After the code starts and BXJ R12 is issued, the code does branch to
the handler whose address
Hello all.
My apologies this is going to be a long one...
All the code mentioned in this email can be found under this directory:
http://people.bath.ac.uk/enpsgp/nokia770/jazelle/
After reading the patent I wrote a piece of code to test whether Jazelle works,
as Scott Bambrough suggested. The
I chose something relatively easy to make sure I didn't lose the will
(battling against both the algorithm and the DSP oddities).
Anyway, my hope is that this might show people that it's quite easy to
use the dsp (for something simple at least), and to get people thinking
of other
If anyone has successfully used DSPLIB I'd love to hear about it:
http://focus.ti.com/docs/toolsw/folders/print/sprc121.html
If not, I will give it a try :-)
I've not used it yet but am interested to hear how you get on.
In fact you want this version:
Thank you for the links, these are things I've not seen before.
So let me dump the stuff I turned up so far:
URL: http://www.scratchpost.org/patches/jazelle-disassembly.png
Here you can see the size and alignment of the java instructions.
(the entire document is
Hello all,
I've sat down and worked out how to use shared memory (shared between
the ARM and DSP). Not rocket science (despite my troubles with for
loops ;) ), but it's probably needed for any useful dspsink codecs (as
illustrated by the use of shared memory buffers for Nokia's dspsinks).
Hello all,
Don't get too excited, I'm writing code, I don't have anything working.
I should also add that I need to check about the copyright for some of
the ASM code I'm using before I can release anything very much, so this
is a theoretical discussion more than anything else.
There are some
Hello all,
This is probably a question for Nokia, though someone else may have looked into
it.
Does anyone have figures for the power consumption of combinations of running
the DSP and the ARM? What I'd like to work out is whether the DSP could be used
for any old task (assuming it has the same
Hi Neil,
I happened to come across this commit mailing list:
https://garage.maemo.org/pipermail/dsm-commits/
Is this related to the 770/N800 closed source DSME code at all? It
looks like it might be.
(I have no strong interest in this myself, but I know that from time
to time questions
I happened to come across this commit mailing list:
https://garage.maemo.org/pipermail/dsm-commits/
Is this related to the 770/N800 closed source DSME code at all? It
looks like it might be.
The first post is a large patch containing the entire source from the
looks of it.
Oh, it is
Oh, it is gone. Page not found. I was very interested in that :-(
Still there for me:
https://garage.maemo.org/pipermail/dsm-commits/2006-July/00.html
I can see listinfo here
https://garage.maemo.org/mailman/listinfo/dsm-commits but clicking
DSM-commits Archives link brings me a
Using the following struct on the DSP-side:
typedef struct endian_test_struct {
unsigned long iamulong1;
unsigned int iamuint1;
unsigned int iamuint2;
unsigned long iamulong2;
unsigned int iamuint3;
unsigned long iamulong3;
} endian_test_struct;
I should qualify
Hello all,
In my investigations of whether I can pass structs through shared memory (after
performing endianness swaps), I looked at the precise endianness of the two
processors and struct packing. This may be of use to someone, so I thought I'd
summarise it here.
I'm not sure if struct packing
Right, I've recompiled the arm side test so that it has a structure
with members that are the same size as those tested on the DSP. My
apologies for my earlier mistake.
What happens if you pack the structure as in
typedef struct __attribute__ ((packed)) endian_test_struct {
Thank you for
I would love to see support for OpenEmbedded.
What would need to be changed on the maemo side to support
OpenEmbedded? Aren't you rather asking for maemo support in
OpenEmbedded?
You are right, maybe this is the proper viewpoint.
For maemo 3.2, I could not get a matching
I think that the group developing Mamona are effectively
using a 'native'
OpenEmbedded setup within Scratchbox. I don't know how far
along they are or
whether this is a better approach than cross-compiling with
OpenEmbedded as I'm
not really up to speed with OE any more.
* Meanwhile, would using the su-18 headers do? The hardware should be
the same right?
Answering myself, no, apparently it won't do. The plugins won't
compile with the -su-18 headers.
What header files/defines are you missing?
Simon
___
Thanks, Brad... So, concerning Python/Gtk+... Is that thee best way to
go?
Also, can you (or anyone) suggest any good resources for developing for
maemo (outside of the SDK docs, of course)... And by developing for
maemo, I mean learning the most applicable language, the best IDE to
use,
Just a quick proof of concept for the 770:
http://people.bath.ac.uk/enpsgp/nokia770/dsp/framebuffer_test/
The screen changes colour, though it appears that the screen updates
only happen from time to time so exactly what changes colour, which
colour it turns, and when is a question of luck.
The screen changes colour, though it appears that the screen updates
only happen from time to time so exactly what changes colour, which
colour it turns, and when is a question of luck. I'm not sure how
one should force an update (And perhaps this will have to be from the
ARM side, I
Sampling rates: Is it true, that the N800 just supports 8 KHz sampling
rate with the microphone in? If yes, is it the same with the N810?
The N810 would be nice because of its build in keyboard. The PSK31
software isn't really that usable with a on screen keyboard.
It looks like the N810 has
Hello all,
I'm looking to share the framebuffer between the ARM CPU and DSP and
therefore would like to ask a few questions about the ARM MMU and in
particular TLBs.
When I try mapping the framebuffer the following messages appear in
dmesg:
[10790.375152] omapdsp: 3 frame buffers found. we use
I'm looking to share the framebuffer between the ARM CPU and DSP and
therefore would like to ask a few questions about the ARM MMU and in
particular TLBs.
Most probably it is related to DSP MMU not ARM MMU but I am not sure.
Until now I thought TLB (translation look-aside buffer) is
(i.e. see my shared memory example code I sent to the list
a few weeks ago, which runs on both 770 and N800).
Yes, I've seen it. Please don't stop with such examples :-)
Don't worry, there are more things in the pipeline :)
Yes, that's why it's not mapped, but there shouldn't necessarily
From the pdf it looks like I should be able to map a section of 1
Megabytes and that should use a single TLB on the DSP (and we
know there
are ~6 TLBs available). There's a gap in the N800's memory
space (in the
same location as the 770's FRAMEBUFFER section) which is
0x10 bytes
If I try to name my memory section FRAMEBUFFER (same code, just changing
the name in the command file), I'm back to the original problematic sort
of output:
snip
Well it makes sense this is really a special case since (at least on
770) you don't want to map just any random memory, you want
I think that is the main problem. The discussion is long (and
so are its
single mails), but the number of participants is rather low
(in relation
for example to the number of accounts in garage).
Perhaps a wiki page would be the best method then. This discussion is getting
rather long
Such Wiki Page exists:
http://maemo.org/community/wiki/extrasrepositoryprocessdefinition/
I invite everybody to add, change etc...
Thanks for the pointer, I'd not seen that.
As told, I'm currently writing a program, to allow people to
do rating of
their installed applications
Then there are (probably obvious) things about the detailed operation
of the above points, like automatically emailing the uploader if a
package doesn't build.
If possible, it might make sense for the interface to the auto-builder
to be integrated into garage.
- It feels reasonable to say
- It feels reasonable to say that a project must have a garage page,
in order to use the auto-builder.
What about the myriad libraries that will be added to build all the
random apps we want? Would each of these need a Garage page or could
they all be grouped under the same page? I
Hello all,
At the start of the year I tried to compile CLN
(http://www.ginac.de/CLN/) and although the compilation worked fine,
the linking into a shared library at the end didn't. I asked on the CLN
list and was given a couple of suggestions to fix this issue, the last
of which was to change
FYI: Just found this news from TI about freeing the DSP toolchain to open
source developers,
http://www.linuxdevices.com/news/NS4338556106.html
http://open.neurostechnology.com/node/1020
I'm not all together sure how this (the Google SoC project) differs
from the dspgateway, except
We do already have a Linux Ti toolchain (
https://www-a.ti.com/downloads/sds_support/targetcontent/LinuxDspTools/index.html)
which is for the C55x only (i.e. is useful to us). I'm not sure the release
of another (similar afaict) toolchain for the C54x will make any odds to us
(except
Hello all,
As some of you may know there's a 2.6.x package of binaries available
from Ti for the OMAP2430 (the link for the OMAP2420 re-directs to these
files).
http://focus.ti.com/general/docs/wtbu/wtbugencontent.tsp?templateId=6123navigationId=12700contentId=27458
Specifically:
OpenSource
After doing this the kernel module can be modprobed (move it to
/lib/modules/`uname -r'/) and it creates sysfs entries. I think there
should be a /dev entry created, I have to look into the name and
numbers and see if I need to create it myself (it may be that the
driver waits for a
Hi all,
I tried compiling dsp_dld (the DSP dynamic loader daemon) from the
source in dspgw-3.3-arm.tar.bz2
(http://prdownloads.sourceforge.net/dspgateway/dspgw-3.3-arm.tar.bz2?download).
This is the correct version of the code as reported by dsp_dld -v on
my N800 running OS2008 beta.
I hope we can just get a source package added to the repo, but if
that's not possible (or might take a while), I'd be happy with some
advice as to how to get it to compile and work.
Thanks to felipec on irc for pointing out that this is actually already in
the repo and is called
Good to see some interest in this still :)
Do we need to set some bit to enable Jazelle?
No, the ARM people like to have special instructions to change
processor modes, like ENTERX or BXJ or the like. (I think. :))
No, we do have to explicitly setup Jazelle mode (IMHO).
I stumbled upon
If the DSP in not the limitation, then the N800 could be used for a
funny project I have now in my head. I there any documentation on how to
program a Linux application to use some existing DSP tasks available
on the N800? I am interesting about the MP3 decoder and a pair of low
bandwidth
It is interesting if it is possible to lock ARM/DSP frequency at 400/166
instead of 330/220 when playing video. That would probably improve
built-in player performance on some heavy bitrate/resolution videos.
Would this be possible then? What knocks the CPU speed down when the
DSP is used
Thanks for your explanation.
np
After having read the basic Gstreamer documentation, I understand
better the sink pad concept of the mp3 task. In the application I am
thinking about now, I don't need to look at the raw audio data decoded
by the MP3 task as long as I can mix with it an
As ARM core is quite fast in N8x0, probably it would make sense to try
keeping DSP out of the way whenever possible (restrict it to 133MHz only,
keep DSP tasks which are fast enough to run at this frequency, port
all the other DSP tasks to ARM)? That is unless improvements to support
more
Quoting Daniel Charles [EMAIL PROTECTED]:
See the merged pipeline below
Yes, this is certainly doable already. I don't have any G7.11 data to
hand, but have tried it by mixing ogg and mp3 data (ogg using Tuomas
Kulve's gstreamer plugin which uses the pcm dsp sink).
E.g. These two commands
Just wondering if AGPS is enabled, or could be enabled on the N810. We
have a chip which supports it (Ti NaviLink GPS5300). The question
(mainly aimed at Nokians) is whether or not they can release a bit
more info to make this possible.
Interestingly, Skyhook Wireless - who have provided
The screen changes colour, though it appears that the
screen updates
only happen from time to time so exactly what changes colour, which
colour it turns, and when is a question of luck. I'm not sure how
one should force an update (And perhaps this will have to
be from the
ARM
I'm a bit surprised about the weak feedback. I was (perhaps too
optimistically) expecting getting lots of names and having
to triage.
Instead, it looks like we are going to think ourselves who it makes
sense to invite to LinuxTag (travel, accommodation, session, why not
having a maemo
Hi Neils,
I have a wedding to go to on the weekend the conference finishes.
The maemo related slots are all on Thursday, so you should
have plenty of
time to get back :)
That's good news, thanks :)
___
maemo-developers mailing list
user/accessoriesAccessories
user/communication Communication
user/games Games
user/multimedia Multimedia
user/office Office
user/other Other
user/programmingProgramming
user/supportSupport
user/themes Themes
user/tools
Hi all,
Just a quick heads up to say that it is now possible to access the
framebuffer from the DSP on the N8x0 devices in the same way as is possible
on the 770.
This requires two things, a kernel patch, and adding a FRAMEBUFFER section
to the /lib/dsp/avs_kernelcfg.cmd file. See
Nice. I've been thinking about garage project named kernel-hacks or
something, that would accumulate interesting kernel patches and even
have some pre-built kernels with those patches applied.
I'm all for this, in fact I was wondering whether I'd be allowed to create a
generic DSP-hacks
A possible interim solution is to use one like nVidia has used for years
for their closed video card drivers. Provide a binary object that
implements all the core functionality of the chip, with a public API.
Then have an open source kernel module wrapper that calls the funcions
in
About silence, in fact a lot of it has not to do with confidentiality
but lack of priority (or too many top priorities in the hands
of us able
to respond).
Sounds promising :)
What about a short term plan with common objectives:
- Raise in a structured way the topics that matter to
Hi Dave,
Let's use this list as a template, then. Can people identify very
specific things (and please, assume I don't know what the
acronyms mean,
and don't know the history behind the issues ;) and I'll get
started on
a wiki page?
Okay, I'll get started then:
1. DSP SBC task - In the
Hi Johan,
On May 7, 2008, at 14:18, Simon Pickering wrote:
1. DSP SBC task - In the roadmap there used to be (what I
interpreted as)
mention of implementing a DSP task to handle encoding audio
for A2DP
use
(where A2DP stands for Advanced Audio Distribution Protocol
I have been thinking about what to present at linuxtag. I can not easely
make a choice right now because we are lacking some form of grand goal.
Can we try to elaborate on the topics? perhaps also have an irc meeting
between linuxtag contributors?
Sounds useful, what about after the IRC
Hello everyone,
I've been hacking together a YV12 to YUV420 converter to run on the DSP. I
have running code, but there are some artefacts on the screen. I was hoping
that some of you with more experience of video stuff might spot an obvious
error.
If you want to run the code, you need to make
Hi all,
Just a quick question. Do presenters need to buy a ticket or do they get in
free as they are presenting? I'm not bothered either way but would like to
know so I can get one in advance and get the discount.
Cheers,
Simon
___
maemo-developers
Just a quick question. Do presenters need to buy a ticket or do they get
in
free as they are presenting? I'm not bothered either way but would like to
know so I can get one in advance and get the discount.
I have the same question - should I take care of a ticket, or do I get
If anyone's bored and fancies looking for some of the mistakes I've no
doubt made converting the BlueZ SBC encoder code to use the DSP's
16bit chars rather than the more normal 8bit chars, please take a look
at the code in the dsp-sbc Garage project and let me know what I've
messed up, or
You can find the code I wrote here:
http://qstream.org/viewvc/trunk/qvid/src/video_out/maemo_dsp_yuv/
A whole bunch of DSP related documents and things I collected
are here:
http://qstream.org/~krasic/770/dsp/
Thanks Buck
I'll take a look.
Cheers,
Simon
Of
Simon Pickering
Sent: 15 May 2008 23:33
To: maemo-developers@maemo.org
Subject: SBC DSP task, converting from 8bit to 16bit chars,
any spare eyes?
If anyone's bored and fancies looking for some of the
mistakes I've no
doubt made converting the BlueZ SBC encoder code to use the DSP's
Hi Michael,
Just a quick question. Do presenters need to buy a ticket or do they get in
free as they are presenting? I'm not bothered either way but would like to
know so I can get one in advance and get the discount.
I just asked the organizers.
Presenters will get free access to
So the answer is no. As long as Maemo's goal is not 'providing a 100%
free platform' as well I[0] will not contribute[1] to it and I expect
that with more and more freedom respecting projects/products you will
have a hard time finding people who do.
This is what I had in mind in my
Hi all,
Just a quick note to say that the DSP task encodes the test .au file
correctly. Still a minor ;) issue that the DSP crashes after the DSP
has finished the encoding task (I think this is probably due to a
non-existent semaphore being written to, will have to test my theory
1 - 100 of 195 matches
Mail list logo
