Rockbox

  • Status Assigned
  • Percent Complete
    0%
  • Task Type Patches
  • Category Drivers
  • Assigned To No-one
  • Operating System Sansa AMSv2
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by funman - 2010-05-19
Last edited by sideral - 2011-05-06

FS#11297 - as3525v2: set_cpu_frequency

This patch modifies hardware registers for pclk & fclk in one instruction.

I’m currently testing it on Clipv2 to see if it gets rid of crashes

From the View HW page it appears that no frequency changing is actually happening at least for my clip+. I’ve got 926ejs freq at steady 240MHz and PCLK at 24 MHz. I also watched the actual register values and they never change. I tried manually boosting/unboosting and still no change. Also no changes while inserting/removing uSD. The good news is no crashes after 30 mins though….

Indeed it didn’t change, no wonder why it didn’t crash then.

Updated patch: use &CGU_PROC in the asm instead of CGU_PROC.

Apparently the asm wrote to *(CGU_PROC) , which was *(void*)(0×00000001), so it just erased the reset / undef instruction and software interrupt vectors

testing the 2nd patch on my clip v2 and it’s hard locked after 30 minutes or so. i set the back light to stay on and the music just stopped and the screen has frozen. i had to hold power to turn it off.

crashed quickly on Clip+ too (freeze)

Another approach

Use a table of fclk/pclk dividers to ensure PCLK doesn’t go too low / too high

On Clipv2/Clip+ it goes to: 20, 24, 26.66, 40 and 48MHz

I didn’t calculate a table for fuzev2

Added fuzev2 table: pclk goes 20, 24, 30, 40, 48MHz

Use a single table for boosting & unboosting, just change PCLK & FCLK in the reverse order when unboosting.

Also cache CGU_PERI value without divider.

Clipv2/+: 20/24/40/48MHz
Fuzev2 : 20/30/40MHz

i’ve been testing v3 and got the freeze after 45 minutes.

no freeze after almost 3 hours of playback.

i wasn’t sure if there were any functional changes between v3 and v5 but i tried v5 anyway. got this error after 20 minutes or so…

Data abort
at 3004A31C
FSR 0×8 (domain 0, fault 8)
address 0xE12FFFA6

(clip v2)

19:53 < FlynDice> funman: clip + cpu freq patches v 4 & 5 still crash

This patch adds back the delays removed in r25753

clipv2 crashed (screen was off) with this v6 patch

My fuzev2 and kugel’s one didn’t crash so far, unlike my clips.

Suggested by kugel: use 40MHz pclk on Clips too

No freeze after 2 hours (playing flac’s). [patch v5]

But I have artefacts during navigation (clicking/whirring sound) also.
The patch does not fixed this issue.


Clip+ (firmware, bootloader and mkamsboot from r26200)

- Remove the delays
- Correct the 24MHz Clip table : PCLK would go as low as 12MHz.

Now it goes: 20, 24, 40MHz

- Restore the delays

it crashed quickly on Clipv2

So far we have:
- no crash on fuzev2
- v1 / v2 crashing
- v3/v4/v5/v6 crashing on clip (incorrect table)
- v8 crashing on clip (no delay)

- v7 working so far (Clip using 40MHz)
- v9 ??

v9 crashed on clipv2

v7 is working good for me on the clip v2. i left it overnight running a battery bench and it’s still going, around 8 hours in…..

v7 ran overnight just fine on Clips & Fuzev2

- This version disables clk_wait() delay (the function is still there but commented out)
- Run Clip clocks @40MHz just like the Fuzev2

I will check again the clip table of dividers for 24MHz, it’s weird because we stay in the same range than when using 40MHz

The table in v8/v9 (the one in v10 is the same than in v7) is OK: in the same 20-40MHz than the Fuzev2, and goes to 20,24,40MHz

my v7 battery benchmark didn’t complete successfully. i last checked around the 10 hour mark and i went to check it again just now (13 hours-ish) but it was off. turning it back on shows 35% battery left but there’s no trace of the battery_bench.txt file. :(

(i’m pretty certain i started the plugin but i can’t be 100% sure :0 )

Clip+ crashed after 31 mins with v10.

2nd crash with v10 playing ogg off of uSD. Data abort at 3004A628, appears to be in timeout_register looking at my rockbox.map: http://pastie.org/971596.

FSR 0×8 (domain 0, fault 8)
address 0xE59FE070

Can you remove the #if 0 in clk_wait() and see if it crashes?

Clip+/Fuzev2 still playing (off of internal) for ~10 hours, i’ll double check which version went on those when they power off or crash

With other patches I have seen similar messages so I think it’s definitely related to this patch and not µSD.

Haven’t been able to crash fuzev2 with v10. Fiddling with EQ and all, it won’t budge! Great!

With PCLK@40MHz I got 15h15 runtime on Clip+, it’s a bit lower than SVN

That seems strange, I’d expect freq scaling to have a nice effect on the runtime. Where can I find your previous results?

We should compare with PCLK@40MHz without cpufreq scaling to really see the effect.

Btw I think I remembered wrong, r25799 showed 14h20 runtime.

Fuzev2+patch shows 19h07 runtime.

I have a bunch of battery_bench files, I can send them to you if you want

I had the v10 version of the patch applied for a few days on a FuzeV2 without crashes.

sync to r27257

- use 248MHz PLLA
- the table of dividers is not changed (should work)
- use 24.8MHz PCLK on Clipv2/Clip+

This last patch crashed on Clipv2/Clip+

Saratoga, should we use 40MHz instead ?

battery life with PCLK@40MHz + dynamic cpu freq improves a lot anyway compared to PCLK@24MHz + fixed cpu freq

Fuzev2 powered off correctly after 18h15, which is 1h45 less than my last SVN benchmark?

Luca_S have you compared the runtime of SVN versus this patch?

Hm, I’m think this patch is the cause for the slight graphics corruption I get on the main backdrop after having played a track (a short horizontal line of black pixels, a bit to the right and below the center of the screen). This with both v10 and v11 of the patch.

Last patch + boosting forced to 248MHz seemed to work:
- 15h40 on clipv2
- 16h35 on clip+

- 21h on fuzev2 when boosting forced to 248MHz

I don’t understand why dynamic cpufreq reduces battery life.

Back when it was being disabled in svn someone messured 3 or 4 hours reduced runtime (i.e. dynamic boosting gave more runtime). We need more tests to be sure what effect it really has.

I did a couple of accelerated battery benches with my FuzeV2. Default settings, except for backlight set to always on, hold button, a single album looping.

Plain SVN: 8 hrs 00 min - http://www.pastie.org/1034689 Plain SVN + V11: 8 hrs 20 min - http://www.pastie.org/1034693

In a recent IRC discussion, someone suggested that the annoying background noise audible during playback on the ClipV2 (FS#11915) could be related to the CPU frequency.

Did anyone experimenting with the AMSv2-adjustable-CPU-freq patch notice any difference in the amount or nature of the background noise?

What is the current status of this patch? Where should I start if I wanted to experiment with this work?

In my Clip+, the problem is not found in latest patch for the moment.
But I made a patch in it because a response worsened.

Following patch lets a CPU work at full speed during backlight lighting to prevent a response decline of user interface.

This is for Clip+ only for the moment.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing