Rockbox

This is the full development version of my changed sources.

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.

   device_disables_v02.patch (8.6 KiB)

FWIW, I tried this on a sansa e200 and I couldn’t discover any problems running this patch so far.

The 40MHz as default clock does not have any effect on runtime.
Runtime on a 5.5G 30GB is now 11:46h (10:24h before) with mpc-playback.

How is using 40mhz as the default supposed to improve battery life? The ratio of boosted to unboosted should still average out to the same average clock, right?

New results:
- DEV_INIT2 = 0×40000 must always be set for button/scrollwheel. If disabled the hold-switch detection is not wrking anymore.

Small cleanup:
- added new DEV_USB0 (0×80) to pp5020.h and renamed DEV_USB to DEV_USB1 → both needed for USB
- added new INIT_BUTTONS (0×40000) 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.

   device_disables_v03.patch (8.7 KiB)

Sorry, my fault… DEV_USB0 must be 0×8, not 0×80…

   device_disables_v04.patch (8.7 KiB)

Further cleanup in button-clickwheel.c and adaption of power consumption for iPod Video to new results with this patch.

- clickwheel: use already defined #defines for some register values
- clickwheel: removed unneccessary commands
- powermgmt: power consumption is about ~36mA now → corrects runtime calculation

   device_disables_v05.patch (10.4 KiB)

Hi all,

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…

   device_disables_test_needed_v... (14.4 KiB)

Hi all,

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?

   device_disables_v06.patch (19.4 KiB)

With this patch I hear (noticable but quiet) clicks and audio glitches - sounds like a few dropped or zero’d samples every now and then. From watching the audio buffer info it *seems* that the audio glitches occur just around the same time as the 24MHz→80MHz transition (although it didn’t seem they occurred in the other direction). Running a plugin that boosts cpu permanently (e.g. pacbox) causes the glitches to go away while that plugin is running.
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.

jhMikeS has a number of thoughts on irc: http://www.rockbox.org/irc/reader.pl?date=20080107

Here are the results of my current measurements on the Sansa E200. All measurements were taken after letting the sansa idle for 2 minutes so that it’s current consumption stabilized down to 10 uA.

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.

Some googling around suggests to me that 30uA is probably not a realistic current draw for a PLL in the MHz range. How sure are you that the PLL is actually disabled in the above build? Is it possible that its still running but muxed off from the core clock?

Saratoga, first thanks for your help with testing – very appreciatetd :)

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…

update with following changes:

- 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 = 0×40004000; /* GPO32_EN from own tests, no effect? */
GPO32_VAL = 0×00004000; /* GPO32_VAL from own tests, no effect? */

thanks a lot!

   device_disables_v07.patch (18.1 KiB)

DEV_EN, bit 0 is not needed but saves little power.

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.

Ok more measurements. Done at 4v, but using a crappy DMM since someone borrowed my nice one. Probably only accurate down to 200uA or so, and had lots of trouble with the load averages since the refresh rate was slow.

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?

Also one other thing:

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!

Just another thing to test. This test-patch enables the I2C device only during I2C-activity and disables it afterwards. On my 5G I still get time/date and battery voltage read out with this one.

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.

   device_disables_i2c.patch (1.1 KiB)

After applying this patch, my e200 refuses to shut down. It just says Shutting Down and hang there.

Interesting, some questions:

- 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)?

I’m using pure v7 (mo modifications) + I2C patch. After removing the I2C patch everything worked fine.

That’s pretty interesting. I wonder, if there is any i2c-commanding which does not use the i2c-pp functions… 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! :)

is this patch ready to be tested on the h10[20GB], i see only one comment saying support exists , but id like to know what kind of features exists for the h10 from this patch please, thank you

This patch’s main changes should also show effect on and work for H10. Please post your results here when you could test it.

With the v7 patch, rockbox is now reporting 30MHz (not 24MHz). Just rebuilt to reconfirm. Is that just a misreporting or is it now running at 30MHz (with PLL disabled)?

