This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#11297 - as3525v2: set_cpu_frequency
Attached to Project:
Rockbox
Opened by Rafaël Carré (funman) - Thursday, 20 May 2010, 00:16 GMT+2
Last edited by sideral (sideral) - Friday, 06 May 2011, 10:16 GMT+2
Opened by Rafaël Carré (funman) - Thursday, 20 May 2010, 00:16 GMT+2
Last edited by sideral (sideral) - Friday, 06 May 2011, 10:16 GMT+2
|
DetailsThis 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 
as3525v2-cpufreq.diff
(3 KiB)
b/firmware/export/config/sansaclipplus.h | 2 +- b/firmware/export/config/sansaclipv2.h | 2 +- b/firmware/export/config/sansafuzev2.h | 2 +- b/firmware/target/arm/as3525/system-as3525.c | 15 +++++++++++---- 4 files changed, 14 insertions(+), 7 deletions(-) |
This task depends upon
Updated patch: use &CGU_PROC in the asm instead of CGU_PROC.
Apparently the asm wrote to *(CGU_PROC) , which was *(void*)(0x00000001), so it just erased the reset / undef instruction and software interrupt vectors
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
Also cache CGU_PERI value without divider.
Clipv2/+: 20/24/40/48MHz
Fuzev2 : 20/30/40MHz
Data abort
at 3004A31C
FSR 0x8
(domain 0, fault 8)
address 0xE12FFFA6
(clip v2)
This patch adds back the delays removed in r25753
Suggested by kugel: use 40MHz pclk on Clips too
But I have artefacts during navigation (clicking/whirring sound) also.
The patch does not fixed this issue.
-------------------------------------------------------------------------------
Clip+ (firmware, bootloader and mkamsboot from r26200)
- Correct the 24MHz Clip table : PCLK would go as low as 12MHz.
Now it goes: 20, 24, 40MHz
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 ??
- 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
(i'm pretty certain i started the plugin but i can't be 100% sure :0 )
FSR 0x8
(domain 0, fault 8)
address 0xE59FE070
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.
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
- the table of dividers is not changed (should work)
- use 24.8MHz PCLK 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
Luca_S have you compared the runtime of SVN versus this patch?
- 15h40 on clipv2
- 16h35 on clip+
I don't understand why dynamic cpufreq reduces battery life.
Plain SVN: 8 hrs 00 min - http://www.pastie.org/1034689
Plain SVN + V11: 8 hrs 20 min - http://www.pastie.org/1034693
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?
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.