This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#6095 - pp5020 frequency scaling experiment
Attached to Project:
Rockbox
Opened by Adam Gashlin (AdamGashlin) - Saturday, 30 September 2006, 13:47 GMT+1
Opened by Adam Gashlin (AdamGashlin) - Saturday, 30 September 2006, 13:47 GMT+1
|
DetailsI'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. 
cpufreq.patch
(1.4 KiB)
firmware/system.c | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) |
This task depends upon
Closed by Paul Louden (darkkone)
Thursday, 01 February 2007, 08:15 GMT+1
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
Thursday, 01 February 2007, 08:15 GMT+1
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
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?
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...
Before your patch, were you getting freezes or data aborts?
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.
Have you still had no success using this on your 4g grayscale?
Leaving work in ~20 minutes, so that'll be my first hour long test <g>
Three were in CBR MP3, 2 in Ogg Vorbis. I have (almost) no VBR MP3s to test.
What were those writes were supposed to do?
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.
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.
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.
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' :)
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.
"#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.
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
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 :)
#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.
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
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
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)
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.
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?
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.
Or something else, i'm intrested :)
Greetings,
William
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
/* 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.
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
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
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 :)
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.
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?
FS#6421.test.diff still will not proceede past ROLO. (didn't expect it to but its an easy thing to check.)
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?)
Battery life is way up though.
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.
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 :))
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)
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.
#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.
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.
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!
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
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.
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.
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 ;)
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.
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)
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.
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?
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.)
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).
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.
http://rockbox.schoorl.nu/cpu_freq_60-90-v1.patch
No COP is needed to use this patch.
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?
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.
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.
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).
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.
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.
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.
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.
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
(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.
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)
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.
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.
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.
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.
"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.
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.