v7 seems to be working great for me on the sansa e280. I’ve just run a battery bench using 380kbps lossyflac files and it ran for 21:27:51 Using the same build & settings without the patch I was getting 16-17Hrs. I’m currently running a test with 192kbps MP3 files, should be complete later today. If there’s anything else I can help with let me know. And may I say Thanks Andree for your patch.

Steve, thanks for letting me know – this is _really_ good news :o) I will post an update of the patch later today. With this one you may test another setting for the normal clock. As far as I understand flac is needing less cpu power (~13MHz) than we spend right now (~24MHz with v7-patch). With further lowering of normal speed you may save some additional mA’s – but the GUI responsiveness will become worse.

Normally people would spend a few minutes interacting with the device and then let it play.Could you not boost the mhz the moment the ui is used?

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.

Next version:

- 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!! :)

   device_disables_v08.patch (19.9 KiB)

With the v7 patch, rockbox is now reporting 30MHz (not 24MHz). Just rebuilt to reconfirm. Is that just a misreporting or is it now running at 30MHz (with PLL disabled)?

misreporting as I forgot to include a .h-file into the patch…

OK, I’ve changed the #if 0 to 1 and set PLL_CONTROL to 12MHz, and now doing a quick flac test on my e280. The sound is still OK but I’ve noticed that CPU Freq displays 24 with a lot of boosting to 80. Would you expect this or should it be displaying 12Mhz?

This is exactly what I expected. The 24MHz comes from system-target.h which is not changed – it has no influence on the real clock. The higher boost ratio shows that the change is working.

IMO, why don’t we both decrease the normal clock and increase the boost clock so that we can reduce the boost ratio. That would be more power efficient.

Not particularly. You’re still going to have to boost just as often, you’ll just spend less time boosted at higher speeds. How often you need to boost depends on what your minimum clock is set at. How long you spend is based at your maximum clock. Since power consumption should be close enough to linearly related to CPU clock, 5 seconds at 80 is equivalent to 4 seconds at 100 in terms of power consumption, and also (assuming a consistent ratio of cycles to instructions processed) the same amount of work gets done. As well, several of the devices shouldn’t be used above 80mhz in the first place. There may be a difference, but it really ought to be trivial. I’d be just as concerned about the minimum speed. If it’s lower, the buffer will empty more quickly (less filling will happen while it’s emptying) and boosts will have to happen more often. Because of this, more time is spent changing the CPU speed from one to another. I’m not saying I’m particularly concerned about that, but if we’re going to quibble over tiny quantities of power, someone’s going to have to do some serious testing to see both what the actual most efficient minimum speed is, as well as the actual most efficient boosted speed is, by coming up with a rather extensive testing process, I think.

Next version:

- 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.

   device_disables_v09.patch (23.3 KiB)

My 12Mhz test using patch_v08 has just finished. Total runtime - 21:05:00. This is a bit less than using 24Mhz. I’ll give 0.9 a try.

Strange… I’ve expected more runtime. Did you use the same settings (volume, wps off/on, same playlist) and was the battery fully loaded?
Can you make available the battery_bench-file somewhere?

Yes, all settings where the same but I did use a later build (a couple of days between them) and battery was fully charged before I began the test. Something else I noticed on v08 & the same thing is happening on v09 and that is the menus/display jumps around when you move around the menus. I thought this was down to the lag. Its better on v09 but it’s still there.

   battery_bench_sansa_flac_v07.... (205.8 KiB)
   battery_bench_sansa12MhzFLAC_... (578.5 KiB)

Forgot to mention, note the difference in file sizes of the two benchmark files?

Another way to save some power may be to lower the processor voltage. On PP502x targets, it is possible to lower the processor voltage from 1.2V to 1.05V by configuring some bits in the CVDD/DCDC3 register of the AS3514 module. I tried this some time ago on my sansa e200 and it seemed to work OK. ADC channel ADC_VDD in the I/O port debug menu indeed shows a lower voltage. I haven’t done any battery benchmarks though.

