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

[freqmod]

@funman: I am using sansa clip v1. (which also has corruption in the file buffering)

[funman]

Hey pals!

I know it's not Christmas but I have some presents for you:
Take this ata transfers fix and this stable mp3 decoding

Now if you can make your sansa crash please tell me how

Next steps:

• USB (any volunteer?)
• MMU / caching & buffering (in progress thanks to flyndice!)
• Recording (I have some trouble with this, it seems to crash even with empty stubs in pcm-as3525.c
• mpegplayer (lcd performance functions) : i'll try to do that for the fuze
• Keymaps work, doc

[wpyh]

@funman: Ogg (Vorbis) and MP3 playback works fine on my 8GB Fuze now. I think you should specify that one has to clean up the build directory before trying out your patch :p

[Hillshum]

Isn't it good advice to do that anyway?

[sko]

Isn't it good advice to do that anyway?

I think so, too.

btw (not very important now I think):
After I noticed that mp3 is working really good with funmans patch, I tried to play a movie (elephantsdream-q6-224x128-354kbps.mpg from the MPEGPlugin wiki-page): sound is working, but no picture, thats much better than before: there were just reboots if I tried to play it.

[cyclon1978]

with both patches i have on e280v2 mp3 playback - great, ogg playback - great, video playback: sound without picture

Thanks!

Andreas

[freqmod]

@funman, well it does not crash, but my clipv1 stops playing when a track  if you shuffle a bit, and the let a track  play about a minutte after the lcd display has been turned of, then it displays (root), (root) and wont play anthing before playback is stopped (i.e. the square icon appears)  (when the disk alignment patch is applyed to rockbox SVN). This applies to mp3, but not to  speex (at least it takes much more time).

I did a full new full checkout from svn and made a new build directory to be shure it was no old remains from other patches.

edit: It does not seem like the oled/lcd has anything to do about it, it chashed when the lcd was active tool.

[saratoga]

funman:  I tested both patches and they work nicely.  I say commit as soon as possible.

Performance is still extremely poor for whatever reason.  MP3 takes ~ 145MHz.  I can shave 10MHz off that by putting everything in IRAM, but thats it.  Cache shouldn't hurt us all that badly when running out of IRAM, unless lack of the MMU imposes some other performance penalty (slowing down sequential IRAM access or similar).  Is it possible some driver is doing a lot of busy waiting?

Otherwise, the port seems quite functional. 

[funman]

@freqmod : I'll try using my clip more to see if I can reproduce (the IRAM patch didn't apply to Clipv1 and m200v4 at all by the way)

@sko/cyclon1978 : on the Fuze you need this patch for mpegplayer

@saratoga : I'll try to look in drivers if they do busy waiting and put some yield() here
Perhaps the slowness comes from the fact that we don't declare the SDRAM nor IRAM as cached (via the MMU) ?

[bertrik]

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

[kugel.]

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

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 

[sko]

• 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 

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

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 

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