This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#9797 - Zero-wait boost for Iriver
Attached to Project:
Rockbox
Opened by Björn Stenberg (zagor) - Tuesday, 13 January 2009, 21:07 GMT+2
Last edited by Marcin Bukat (MarcinBukat) - Sunday, 05 June 2011, 13:21 GMT+2
Opened by Björn Stenberg (zagor) - Tuesday, 13 January 2009, 21:07 GMT+2
Last edited by Marcin Bukat (MarcinBukat) - Sunday, 05 June 2011, 13:21 GMT+2
|
DetailsCurrently, boosting on coldfire involves waiting for PLL lock which can take as much as 10ms.
This patch changes the boosting to just toggle the clock divider and not change the PLL frequency, and thus not having to wait for it to stabilize. This makes the boost near instantaneous. The MCF5249 docs can be interpreted to say you're not supposed to do this, but they are not conclusive. My limited testing showed no side effects so far. In order to get clean clock dividers, the patch also changes the operating frequencies from 124/45 MHz to 112/22 MHz. The "default" (idle) frequency is unmodified in this patch and still uses PLL bypass, but is used so rarely it shouldn't have much impact. Zero-wait boost opens up possibilities for more efficient cpu management in Rockbox. Coldfire is the only platform where we are not sure this is possible. Ideally, someone who uses an Iriver player as their daily player should run this patch and see if any side effects pop up. 
coldfire-quickboost.patch
(8.4 KiB)
firmware/target/coldfire/system-target.h | 8 - firmware/target/coldfire/iriver/system-iriver.c | 154 ++++++++++++------------ 2 files changed, 82 insertions(+), 80 deletions(-) |
This task depends upon
Closed by Marcin Bukat (MarcinBukat)
Sunday, 05 June 2011, 13:21 GMT+2
Reason for closing: Out of Date
Additional comments about closing: Old, and with our current power management implementation doesn't gain much. Another point is that pll lock time stated in documentation is worst case scenario and usually pll is locked pretty fast.
Sunday, 05 June 2011, 13:21 GMT+2
Reason for closing: Out of Date
Additional comments about closing: Old, and with our current power management implementation doesn't gain much. Another point is that pll lock time stated in documentation is worst case scenario and usually pll is locked pretty fast.
1) I'm getting 15.4% boost ratio playing MP3s (just CBR 128kbps). I'm using album art with default WPS if that's relevant. Will compare with SVN later today, but I don't think I had to boost at all before.
2) Atter initial boosting at boot has completed, I have a boost count of 0 but the CPU frequency is at 112MHz (both according to the debug screen).
The boosted cpu speed is changed to 112 MHz, to get clean and simple clock division. It will be optimised later if we decide this is a working solution for boosting.
What I'm really looking for is serious side effects such as crashes, freezes, misbehaving timers etc.
At some point during a track transition playback began to become slow and choppy (audio seems to drop out multiple times per second). In the buffering debug menu the pcm was almmost empty (it always filled up only a little bit and ran empty again). The boost was below 20%. After some time the player froze and required a hard reset. This happened only once so far.
There are sometimes little audio dropouts shortly after track transitions (when using crossfade and a WPS with peakmeters they seem to be more obvious).
I think a quite reliable reproduction recipe is to turn on crossfade and select the rockbox_default theme (not cabbiev2). Then play a playlist/folder of mp3 files and a few seconds after a track transition skip back to the beginning of the track. Then there should be dropouts. (I was not able to reproduce this with a clean SVN build.)
attached is an audio sample of those dropouts.
Ocasionally there was a short droput after fast forwarding or when the disk spins up for rebuffering.
H300 with r19771
I haven't noticed any problems with buttons or the time (but the time isn't on my WPS...)
the plan is to boost more often in the GUI after this patch is in yeah? so my problem will be fixed later?
How do dividers work? I suspect 22MHz is a little too slow for "unboosted", or we're going to need more forced boosting.
I'll look into adding a flag that is set if the pcm empties unexpectedly, plus a display of this flag somewhere in the debug menu. That would show if audio dropouts are due to insufficicent processing power or it the glitches are somehow caused by the new clock manipulation.
The reason I use these slow clocks instead of higher speed is that they are directly compatible with the various timer initializations already used, and I didn't want to have to recalculate them.
Another test is to use 56MHz as the "normal" clock. It uses the same PLL speed as 112 and just divides with 2 instead of 5. I'm attaching a patch for that to this comment. (Apply instead of parent patch.)
From the point of view of battery life, we want as slow as possible, and then to make time critical code boost as needed (GUI, buffering, etc). This way only as many clocks are used as are actually needed.
The following procedure* seems to produce all kinds of weird behavior when playing back mp3 files (AAC and Ogg Vorbis play back normally):
Reset settings, turn on crossfade and choose the rockbox_default theme. Then start playing a folder with (normal size) mp3 files. After buffering finishes skip to the 2nd track, let it play for a few seconds and skip back to the beginning of the 2nd track. Then slowly skip forwards through the playlist (letting every track play for ~10 seconds or so).
Doing that i have noticed the following issues:
- dropouts like described earlier.
- crossfading works incorrectly. The old track fades out and suddenly jumps to full volume again for a moment.
- playback can become slow and choppy like described earlier.
- when the disk needs to spin up to load the next track then the player sometimes freezes with the disk spinning (requiring a hard reset).
* I'm not sure if all steps are required for reproduction. I haven't done too much testing because of the occasional freezes (i doubt that this is good for the hard drive).
Since those Problems seem to only happen with mp3 files i was wondering if it is possible to make a build that runs at 22MHz normal CPU frequency using the standard frequency switching method in order to see if the problems are related to the new frequency switching method or if this is a problem with the mp3 decoder that only shows up at lower CPU frequencies.
The MP3 dropouts are definititely associated (or increased) with this patch, however, so maybe good to look into the lack of boost there before committing this. Otherwise, go for it!
FS#9800)The purpose of this boost research is to do a more general rework of the boosting system, so we can lower the normal frequency while making the GUI more responsive. This patch alone is not good enough.