Rockbox

Tasklist

FS#6095 - pp5020 frequency scaling experiment

Attached to Project: Rockbox
Opened by Adam Gashlin (AdamGashlin) - Saturday, 30 September 2006, 11:47 GMT
Task Type Patches
Category Operating System/Drivers
Status Closed
Assigned To No-one
Operating System iPod 4G Color
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I'm not sure what to make of the results I've been getting, but I figured I should put it up here for review.
This is a patch which attempts to fix the freezes experienced with pp5020 targets when frequency scaling (HAS_ADJSUTABLE_CPU_FREQ) is used. I read out the CPU interrupt enable mask status from 0x60004020 and 0x60004120 before setting the frequency in set_cpu_freequency() and write it back to CPU_INT_EN and CPU_HI_INT_EN at the end of set_cpu_frequency(). Since I started testing this I noticed the following behaviors on my ipod color:

* scrolling through the file listing or changing volume seems a bit sluggish
* prolonged scrolling no longer causes playback to skip (is this normal?)
* I have not yet experienced a freeze (in hours of VBR MP3 playback)
* power consumption seems to be consistent with what would be expected with the CPU only occasionally boosted, but I have not yet done a full test, I will add a comment to this task when I finish the runtime comparison tests.

So just thought I'd get this out there to stimulate discussion, or something, I'd love to have rockbox running stably without halving my battery life.
This task depends upon

Closed by  Paul Louden (darkkone)
Thursday, 01 February 2007, 07:15 GMT
Reason for closing:  Out of Date
Additional comments about closing:  Start a new task with a patch that works without kernel_on_cop or post the fixes merged with kernel_on_cop to that patch so that it can be included when that hits CVS. It can then be revised to \"Proper Processor Use\" instead of just Kernel_On_Cop
Comment by Adam Gashlin (AdamGashlin) - Saturday, 30 September 2006, 12:06 GMT
As it was pointed out to me, the first two issues mentioned involving scrolling are not related to this patch. In fact, I am now waiting for a crash in a clean CVS checkout to see if this entire phenomenon was caused by other changes in CVS.
Comment by Adam Gashlin (AdamGashlin) - Saturday, 30 September 2006, 22:10 GMT
Here's something different I'm trying (since the original patch here has been shown to not work), based on what I've seen in my disassembly of the apple firmware, changes to system_init().
Comment by Adam Gashlin (AdamGashlin) - Sunday, 01 October 2006, 01:30 GMT
Hi, the old one froze, in the spirit of ETERNAL HOPE here's another, with that thingy ((*0x70000024)|=0xc0) in system_init() done at the beginning of set_cpu_frequency().
Comment by Adam Gashlin (AdamGashlin) - Sunday, 01 October 2006, 01:31 GMT
And, incredibly, it managed to freeze 10 seconds after I posted that, after running for two hours.
Comment by Adam Gashlin (AdamGashlin) - Monday, 02 October 2006, 02:44 GMT
Another experiment, moved things around based on my interpretation of what is going on with those crazy register writes. Maybe if we're not reprogramming the PLL all the time... (the theory here is that set_cpu_frequency only does a switch between the 24MHz clock and the full speed clock, when boosted, and only set the full speed clock on system_init).
Comment by Mike Miller (mikeage) - Tuesday, 03 October 2006, 11:35 GMT
I tested your latest patch (cpufreq2.patch) on my 4g grayscale. It ran for about 3 hours, and then crashed.
Comment by Adam Gashlin (AdamGashlin) - Tuesday, 03 October 2006, 13:21 GMT
Thanks for the report, this is the first I've heard of it crashing.
Comment by Adam Gashlin (AdamGashlin) - Tuesday, 03 October 2006, 13:25 GMT
Can you give any more details about what you were running? Did you get the same sort of crash we're used to?
Comment by Mike Miller (mikeage) - Tuesday, 03 October 2006, 14:31 GMT
I was running the nightly from 03/10/2006 with your patch. The iPod just froze, which is what I've been seeing with frequency scaling enabled. I've gotten data aborts a few times, but usually, it just freezes in the middle of a song (different each time, of course).

I have noticed that it appears to occur more often on ogg than mp3.. maybe there's more CPU frequency switching there?

Anything else I should look for?
Comment by Adam Gashlin (AdamGashlin) - Tuesday, 03 October 2006, 14:37 GMT
I'm just trying to get an idea of what I should be trying to get it to crash. I'll run through some OGGs.
Comment by Mike Miller (mikeage) - Tuesday, 03 October 2006, 15:28 GMT
Is there any benefit to building a (D)eveloper version instead of a (N)ormal build?
Comment by Adam Gashlin (AdamGashlin) - Tuesday, 03 October 2006, 15:33 GMT
I don't know of any such benefit, I think that bit of the build script just allows you to enable other stuff.

To keep y'all updated with what I'm currently testing, here's a slightly modified patch. The only possibly important change is it removes the TIMER1 interrupt setting. It also properly reports what frequency is currently being used. Still haven't managed a freeze yet...
Comment by Mike Miller (mikeage) - Tuesday, 03 October 2006, 15:37 GMT
Ok. I'll try cpufreq3.patch now. When I asked about the developer build, I was asking if there's an advantage in terms of logs or anything else... I don't know how the logf works, and I wasn't sure if that kinda thing can be useful for these crashes.

Before your patch, were you getting freezes or data aborts?
Comment by Adam Gashlin (AdamGashlin) - Tuesday, 03 October 2006, 16:39 GMT
I was getting both freezes and data aborts, though more often freezes.
When you enable logf in the build some things will be logged, you can access "dump logf" in the debug menu to dump this to a file. I don't think it is preserved through crashes, though, and I don't think any pertinent information is logged, anyway. Though you could always add some more.
Comment by Mike Miller (mikeage) - Tuesday, 03 October 2006, 17:48 GMT
Sorry to say, but I've had two crashes with your cpufreq3.patch :-/
Comment by Barry Wardell (barrywardell) - Wednesday, 11 October 2006, 19:04 GMT
I've just tested this patch on my H10 and it seems to work quite well so far. It has gone two hours without freezing. In the past my H10 only lasted a couple of minutes before freezing.
Comment by sublimal (sublimal) - Thursday, 12 October 2006, 12:58 GMT
tested cpufreq3.patch on ipod 4g g/s (20061012). I haven't seen a freeze yet, but there were playback issues (buffer related) after about 10-30 mins of continuous playback. System was still useable (navigation was fine). Playback issue couldn't be corrected without a reboot.
Comment by Adam Gashlin (AdamGashlin) - Thursday, 12 October 2006, 15:08 GMT
I have noticed occasional playback issues, channels switched or muted at random, but these seem quite rare. This is on a 4g color, though.
Comment by Phillip Michael (moufsnafa) - Friday, 13 October 2006, 06:49 GMT
I am using cpufreq3.patch on my ipod 4g grayscale. I have played several hours of music with no freezes or data aborts. Without the patch, I could only play a few songs before it froze.
Comment by Matthias Urlichs (smurf) - Friday, 20 October 2006, 04:50 GMT
cpufreq3.patch works for me, too.
Comment by Adam Gashlin (AdamGashlin) - Friday, 20 October 2006, 14:23 GMT
smurf: for what target(s)?
Comment by Matthias Urlichs (smurf) - Saturday, 21 October 2006, 07:58 GMT
sorry for omitting that -- ipod photo.
Comment by Travis Tooke (tdtooke) - Saturday, 21 October 2006, 08:20 GMT
I used this patch with much success on 2006-10-15 for my iPod mini1g. With more recent versions I did experience playback issues. I just added the cpuboosttracker2 patch to the latest from CVS and everything is working again properly for me. I don't know if that patch was a factor or some other change was but I thought I'd mention that in case it might help somebody.
Comment by Mike Miller (mikeage) - Sunday, 22 October 2006, 07:45 GMT
I have (mostly) daily builds with this patch available at http://mikeage.net/content/rockbox/index.php for 4g, mini1g, and color (photo, not video) if anyone wants...
Comment by Adam Gashlin (AdamGashlin) - Sunday, 22 October 2006, 15:28 GMT
Thanks for the builds, Mike.
Have you still had no success using this on your 4g grayscale?
Comment by Mike Miller (mikeage) - Sunday, 22 October 2006, 15:37 GMT
To be honest, I stopped trying after that first attempt. After seeing how many people seemed to be helped, I figured I'll give it another try. As long as I'm making builds for myself, I figured I may as well make them available to others.

Leaving work in ~20 minutes, so that'll be my first hour long test <g>
Comment by Jeremy (shaid) - Monday, 23 October 2006, 02:48 GMT
Well, if it makes you feel better Mike, it doesn't help my 4g greyscale pod either. You're not the only one, I still get crashes. Tested it last night, had 4 of them. Incidently, they were in CBR files, no crashes in the few VBR I played. Doesn't mean anything without more testing, though.
Comment by Mike Miller (mikeage) - Monday, 23 October 2006, 04:42 GMT
Four crashes last night and one data abort.

