Re: DSP SBC encoder task

> I only say stepping around gstreamer since the gst way would be to > make one gst plugin for soft and one for dsp codec and let gst choose > one when building a pipeline. ie, they're prepared for multiple > implementations of a given codec. Ah, ok, I'm with you now. Well as you said before, l

Re: DSP SBC encoder task

Hi Chaps, > I have been thinking more about this and I think another approach > could be considered. > > It would be easier to plug your work into everything else if you wrote > it up as a patch to the regular sbc.c so it transparently chooses the > soft or dsp codec at runtime. It would work with

Re: DSP SBC encoder task

>> 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 >> tomorrow)

DSP SBC encoder task

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 tomorrow)

RE: Hello Maemo - CFSONID 2008

> > 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

Re: LinuxTag ticket?

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 acce

RE: SBC DSP task, converting from 8bit to 16bit chars, any spare eyes?

PROTECTED] On Behalf 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

RE: Help with YV12->YUV420 converter

> 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

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 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 a

Re: Help with YV12->YUV420 converter

Hi Buck, > I have not looked at your code, so forgive me if I say something obvious. > > The one thing that bit me was the fact that the DSP/toolchain did not > handle access to data objects larger than 64k, due to 16 bit > restrictions on the DSP. My understanding is that later toolchains > remo

RE: LinuxTag ticket?

> > > 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,

LinuxTag ticket?

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 m

Help with YV12->YUV420 converter

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 so

Re: Let's do something together in LinuxTag

Quoting Frantisek Dufka <[EMAIL PROTECTED]>: > Jose Manrique Lopez de la Fuente wrote: >> Is the irc meeting log available somewhere? >> > Something is here > http://maemo.org/maemo-meeting/maemo-meeting-2008-05-13.html > but it appears to be cut at midnight. I couldn't attend so actually I'm > not

RE: Let's do something together in LinuxTag

> 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

RE: Would like to know the status of (was RE: Corporate ownership ofopen source projects [LWN])

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

Would like to know the status of (was RE: Corporate ownership of open source projects [LWN])

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

RE: Corporate ownership of open source projects [LWN]

> 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

RE: Corporate ownership of open source projects [LWN]

> > 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

RE: kernel patches, Re: DSP framebuffer access on N8x0

> 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 pr

DSP framebuffer access on N8x0

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 https://bugs.ma

RE: [RFC] Maemo package guidelines: mandatory categories

> > user/accessoriesAccessories > > user/communication Communication > > user/games Games > > user/multimedia Multimedia > > user/office Office > > user/other Other > > user/programmingProgramming > > user/supportSupport > > user/themes Themes

RE: Let's do something together in LinuxTag

> Hi Neils, Oops, sorry Niels. Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers

RE: Let's do something together in LinuxTag

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 maemo-

Re: Let's do something together in LinuxTag

> > 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 > > havin

RE: DSP framebuffer access

> > 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

Re: N810 AGPS?

>> 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 pr

N810 AGPS?

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. We could do AGPS LTO (Long term orbit) for example ove

Re: Using available DSP tasks

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 t

Re: Frequencies scaling with OS2008

> 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 > mor

Re: Using available DSP tasks

> 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

Re: Frequencies scaling with OS2008

>> 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 u

Re: Using available DSP tasks

> 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 > bandwi

Re: RE: RE: Java acceleration/Jazelle

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 stumbl

RE: Working source package/compilation instructions for dsp_dld?

> 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 "osso-ds

Working source package/compilation instructions for dsp_dld?

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. Unf

Re: PowerVR

> 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 conn

PowerVR

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=6123&navigationId=12700&contentId=27458 Specifically: OpenSource

Re: TI frees its DSP toolchain for open source apps (?) - linuxdevices

