FS#8379 - power consumption issues PP502x/5G
Attached to Project:
Rockbox
Opened by Andree Buschmann (Buschel) - Thursday, 27 December 2007, 19:14 GMT
Last edited by Robert Kukla (roolku) - Sunday, 10 February 2008, 16:12 GMT
Opened by Andree Buschmann (Buschel) - Thursday, 27 December 2007, 19:14 GMT
Last edited by Robert Kukla (roolku) - Sunday, 10 February 2008, 16:12 GMT
|
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.
Thanks, and let us know whether there's anything left to check.
- bugfix for initializing PCF (power controller), this did not work in svn as I2C must be initialized before setting PCF registers
- added "View PCF register" to the engineering menu
- changed the voltage supplies after several tests:
- DCDC1 -> seems to be core voltage (default = 1.2V), not changed yet it was instable for 1.1V and below
- DCDC2 -> unknown (default = 1.2V), switched off
- DCUDC1 -> unknown (default = 1.8V), not changed as immediate reset happens when switching this off
- D1REGC1 -> seems to be WM-codec (default = 3.0V), set to 2.7V as first step (works also with 1.8V)
- D3REGC1 -> seems to be LCD/BCM (default = 3.0V), set to 2.7V (works with 2.5V but looses contrast then)
- PCF register configuration is contained in <firmware/drivers/pcf50605.c>
This version runs in a battery bench for 8h now and shows estimated savings of ~2.5mA even without changing the core voltage.
I am very interested in support with playing around with those settings.
Maybe you can perform similar tests with a non-Video iPod?
Maybe you can check to what voltage we can the set the core for stable action?
Maybe you can check what is the minimum voltage for the WM-supply without artifacts on high volume?
Fiddling out how PWREN1 can be set/unset would be a great help!
Perhaps RMAA tests should also be performed to measure audio output before and after changing the voltage on D1REGC1?
Good catch! No wonder my Sansa power measurements for different core voltage settings on the AS3514 were inconsistent.
Regarding the Wolfson chip. As there is no spec available (at least I did not find any) I assume to have similar voltages possible than with other Wolfson codecs -- which can be driven from 1.8V to 3.6V (PCF default = 3.0V).
About the LCD I am not sure. I've found some spec which claim their LCDs to work down to 2.5V. When changing the voltage on my 5.5G I saw no visible effect when lowering it from 3.0V to 2.7V. From 3.0V to 2.5V you'll see the contrast and brightness is going down a bit, when using 1.8V there are heavy artifacts visible on screen.
Maybe someone will find what Apple OF does with these registers?
Further testing results:
- lowering core voltage to 1.15V is not stable -> should be left at 1.2V (which is PCF default configuration)
What kind of changes does this patch to the PCF-configuration?
- switches off DCDC2 (this will have no effect to the core's power supply as the default PCF-config is set to only use DCDC1 as core voltage)
- lowering voltage supply of LCD to 2.7V
- lowering voltage supply of WM-codec to 2.7V
- all other settings are equal to the defaults of the PCF when not touching the registers
with the unofficial build 16150,it can play 9 hrs of flac lossless music
with the official build 16170,it can only play 6hrs 25mins of flac music.
i installed a 1200mAh battery for the ipod though.
I've made a full battery bench with pcf-test-02 and reached 14:00h with my 5.5G 30GB (playing 179kbps-MPC at -56dB, no WPS active).
I've made a full battery bench with pcf-test-02 and reached 14:00h with my 5.5G 30GB (playing 179kbps-MPC at -56dB, no WPS active).
- iPod Video: uses 2.6V for the LCD and 2.5V for WM8758
-> needs check for any issues with display
-> needs check for any issues with audible distortions (at higher volumes)
-> needs battery bench
- 4G grey: sets the registers for minimum startup configuration
-> needs check for issues with startup
-> needs battery bench
playback time has been lengthened a bit to 9 hrs 23mins. flac level 5 format,-33db of volume,no WPS active.
the issue i noticed was the weak constrast in black and white colour. not sure if its done purposely for reducing the power consumption on display.
Are you sure the contrast has degraded with using this patch-version?
thats a bit odd if this isnt done purposely.
can anyone with a iPod 5G 60GB or 5.5G 80GB make battery runtime tests with and without pcf03-patch against a svn revision which is <16104? It seems like these iPods have severe HDD-problems with the svn since revision 16104. Most of the latest test runs might be invalid for those iPods and might show far to short runtime.
Thanks a lot for your support!
I seem to have got 11:54 on svn, and 13:13 with pcf-test-03. That is a lot less than I got last time with (16:40 with device_disables_v07.patch). The files were different however (although they were all 96kbps mp3s with the same encoder settings), the old measurement was made without battery_bench (I used the running time to get the value), and wps was definitely off.
Here is a patch to update the battery estimation code for the e200 and c200 with my measurements. Would you mind adding it to your patches so that it gets committed at the same time?
Flarkis, with what kind of build and patch did you test? e.g. self built (patch pcf03 + svn 16134) or pre-built (soaps build -- which version).
Did you test against the unpatched version?
What should you take a look at when using these patches?
- does it start?
- does it play audio?
- does it start, but does not update LCD?
- contains all previous patches which were tested on the different players (H10, C200, E200, iPod Video (30/60/80GB)/nano/4G grey/4G color)
- contains saratoga's changes for e200/c200 battery settings
The patch can be further optimized for
a) 4G color and mini 1G/2G through finding the minimum register enables for startup (see test patched for iPod color above).
b) all iPods -- except iPod Video, this has been done already -- through checking/disabling/lowering the voltage supply via PCF power controller
Both optimization methods cannot be done for those devices by myself as I do not own these. So, if you want to support this patch please ask what to do or meet me in IRC.
Question: For mrobe100 there was a change in svn to choose the same method to reset PP502x-registers like the H10 uses. Is this still valid when using this patch?
AceNik: I do not have commit rights.
disorganizer: Please use v14.
If I compare the numbers, it seems that on v16057 the wps makes a difference of 15% while on v16179-PCFv03, the difference is more than 20%. Does that make sense (i.e. does your patch help more with the wps off than with the wps showing) ?
Nevertheless 15% sounds too much...
Also, you might consider asking Bagder for commit access yourself.
sorry, I've made a mistake (typo) in the ipod color test patches :( Here's the corrected one...
based upon direcow's testing results here is the next patch.
- minimum register configuration for 4G color/photo
- switching off/on the IDE0-enable register in parallel to HDD power for 4G grey, 4G color/photo, mini 1G and mini 2G
So, this patch needs testing on the targets above. For all there should be tested whether HDD-access re-enables fine after HDD-sleep. For 4G color/photo it should of course be tested whether the target starts fine...
We're getting closer to finish this one :)
next test-patch for iPod Video's PCF-configuration.
- use ECO-mode for most of the (active) voltage regulators to save some power in the PCF-chip
- usage of ECO-mode was checked against specification of PCF, e.g.
a) power supply for Wolfson codec will not be set to ECO as this regulator cannot deliver >5mA in ECO-mode
b) IOREG power supply is not set to ECO as this would make I2C operation to PCF impossible
This patch will of course need battery benching as well as checking for any weird side effects (which I did not see so far).
This patch is only valid for iPod Video.
test patches may fail -- the last one did. In PCF-v05 there were instabilities reported. The following patches were created to check if ECO mode for DCD regulator or both the DCD and DCUD regulator were the root cause for this.
pcf-v06:
- no ECO mode for DCD regulator
- some code cleanup
pcf-v07:
- no ECE mode for DCD and DCUD regulator
- some code cleanup
What has to be clarified before bringing the basic patch to svn?
FS#8568(backrolling spinlock) with this patch. The battery consumption issues for iPod 5G 60/80GB in svn itself should be solved with this additional patch.It contains general optimization for all PP502x-targets, special optimizations were made for H10, Sansa C200, Sansa E200, iPod 4G gray/color/photo, iPod nano, iPod Video 30/60/80GB.
All targets:
- only enable USB-device, if needed -> saves 6-8mA
- use 24MHz as default clock -> more runtime for low consuming codecs like MPC, FLAC
- enhanced debug menus:
- additional registers in "View I/O ports"
- added "View PCF registers" (for targets having PCF power controller)
- "Debug Scrollwheel" (for 4G-scrollwheels only)
H10, E200, C200, iPod 4G, nano, Video:
- special "minimum" settings for the enable and init register of PP502x
E200/C200, iPod nano, Video:
- adapted assumption of current consumption for better runtime estimation (E200/C200 by saratoga)
- corrected battery capacity for C200 (by saratoga)
iPods with 4G scrollwheel:
- switching off scrollwheel, if hold is active
iPod 4G, nano, Video:
- switching off/on IDE-device in parallel to HDD-power
PP5020:
- only use ADC device, if needed by target (H10)
iPod Video:
- configure PCF power controller to lower voltage for LCD and WM codec supply
1) The PCF code takes care of setting sensible defaults for the Video, but no the other devices. You're certain this is OK to do?
2) It disables the vout pin on the dock, which apparently is needed for some accessories to work with rockbox.
Also, I would like to leave the core clock speed at 30MHz for now. We can still adjust it later, but some people are uncomfortable with doing it all at once. Could you make these changes? I could do the PCF ones I guess, but not the cpu clock changes.
1) + 2) I understand your worries and made the following changes: Leave the iPod Video settings and re-add the settings for all other iPods like they are set in svn. Also keep the dock connector pin enabled for all iPods.
24MHz/30MHz: When not changing the normal clock to 24MHz we will loose runtime significantly for the low consuming codecs like MPC and FLAC. This was one of the main changes in this patch. As this configuration has been well tested over a long period I would really like to keep it this way.
I think it should be done as a separate commit, and only once everyone else who worked on the Ipod port has had a chance to comment.