Three were in CBR MP3, 2 in Ogg Vorbis. I have (almost) no VBR MP3s to test.
Comment by Barry Wardell (barrywardell) - Tuesday, 24 October 2006, 11:33 GMT
Here's my attempt at the whole cpu frequency thing. So far, my H10 has gone for two hours without a crash.
Comment by Phillip Michael (moufsnafa) - Tuesday, 24 October 2006, 20:12 GMT
I tried cpufreq4.patch on my 4g grayscale ipod. It didn't freeze, but the audio channels seemed to randomly switch sides while playing AAC files. I didn't test any other file types.
Comment by Adam Gashlin (AdamGashlin) - Tuesday, 24 October 2006, 21:27 GMT
I'm getting the random switching also, with m4a and mp3. I've very rarely had the same thing happen with cpufreq3.patch, but it seems to happen very frequently with 4.
Comment by Adam Gashlin (AdamGashlin) - Tuesday, 24 October 2006, 22:24 GMT
I removed anything referencing COP_CTRL and CPU_CTRL from set_cpu_frequency in cpufreq4.patch, the switching seems to have gone away. I'll be running this modification for a while to see if it still crashes anyway... (running on a 4g color, btw).
What were those writes were supposed to do?
Comment by Adam Gashlin (AdamGashlin) - Wednesday, 25 October 2006, 01:19 GMT
fwiw, cpufreq5.patch freezes
Comment by Travis Tooke (tdtooke) - Wednesday, 25 October 2006, 03:53 GMT
I haven't had any freezes, but one odd thing that has happened with this one as well as cpufreq3 is that occasionally I will get these odd pauses in playback. They don't last long and tend to clear up followed by hours of perfect play.
Comment by Adam Gashlin (AdamGashlin) - Wednesday, 25 October 2006, 05:04 GMT
I've noted before that dan_a's kernel_on_cop_4 patch prevents freezes, here's a modified version of that patch that doesn't actually try to run anything but a main thread on the COP. I'm going to try paring this down to see quite what it is that helps.
Comment by Adam Gashlin (AdamGashlin) - Wednesday, 25 October 2006, 07:07 GMT
aaand that doesn't boot all the time (though it never when it did succeed in booting). Here's yet another that I'm running now, doesn't start the COP thread (just uses the sleep loop).
Comment by Daniel Ankers (dan_a) - Wednesday, 25 October 2006, 07:08 GMT
Barry: Try redoing your patch with CURRENT_CORE replaced by current_core(). Until the COP work gets integrated, CURRENT_CORE is #defined to be 0.

Adam: One thing that has been reported to me about the kernel_on_cop_4 patch is that the boost count keeps increasing, meaning that frequency scaling doesn't take place. That may be what is preventing freezes.
Comment by Adam Gashlin (AdamGashlin) - Wednesday, 25 October 2006, 07:25 GMT
With the 4-nothread boosting seems to be working properly, at least according to the audio debug screen. The codec is not even attempting to run on the COP.
Comment by Adam Gashlin (AdamGashlin) - Wednesday, 25 October 2006, 17:12 GMT
Well, 4-nothread still freezes (though it took several hours). I'm going back to cpufreq3.
Comment by Stefan Keller (Loki) - Sunday, 05 November 2006, 09:51 GMT
On my 20GB 4G grayscale iPod I'm experiencing random freezes, reboots and data aborts.
With the stock daily build the iPod would freeze or reboot roughly every 30mins when playing MP3s, when playing OGGs it doesn't happen that quick.
I tried cpufreq3-5 and at least with 4 and 5 the crashes got much less frequent.
Finally I tried a combination of 4-nothread and cpufreq5 and this one is playing a mixture of OGGs, CBR and VBR MP3s for 6+ hours now without a crash.

Perhaps some of you want to try this one.
Comment by Adam Gashlin (AdamGashlin) - Monday, 06 November 2006, 01:33 GMT
I'm still getting freezes on my iPod photo with kern_on_cop_nothr_cpufrq5, I guess this demonstrates again that there is some difference between the grayscale and color 4g ipods at work here.
Comment by Stefan Keller (Loki) - Monday, 06 November 2006, 03:19 GMT
Well, I'm getting freezes too. :(
It played fine for more than 6 hours. I switched the iPod off and later this day turned it on and it resumed play. Then it froze after just about an hour of playback.
Comment by Jamie (Scumm_Boy) - Wednesday, 15 November 2006, 07:25 GMT
RE: cpufre3.patch... I've been running the daily builds that Mike has been putting out on my iPod Mini 1g player, and I went from having to reboot every 3 or 4 songs to 3+ hours of continuous playback with no lockups or slowdowns! Thanks!
Comment by William Peters (w1ll14m) - Wednesday, 22 November 2006, 18:19 GMT
Looks nice, I will try to test kern_on_cop_nothr_cpufrq5.diff on my ipod video,
but I have two questions:
Can i still use the create_thread_on_core(COP, thread_name, somethingelse) instead of
create_thread(thread_name, somethingelse) and can I still use the code even the COP is in sleep mode?
I think it will, but i want to know for sure:)

I've patched my custom build with the 'early work on the COP' now I've moved some threads to my COP
and i want to let the Threads stay on the COP, that's wyhy I want to know if I can still use 'create_thread_on_core' :)
Comment by William Peters (w1ll14m) - Monday, 27 November 2006, 17:00 GMT
hmmm it seem's to difficult to patch this one into the daily (20061124) there's to much changed in the source.
And i started patching and stuff since i've first seen rockbox (6 weeks ago) so i don't have enough knownledge to succeed patching. After patching i've got the 'main' thread running on the COP at 10% but when I try to change codec to the COP it won't buffer music any more and crashes a lot, so i've removed the codec thread from the COP back to the main CPU.

I have a build which i made with another patch a few weeks ago, that worked fine. it looks like something has changed in thread.c in the source code since then. I would like to use the COP again, but i don't have much knownledge (yet) is there something i can do to help this patch? Because this is something that has to be in rockbox (I think) and could help the performance of rockbox a lot by balancing the threads between the cores.
Comment by Adam Gashlin (AdamGashlin) - Monday, 27 November 2006, 17:14 GMT
The cop_nothread patches don't actually seem to work for crash prevention, anyway.
Comment by Jason Lyons (bipton) - Sunday, 07 January 2007, 04:47 GMT
I'm not a programmer, I have a grayscale 4g, I read the pp5020 pdf and saw the cpu can run as low as 32mhz or 80mhz.In /firmware/export/system.h the lines define some scalin' stuff I believe.

"#elif defined(CPU_ARM)

/* TODO: Implement set_irq_level and check CPU frequencies */

#define CPUFREQ_DEFAULT_MULT 8
#define CPUFREQ_DEFAULT 24000000
#define CPUFREQ_NORMAL_MULT 20
#define CPUFREQ_NORMAL 60000000
#define CPUFREQ_MAX_MULT 25
#define CPUFREQ_MAX 75000000

It seems that the different frequencies are defined at a multiplier of 3, I changed it to this

#elif defined(CPU_ARM)

/* TODO: Implement set_irq_level and check CPU frequencies */

#define CPUFREQ_DEFAULT_MULT 8
#define CPUFREQ_DEFAULT 32000000
#define CPUFREQ_NORMAL_MULT 14
#define CPUFREQ_NORMAL 56000000
#define CPUFREQ_MAX_MULT 20
#define CPUFREQ_MAX 80000000

It locked up after 2 1/2 songs encoded at 320k MP3, but not like a usual lock up, I was able to unlock it and leave the debug page back to the WPS screen and resume the song from where it stopped.

Comment by Jason Lyons (bipton) - Sunday, 07 January 2007, 08:06 GMT
I've had the ipod playing musepack files for the last 3 1/2 hours now, the player stop playing the audio twice, the wps screen said playing, but no audio. I unplugged my headphones and plugged them back in and the audio continued from where it was, no reboots during the entire time. Tomorrow I will revert the changes and see what happens.
Comment by William Peters (w1ll14m) - Tuesday, 09 January 2007, 18:04 GMT
@Jason Lyons

I've tried this with Current CVS but now my ipod is slower....
I'm Using hardware EQ and Software EQ verry intense, with this patch my music (mp3@320kbps) hangs for a sec with an interval of 5 to 10 seconds with a verry simple WPS

So i was playing with this stuff and got to this:

firmware/export/system.h
/* TODO: Implement set_irq_level and check CPU frequencies */

#define CPUFREQ_DEFAULT_MULT 4
#define CPUFREQ_DEFAULT 12000000
#define CPUFREQ_NORMAL_MULT 15
#define CPUFREQ_NORMAL 45000000
#define CPUFREQ_MAX_MULT 35
#define CPUFREQ_MAX 105000000