Steve, the display issues can be reproduced by other sansa users. We are checking the reason right now. Regarding the largely increased bench-file: I assume the switching from very low current (12MHz) to high current (80MHz) causes a short drop of battery voltage, during the 12MHz it goes up again. You can see lots of pending with a difference of 1mv.

Ref the benchmark files, Its also me not being very observant, the second file actually contains 3 different benchmarks.

If the Vcore really can be adjusted from 1.2 to 1.05v at lower frequencies, I would expect a large improvement.

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!).

Update needed.

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.

   device_disables_v10.patch (23.3 KiB)

Ok got my good DMM back.

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, 0×21, 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.

My last battery bench (30GB 5G with mpc) clearly shows a small gain (equals ~0.2mA = ~0.6MHz) when using v09 (12MHz normal clock) vs. v08 (24MHz normal clock). I assume mpc will sometimes (depending on the actual bitrate) need less than 24MHz – that’s where the small gain comes from. So, I still hope to see stel’s next measurements with flac showing even more gain compared to the 24MHz-setting.

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?

Will this negatively affect Peakmeters and other animated UI elements (scrolling lines, for example) at periods when there’s no user input? Some players are quite visible even when the backlight is off, and the UI shouldn’t noticeably change in performance just because the user hasn’t touched the player for 4 seconds.

Like I suggested in IRC, put the cpu to 12MHz when the backlight is off (let me finish before being yelled at….), leave it at 24 when its on and go up to 80 for boost, If the codecs have no problems running at 12 and the only reason to not always run at that speed is the UI then I tihnk its fine when the light is off…

now, on the targets which are visible with the light off, either disable this, or make it user configurable.

hey Mr.Andree, firstly thanks for all the efforts & quick initiative to respond so fast, i tried the patch v10, with my h10 [20GB] today, im sorry to report that it hangs on the rockbox logo screen & does not proceed any further.
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?

Hi Nikkhil, can you please try to choose older patch-versions step by step and report from which patch-version on your unit doesn’t start?

I’d guess its probably the DEV_EN bits. They’re not all the same on every PP target. The Ipod and Sansa ones may disable something needed on the H10.

hey buschel, i tried patches, V10,9,8,7,6 , none seem to make the patch work on h10 [20GB].
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

hi nikkil, please also check the older patches as these do not have any changes in the clock setup. the change in power-ipod is not relevant for h10 and there should no change be needed there. i assume the clock setup is the problem (came in with v6). you may also try to change “#if 0” in syste-pp502x.c to “#if 1” in v10-patch.

Hey andree,
change “#if 0” in syste-pp502x.c to “#if 1” in v10-patch –> does not work
trying patches V 1-5

hey andree,
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

hi nikkhil, hmmm then the only relevant change left is the disabling of DEV_USB0 and DEV_USB1, seems like H10 may need them after the initialization. You can easily check via commenting the two lines DEV_EN &= ~DEV_USB0 and DEV_EN &= ~DEV_USB1 in usb-fw-pp502x.c. or simply restoring this file after applying the patch.

commented the 2 lines in v10 still gets stuck at the rockbox logo?

My 18MHZ test has just finished. 21:14:04, a good result, but still not as good as my original 24MHz test. Maybe my battery is getting tired because of all the full discharges (about 7 over the past couple of weeks). I just want to add that all my tests use default settings except - bass 7db, brightness 1, & my own text based WPS with no scrolling or peak meter. During testing the unit is left alone until power off. I will take a break from the battry tests for a while but if theres anything else I can help with, give me a shout. Thanks again for the work you are putting into this patch Andree.

   battery_bench_sansa18MHzFLAC.... (196.1 KiB)

