Rockbox Development > New Ports

SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2

<< < (156/386) > >>

kugel.:

--- Quote from: bertrik on April 10, 2009, 02:07:39 PM ---IIRC from the discussions on IRC, a lot of ARM targets currently use long calls which makes the code slower and bigger. I think one of the most important things we could do with the MMU is to map memory regions such that they are close enough to each other to use short calls, thereby shrinking the code and speeding it up (slightly).

--- End quote ---

Yep, indeed. BTW: The long-call border is 64MB. I.e., if a foo() calls bar() and bar is more than 64MB away. then a long call must be used.

If we can put everything within 64, e.g. by mapping the iram just after the dram, we can get rid of long calls.

helios:
MPEG-3, Ogg Vorbis, and C64 SID files now work nicely with revision 20680 on Sansa e250v2! FLAC already worked with revision 20619 and version 3.2 of rockbox.

FlynDice:
I'm spinning my wheels working on the mmu but plugging away. I can tell you a whole bunch of things that don't work and not one that does.  I think the mmu is actually functioning as several people have reported success mapping memory regions to different locations.  Whenever I try to enable caching however I get a mirror image lcd screen.  I have tried all kinds of combinations of invalidate_cpucache, clean_dcache, clean_dcache_range etc. to no avail.

In my flailing away at the problem I did come up with several questions though:


* It appears we have leftover room in iram, is there a reason not to use it for the stack?
* Do we really need the mmu functioning in the bootloader?  It seems to me it overcomplicates things.
* And , of course now that Funman has mp3 and ogg playing so nicely for me(thanks a ton by the way) how do I stay motivated  :P

sko:

--- Quote from: FlynDice on April 11, 2009, 03:14:09 AM ---
* And , of course now that Funman has mp3 and ogg playing so nicely for me(thanks a ton by the way) how do I stay motivated  :P
--- End quote ---
Well, iiuc the performance would be much better with mmu, 145 MHz for playing mp3 is to much and decreases the runtime I think.

btw: what about FS#9985 (rtc fix) I think it's working good, maybe commit it?

I would also like to say that the work you guys do is really great, many thanks! I hope I will understand it someday :)

EDIT: I made a patch to make menus wrap on e200v2, maybe someone may have a look at it: FS#10127

kugel.:

--- Quote from: FlynDice on April 11, 2009, 03:14:09 AM ---I'm spinning my wheels working on the mmu but plugging away. I can tell you a whole bunch of things that don't work and not one that does.  I think the mmu is actually functioning as several people have reported success mapping memory regions to different locations.  Whenever I try to enable caching however I get a mirror image lcd screen.  I have tried all kinds of combinations of invalidate_cpucache, clean_dcache, clean_dcache_range etc. to no avail.

In my flailing away at the problem I did come up with several questions though:


* It appears we have leftover room in iram, is there a reason not to use it for the stack?
* Do we really need the mmu functioning in the bootloader?  It seems to me it overcomplicates things.
* And , of course now that Funman has mp3 and ogg playing so nicely for me(thanks a ton by the way) how do I stay motivated  :P
--- End quote ---

Please keep up the good work! Have you found a combination which is not so utterly slow?

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version