what it hink:
#define CPUFREQ_MAX is just for the debug, matybe it has a function i'm not shure.
But when I change the MULT my ipod go's faster,
Example:
I use Soft+Hardware EQ
I use a Simple WPS (Custom Theme)
I used the folowing patches:
Kernel_on_cop_6
Button_press_usb_power (or something like this)
cop_couter
07-full_screen_logo

I moved pcmrec and playlist_cachectrl top COP

This is what I've always used.
since I changed the the MULT options to the settings listed above.
my GUI is running very smooth and fast my audio does not have any timeout's any more.

So my opinion is:
3 Mhz x [MULT] = CPU Frequency
like:
3 Mhz x 35 = 105Mhz

Can anyone else confirm this ?

Regards William
Comment by Jason Lyons (bipton) - Wednesday, 10 January 2007, 06:49 GMT
Can you tarball your patched sources and email them to me please?
Comment by William Peters (w1ll14m) - Wednesday, 10 January 2007, 08:55 GMT
@Jason Lyons

Get patched source here:
http://rockbox.schoorl.nu/rockbox_patched.tgz

Get compiled version here:
http://rockbox.schoorl.nu/rockbox_patched.zip

Get compiled bootloader.bin here:
http://rockbox.schoorl.nu/bootloader.bin

Get compiled bootloader-ipodvideo.ipod here:
http://rockbox.schoorl.nu/bootloader-ipodvideo.ipod

This should get you started...

Please let me know if this works for you :)
Comment by Jason Lyons (bipton) - Wednesday, 10 January 2007, 19:08 GMT
I changed the values to

#define CPUFREQ_DEFAULT_MULT 8
#define CPUFREQ_DEFAULT 32000000
#define CPUFREQ_NORMAL_MULT 10
#define CPUFREQ_NORMAL 40000000
#define CPUFREQ_MAX_MULT 20
#define CPUFREQ_MAX 80000000

I still have weird lockup issues, so I changed the boost counter to "1" under cpu frequency and ran MPc's all day,along with battery bench. Playback was smooth and uninterrupted the whole day, menu scrolling was also smooth, playtime ended up being 6 hours 7 min, which is a couple minutes better than when I had the cpu scaling.
Comment by William Peters (w1ll14m) - Wednesday, 10 January 2007, 20:20 GMT
@Jason Lyons

What happens when you use these settings?

#define CPUFREQ_DEFAULT_MULT 4
#define CPUFREQ_DEFAULT 12000000
#define CPUFREQ_NORMAL_MULT 15
#define CPUFREQ_NORMAL 45000000
#define CPUFREQ_MAX_MULT 35
#define CPUFREQ_MAX 105000000

Setting boost counter to 1 just makes the CPU constant boosting (i think)

Is i've calculated:
i've set 12MHz to default (almost never used)
i've set 45MHz to normal
i've set 105MHz to 'boost mode' (means when ipod has not enough buffer or is to slow for decoding it give's a boost by more CPU Power)

Have you used my rockbox.ipod? maybe it's also fast on your device.

Since I use this customised source,
My UI is faster,
Buffer loads now completely (before because I use soft+hard eq the CPU was to busy (aka 100% (boost))
and could not fill the full buffer.

and navigation is also much faster then usual

Regards,
William
Comment by William Peters (w1ll14m) - Wednesday, 10 January 2007, 20:37 GMT
@Jason Lyons

I had the same problems with your code:
#define CPUFREQ_DEFAULT_MULT 8
#define CPUFREQ_DEFAULT 32000000
#define CPUFREQ_NORMAL_MULT 10
#define CPUFREQ_NORMAL 40000000
#define CPUFREQ_MAX_MULT 20
#define CPUFREQ_MAX 80000000

I think the main reason is the MULT (Multiplier)
this is how i think it works:
ipod core (3MHz)
3MHz X MULT = Frequency
that would be:
3MHz x 25 = 75MHz (Default at boost)
3MHz X 35 = 105MHz

your code:
3MHz X 20 = 60MHz that explains why the music sometimes topped for one second.

I think that the if you set 'CPUFREQ_MAX_MULT' higher than 25 will increase performance.
Also you can check in debug menu --> Biew audio thread
you can see boost ratio, what do you have there?
my boost ratio is between 65% and 75%

I think it's the MULT which makes the difference.

Regards,
William
Comment by Jason Lyons (bipton) - Wednesday, 10 January 2007, 21:01 GMT
where did you get 3Mhz for the core speed? Your build on my ipod 4g doesn't play audio, the codec buffer fills under the debug screen, but that's it, under OS Stacks it shows the codec @ 0% . I'm using the ipod loader 2, would it make a difference if I used the rockbox loader instead? The pdf file for the PP5020 states the CPU's can run at 32Mhz - 80Mhz, I couldn't imagin runnin' it at 105Mhz would be too healthy for the hardware or for battery life. When I locked it @ 80Mhz audio was clean and never hesitated, menus ran fluid, I don't use any EQ, and my battery lasted 6 hours.
Comment by William Peters (w1ll14m) - Wednesday, 10 January 2007, 21:50 GMT
@Jason Lyons

I guessed the 3 MHz by calcluating back.... so it's just a guess
you need the COP patched bootloader codec thread is running on COP

Here is my custom eq (enables soft and hardware eq)
(application/octet-stream)    Bass.cfg (0.8 KiB)
Comment by William Peters (w1ll14m) - Wednesday, 10 January 2007, 21:51 GMT
and it is compiled for the ipod video
Comment by Jason Lyons (bipton) - Saturday, 13 January 2007, 03:07 GMT
Ok I have tried to do this change the divider for the 24Mhz clock they have set to 3 rather than 8 in system.c
No one knows anything about this line

/* Clock frequency = (24/8)*postmult */
outl(0xaa020000 | 3 | (postmult << 8), 0x60006034);

Then I changed the multipliers again to reflect the (hopefully new frequency of 8Mhz)

#define CPUFREQ_DEFAULT_MULT 4
#define CPUFREQ_DEFAULT 32000000
#define CPUFREQ_NORMAL_MULT 4
#define CPUFREQ_NORMAL 32000000
#define CPUFREQ_MAX_MULT 10
#define CPUFREQ_MAX 80000000

My thought is having only 6 or 7 different speed steps or what not for the cpu at speeds within the ARM's operating frequencies rather than the weird 3Mhz with 15 or so steps in clock speed. It's just a thought, I just loaded it on my 4g grayscale, I'm using a bootloader from todays cvs (which still reboots a handful of times before launching rockbox) and w1ll14m's patched src he linked up there.
Comment by William Peters (w1ll14m) - Monday, 15 January 2007, 09:05 GMT
So far I haven't encountered any instabilities when running rockbox on 105 MHz and also it sounds strange,
but my battery life has increased because the disk is less used.
Previous the buffer wouldn't fill till maximum but hang somewhere around 1 or 2 tracks
My harddisk was used much more then it does now.

It all makes sense now so they've calculated like
24/8=3xMULT=frequency

so instead what you've done
24/3=8xMULT=frequency

If it is true that the core's run 32MHz at default then you can use this formula
32/4=8xMULT=frequency
This looks a bit more logical.

it shouldn't make any difference but you never know :)
Does this work for you with the modified MULT?
Comment by Travis Tooke (tdtooke) - Tuesday, 16 January 2007, 03:36 GMT
I think I'm going to try what you're working on William, and if things go well for me I'll post a patch file here for those changes. My thanks to all who are taking their time to work on this problem.
Comment by Travis Tooke (tdtooke) - Tuesday, 16 January 2007, 10:32 GMT
I still get lockups with those settings on my ipod mini1g. It does run fine with me boosting it from the debug menu, but then that's an option you can take with a clean build. I will say the perfomance is definately better with kerneloncop6 though.
Comment by William Peters (w1ll14m) - Tuesday, 16 January 2007, 12:28 GMT
@Travis Tooke
I don't have any lockup's i'm using an ipod video 30GB 5g.
Does the ipod 1g also have a pp5020 chip?

Basicaly what i'am doing is just overclocking my ipod to improve, with these changes to the source code:
#define CPUFREQ_DEFAULT_MULT 4
#define CPUFREQ_DEFAULT 12000000
#define CPUFREQ_NORMAL_MULT 15
#define CPUFREQ_NORMAL 45000000
#define CPUFREQ_MAX_MULT 35
#define CPUFREQ_MAX 105000000

Your ipod will run default 12MHz (never used)
In Normal operation 45MHz
In Boost mode 105MHz.

Somwhere this week i'm getting a brand new ipod 5g 60GB so this ipod become's my test device:) i will run some more tests with higher frequency's and all that kind a stuff.
Comment by Travis Tooke (tdtooke) - Wednesday, 17 January 2007, 04:26 GMT
Yes, the mini1g does have the pp5020 chip. I get the gist of what you're doing there but I did notice on mine if I viewed the cpu freq in the debug screen without actually doing anything that at times my ipod actually was running on 12mhz(might be just a mini thing?). I think on my mini I could probably get away with something like you have if I raised the 12mhz default and maybe played around with the others to make everything match up nicely. I do think you guys have found the cause of the scaling problem, I just need to tweak it a bit for my mini, and I'm very jealous about that new 60G!
Comment by Jason Lyons (bipton) - Wednesday, 17 January 2007, 05:39 GMT
I thought this issue was only with the 4g's William, the 5g's I've heard don't suffer from the scaling bug. Any hoot I just compiled a clean svn version with stock options and my player locked up as soon as it loaded the first song, changing the frequency values along with the multiplier it has been runnin' fine for the last two hours or so playin, musepack, mp3, and oggs. I changed the frequency "I believe" to be 1mhz in firmware/system.c and used a normal multiplier of 32 and a maximum of 80, I've also used a 2mhz, 4mhz, 8mhz, and 12mhz. If i remember right 12mhz with a low multi. of 3 for 36mhz and a high of 6 for 72mhz suffered freezes, and data aborts.Travis the frequency that the debug screen reports is the hard coded CPUFREQ_NORMAL and CPUFREQ_MAX, when it drops below 100% boost it lowers the speed of the cpu and reports whatever you have in the firmware/exports/system.h file for those values.
Comment by Travis Tooke (tdtooke) - Wednesday, 17 January 2007, 06:06 GMT
@Jason, can you make a diff of that? and are you also running kernel_on_cop_6?
Comment by William Peters (w1ll14m) - Wednesday, 17 January 2007, 12:43 GMT
@jason What did you changed? was it the 'outl(0xaa020000 | 3 | (postmult << 8), 0x60006034);'
Or something else, i'm intrested :)

