This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#8379 - power consumption issues PP502x/5G
Attached to Project:
Rockbox
Opened by Andree Buschmann (Buschel) - Thursday, 27 December 2007, 20:14 GMT+2
Last edited by Robert Kukla (roolku) - Sunday, 10 February 2008, 17:12 GMT+2
Opened by Andree Buschmann (Buschel) - Thursday, 27 December 2007, 20:14 GMT+2
Last edited by Robert Kukla (roolku) - Sunday, 10 February 2008, 17:12 GMT+2
|
DetailsSome changes as start for further work on DEV_ENx-stuff:
1. en-/disabling DEV_IDE0 together with HHD power-off 2. disabling DEV_OPTO (= iPod clickwheel) when hold button is locked 3. disabling DEV_USB until USB is detected via GPIO - allow initialisation of USB and then disable DEV_USB - re-enable DEV_USB on USB-detection - DEV_EN = 0x8 is also needed for USB like DEV_USB Questions: - anybody knowing what DEV_EN = 0x8 may be? - what are DEV_INIT2 |= INIT_USB and GP032_ENALBE |= 0x200 needed for? these lines seem to have no effect with a 5G... 
device_disables_v01.patch
(4.6 KiB)
|
This task depends upon
Further changes:
- disable several registers based upon self-tests
With these changes runtime tests show the capability of a ~12h runtime with 5G 30GB (former measurements: 10.5h).
Additional change:
- use 40MHz as default clock -> I assume to have further increase through this as we avoid boosting which also seem to cause higher power consumption.
Runtime on a 5.5G 30GB is now 11:46h (10:24h before) with mpc-playback.
- DEV_INIT2 = 0x40000 must always be set for button/scrollwheel. If disabled the hold-switch detection is not wrking anymore.
Small cleanup:
- added new DEV_USB0 (0x80) to pp5020.h and renamed DEV_USB to DEV_USB1 -> both needed for USB
- added new INIT_BUTTONS (0x40000) to pp5020.h
- removed the not needed lines in usb-fw-pp502x.c (setting DEV_INIT2 and GPO32_ENABLE)
- cleaned up system-pp502x.c -> only leave the new initialization of DEV_EN/DEV_EN2/DEV_EN3(?)/GP032/DEV_INIT2, no change in clock anymore
Remark:
This version should not change the power consumption at all (at least for playing codecs which still boost @40 MHz), it is just a code cleanup.
- clickwheel: use already defined #defines for some register values
- clickwheel: removed unneccessary commands
- powermgmt: power consumption is about ~36mA now -> corrects runtime calculation
for the next steps I need your help. I would like to test whether there is some measurable difference between using 24MHz-clock with and without PLL. The attached patch includes all patch-versions before but includes some more changes in clock-configuration for PP5022/5024. Idea is: Why not using 24MHz instead of 30MHz as "normal" clock -- then we could disable the PLL. Now I've got two major problems where you might support further development:
1.
Anyone capable of measuring the current consmuption for three different clock setting?
a) CPU @30MHz with PLL (=normal clock)
b) CPU @24MHz with PLL (=normal clock, but use the clocksetup I already added commented in the patch -> "PLL_CONTROL = 0x8a220401; /* 24 MHz = (4/1 * 24MHz) / 4 */")
c) CPU @24MHz without PLL (=normal clock, but set the "#if 1" to "#if 0" to use the block marked "--- new without PLL ---"
2.
Anyone has a tip why using the switched off PLL for "normal" clock is instable? When using the setting 1c) as described above the iPod will hang up after about 1--1.5 hours...
new version of the patch with the following changes:
1. Detailled rework of frequency scaling based upon "H10 (PP5020) Clock Handling v0.4 by MrH"
- until now works stable on my 5.5G 30GB (>12h overallruntime)
- works with changing between PLL driven and non-PLL driven clock (svn code does not work with this)
- disable PLL when not used
- use 24MHz (non-PLL) for normal clock
- add #define for PLL_ENABLE to PP5020.h
2. Minor cleanup in system-pp502x.c
- remove tabs
- use #if/#elif for better readability
As the results in runtime measurements show similar results for 24MHz via PLL vs. 24MHz without PLL I am not quite sure whether the PLL is fully deactivated. Maybe there must be some of the unknown DEV_ENs be cleared?
Could turning on PLL cause an audio glitch in this way?
Re stability - I saw no problems in 'regular' use but haven't yet tried a longer test.
Stock SVN: 42.71 ma
v06 patch: 34.19 ma
device_disables_test: 37.22ma
device_disables_test with the #if changed to #if 0 to disable PLL: 37.19ma
To make sure I was using the new PLL code, I deleted the stock and got identical results. Evidently the PLL uses ~ 30ua.
From the runtime tests I have similar results -> no significant change. I am not sure, if the PLL is fully disabled -- as known there is no documentation. I just tried to reengineer some stuff with the known registers...
- frequency scaling: hopefully solved the glitch-issue without harming stability (runtime test is running right now)
- DEV_EN: do not enable bit 0 of DEV_EN (only set by wmcodec- and as3514-init) as it seems to be not needed on at least my 5G
what can you test?
- is DEV_EN, bit 0, also not needed on your target?
- is frequency scaling stable? -> long runtime without freeze
- are glitches still audible when switching from 24 -> 80 MHz?
saratoga:
If you still have your equipment around: Could test if there is difference in current consumption when you remove the folling lines in system-pp502x.c against leaving them active?
CACHE_PRIORITY = 0x0000003f; /* DEV_EN3 from own tests, no effect? */
GPO32_ENABLE = 0x40004000; /* GPO32_EN from own tests, no effect? */
GPO32_VAL = 0x00004000; /* GPO32_VAL from own tests, no effect? */
thanks a lot!
Heres the lowest power settings I could find on the Sansa that didn't crash the device:
http://pastebin.ca/768034
If its commented out, then the build didn't work with it. So I found nearly the same results as you, but did not need bit 3 or 5 enabled in CACHE_PRIORITY. Or at least didn't need them just to decode a single track, which was all I took the time to test for.
Will check the GPO32 results when I get a chance.
Anyway,
Retail firmware:
idle power: 35.7 ma
LAME APS: bounces everywhere in [47.7 to 51.6 with spikes to 90ma every so often (!) ]
Rockbox w/ v7 patch:
33.9 ma idle, VBR Mp3 playback [36.1 no boost, 56.2 boost]
Rockbox w/ v7 patch and the above lines commented out (GPO32_ENABLE and GPO32_VAL):
34.2 idle, [36.2, 56.1]
(a marginal improvement but barely distinquishable on my crappy meter)
Rockbox w/ v6 patch (for reference):
33.9 idle, [35.8, 55.8]
The mp3 numbers are really rough, so pay more attention to the idle numbers.
Also, I noticed an odd thing. When the screen is activated, it will eventually turn off, but power stays highish for another 10 seconds or so before it clicks down to the idle draw. Any idea whats happening then?
I got about 45% boost on these mp3 files. That works out to an average current of about 45ma, while the retail OS averaged about 47ma. I think for VBR MP3 at least we're now using less power then the retail OS, though its pretty close! Good work Buschel!
saratoga: May I ask you for a measurement? Runtime tests didn't show much effect, but it's much more reliable to measure it directly.
- Which one of the patches above did you use?
- If you used v7, did you try some of the older ones as well? We may track down the problem via using older versions.
- Did you change something in the patched code (especially e.g. using the "minimum startup configuration" in systewm-pp502x.c of several register also for your player)?
So, if saratoga measures "no effect in power consumption" on this one, it will not be included in the next v8-patch.
Thanks for your test support! :)
I have been using this patch and it really increases runtime with hours on my sansa e280, good job :-) If I have the time I will do a bench with various file formats.
- also do not enable DEV_EN Bit 0 for as3514
- remove udelay in freq switching after several runtime tests without any issues
- added several (commented) new clock settings for testing especially for flac users
@flac users:
Please set "#if 0" in system-pp502x.c to "#if 1" and choose a clock which is below 24MHz (12MHz and 16MHz would be interesting). This way the GUI may become quite lagged, but the total runtime should further increase significantly.
ToDo's:
1. Finding a way to boost the frequency on GUI-activty (unboosting after timeout) -> clock can be lowered without laggy GUI -> better runtime for efficient codecs
2. Adding a new setting to disable the WPS when backlight is off -> better runtime as the WPS needs quite a lot of CPU power
Happy testing and thanks for your support!! :)
- use 12MHz as normal clock
- boost, if GUI is active (boost, if any button was pressed. unboost after hardcoded timeout of 4sec)
Should give further runtime to users of highly efficient codecs without changing the patch and without introducing laggy GUI.
Comment:
GUI-boosting is right now enabled in a quick-and-dirty way. So, it will affect all targets (also no PP-targets) right now.
Can you make available the battery_bench-file somewhere?
Back of the envelope calculation suggests that the CPU should use just 75% of the power it needs at 1.2v when run at 1.05v. Assuming its possible to run at <=30MHz at low voltage, and a 50% boost ratio for typical codecs, then we should see 4.5ma saved for slow codecs. Faster ones (MPC,FLAC) would see see 9ma savings (which would be over 6 additional hours on the Sansa!).
The GUI-boost did not work for all targets, therefore the CPU-clock was too low for normal GUI interaction on most targets.
So I roll back the changes and will use 24MHz as normal clock as long as there is no full solution for the GUI-boosting.
If someone has better ideas about how to boost/unboost for GUI interaction please let me knwo or post a patch here.
desc, idle (unboost, boost)
v10 patch, low voltage enabled: 30.48 (32.5, 49.3)
v10 patch, stock 32.06 (34.1, 54.2)
SVN 40.99 (43.3, 61.8)
The low voltage setting is surprisingly stable at 80MHz. I checked the VBE1 and VBE2 ADC readings, but they were actually higher by 9 or 10 each then stock SVN. Is that what should be expected if the voltage really is lower? I tried putting "pp_i2c_send(AS3514_I2C_ADDR, 0x21, 3);" at the top of pp_set_cpu_frequency() if it matters.
Also, I'm still very curious what is using all that power for the ~10 second after the backlight is flipped off. Do we delay switching off the screen? If so, we could save quite a bit of power by decreaseing that delay.
This leads to the next question for support: As I wrote yesterday, the v09-patch had to be rolled back as the GUI-boost did not work properly for non 4G-scrollwheels -- this is because _all buttons_ are detected well, but the _scrollwheel_ is not. For 4G-scrollwheels I could fix it, can anybody check this for the other targets? Or are there some better ideas for a generic solution?
now, on the targets which are visible with the light off, either disable this, or make it user configurable.
I'm i forgetting to add any other patch too, like the i2c path that i see above, please let me know, thank you.
P.S: i patched svn version 16088 with device_disables v10 patch, anything else to be done?
Just one doubt in my mind, the patch seems t be patching a file called "power-ipod.c", shouldnt it also be patching "power-h10.c" also then
i just think that could be the trouble, also recently a h10 file the adc file was deleted from svn, & a new one was made to share the same code with mrobe, its called "adc-pp5020" i think.
just thought to let you know, since i see no files of irivers h10 gettin modified in the patch so patch v6-10 dont work, screen hangs on iriver logo itself from V6-9
change "#if 0" in syste-pp502x.c to "#if 1" in v10-patch --> does not work
trying patches V 1-5
dude v1-5 also none of them seem to go beyond the rockbox logo, everything hangs.
have you tried to talk to barry on this ?
so basically for now this patch on h10 [20GB] does not work
add "GPO32_ENABLE |= 0x200;" before "outl(inl(0x7000002C) | 0x3000000, 0x7000002C);" (~line 35)
add "DEV_INIT2 |= INIT_USB;" before "while ((inl(0x70000028) & 0x80) == 0);" (~line 46)
I just patched (v10) over current (16091) svn, and built for my 5gb h10. While the ready-made builds distributed by Soap had the same symptoms as described by Nikkhil, editing the source with both your latest recommendations and the earlier one about commenting out the DEV_USB0... lines did end up in a build that could boot. -- I'll see if its stable and try to do two battery bench (with/without) to compare tonight/tomorrow.
Thanks for your work :D
Can you try to figure this out?
1. commenting the two lines DEV_EN &= ~DEV_USB0 and DEV_EN &= ~DEV_USB1 in usb-fw-pp502x.c.
2. add "GPO32_ENABLE |= 0x200;" before "outl(inl(0x7000002C) | 0x3000000, 0x7000002C);" (~line 35)
add "DEV_INIT2 |= INIT_USB;" before "while ((inl(0x70000028) & 0x80) == 0);" (~line 46)
im attaching the modified patch for the h10 with v10 of the original patch, ill check the build with my settings on it & get back to you on the results in a bit
PS: im curious on how to do a battery bench, i mean i know the plugin is the key, but how to use it, as in do i have to be doing only listening to music, & restrict from data transfers from the comp, or play any games.
1. add "GPO32_ENABLE |= 0x200;" before "outl(inl(0x7000002C) | 0x3000000, 0x7000002C);" (~line 35)
add "DEV_INIT2 |= INIT_USB;" before "while ((inl(0x70000028) & 0x80) == 0);" (~line 46)
with the DEV_EN &= ~DEV_USB0 and DEV_EN &= ~DEV_USB1 uncommented, ill test this build with my settings instead.
FLAC
Default Settings & Theme
Volume -20db
Total 21h 52m
Awesome.
- does fully remove the GUI-boost function -> should fix the reported issues with laggy scrolling
- should work for H10 now as a first shot (Thanks to Alexandre and Nikkhil!)
Nikkhil, Alexandre: Thanks for your support, now there are 2 more things I would like to ask you to test:
1. Do we need both lines (GPO32-ENABLE, DEV_INIT2) or just one of them?
2. Depends on point 1.) It is still of interest whether it is possible to switch off and on the GP032_ENABLE- and DEV_INIT2-bit together (in time) with DEV_USB0 and DEV_USB1 -- this may save some power (in fact nobody knows, but we should give it a try).
Can you add "GP032_ENABLE &= ~0x200; DEV_INIT2 &= ~INIT_USB;" right below the "DEV_EN &= ~DEV_USB1;"
plus adding "GP032_ENABLE |= 0x200; DEV_INIT2 |= INIT_USB;" within the "if (retval)"-condition?
Thanks, Andree
I couldn't wrap my mind around the second series of tests you propose, I can't find my way around that advanced logic... However I can say that regarding "1)do we need both lines?" the answer is no. The DEV_INIT2 line is needed but I could comment out the GPO32-ENABLE line and get a boot without a hiccup.
Both patches do not enable GPO32 anymore, but
h10-test-01: does one-time enable DEV_INIT2 and keep it enabled even if USB is not connected
h10-test-02: does enable DEV_INIT2 for initialization and disabled it afterwards. re-enabling takes places on USB-connect.
Could you please test whether 01 (or even better: 02) still work?
Thanks in advance, Andree
@Angyman: You're right :/ Anyway, it shouldn't have compiled then...
1) Playing MP3 V0 Audio - Scrolling through the file browser shortly after starting the playlist is noticibly "chunky" and can generate a reproducible skip.
2) Playing FLAC Audio - The scrolling is much better (though there's still an occasional noticible lag) and I cannot generate a skip (despite my best efforts!).
2) With audio stopped the scrolling is also slow/"chunky", but in a different way.
1) Same.
2) Very occasional (after 5 pages or more of helvR12) and brief (half a second) lag in scrolling.
3) With audio stopped you need to scroll a lot more (2 pages of helvR12) before the scrolling slows down at all. At which point it stays for a short period and then returns to normal.
This one will set/unset the DEV_INIT2 for USB for all PP5020-targets.
If this still does not work, please re-restore the line "GPO32_ENABLE |= 0x200;" in usb-fw-pp502x.c (you can see where it is deleted the patch).
But with my iPod nano it seem to result in some problems with the button handling with the solitaire plugin which requires you to press the menu button and select at the same time to return to the menu after starting a game. This works perfectly with out your patch applied but dose not work at all with your patch.
Nothing happens when you hold down the menu and select button until I have been holding down the button long enough to cause rockbox to reboot (the only way to exit the plugin as you can't return to the menu to exit).
angryman: so you still making the custom builds, im a fan, does this mean you gonna incorporate this patch too in ur builds?
so is the h10-test-02 patch, the final for h10 now ?
andree, any more tests to be done, id be glad to thanks
Nikkhil, you may test the pp5020-test-01.patch on your H10.
- includes the PP5020-changes which were already validated for H10 and iPod Color/Photo
- fixes error with not recognized key combinations (like MENU + SELECT) for 4G_KEYPAD (iPod 4G, Color, Mini, Mini2G, Nano, Video)
No further changes.
@Nikkhil: Mono is making the custom builds now. But he follows also this thread and offered already testbuild.
update: v12 working brilliant running a bench for h10 will post in a while
I would like to transfer such results to the patch, so please post your results here.
My last FLAC test (about 2 months ago) gave 7h 23m, and a 200kbps MP3 test at the same time gave 6h 50m. I'll try and run more tests over the weekend, including a reference test with the Apple firmware.
- sets several PP-registers to the minimum startup configuration -- thanks to preglow for the testing!
- adjusts the estimated runtime via adaption of assumed current consumption for nano / e200
This test patch will be merged to v13 after positive feedback from further nano-users.
If someone has found similar configurations for other players please post the resulting code sequence here.
- patch v11 with GPO32 line commented out (see comments 2/3 days ago) : 6h08
- patch v12 (2nd edition, as built by Soap) : 5h55 ... Note, strangely the bench reports 1:58 hours left when the bench is stopped. Since I didn't have to remove battery and reset the player I doubt there was any player freeze. Still, it stopped around ~3800v while previous test stopped at ~3700.
- For kicks, a previous bench with a regular build, two months ago, gave me 4h45 runtime.
Attaching both if someone wants to inspect 'em.
Now benching v11-based 'h10-test-01.patch' since it hasn't been run yet (..test-02 was ran by Sasha).. It boots up well, let's see runtime.
DEV_EN2 / CACHE_PRIORITY & DEV_INIT2 work without changes. DEV_EN & DEV_INIT1 don't initialise rockbox properly but resume music & buttons/wheel still function. How do you work out these numbers?
Please try to set to "DEV_EN = 0xc4004124" and retry -- 0x800 (=I2S) and 0x2 (ExtClock) will be set by rockbox later on. 0x40 (SER0), 0x10 (??), 0x1 (??) are not needed on iPod Video and nano -> if it does not start, please try to check it Bit by Bit.
- sets several PP-registers to the minimum startup configuration -- thanks to stel for the testing!
- incorporates all changes contained in v12 and nano-test-01
Please check for any problems with startup or other malfunctions.
Thanks a lot!
Andree
#if defined(SANSA_E200) || defined(SANSA_C200)
/* Reset all devices */
DEV_RS2 |= 0x20;
DEV_RS = 0x3bfffef8;
DEV_RS2 = -1;
DEV_RS = 0;
DEV_RS2 = 0;
/* set minimum startup configuration */
DEV_EN = 0xc4004124; /* DEV_EN1 minimum configuration for startup */
DEV_EN2 = 0x00000000; /* DEV_EN2 minimum configuration for startup */
CACHE_PRIORITY = 0x0000003f; /* DEV_EN3 minimum configuration for startup */
// GPO32_ENABLE = 0x40004000; /* GPO32_EN minimum configuration for startup */
// GPO32_VAL = 0x00004000; /* GPO32_VAL minimum configuration for startup */
DEV_INIT1 = 0x54000000; /* INIT1 minimum configuration for startup */
DEV_INIT2 = 0x40000000; /* INIT2 minimum configuration for startup */
#elif defined (IRIVER_H10)
- use the same register startup configuration for c200 like for e200
31.93 / 48.60
SVN:
40.99/56.90
e200-test w/ dev_en bit 3 set to zero:
31.93/48.95
I also played around with some of the AS chip's power management registers, but the results are a bit odd so I think I'm missing something.
e200test w/ CPU @ 1.05:
32.22/49.3
e200test w/ VIO @ 3.2 (default is probably 3.6?):
32.13/49.50
e200test w/ VIO @3.2 and VDD@ 1.05:
32.00/49.3
There doesn't seem to be a consistent trend, so I don't think this is working correctly. That or I need to explore the AS register defaults. Does anyone have a plugin or something similar setup to view register values that I could easily modify? Its possible we're already using lower then default values inadvertently.
Btw, the configuration of the iPod Video's power management is not as up-to-the-limit as with other players. It will shut off @3.45V, most other players shut off @3.3 or even below. I will do a test with lowered shut off level on my 5G and report here -- should give a few minutes extra.
- minor change for e200 (removed 0x4000 from DEN_EN, based upon stel's test report). this needs to be validated on both e200 and c200.
- major change for h10. added startup configuration for h10 based upon PaulPosition's tests. this needs to be validated on h10 and h10_5GB
- removed initialization of 2 register bits from adc-pp5020 which were (from the source code comment) only use for h10 (remote and wheel). disabling these needs to be validated on other PP5020-targets.
- inserted some additional debug information to the "i/o port menu" (DEV_INIT1, DEV_INIT2, GPO32_ENABLE)
- inserted some additional debug information for IPOD_4G_PAD scrollwheel
If you use this patch please post your player type and i/o port settings (idle, HDD off) here.
Thanks for your continued support!
I'll benchmark the battery tonight and post results tomorrow morning. -- Thanks.
GPO32_VAL(10000004)
GPO32_EN (10000204)
DEV_EN (C4005926)
DEV_EN2 (00000000)
DEV_EN3 (0000003F)
DEV_INIT1(54000000)
DEV_INIT2(00000000)
and it is this which Marc_Guay is using.
Just finished benchmarking the pp5020-test-02 patch for runtime data.
Patched over release 16133 (the one the patch was, seemingly, made for). -- Same set of files (double album of mp3, 192kb), volume at -20db, cleared the settings on booting so default wps, etc., device on hold (so no interruption).
** 06:49:04 ** (file is attached below)
For comparison here are my previous benchmarks :
v11 - 6:08 (see http://www.rockbox.org/tracker/task/8379#comment20826)
v12 - 5:55 (but strangely it seemed to stop before completion, see http://www.rockbox.org/tracker/task/8379#comment20826)
svn (r??) from jan 19th - 05:27 <--(Strange considering a bench two months ago gave me only 4:45. Maybe different files..?)
Original Firmware gives me about 7:15 (through piping output into my soundcard's line-in, recording and checking the wave's lenght)
Considering those tests aren't exact science (there may be quite a few minutes lost to battery dying before disc-write) those results are VERY exciting to me and, I suppose, all H10 and portalplayer users.<