>> 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 >> (ex

Re: TI frees its DSP toolchain for open source apps (?) - linuxdevices

>> 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, ex

RE: Help getting round compiler a error (compiling CLN)

Thank you both for your ideas, > > Duplicate symbols during linking is normally cause by > having code/functions > > with the same name in to different object files. This could > again be caused > > in general having problems with code in headers or wrong > includes, like for > > example hav

Help getting round compiler a error (compiling CLN)

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

Re: extras: autobuilders

>>> - 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 p

Re: extras: autobuilders

> 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

Re: Repositories mess: conclusions and actions

>> I still think the "assume it works unless people complain" would be the best >> method, but if your rating app could also track dependencies that would > > I'm not against it personally, it is Nokia that stress the Quality aspect. I > can understand this, since the Extras Repository is somethin

RE: Repositories mess: conclusions and actions

> 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 applicatio

RE: Repositories mess: conclusions and actions

> 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 l

Re: ARM MMU questions

>> 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: > 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 w

RE: ARM MMU questions

> 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 byte

Re: ARM MMU questions

>> (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 necess

RE: ARM MMU questions

> > 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 buff

ARM MMU questions

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 f

Re: Audio in on N800 and N810

> 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

Re: DSP framebuffer access

> 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

DSP framebuffer access

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. I

Re: Developing for maemo...

> 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

Re: [maemo-developers] More missing source

>> * 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 ___ mae

RE: Ideas for Diablo and Elephanta: OpenEmbedded

> > 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. >

RE: Ideas for Diablo and Elephanta: OpenEmbedded

> >> 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 matc

Re: DSP vs. ARM endianness and 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 f

DSP vs. ARM endianness and struct packing

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 m

RE: DSP vs. ARM endianness and struct packing

> 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 shoul

Re: DSME code?

>>> 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

Re: DSME code?

>>> 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

Re: DSME code?

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 ques

Re: Ogg vorbis/tremor dsp task questions

>> 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. > Unfortunately I

ARM/DSP power consumption

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 o

Ogg vorbis/tremor dsp task questions

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

DSP Programming: Using shared memory

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). It's

RE: RE: Java acceleration/Jazelle

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: > Here you can see the size and alignment of the java instructions. > (the entire document is >

Re: Proof of concept G.711 dsptask

> 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: http://focus.ti.com/docs/toolsw/f

Re: Proof of concept G.711 dsptask

>> > 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

Proof of concept G.711 dsptask

Hello all, I've created a quick proof of concept dsp task that should perform pcm->ulaw encoding. I say should as I've only quickly inspected the first few hundred bytes of the each file using a hexeditor so there might be discrepancies later on. Code and instructions here: http://people.bath

RE: Java acceleration/Jazelle

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 pa

Re: Java acceleration/Jazelle

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 is

Re: Java acceleration/Jazelle

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,

RE: Java acceleration/Jazelle

> >> The second thought is learn the ABI convention for calling C methods > >> from assembly and you can pass whatever data you need to a function > >> that will do the printing for you. I'd suggest going with this route > >> since it will be the most straightforward without soldering but also > >

RE: Java acceleration/Jazelle

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 > conn

Re: Java acceleration/Jazelle

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 ha

Re: Java acceleration/Jazelle

>>> 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 >> wor

Re: Java acceleration/Jazelle

> 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 maemo-developers@mae

Re: Java acceleration/Jazelle

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 (o

Re: Java acceleration/Jazelle

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

RE: Java acceleration/Jazelle

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

Re: Java acceleration/Jazelle

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

RE: Java acceleration/Jazelle

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

RE: Wish list request for DSP EAP_* function header/information

tarted looking at this yet. Thanks, 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 head

Re: Java acceleration/Jazelle

>> 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 >> handle

Java acceleration/Jazelle

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

RE: 3d chipset...

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 200

Wish list request for DSP EAP_* function header/information

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 be

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-

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 aft

RE: Wishlist (was:Re: N800 and USB host mode)

> > 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 suppor

RE: Help debugging segfaults

> > 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. :) > Hint "std::string::compare ()" > Hint "std::operator< " > > I'd start h

RE: Help debugging segfaults

> 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 be: > - /usr/lib/

Help debugging segfaults

Hello everyone, I don't have much experience debugging segfaults and would appreciate any pointers. I've compiled giac/xcas for the N800, but get a segfault when I try to run it (icas is the command line version). The gdb output is as follows:

RE: [maemo-developers] Multiple Choice Response Form (Re: How tolearn DSP development for N800?)

> 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

RE: [maemo-developers] Speed test with vfp (floating point) on N800

> > > 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. > Duh, I was looking at the wrong results from > http

RE: [maemo-developers] Speed test with vfp (floating point) on N800

> 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

<    1   2   3   >