Greetings,
William
Comment by William Peters (w1ll14m) - Wednesday, 17 January 2007, 12:47 GMT
@travis I've found a person who won this thing and has allready an ipod nano 2g and wants to sell his 5g 60GB (he's nuts!!)
So it's brand new in a box even in the plastics and never touched and he sells it for 250 euro :) when i bought my 5g 30GB (359 euro) the 60Gb version was 429 euro :|
I saw this iPod and my thoughts were HE's MINE :)
lol
Comment by Jason Lyons (bipton) - Wednesday, 17 January 2007, 15:40 GMT
I never made a diff file before, but in firmware/system.c I changed this line

/* Clock frequency = (24/8)*postmult */
outl(0xaa020000 | 3 | (postmult << 8), 0x60006034);

to

/* Clock frequency = (24/24)*postmult */
outl(0xaa020000 | 24 | (postmult << 8), 0x60006034);

this should give you 1Mhz instead of 3, you can change the divider to get 2, 4, 8, 12, or whatever else you may want to try. Then I adjusted the multiplier values in firmware/exports/system.h for the ARM cpu.

#define CPUFREQ_DEFAULT_MULT 24
#define CPUFREQ_DEFAULT 24000000
#define CPUFREQ_NORMAL_MULT 30
#define CPUFREQ_NORMAL 30000000
#define CPUFREQ_MAX_MULT 76
#define CPUFREQ_MAX 76000000

These values would match having a 1Mhz frequency to work with, I run it @ 80Mhz for the max also, but the ipl guys have set it to 75 for stability, and they're the gurus behind alot the code. If you change the CPU speed to something else remember to adjust the multiplier values accordingly. I'm using William's patched code with code and also testing the daily svn.
Comment by William Peters (w1ll14m) - Wednesday, 17 January 2007, 19:53 GMT
@Jason Lyons
I think we could also change the COP frequency (That would add another performance boost :))
I'am trying to find whether or not the COP has the same code used.

Regards,
William
Comment by William Peters (w1ll14m) - Wednesday, 17 January 2007, 20:13 GMT
@jason Lyons

I've found something else somewhere in the source code:
#define CPUFREQ_DEFAULT_MULT 1
#define CPUFREQ_DEFAULT (CPUFREQ_DEFAULT_MULT * CPU_FREQ)
#define CPUFREQ_NORMAL_MULT 4
#define CPUFREQ_NORMAL (CPUFREQ_NORMAL_MULT * CPU_FREQ)
#define CPUFREQ_MAX_MULT 11
#define CPUFREQ_MAX (CPUFREQ_MAX_MULT * CPU_FREQ)

Maybe we should check in which file it is located and what is does.
I think 'CPUFREQ_MAX_MULT * CPU_FREQ' is a different way of calculating total frequency.

Go to /cvsroot/rockbox (where you have your patched rockbox source)
and run this command find . -name "*.h" -o -name "*.c" | xargs cat | grep CPUFREQ_
Looks intresting :)

Regards,
William
Comment by Jason Lyons (bipton) - Thursday, 18 January 2007, 02:24 GMT
Here's a patch for svn with one cpu. I ran today with william's source and my changes from 100% battery til the player died, scaling was on.I haven't had a good chance to test the svn with this. The bootloader wigs out with cop and scaling though, so I had to flip the lock switch to clear settings and have rockbox load fully.
Comment by William Peters (w1ll14m) - Thursday, 18 January 2007, 16:12 GMT
@jason Lyons

We could get the COP running at 1/2 or 1/4 of the speed the main CPU is running instead of 1/1.
So we could let the main core run at 90MHz or so and compensate the power usage
with setting the COP to 1/2 of the main CPU speed.

That means:
The Audio thread gets a little more power for audio buffer, then let the codec thread run at COP (COP will be set to 1/2)
So a fast but still less power consuming.

Eventualy it also should get a boost mode switching between 1/1 and 1/2, so if the codec thread needs more power than COP has given, then it will boost the COP to 1/1 of the main core.

I will search around a bit :)
Comment by Robert Cotey (coteyr) - Friday, 19 January 2007, 08:27 GMT
Unfortunatly I do not know about ARM processors enough to help code, but i can help test.

