• Status Assigned
  • Percent Complete
  • 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 Rafaël Carré - 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

Jack Halpin commented on 2010-05-20 05:28

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

Rafaël Carré commented on 2010-05-20 09:17

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

Marc Hewson commented on 2010-05-20 11:00

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.

Rafaël Carré commented on 2010-05-20 13:11

crashed quickly on Clip+ too (freeze)

Rafaël Carré commented on 2010-05-20 14:04

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

Rafaël Carré commented on 2010-05-20 14:25

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

Rafaël Carré commented on 2010-05-20 15:27

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

Marc Hewson commented on 2010-05-20 15:33

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

Thomas Martitz commented on 2010-05-20 17:38

no freeze after almost 3 hours of playback.

Marc Hewson commented on 2010-05-20 18:02

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)

Rafaël Carré commented on 2010-05-20 18:07

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

This patch adds back the delays removed in r25753

Rafaël Carré commented on 2010-05-20 18:38

clipv2 crashed (screen was off) with this v6 patch

Rafaël Carré commented on 2010-05-20 19:17

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

Suggested by kugel: use 40MHz pclk on Clips too

Sascha E. commented on 2010-05-20 19:55

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)

Rafaël Carré commented on 2010-05-20 21:51

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

Now it goes: 20, 24, 40MHz

Rafaël Carré commented on 2010-05-20 22:08

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

Rafaël Carré commented on 2010-05-20 23:19

v9 crashed on clipv2

Marc Hewson commented on 2010-05-21 07:55

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

Rafaël Carré commented on 2010-05-21 09:53

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

Rafaël Carré commented on 2010-05-21 10:01

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

Marc Hewson commented on 2010-05-21 13:02

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 )

Jack Halpin commented on 2010-05-21 14:51

Clip+ crashed after 31 mins with v10.

Jack Halpin commented on 2010-05-21 19:40

2nd crash with v10 playing ogg off of uSD. Data abort at 3004A628, appears to be in timeout_register looking at my

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

Rafaël Carré commented on 2010-05-21 21:03

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.

Mark Mitchinson commented on 2010-05-21 23:08

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

Rafaël Carré commented on 2010-05-24 10:23

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

Thomas Martitz commented on 2010-05-24 11:10

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

Rafaël Carré commented on 2010-05-24 11:41

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

Luca Leonardo Scorcia commented on 2010-06-19 09:54

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

Rafaël Carré commented on 2010-07-03 18:56

sync to r27257

Rafaël Carré commented on 2010-07-04 18:21

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

Rafaël Carré commented on 2010-07-05 13:28

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

Rafaël Carré commented on 2010-07-05 13:37

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?

Magnus Holmgren commented on 2010-07-05 14:44

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.

Rafaël Carré commented on 2010-07-06 14:08

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

Rafaël Carré commented on 2010-07-06 16:28

- 21h on fuzev2 when boosting forced to 248MHz

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

Thomas Martitz commented on 2010-07-07 06:24

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.

Luca Leonardo Scorcia commented on 2010-07-07 18:09

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 - Plain SVN + V11: 8 hrs 20 min -

sideral commented on 2011-02-18 13:15

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?

Sei Aoyumi commented on 2011-06-03 20:35

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.


Available keyboard shortcuts


Task Details

Task Editing