Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Xanikseo:
--- Quote from: GodEater on May 11, 2010, 06:44:47 AM ---Why on earth would you run the sim in Wine? It compiles just fine for linux.
--- End quote ---
I don't have to compile anything if I download the windows binary ;). I know this goes against the grain :P, but it was late and I didn't want to read any instructions :D.
funman:
--- Quote from: bYOndo on May 11, 2010, 08:30:11 AM ---r25939-100510: my clipv2 seems much more stable now!
I didn't modified anything about cpu boosting, I don't even know how I can do that, so it's just the default settings.
--- End quote ---
Yes boosting/unboosting has been disabled so it defaults to boosted.
It's stable for me, I completed 2 battery_bench cycles on Clip+/Clipv2 (Fuzev2 2nd bench still going).
--- Quote from: bilditup1 on May 11, 2010, 09:20:12 AM ---Time was 15:24. This is 24 minutes shorter than build 25821. I guess this is due to the changes funman made in 25924? I don't know how much, if at all, this was mitigated by saratoga's changes in 25936 to sd-as3525v2.c.
--- End quote ---
Small variations are frequent I think, not necessarily linked to a different revision (Try running 2 benches on the same revision and see if they change).
Current theory on set_cpu_frequency(): instruction caching and/or icache content goes wrong while PCLK is lower than 24MHz (happens for a really short time).
Invalidating the icache before returning seems to help, the crashes are at least less frequent.
If this is the case we need to make sure the code after lowering PCLK and until the icache invalidation (included) is not in the icache.
EDIT: doing it like the OF (increase/decrease the dividers one by one) seems to work too; and the advantage is that we can explain why: "the OF does it"
Xanikseo:
So far the suggested patch (loop) looks more stable than the first patch, funman, unfortunately it results in scrolling to be incredibly slow.
EDIT: Not just scrolling, but everything: most notably backlight fading, volume fading
The first one isn't so stable, I can get crashes quite easily...
(Unrelated) Oh! And playing 48KHz OGGs now works perfectly :D! Great!
I tend to get crashes at the end of tracks though now (introduced sometime between r25956 and r25936)... I suspect the two are related somehow, perhaps the dsp related submissions?
Haha finally, an error message (couldn't see them as backlight was always off)
--- Code: ---Data abort
at 300506D8
FSR 0x8
(domain 0, fault 8)
address 0xEBE4300F
--- End code ---
EDIT: Cannot reproduce this crashing if I disable crossfade.
funman:
--- Quote from: Xanikseo on May 11, 2010, 02:15:16 PM ---So far the suggested patch (loop) looks more stable than the first patch, funman, unfortunately it results in scrolling to be incredibly slow.
EDIT: Not just scrolling, but everything: most notably backlight fading, volume fading
The first one isn't so stable, I can get crashes quite easily...
--- End quote ---
Thanks for testing, I made a mistake in the 2nd patch and updated it.
Xanikseo:
Yes your new loop patch patch seems to have fixed the slowness. For some bizarre reason, there is no more crashing at the end of tracks with or without crossfade, now that I am using your patch :o. Baffling as this shouldn't have anything to do with cpu boosting...
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version