Tried test.diff on a iRiver h10 20g and it freezes at the bootloader screen. No errors. On a side note I Tried fresh SVN co just upping the CPU to 80 MHz and it would run but still lockup after around 15-20 Mins.
Comment by Robert Cotey (coteyr) - Friday, 19 January 2007, 15:12 GMT
Ok just to make sure, I tested a fresh SVN build built from my machine (so I could varify its not gcc4) and it worked fine. There were other bugs, Poor battery life, songs not playing correctly but nothing directly releating to CPU speed or boosting (boosting is turned off I didn't modify the code at all).

it does look like an error for test.diff patch.

I also Tried test.diff and upping the cpu in config_h10.h so they match. I still could not get the device to boot. One, question to try to reproduce Jason's results. How do you "flip the lock switch to clear settings", is this an ipod only feature?
Comment by Robert Cotey (coteyr) - Sunday, 21 January 2007, 00:17 GMT
the lockup at 15-20 minuets has been tracked down and was not related to the CPU speed. Trying again at 80Mhz without booting support did not lock the device. (The issue was related to hard drive reads and was fixed in svn after a conversation regaurding  FS#6421 .

test.diff still will not proceede past ROLO. (didn't expect it to but its an easy thing to check.)
Comment by Jason Lyons (bipton) - Sunday, 21 January 2007, 21:54 GMT
Good call on the ata patch Robert, I just patched it along with my changes for my 4g ipod. Ipod boots and shuts down now properly with cpu scaling on. I'm still using william's source he provided above. I'll run some more tests today.
Comment by Robert Cotey (coteyr) - Sunday, 21 January 2007, 22:15 GMT
Going to see if I can get a stable build from SVN with boosting turned on and the changes from William Peters (w1ll14m) - Tuesday, 09 January 2007, 07:04PM
Comment by Robert Cotey (coteyr) - Sunday, 21 January 2007, 22:37 GMT
Ok I have updated the my copy of the code to include William Peters (w1ll14m) - Tuesday, 09 January 2007, 07:04PM.
The following patches are in place
10 kernel_on_co_6
ata_poweroff_always_enable3
progressbar_slider.patch

So far everything seems stable. ROLO booted to rockbox. CPU is boosting (alot actually) and I have not had a data about or lockup

my wps is the rockbox default and i have no non-standard settings (no EQ etc)

everything seems stable. I will report back more when i get a change to let the battery run down to 0. (7 hours before CPU boosting.)

I would like to see how low the CPU freq can get and still maintain playback. But first these patches.

Attached is a "dirty" patch aginst SVN to show the changes. If it is stable I will create a diff that does not have the ata or progressbar patch (i think kernel_on_cop6 is needed to make it all work, am I correct?)
Comment by Robert Cotey (coteyr) - Monday, 22 January 2007, 01:08 GMT
Ok so I do experance some lockups. Much less then before. It seems that the cpu does at times go all the way down to 12Mhz. This causes a "kinda close to" lockup. It would seem the awnser is to increese the default speed to something like 32. Then the normal to 45 (seems a good speed on this device) and the Max to 80 or so. 105 might be causeing some lockups as well. Trying these changes now.

Battery life is way up though.
Comment by Robert Cotey (coteyr) - Monday, 22 January 2007, 07:04 GMT
Great news (aside from the colts winning)

I ran with the following:
#define CPUFREQ_DEFAULT_MULT 10
#define CPUFREQ_DEFAULT 30000000
#define CPUFREQ_NORMAL_MULT 15
#define CPUFREQ_NORMAL 45000000
#define CPUFREQ_MAX_MULT 30
#define CPUFREQ_MAX 90000000

stable for the entire life of my battery. Unfortunatly that still wasn't very long.... Perhaps the settings need a bit more tweeking.
Comment by William Peters (w1ll14m) - Monday, 22 January 2007, 08:38 GMT
@Robert Cotey

Nice you got it stable :)
My ipod still runs at 105 MHz is very stable so far, and battery lives longer than normal.
As i tweaked my ipod with a nice Software EQ and a good theme I will never run at 12MHz but it could be that it causes a lockup when in goes in that mode.
Also, When i play music (CPU is boosted) my scrolling goes way faster, then when i stop the playback it will slow down a little.

maybe we should make a patch which defines a new 'standard' frequency.

like:
32MHz at default speed
54MHz at normal speed
90MHz at Boost mode

I believe it will use less boost mode (which consumes most power) and whne it 'NEEDS' power it will go to boost and boost a few seconds till boosting is complete.
that would mean still optimizing power and optimizing performance when needed.

When i have my new ipod, i will go wild (testing on my devPod :))
Comment by William Peters (w1ll14m) - Monday, 22 January 2007, 08:47 GMT
@Robert Cotey

Kernel_on_cop6 is needed by my patched source code becuase I hardcoded 'codec', 'pcmrec' and 'playlist cachectrl' threads to COP
but if you would take a SVN build and change those freq's it will work (but no support for COP)

Comment by Robert Cotey (coteyr) - Monday, 22 January 2007, 09:46 GMT
I was under the impressions that the kernel_on_cop6 patch laied the groundwork for the 2nd CPU 'and' put the codec thread there. The name entails it adds the kernel there too. I am testing some new settings I am going to try to lower my cpu normal cpy usage some to see if that extends battery life. Right now the two biggest drains on battery life I can find are cpu and HD activity. The ata_poweroff_always_enable3 seems to help alot with the Hard drive but I never see my device need to boost in play mode. Only when menuing or browseing. Thats fine but if we can reduce CPU usage more for playback then lets go for it.

I am doing this to find the minimum "normal" cpu.

I am playing a large playlist of high bitrate MP3 files with EQ and crossfade on. I use CPU freq page and the audio thread page.

My goal is to keep the audio thread full without boosting. I am useing the same patches as before.
Comment by Robert Cotey (coteyr) - Monday, 22 January 2007, 10:36 GMT
#define CPUFREQ_DEFAULT_MULT 6
#define CPUFREQ_DEFAULT 18000000
#define CPUFREQ_NORMAL_MULT 8
#define CPUFREQ_NORMAL 24000000
#define CPUFREQ_MAX_MULT 32
#define CPUFREQ_MAX 96000000

seems to be the best for me. It keeps the audio buffer full and the codec buffer full. Any lower and I get broken sound, weird navagation, or stuck constantly boosting.

I seem to run at boost while reading from the harddrive. Then I go back to no boost untill I change the tracks manualy. If the tracks change automaticly i never need boost. At any rate I think this is stable enough for a patch. I will stick the clean diff file up here tomarrow unless someone beats me to it. First I want to confirm does the kernel_on_cop6 patch do anything other then add the api in? Is the codec thread ran from the COP with that patch?



the Comments by William Peters (w1ll14m) - Thursday, 18 January 2007, 05:12PM are very intresting. If the COP can be boosted as well...... Maybe we can squeese more battery life out of these little mp3 players.
Comment by MichaelGiacomelli (saratoga) - Monday, 22 January 2007, 19:17 GMT
Does the voltage adjust itself automatically when you change the CPU speed or can we control that too? (I seem to recall the PP data sheet mentioning voltage adjustments in real time.)
Comment by Jason Lyons (bipton) - Tuesday, 23 January 2007, 05:11 GMT
Patched todays svn with your patch and my changes, player lasted almost an hour longer than usual, but I had those weird "no so" lockups also after 2 hours. Seems my recording doesn't work either.
Comment by William Peters (w1ll14m) - Tuesday, 23 January 2007, 07:38 GMT
@Jason Lyons

Maybe it's because pcmrec is moved to COP (Atleast with my patched source).
My Player last indeed an hour or more then usual, and still more performance. I like it :)

@MichaelGiacomelli
I have no clue but it seems to me if you want to boost the CPU with giving it more Voltage i would think that is *realy* power consuming.
Comment by William Peters (w1ll14m) - Tuesday, 23 January 2007, 10:45 GMT
Today i will try to use the new SVN from rockbox and patch it,
maybe i will write a diff for those changes for the current SVN.

Also i read on IRC that there's a small patch for optimizing disk access so that patch is on my whish list too.

I'll let you guys know how it goes :)
Rockon!
Comment by William Peters (w1ll14m) - Tuesday, 23 January 2007, 21:50 GMT
ok, i have rockbox running at ipod 5g 60GB
normal CPu speed 60MHz (boosts less) and boost 90MHz

Looks like it's stable

Patches:
kernel_on_cop_6.diff
ipod_brightness_6.patch
buttonpress_for_usb_connect_20070122.patch
select_ipod_memory_2_(senab_sync).patch

and oufcourse:

firmware/system.c:
outl(0xaa020000 | 8 | (postmult << 8), 0x60006034);
to
outl(0xaa020000 | 24 | (postmult << 8), 0x60006034);

firmware/export/system.h:
#define CPUFREQ_DEFAULT_MULT 8
#define CPUFREQ_DEFAULT 24000000
#define CPUFREQ_NORMAL_MULT 20
#define CPUFREQ_NORMAL 60000000
#define CPUFREQ_MAX_MULT 25
#define CPUFREQ_MAX 75000000

to

#define CPUFREQ_DEFAULT_MULT 24
#define CPUFREQ_DEFAULT 24000000
#define CPUFREQ_NORMAL_MULT 60
#define CPUFREQ_NORMAL 60000000
#define CPUFREQ_MAX_MULT 90
#define CPUFREQ_MAX 90000000

iPod 5g 60Gb won't run on 105MHz :(
Maybe it's usefull to others :)

i'll test the stability
Comment by Robert Cotey (coteyr) - Wednesday, 24 January 2007, 00:55 GMT
William, can we get a copy of your patch that puts the threads on the COP.

I had never changes system.c (guess I have something new to try)

This patch seems just about ready for svn. But I think a few things needs defining first.

The frequencies. We al need to decided on frequencies. We all have diffrent players so we need to come up with whats stable.

I think the default should be set to something low (I don't know what it does and my player rarely (if ever) runs there.)
The Normal should be as low as we can get it and still not effect playback (as that is the primary pourpos of the player)
The Max should be as high as we can set it so we spend less time there.

Low at 24 seems ok. No reason why it's not (its fast enough for when it rarely goes there and slow enough not to be a drain).
Normal I run fine at 24, 60 was suggested by William, 30 and 45 seem common numbers too. William, why 60? If kernel_on_cop_6 moves some load to the COP then maybe we can lower it more, but we can't lower it so much that we interfear with response time alot (some slowness is ok IMO but to much (noticable) is not ok)
High 105 is out nither the H10 or the 5G iPod can pull it off. 90 seems reasonable. maybe 100?

I need to find out if kernel_on_cop6 moves the codec thread/kernel. If so that may be why I can run at 24.
Comment by Jason Lyons (bipton) - Wednesday, 24 January 2007, 03:30 GMT
I have been using the 1mhz increment with some of the weird "not so lockups" as described earlier and also 24/3 for 8mhz, i haven't run into any issuse "yet on my 4g grayscale. I have the test2 patch with svn and I'm getting over an hour more of battery life. I would say run the low @32 and high at 76-80 because that's what the PP5020 operating frequencies are documented as, I believe the newer PP5021+ can run at 100Mhz, I don't know that low point on those.
Comment by William Peters (w1ll14m) - Wednesday, 24 January 2007, 08:51 GMT
@Robert Cotey
This patch was written by Brandon Low:
http://www.rockbox.org/tracker/task/5755#comment12161

I don't think you would ever be able to rin at just 24MHz it will cost buffer.
Buffer is important with harddive based players, if your CPU speed is enough for a complete buffer it's ok.

I wouldn't recomend to let it run slower than 75MHz (Boost mode)
You can change the normal frequency (using if boost is not needed) turn it up a little and your player will use boost mode less.
Comment by William Peters (w1ll14m) - Wednesday, 24 January 2007, 12:46 GMT
@jason lyons

That explains why i can't run 100MHz at my 60GB 5g ipod video and i can at 30GB 5g ipod video.
I think 5g 30Gb has an PP5021x and ipod 5g 60GB has an PP5020.

My ipod is still very stable ;)
Comment by Robert Cotey (coteyr) - Wednesday, 24 January 2007, 12:49 GMT
Thanks William, that answered everything I needed it to. I have been doing some experementation with outl(0xaa020000 | 24 | (postmult << 8), 0x60006034) set so I can tune by 1Mhz.