nikkhil, now it’s becoming interesting. additionally to commenting the 2 lines mentioned above please add the following lines to usb-fw-pp502x.c:

add “GPO32_ENABLE |= 0×200;” before “outl(inl(0x7000002C) | 0×3000000, 0x7000002C);” (~line 35)

add “DEV_INIT2 |= INIT_USB;” before “while ((inl(0×70000028) & 0×80) == 0);” (~line 46)

nikkhil, when i first started to play with the USB-stuff i had similar issues. so i really assume this must be the place to look at – especially as the v01-patch doesn’t touch anything else which is used by h10.

Andree,

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

Alexandre, that’s good new :o) Some questions: Did you need to do _all_ the (4) changes I described? I am aksing because switching off USB0 and USB1 will bring the most savings in power consumption. The finest would be, if the GPO_ENABLE and/or DEV_INIT2 is only needed while USB-initialization and can be switched off together with USB0 and USB1 at the end of the USB-initialization – and of course switched on again together with USB0 and USB1 when USB-insert is detected.
Can you try to figure this out?

hey andree, as confirmed by alexandre for the 5GB, the 20GB also works with the following changes:
1. commenting the two lines DEV_EN &= ~DEV_USB0 and DEV_EN &= ~DEV_USB1 in usb-fw-pp502x.c.
2. add “GPO32_ENABLE |= 0×200;” before “outl(inl(0x7000002C) | 0×3000000, 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.

   h10_v10device_disables.patch (23.4 KiB)

i tried the other alternative too it works, now i only added these lines
1. add “GPO32_ENABLE |= 0×200;” before “outl(inl(0x7000002C) | 0×3000000, 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.

patch for the above incase anyone else trying, also an this be treated as a generic patch? v10 with h10 support?

   h10_v10device_disables2.patch (23.4 KiB)

Hold ON
FLAC
Default Settings & Theme
Volume -20db
Total 21h 52m
Awesome.

   SansaE200-battery_bench-FLAC-... (213.7 KiB)

New patch version v11:

- 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 &= ~0×200; DEV_INIT2 &= ~INIT_USB;” right below the “DEV_EN &= ~DEV_USB1;” plus adding “GP032_ENABLE |= 0×200; DEV_INIT2 |= INIT_USB;” within the “if (retval)”-condition?

Thanks, Andree

   device_disables_v11.patch (20.5 KiB)

Made a mistake in my total time report, should be 20h 53m.

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.

PaulPosition, taking your result into account I’ve attached the following patches based upon v11.

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

   h10-test-01.patch (20.4 KiB)
   h10-test-02.patch (20.6 KiB)

@Buschel @Paul theres a typo mistake in your code advice… GPO is written with zeros instead of O’s… but anyway i am not sure either if you meant that its now of interest to see if we could just turn on and off the needed DEV_INIT2

I just wonder if this H10-speciality is a PP5020-speciality (as far as I can see the verified targets use PP5022/PP5024)… Are there any other targets which show problems with starting up or USB-detection?

@Angyman: You’re right :/ Anyway, it shouldn’t have compiled then…

h10-test-02 patch seems to work… (didnt test h10-test-01)

I mean it boots up… and music is playing fine… Connecting and disconnecting USB behaves as usual…

SansaE200-v16095-DDv11-BBv01

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.

Same order with v10:

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.

I just downloaded and installed the v11 Device Disables patched Mini 1st gen build by Soap to my iPod mini and has found that it will not boot. It freezes at the boot logo and goes no further. Current svn build r16095 does work.

It might be related to the H10 problems as the 1st gen ipod mini also has a pp5020 cpu. If you tell me what changes to make, I can test any new patches so we can get this to work.

Hi, next pure test patch for the Mini 1G, the 4G iPod, the Color iPod, mrobe100 and tpj1022 – based upon the H10-results.
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 |= 0×200;” in usb-fw-pp502x.c (you can see where it is deleted the patch).

   pp5020-test-01.patch (20.5 KiB)

I have been doing some testing of version 11 of your patch on my ipod nano and Sansa c280 and generally it works well and improves the battery life quite nicely.

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).

whoa, looks like i missed out on a lot, where do i start with now, im confused?
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

Dwyloc, I’ve just recognized the error I’ve made in the wheeldriver (some change for GUI-boost which was not fully removed). Will correct it this evening with a new patch-version, sorry for any inconvenience.

Nikkhil, you may test the pp5020-test-01.patch on your H10.

New version v12:

- 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.

   device_disables_v12.patch (20.4 KiB)

@Buschel: Tested a build now for while (H10_v2.patch) and encountered from time to time a music skip. Once it hung up with an data abort error. It really seems to miss only a bit of power in some occasions. But already wanna say thanks for the work also

@Nikkhil: Mono is making the custom builds now. But he follows also this thread and offered already testbuild.

Please don’t test these patches with any other patches (for example, by way of unsupported builds other than one that JUST includes these patches). It’s quite important that any bug reports here not possibly be caused by conflicts with other patches, and that times here be unaffected by the performance of other patches. You don’t want the people working on this patch to have to possibly spend hours trying to track down a bug that doesn’t actually exist in the patch, rather than working to make it better, do you?

@Llorean: got it but isnt it kinda obvious, not to test a patch with other patches?

update: v12 working brilliant running a bench for h10 will post in a while

If it were so obvious, I would expect people not to be asking about custom builds incorporating this patch. Why does it matter if any of them are: When this patch is well tested it will go in SVN. Until it’s well tested, it shouldn’t be in custom builds. Once it’s in SVN, all custom builds made after that time will have it anyway.

@LLorean: alrite sir, but i just made a comment to angryman i dont see whats wrong, i can make my own builds, it was just a general statement, & yes making an improvement is the real deal i get it.

No maybe it was my fault. I just wanted to say that theres someone else making custombuilds and yes also with this build. But i agree with Llorean that patches shouldnt be mixed during testing. I reported things i found with a build which didnt contain any further patches.

Not sure if feedback for older versions of the patch is still useful, but I’m running r16057 with device_disables_v07.patch on my sansa c250 without any problems. I got 16h40m out of it playing 96kbit/s mp3, without WPS.

Ipod 5G 60 GB, LAME -V5 files, version 12 patch. Total runtime of 15 hours, 53 minutes!

   20080114 battery_bench.txt (236.7 KiB)

Did some of you make tests which is the minimum startup configuration of DEV_EN/DEV_EN1/DEV_EN3/DEV_INIT1/DEV_INIT2 for other players than the iPod Video? If you want to start such tests you may use the configuration for iPod Video as a start (system-pp502x.c, starting with “#elif defined (IPOD_VIDEO)”).
I would like to transfer such results to the patch, so please post your results here.

Ahem, typo → DEV_EN / DEV_EN2 / DEV_EN3 (=CACHE_PRIORITY) / DEV_INIT1 / DEV_INIT2

FLAC test, ipod Color 60GB, original battery (about 2.5 years old), patch v12 - 9h 10m.

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.

New test version for nano-owners.

- 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.

   nano-test-01.patch (21.1 KiB)

Battery benches results.. H10 5gb, 192k mp3 double-album, -20db, no DSP/eq, set on hold
- 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.

   H10_V11_wo_GPO32.txt (112.2 KiB)
   iRiverH10_5+6-v16105-DDv12.txt (106.6 KiB)

Hi Andree, I’ve been testing the DEV_EN / DEV_EN2 / DEV_EN3 (=CACHE_PRIORITY) / DEV_INIT1 / DEV_INIT2 on the E280.
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?

ok, I’ve now also got DEV_EN working using 0xc4005977 on the e280

Hi stel, thanks a lot for working on this! Did you use the iPod Video’s or the nano’s settings basically?
Please try to set to “DEV_EN = 0xc4004124” and retry – 0×800 (=I2S) and 0×2 (ExtClock) will be set by rockbox later on. 0×40 (SER0), 0×10 (??), 0×1 (??) are not needed on iPod Video and nano → if it does not start, please try to check it Bit by Bit.

I used the Video’s settings and DEV_EN = 0xc4004124 worked fine.

ok, I’ve now also got DEV_EN working using 0xc4005977 on the e280

Stel, I am still interested in your results about DEV_INIT1. Is 0×5400000 needed (and what function for?) or can you switch off some of these?

Hi, I’ve tried turning the others off in turn and 0×54000000 is the only one that will work properly. 0×14000000 booted rockbox but the lcd can’t display red. Change any of the others and you get no display. Anything else I can help with?

Hi, next test version for e200 users.

- 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.

   e200-test-01.patch (23.5 KiB)

Saratoga, if you’ve still got your measurment equipment you could do me a favour. Can you measure the power consumption (idle, HDD off) with the newest test patch for e200 (see above)? And can you try to disable DEV_EN 0×100 and do another measurement again?

Thanks a lot!
Andree

Andree, I’m testing the e200 patch now and it doesn’t seem to be working. I’m just removing the GP032 entries to try again. At the moment all I get is a white screen on startup.

Stel, what exactly where the settings and lines of code you’ve enabled for your test build? Seems like I’ve got something wrong here…

The below works using the v12 patch. I’ve commented out the GP032 lines as they do stop the e200 from starting correctly.

#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 = 0×40004000; /* GPO32_EN minimum configuration for startup */
GPO32_VAL = 0×00004000; /* 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)

I’ve just found that GPO32_VAL= 0×10000000; with the above works on the e200

Hi, after some debugging with soap and input from stel → next version for e200 testing, and sorry for any inconvenience.

   e200-test-02.patch (22.9 KiB)

The last patch version for today → changes for c200 only.

- use the same register startup configuration for c200 like for e200

   c200-test-01.patch (22.9 KiB)

e200-test patch (idle/boost=1):

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.

Next version v13 contains all test builds (nano, e200, c200).

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.

   device_disables_v13.patch (21.8 KiB)

Andree, I’ve just found that setting DEV_EN=0xc4000124 will work on the e200

Steve, will be changed with next update.

Next test version for e200/c200, h10 and PP5020-targets.

- minor change for e200 (removed 0×4000 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!

   pp5020-test-01.patch (26.7 KiB)

Just a quick comment : testing this latest patch my H10(5gb) boots, it all seems good. Dunno if you have any use for the values from debug-io screen but they are: GPO32_VAL(20000000) GPO32_EN(21000000) DEV_EN(C2001926) DEV_EN2(00002020) DEV_EN3(0000003F) DEV_INIT1(DC001100) and DEV_INIT2(00000000).

I’ll benchmark the battery tonight and post results tomorrow morning. – Thanks.

SansaE200-v16150-PP5020v02-BBv01

GPO32_VAL(10000004)
GPO32_EN (10000204)
DEV_EN (C4005926)
DEV_EN2 (00000000)
DEV_EN3 (0000003F)
DEV_INIT1(54000000)
DEV_INIT2(00000000)

note, Buschel, I took the liberty of renaming your most recent patch to ‘pp5020-test-02.patch’ since 01 had already been used.
and it is this which Marc_Guay is using.

soap, you are right. I already backup’ed the 01-version, so I didn’t see. Thanks :)

H10 - 5gb
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.

   PP5020-test-02-bench.txt (124.8 KiB)

Hi, this is the next exciting test patch (at least for iPod Video owners):

- 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:

1. DCDC1 → seems to be core voltage (default = 1.2V), not changed yet it was instable for 1.1V and below
2. DCDC2 → unknown (default = 1.2V), switched off
3. DCUDC1 → unknown (default = 1.8V), not changed as immediate reset happens when switching this off
4. D1REGC1 → seems to be WM-codec (default = 3.0V), set to 2.7V as first step (works also with 1.8V)
5. 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?

   pcf-test-01.patch (32.4 KiB)

Btw, when reading the PCF-spec one interesting thought comes up my mind. The DCD voltage (which I assume is core voltage) can be dynamically switched between DCDC1 and DCDC2. All we need is the knowledge how to set/unset PWREN1 (input signal for PCF, maybe connected to some GPIO of PP502x?). Then we could switch betwenn lets say 1.2V for boost and a lower voltage (which needs to be evaluated) for normal CPU clock.
Fiddling out how PWREN1 can be set/unset would be a great help!

Buschel, I am not going to be able to make test builds for another 12 hours or more. Sorry about that.
Perhaps RMAA tests should also be performed to measure audio output before and after changing the voltage on D1REGC1?

bugfix for initializing PCF (power controller), this did not work in svn as I2C must be initialized before setting PCF registers

Good catch! No wonder my Sansa power measurements for different core voltage settings on the AS3514 were inconsistent.

Runtime test finished on my 5G: 12:52h, with custom WPS and the battery not fully loaded. Savings are about 2.9mA. With WPS disabled and full battery this patch should give >14.5h runtime → strrrriiiikkke!

Ok, after some further testing it showed that significantly lowering the core voltage is not possible. Quick test showed that only 1.125V and 1.15V seem to work – will do overnight test with 1.15V now. Further lowering for the non-boosted 24MHz clocking is also not possible, the device freezes. So, there is no need to think about dynamical voltage switching…

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?

Hm, on ipod 5g 60gb I’m having problems actually booting with the pcf_ patch (even with the suggestion to comment out the pcf init)

Sorry, the pcf-test-patch was broken :/ Please use this following one.

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

   pcf-test-02.patch (32.7 KiB)

im reporting the results of battery bench in my 4th gen gray scale ipod.
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.

Palanoid, thanks for the measurement – seems like flac as is the real winning format :)

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).

Palanoid, thanks for the measurement – seems like flac as is the real winning format :)

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).

Next test patch for iPod Video and 4G grey users.

- iPod Video: uses 2.6V for the LCD and 2.5V for WM8758

1. > needs check for any issues with display
2. > needs check for any issues with audible distortions (at higher volumes)
3. > needs battery bench

- 4G grey: sets the registers for minimum startup configuration

1. > needs check for issues with startup
2. > needs battery bench

   pcf-test-03.patch (33.4 KiB)

done a bench with the latest build that is put up by soap (16179)
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.

Hi palanoid, the voltage level adjustments are only used for iPod Videos. All other targets do not use it.
Are you sure the contrast has degraded with using this patch-version?

i didnt apply any patches,but only downloaded the updated build (SVNr16179) from the forums.
thats a bit odd if this isnt done purposely.

Hi,

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!

Here are some benchmarks on my C250 using soap’s builds. I used 96kbps mp3 files, and the volume set to a few steps above minimum. I don’t remember if the WPS was showing.
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.

   SansaC200-v16179-BBv01.bench.... (112 KiB)
   SansaC200-v16179-PCFv03-BBv01... (123.5 KiB)

Hmm, maybe the actual problems with svn also affect the Sansa? What was the svn runtime with older svn (<16104) – I cannot check my database with all the measurements as I am at work now.

Unfortunately I didn’t measure an unpatched build back then (no time. I wish I had one of these players where you can do a full battery benchmark in 5 hours). I can do some tests over the weekend. Do you have any preference as to what revision/patch combinations I should try (I can do my own builds, so any combination is possible) ?

The best would be to use the svn version which you already used with the v7-patch.

Buschel:

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?

   sansapower.patch (2.4 KiB)

Using these patches has a negative affect on rockboy on the 5.5G. On saving state and leaving the menu to return to the game you get a plugin error that flashes by quickly than disapears. I have been able to replicate this error on 2 different 5.5G.

saratoga, I will add your code to the next patch.

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?

Here are the results for my Sansa C250 using (nearly) plain svn v16057 with the sansa battery benchmark patch applied, using the same mp3 files as my v16179 tests, and WPS off (main menu showing). I got 13:44, so there seems to be a regression in svn.

   SansaC200-v16057-BBv01.bench.... (120.7 KiB)

Great, so no main issue of the patch :)

I retested plain v16057 with the WPS showing, and got 11:54. That means that just showing/hiding the WPS makes a 15% difference. I’ll retest soap’s latest builds while paying attention to this.

Hi, as I could not find a willing tester on IRC I’ve generated 11 patch-versions for testing with iPod Color/Photo. If anyone is interested in testing and willing to accept that the player will not start regularly with these patches, it would be appreciated support for fiddling out the register config of a iPod Photo/Color. Please respond here and state the results for each patch.

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?

   ipod-color-patch.zip (72.3 KiB)

hey andree, sorry been very busy, but lookin at the progress, cant you get a decent part of the patch like for a few players tested enough, to be included in the svn ?

errors patching pp5020-test-01.patch with most recent svn. please resync

Next patch version v14 (synched against 16206):

- 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.

   device_disables_v14.patch (34.8 KiB)

Here is my latest testresult : v16179-PCFv03 (soap’s build) on sansa c250 with the same files as usual, and wps off. I got 16:03, so my first test on this build most likely had the wps showing. I’ll redo the test without your patch next. After that, maybe it’s time to see how long the OF lasts.

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) ?

   SansaC200-v16179-PCFv03-BBv01... (141.6 KiB)

Frank, the difference in runtime between WPS on/off becomes larger with my patch. This is because the WPS needs the same amount of current as before, but the current in general was reduced by my patch. E.g. 5mA of 50mA = 10%, 5mA of 40mA = 12.5%.
Nevertheless 15% sounds too much…

Buschel: I’ll commit a patch whenever you’re ready.

Also, you might consider asking Bagder for commit access yourself.

saratoga: I think I shouldn’t do my first try for a commit with such large patch

Hi,

sorry, I’ve made a mistake (typo) in the ipod color test patches :( Here’s the corrected one…

   ipod-color-patch-v2.zip (72.2 KiB)

Hi,

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 :)

   ipod-4G-grey-color-mini1-mini... (35.9 KiB)

Mea culpa, did the same mistake again…

   ipod-4G-grey-color-mini1-mini... (35.9 KiB)

Hi,

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.

   pcf-test-05.patch (35.9 KiB)

Hi,

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

   pcf-test-06.patch (34.1 KiB)
   pcf-test-07.patch (34.1 KiB)

Btw, I would like to start discussion about bringing this patch to svn without the latest ECO-mode changes. I want to take the v2-patch for 4G-grey-color-mini-1G-2G as well as some code cleanup (mostly comments). For further experiments on the PCF-settings I would like to create a new patch-tracker entry, just to have new clean start.

What has to be clarified before bringing the basic patch to svn?

Please use the patch in flyspray  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.

So, this my svn-candidate for the battery runtime optimization 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:

1. additional registers in “View I/O ports”
2. added “View PCF registers” (for targets having PCF power controller)
3. “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

   device_disables_v15.patch (33.9 KiB)

Buschel: Amiconn mentioned two problems he saw with the patch.

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.

Saratoga/Amiconn:

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.

Forgot to attach the patch…

   device_disables_v16.patch (33.9 KiB)

I agree, but I think its reasonable to commit them separately. Changing the base clock speed will impact plugins and the UI responsiveness, so its a somewhat less straightforward change.
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.

Use 30MHz as normal clock, but keep the 24MHz-code.

Hmm, forgot it again…

   device_disables_v17.patch (34.2 KiB)

Please have a look at: http://www.rockbox.org/tracker/task/8581