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

[Xanikseo]

Why on earth would you run the sim in Wine? It compiles just fine for linux.

I don't have to compile anything if I download the windows binary . I know this goes against the grain , but it was late and I didn't want to read any instructions .

[funman]

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.

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

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.

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 ! 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: [Select]

Data abort
at 300506D8
FSR 0x8
(domain 0, fault 8)
address 0xEBE4300F

EDIT: Cannot reproduce this crashing if I disable crossfade.

[funman]

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

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 . Baffling as this shouldn't have anything to do with cpu boosting...

[ubbut]

@Xanikseo
I a experienced the same problem (clip+ crashes at the end of a track) and currently i have to wait until the battery is low the boot again.

Is there any possibility to reset the device?

edit: ok just got it: you have to hold the power button very very long (i only tried to hold it very long)

thx

I will also test the new patch and see if it still crashes

[ssorgatem]

Has anyone tested rockbox for the fuzev2 built with the eabi toolchain? I'm currently running it, and it works great!  (in previous revisions it wouldn't even boot).

So far, I haven't had any issue I wouldn't have had with a "normal" build.

PD: is doom working for anyone?

[mc2739]

Has anyone tested rockbox for the fuzev2 built with the eabi toolchain? I'm currently running it, and it works great!  (in previous revisions it wouldn't even boot).

So far, I haven't had any issue I wouldn't have had with a "normal" build.

PD: is doom working for anyone?

Doom is known to have problems when using the eabi toolchain.

[ssorgatem]

True, with non-eabi doom.rock it works (in a eabi-built rockbox)

[funman]

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"

Doesn't work


With FS#11257 recording should work fine (only tested on Clip+ so far)

[torne]

True, with non-eabi doom.rock it works (in a eabi-built rockbox)

Doing that is rather dodgy and it's a miracle it works - EABI and the old toolchain are not supposed to be compatible with each other. Doom doesn't work with EABI on *any* device at the moment, it's nothing specific to the sansas.

[ssorgatem]

True, with non-eabi doom.rock it works (in a eabi-built rockbox)

Doing that is rather dodgy and it's a miracle it works - EABI and the old toolchain are not supposed to be compatible with each other. Doom doesn't work with EABI on *any* device at the moment, it's nothing specific to the sansas.

Yes, I know, I was just playing with it 

As far as i've tested, eabi rocks do work in non-eabi rockbox and the other way around, too (I discovered this having two separate builds in my fuze: non-eabi and eabi).

[torne]

This will only work for plugins which don't use plugin api functions that do certain things that differ between EABI and OABI. The complete list is rather esoteric and I'm not sure whether we actually *have* any plugin api functions that fall under that category, so... who knows.

[Xanikseo]

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"

Doesn't work

You mean it doesn't make crashing less frequent? That's a shame... It somehow fixes a new the problem of crashing at the end of tracks though, although it may not fix the root of the problem. I've been using your patch, and it seems quite stable, I find it hard to crash.

[funman]

I have no crashes with SVN so less frequent crashes isn't a solution, unless they are infinitely less frequent (i.e. there are no crashes either)