I currently run at 24MHZ without sacrificing buffer. Using battery_benchmark plugin to mesaure, my hd does not seem to activate more frequently then when boosting was completely disabled. (svn default as of right now) Useing the Audio Thread page I see both buffers full and the same number of tracks in the buffer. It looks like When I start playback the player boosts fills the buffer from hd and then the drive spools down and powers off, it then runs at 24Mhz. I can't tell if it is boosting to re-read stuff into the buffer.

The exception is when I ahve the eq turned on. Then the player is constantly boosted. It never even tries to "un-boost". The audio buffer and codec buffer still fill but the player never switches down to 24 Mhz. If I force it to 24 (via debug-> CPU Frequency) The audio buffer dries up and skipping starts. I tested with 32, 48, and 60 Mhz, the behavior stayed the same. It's important that I note that the default un-boosted speed of 75Mhz also had this behavior (skipping with EQ turned on)

One thing that would be intresting to do/test is boosting when ever the harddrive is turned on, letting us run the HD for a shorter time.

Anyway of topic.

I currently run at 24Mhz/100Mhz with no scarifice of stability or bufferage. (eq turned off)

I wantned to see the bit of code that forced threads to COP because moving the EQ thread to COP my help (not sure) with the skipping wih EQ and no boost (at 100Mhz I get no skipping)


I agree with "I wouldn't recomend to let it run slower than 75MHz (Boost mode)" setting it lower then that seems kinda pointless. As I said, I think that should be set to the higest possibal value that doesn;t cause stability issues, so we spend less time doing whatever task we needed to be boosted for. The EQ throws a wrench into that one though.

The Low speed seems fine at 24 as the buffer fills, does it fill on your player at that speed? Is there a better way/diffrent way to tell.

and "You can change the normal frequency (using if boost is not needed) turn it up a little and your player will use boost mode less." seems to be true. I do boost for starting new playlists, or other CPU intensive tasks if my normal was higher I would likly not boost as much in thoes circumstances, however I speen 95% of the player time listening to music, very little rebuild dircache or tagcache, playing doom or other stuff so I use playback as a test. What I have not tested yet is recording. That could change things.
Comment by Robert Cotey (coteyr) - Wednesday, 24 January 2007, 13:50 GMT
Ok so i got an data abort at 100Mhz looks like 90-95 might be the tops I will test more when I get home.
Comment by William Peters (w1ll14m) - Wednesday, 24 January 2007, 14:17 GMT
@Robert Cotey

EQ audio processing is in the audio thread (which dies when moved to COP).
Your player will be crashing a lot and databaorts and when rockbox boots up
you can start a song but buffer won't fill else rocobkx crashes.

Let me give you an example of howto replace threads to a different core:
Normal a thread is created this way (apps/playback.c):
codec_thread_p = create_thread(codec_thread, codec_stack,
sizeof(codec_stack),
codec_thread_name IF_PRIO(, PRIORITY_PLAYBACK));
this is the codec thread

after COP patch:
#if (NUM_CORES > 1)
codec_thread_p = create_thread_on_core(COP, codec_thread, codec_stack,
sizeof(codec_stack),
codec_thread_name IF_PRIO(, PRIORITY_PLAYBACK));
#else
codec_thread_p = create_thread(codec_thread, codec_stack,
sizeof(codec_stack),
codec_thread_name IF_PRIO(, PRIORITY_PLAYBACK));
#endif

the difference between the normal create thread is just this part:
create_thread_on_core(COP,
instead of: create_thread(

90MHz is most stable with pp5020 SoC players (when you are going to overclock your player), i can recommend you
to set boost to max 90MHz and normal to 60MHz (then player needs less boosting even with EQ turned on like I have)
Comment by MichaelGiacomelli (saratoga) - Wednesday, 24 January 2007, 22:44 GMT
Low is what happens when the player is idle right? If so, I think it should be as low as possible, so you're not burning through battery at idle waiting for the user to input a command. IMO normal + boost should be calibrated for actual playback, but low should not be.

Also, theres some advantage to not going too high. Generally power consumption rises quite a bit faster then clock speed (which is why the PP CPUs use two cores in the first place, since two cores at half the clock speed use much less power then 1 core at 2x the clock speed). IMO boost should be set high enough to do everything we need, but no higher. If you can accomplish something boosted to a lower speed, you'll use less power at the lower speed (even if the task takes longer).

Anyway, this is great work. I'm really impressed with how the PP targets have improved over the last couple months.
Comment by Robert Cotey (coteyr) - Wednesday, 24 January 2007, 23:58 GMT
@Michael
Low = never except once in a blue moon. Even idle it runs at normal mode. The Low should probably never get used and its likely a bug somewhere if it is.
Normal = What we always run at
Boost = what we run at when are buffers are empty/were doing a heavy CPU task (building tag cache)

@ everyone

Hmm I can agree never to go over 90 I tried 100 today and as I stated it was unstable. 60 seems fair. Allows little to no boosting during playback but still full functonality. 24/48 does not allow for EQ or dithering, useing either of thoes functions whould force 100% boost (at 24Mhz or 46Mhz).

I think this patch should be ready for SVN it seems stable and the frequiencies seem to be well defined at 60/90. Perhaps another task should be used to further tweek the kernel_on_cop and what threads should go on what proc. I think as Michael suggests, that if we can evenly distribute everything over both cores maybe the CPU can safely go lower (i.e. ata on COP etc) The other option (to creating a new task) is useing this one to help define what threads can/should go where and what frequencies we would use in that case, but seeing that all svn builds have boosting disabled and enabeling it signeficantly improves battery life, perhaps we should call this one done and start a new task to fine tune threads and frequencies. What ya think?

Comment by Jason Lyons (bipton) - Thursday, 25 January 2007, 01:04 GMT
I moved the ata thread to the cop and had weird data aborts and other problems, it didn't lockup though.I also moved the pcmrec thread to the cop and noticed "shutting down" took ALOT longer. Maybe we can add different frequencies for the different PP types also (4g only have a max freq. of 80Mhz).
Comment by Paul Louden (darkkone) - Thursday, 25 January 2007, 04:06 GMT
This patch seems to be trying to fix two problems with one patch: This is NOT a popular thing among the core developers.

Raising the CPU frequency is NOT the solution to the skipping problem.

If you want the patch to have a better change of inclusion, someone post a version that fixes the freezes but does not change the currently chosen frequencies. There is much more likelihood of it getting included if the patch has only a single purpose. As well, it's good to make sure the code follows the guidelines (I haven't checked, it may already do so, but reminders are good.)
Comment by Steve Bavin (pondlife) - Thursday, 25 January 2007, 07:53 GMT
Also, make sure the patch doesn't depend on any other patches regarding the COP...
Comment by William Peters (w1ll14m) - Thursday, 25 January 2007, 08:51 GMT
@Steve Bavin, Paul Louden

This patch isn't fixing 2 things, let me explain a little.
The patch i use is just letting the core(s) run at a higher frequency, COP patch isn't needed at all (only if you want some load balancing between processors)

Normaly default frequency's are enough but when you turn on Software EQ buffer runs low.
If buffer runs low, it will try to refill the buffer again (lower freqiencies then 75 at boost will cause skipping in this case) because software EQ is running CPU is allready at boost
So the buffer fill's slow or buffers a little, that means the HD is needed more often then usual (which consumes more power then letting the core's run a little higher).

When i use 60MHz as default clock and 90MHz as Boost my overall boostratio after a full buffer is around 50% - 75%
with Software EQ is turned on, this means that my ipod is running almost half of the time using 60MHz then normal constant boosting 75MHz and more disk usage.
It seems to me that this way of using the ipod uses less power than normal rockbox with SW EQ @constant 75MHz boost and more disk usage.

As i have an ipod 5G 60Gb it's usefull it has 64MB ram and a bigger harddisk so it would just consume a little more power.
If you want to load balance with some threads you can optionaly patch the COP patch to your custom build it's not required by frequency scaling.

And as Robert Cotey said:
CPUFREQ_DEFAULT is probaply never used in rockbox (i can't mention even one time i've seen this frequency in rockbox maybe it's used in the bootloader or something i have nu clue)

@Jason Lyons
Most important threads like ATA, Audio, Power, USB, diskcache, dircache, Backlight and scroll cause problems when you move them to the COP this way.
the threads i've moved are:
Playlist cachectrl
pcmrec (i don't use it and player needs indeed longer to shutdown.

This configuration is used in my previous source code pasted somewhere above.

PP5020 has a normal max of 80MHz (so ipod 5g's 30GB has a pp5021x and 5g 60GB has a PP5020 I believe)
but you can let a PP5020 run at 90MHZ (overclocked).
As far as i know a PP5021x can run max at 105MHz (overcloacked as far as i have tested it).
Comment by Paul Louden (darkkone) - Thursday, 25 January 2007, 08:55 GMT
Yes, and my point is that this TASK is about Fixing the Freeze, and has NOTHING TO DO WITH SKIPPING MUSIC PLAYBACK. It has to do with fixing a full, hard freeze.

You have thusly made this thread now contain information about two tasks, one of which is your solution (which is not a valid solution because it doesn't actually fix anything, just creates a new situation where it's not as noticeable) to the music skipping problem, and the second and original thing being the attempt to fix the actual freezes.

My point was that there needs to be a clearly posted patch relating to fixing the FREEZE if it wants to be included.
Comment by William Peters (w1ll14m) - Thursday, 25 January 2007, 09:28 GMT
In addition, here is the patch:
http://rockbox.schoorl.nu/cpu_freq_60-90-v1.patch
No COP is needed to use this patch.
Comment by Paul Louden (darkkone) - Thursday, 25 January 2007, 09:31 GMT
Please stop posting patches unrelated to what the original task is about.
Comment by William Peters (w1ll14m) - Thursday, 25 January 2007, 09:32 GMT
This patch doesn't give my any lockups or data aborts on my ipod video.
Comment by Paul Louden (darkkone) - Thursday, 25 January 2007, 09:33 GMT
Your iPod Video is NOT a PP5020 device.
Comment by William Peters (w1ll14m) - Thursday, 25 January 2007, 09:49 GMT
This should also work fine for PP5020 devices
Comment by Paul Louden (darkkone) - Thursday, 25 January 2007, 09:51 GMT
It has NOTHING TO DO WITH THE TASK

PP5020 devices experience unexplained freezes. You are trying to improve playback. They are unrelated. Please, understand what I'm saying.

Yes, you can increase playback speed on PP5020 devices. But what does that have to do with the current bug in Frequency Scaling that ONLY affects them?
Comment by Robert Cotey (coteyr) - Thursday, 25 January 2007, 09:52 GMT
@Paul, perhaps I do not under stand. The origanl problem this thread was created to fix was that fact that CPU Boost could not be enabled on pp5020 devices without really bad issues with locking up and data aborts. we discovered a few things.

1. enabeling cpu scaling on the targets after modifing outl(0xaa020000 | 24 | (postmult << 8), 0x60006034) seems to work well
2. the target frequencies needed to be adjusted after modifing the multiplyer.
3. we are trying to find the best frequencies to run at. Applying a patch that reduces preformance would not be a good thing, and the numbers have to be changed anyway.
4. The kernel_on_cop stuff is something we were playing with to see if that reduced the crashing/lockups also science we were playing with it, it explains how I was able to run my player at a much lower speed without buffering issues. However as you state that is not really a valid point in relation to this task, therefore I suggested that we focus on nailing down the proper frequencies without the kernel_on_cop_6 patch and move our disscussion on what threads belong on what core and what benifits that would give us to a diffrent task, allowing us to polish up the response to this one, as it increese battery life and does seem to resolve the issue.

Using the cpu_freq_60-90-v1.patch above my h10 (a pp5020 http://www.misticriver.net/wiki/index.php/H10_Hardware_Data) runs very stable with increesed battery life. I have not crashed or had a data abort (when not running over 90 Mhz). One thing is missing from the patch however and that is the firmware/exports/config-h10.h change that has to be made to re-enable frequency scaling on h10 targets.

Comment by Paul Louden (darkkone) - Thursday, 25 January 2007, 09:55 GMT
The target frequencies may need to be adjusted, but they should be adjusted to be as near the current ones as possible if those cannot be hit.

A patch should do as little as possible. If frequencies also need to be adjusted for performance, it should be done in another patch, separate.
Comment by Robert Cotey (coteyr) - Thursday, 25 January 2007, 10:05 GMT
That i can understand. Give me some time, it's 4am here and I will provide a patch that only adjusts the multiplyer and keeps the frequencies the same.

It's important to note that for full playback useing EQ 75Mhz does not seem to be enough, so boosting to that speed may be in-effecient. I will start a new task with the patch to the proposed new frequencies, and link it with this one. In that thread we can discuss the frequencies and what levels they need to be at to enable smoother playback and gui navagation (even forced to 75Mhz the entire time rockbox on the H10 can not handle Software EQ).
Comment by Paul Louden (darkkone) - Thursday, 25 January 2007, 10:08 GMT
The trick is, iPods actually run playback at about 33mhz in their native firmware.

We CAN achieve proper playback without going past 75 with use of the COP properly, if we get things well optimized. Increasing the frequencies used isn't a proper solution to the playback problem.

But my real problem was that what SHOULD be two patches was being discussed as one, as I've said. You're free to start a new patch for new speeds, but they're much more unlikely to be accepted, since they *shouldn't* be needed if optimization works out.
Comment by William Peters (w1ll14m) - Thursday, 25 January 2007, 10:13 GMT
@Paul Louden

My patch is not only for playback, it's for overall performance and stability for pp5020 and those chips.
A friend of mine uses an ipod 4g (has definitly an PP5020) and runs fine with this patch no lockups etc.
If I understood this the wrong way, then I apologize for those here patches etc.

@Robert Cotey
Maybe we should open a new FS task for this? like PP502x performance improvement experiment.
Comment by Daniel Ankers (dan_a) - Thursday, 25 January 2007, 10:20 GMT
I think that if we get better battery life and no lockups with a higher normal frequency then there is no reason not to use that.
However, I would be concerned that by raising the normal frequency you are simply hiding the problem (boosts happen less often, therefore lockups caused by boosting happen less often.)

I will test the patch which keeps the frequencies the same on my 4G greyscale iPod tonight.
Comment by Robert Cotey (coteyr) - Thursday, 25 January 2007, 10:20 GMT
i think we agree that the player should be running at lower speeds (again this goes to the next patch/task that is not created yet) hense the focus on kernel_on_cop6 which allows us to run at lower speeds. However you are correct and a patch should attempt to fix a single issue. I also think that simply upping the CPU is not a valid option in regaurds to EQ and playback. However moving the threads around a bit might be. As far as I can tell both cores run 100% of the time therfore it is safe to assume that the OF makes use of them.

Anyway, off topic again.

@William

Yes a new thread for the kernel_on_cop6 v.s. playback and performance seems the correct way to go. (maybe there is a kernel_on_cop6 task already need to hunt for it fist. In that task we can discuss the effects of moving threads around and such. But first give me a chance to create a patch that enables cpu boost on the H10s but keeps the frequencies the same and does not use kernel_on_cop6. (i need time to test the patch). Then we can focus on what threads we can move where (new task), and performance issues.

Comment by William Peters (w1ll14m) - Thursday, 25 January 2007, 10:31 GMT
@Robert Cotey

Sound's fine to me :)
there is a task called 'Add the beginnings of coprocessor support on iPods' (http://www.rockbox.org/tracker/task/5755) which developed the kernel_on_cop6 patches
you can email me at w1ll14m *AT* gmail *dot* com
Comment by Robert Cotey (coteyr) - Thursday, 25 January 2007, 10:34 GMT
here is the patch. This enables CPU boosting on the h10 only (it's the only device I can test with) It seems to be running stable but I have to go to work now. I will know better at the end of the day if Daniels fears are unfounded or if there is a larger issue that we covered up.
(i hope the former, because I never recived a data abort or lockup when using this method (though I don't reeally understand why) and i did boost (i ran with my cou at 24Mhz so I probabaly boosted more ? don't know guess we will find out.)

Again this is for testing only.
Comment by Jason Lyons (bipton) - Thursday, 25 January 2007, 20:40 GMT
Ok here is a patch against this morning's svn, all it changes is the settings for the cpu multipliers and running frequencies. It does not overclock the cpu and is as close to the old settings. I have a grayscale 4g (PP5020) that locks up VERY quickly with the default settings of scaling set, but has been running very stable with these new changes.I've been testing it with a playlist of 1000+ songs mostly musepack and a couple albums of 500k ogg.Please test it if you have a PP5020 device.I don't run any eq and use the zezayer wps.THIS PATCH IS ONLY FOR THE SCALING ISSUE WITH PP5020.
Comment by Jason Lyons (bipton) - Thursday, 25 January 2007, 21:01 GMT
linuxstb just learned me how to do a proper patch, i think this is it.
Comment by Dave Chapman (linuxstb) - Thursday, 25 January 2007, 21:49 GMT
I've just tried scaling-test2.diff on my Photo, and it froze after about 5-10 minutes.
Comment by Adam Gashlin (AdamGashlin) - Thursday, 25 January 2007, 21:57 GMT
it froze quickly for me, too, then I rebuilt and installed the bootloader; it is still running now.
Comment by Jason Lyons (bipton) - Friday, 26 January 2007, 01:04 GMT
I have added 500 ms to the already 2000 udelay for the pll, and made a new bootloader based on the changes. So far no lockups or goof ups. I experienced lockups quickly also after loading my playlist on the last patch.
Comment by Adam Gashlin (AdamGashlin) - Friday, 26 January 2007, 03:02 GMT
I did finally get scaling-test2 to freeze on me, I was playing with the equalizer at the time.
Comment by Jason Lyons (bipton) - Friday, 26 January 2007, 04:00 GMT
Man i don't know, you big time developers I think have a good idea about it having to do with the COP, cause I get alot better stability BUT, no matter what I will get lockups. Whether it's different frequencies/w different multipliers, or different delay timings for the PLL, I still get lockups.I have a build with my changes and the added COP with the codec running on the COP and I get 5-5.5 hours runtime, from 100% to ded no problems. Maybe the fix for the PP5020 is gonna have to include the COP.
Comment by Daniel Ankers (dan_a) - Friday, 26 January 2007, 10:04 GMT
I've had great results so far with the cpufreq3.patch on my G4 greyscale.
Comment by Jason Lyons (bipton) - Saturday, 27 January 2007, 00:35 GMT
6 hours 2 min on cop build with frequency adjustment, no lockups. Are the rest of the PP**** family targets stable with COP yet? If we get COP in svn we can add the frequency changes to allow scaling, correct? It would be one patch for COP (no scaling), then another patch for the frequency change for the scaling issue.
Comment by Adam Gashlin (AdamGashlin) - Sunday, 28 January 2007, 14:41 GMT
cpufreq3 seems to be getting stuck unboosted for me... I need to reboot to get it working normally again.
Comment by Chris (decayed.cell) - Tuesday, 30 January 2007, 08:16 GMT
Tested scaling-test2.diff - I get more lockups on my friend's 4G Grayscale ipod
Comment by Chris (decayed.cell) - Tuesday, 30 January 2007, 10:35 GMT
Tested William Peters (w1ll14m)'s heavily flamed (by darkone) patch on 4G Grayscale ipod. The guy is just trying to help for godsake. No freezes as of yet, I've been playing mp3s for about 1.5 hours nonstop now.
Comment by William Peters (w1ll14m) - Tuesday, 30 January 2007, 10:56 GMT
Jason Lyons

that is what i'm thinking maybe this isn't the most clean
way to clear this problem, but atleast we have a 'temporary' fix for the freezes.
Even if it needs 2 patches if it works why not?. (I still agree to create a new FS task for optimizing PP50** targets)
Comment by Paul Louden (darkkone) - Tuesday, 30 January 2007, 10:59 GMT
A "temporary" fix is to disable CPU scaling. We already had one, a second one is redundant.

This task exists for a PROPER fix, which is why I keep saying please separate the discussion into "fixing CPU scaling" and a separate "Optimization." Also, "optimization" is separate from "Running the CPU faster so that slow code isn't as relevant".

From this point on, discussion should be related to an appropriate way to figure out *why* scaling crashes the target, and how to scale in a way that does not cause crashes.
Comment by Chris (decayed.cell) - Tuesday, 30 January 2007, 11:37 GMT
Tested on 5.5G iPod - crashes whilst I'm doing Update Now for the database. Testing more... you should make another thread for it I guess
Comment by Chris (decayed.cell) - Wednesday, 31 January 2007, 20:28 GMT
Hasn't crashed since then, I feel that the ipod is more responsive with this patch, especially with the scrolling list - when it lags, it doesn't lag as much (after scrolling a few pages the scroll slows down, then you have to stop and start scrolling again - weird bug). I have this being tested on a friends' 5G 30GB iPod - appears to be working correctly too. Today (hopefully) I'll testing on a 4G Color.
Comment by Paul Louden (darkkone) - Thursday, 01 February 2007, 03:29 GMT
Seriously guys: This is the WRONG TASK FOR PERFORMANCE ISSUES.

This is ONLY for the issue regarding processors freezing, and should involve only fixes for that, not for increasing the CPU speed or anything else.

If I see ONE more comment unrelated to the PP5020 thread, I will close this task and actually force you to split it by no longer providing a location for you to discuss your off-topic patches.
Comment by Chris (decayed.cell) - Thursday, 01 February 2007, 05:45 GMT
Alright then, the patch that William Peters made fixes freezing that I was experiencing on my friends 4G Grayscale and 4G Color iPods. HAPPY?
Comment by Paul Louden (darkkone) - Thursday, 01 February 2007, 06:49 GMT
Because they run the processor at a much faster speed, they also boost significantly less, which means there's a possibility that they don't even TRIGGER the bug, but that it's still there.

I stated clearly that these are two different tasks. If the problem is that "boosting can cause freezes" the solution is not "so boost less often."

It's been stated that the modified code still causes freezes when it doesn't run at the higher speed, which strongly suggests the problem is not actually solved by this patch.
Comment by Robert Cotey (coteyr) - Thursday, 01 February 2007, 07:07 GMT
well actually, William and I have me communicating off the board(mostly because while trying to track down stuff we get yelled at) . The stability of the patchs most likly has nothing to do with frequency at which you run. I currently run at 24/30/75 (the default as of SVN:HEAD) It's more likly that the problem, while still corrected by William's eayler patches, Jason's early patch, and my test2.diff, has nothing to do with frequency. I have done some testing and it appears that you can pick any frequency and still have no problems when switching between boost and non-boost. The problem seems to be related to the CPU state with boosting takes place. I know that the COP and CORE1 have to be running at the same speed on pp targets. There's no way around that (according to manufactures docs). The logical "missing step" in all of this is the KoC patch. The KoC patch creates a thread on COP there by setting the COP to a non-sleep/non-idle state. Switching frequency then appears to work. Unfortunatly do to some deadlines at work I do not have to time to properly test this theory. To test this thory one would enable CPU frequency scaling on a pp target and see if it crashes (it appears to). Then enable the second COP in some manor (KoC works but a qucik hack could be used for testing) make it do work so it's non-idel/non-sleep and then try scaling the frequency. It's not to bad of a task I just plain don't have the time/ambition.

I can say this though. With KoC running I do not have any problems what so ever in regaurds to cpu scalling, so the awnser is in the KoC patch. Just got to isolate it.

Comment by Chris (decayed.cell) - Thursday, 01 February 2007, 07:07 GMT
Okay point taken, but I'd like to add something

"I've just tried scaling-test2.diff on my Photo, and it froze after about 5-10 minutes."

"It froze quickly for me, too, then I rebuilt and installed the bootloader; it is still running now."

"Tested scaling-test2.diff - I get more lockups on my friend's 4G Grayscale ipod"

"I did finally get scaling-test2 to freeze on me, I was playing with the equalizer at the time."

As far as I know, nobody besides me and Robert Cotey:

"Using the cpu_freq_60-90-v1.patch above my h10 (a pp5020 http://www.misticriver.net/wiki/index.php/H10_Hardware_Data) runs very stable with increesed battery life. I have not crashed or had a data abort (when not running over 90 Mhz). One thing is missing from the patch however and that is the firmware/exports/config-h10.h change that has to be made to re-enable frequency scaling on h10 targets."

have bothered to test Williams patch, these freezes where with the scaling-test2.diff, not cpu_freq_60-90-v1.patch

If this temporarily fixes the lockups then it is at least slightly relevant. It doesn't matter how it is fixed, but as long as there is a temporary fix to alleviate the problem then we can use that whilst we figure out a proper way to fix this boosting bug.

My interpretation of this thread is that there are freezing issues with the 4G iPods and there needs to be a fix to fix this. If this patch makes the processor run faster to 'fix' this problem, then it is not as irrelevant as you make it out to be.

"This is ONLY for the issue regarding processors freezing, and should involve only fixes for that, not for increasing the CPU speed or anything else."
You even stated this yourself, there is an issue of processors freezing - if increasing the CPU frequency helps with the freezing then it should be at least considered as an alternative. I just think you were a bit harsh on William when you said it was off topic... the topic was to fix the freezes, and (for me at least) his patch helps.

In any case, this thread should be closed and two new ones should be opened, one to tackle the freezing bug by fixing the boosting, and the other to tackle the freezing bug by increasing CPU frequency.
Comment by Paul Louden (darkkone) - Thursday, 01 February 2007, 07:10 GMT
It is 100% irrelevant.

It has been known from the start that simply disabling CPU scaling is a temporary fix.

This TASK (not thread) exists to find a FULL fix. Not a temporary one. Period.

Loading...