Sansа Clip Zip - Improve battery life

[saratoga]

Well, but I observe that also when compiling the bootloader, the file 'button-fuzev2.c' get's compiled:

The bootloader includes button drivers (and most other drivers).

Why is it not sufficient to just have a small bootloader ("fuzpa.bin") without the original firmware?

You could try and implement this, but without the original firmware as a backup you would brick your player if the main rockbox build or bootloader USB became inoperable. 

Does it fallback to the original firmware automagically if we don't have the .rockbox-tree on the device?

No I think it is too late to boot the OF by then since the bootloader will already have run.  Instead it tries to use the bootloader USB mode.  To boot into the OF you must start the process before the bootloader itself runs (since it will overwrite part of the OF in memory).  That is why you must hit a button as soon as you hit power to boot into the OF, any later and its already overwritten.  Possibly this could be changed but there is no reason to.

[saratoga]

I did notice that during frequent boosting some button inputs are skipped, although maybe that is unrelated.

For fuse v2 we disable irq when check hold/power buttons, probably we should do same for clip v2.

I will do more testing, I want to make sure that the button problem does not occur in the stock builds before we disable IRQs for 20 microseconds at a time.  It could just be the CPU being overloaded by APE files.  I did test overnight playing APE files, player is still running fine now, so boosting appears quite stable.

I think we should think about committing this in parts. 

First part:  the frequency/voltage scaling code.
Second part:  config file changes to enable frequency scaling
Third part: wait a little while and make sure no one finds a device that breaks when frequency scaling.
Fourth part:  enable voltage scaling.

This way if there is some subset of devices that needs different voltages or delays we will be able to identify and correct them more easily.

[Mihail Zenkov]

I will do more testing, I want to make sure that the button problem does not occur in the stock builds before we disable IRQs for 20 microseconds at a time.

Probably we can enable irq before second delay.

I think we should think about committing this in parts. 

Good. At first step I suggest test and commit frequency changes and related fix for buttons .

[oid_maps]

Adding the delay fixes boosting (well played for a few minutes at least).

Removing the second delay causes immediate reboot. 

I did notice that during frequent boosting some button inputs are skipped, although maybe that is unrelated.

Edit:  Both delays set to 10 works pretty well, will try other values:

http://mit.edu/mgg6/www/rockbox-clip_10_10delay.7z

Edit2:  diff:  http://mit.edu/mgg6/www/amsv2_scaling_v10.patch

Confirmed: For my fuzev2, both delays to 10 does _not_ work
(I did apply the following patches, in that order:
amsv2_scaling_v9.patch
fix_button_clipv2_irq.patch
fix_hold_fuzev2.patch (with adjusted delay values)
rockbox-gui_boost.patch
rockbox-restore_irq.patch
rockbox-usb.patch

and an own patch which enables maximum hardware supported frequency range (76 .. 108 MHz) and finest granularity (0.05 MHz) of the radio tuner)

[saratoga]

Adding the delay fixes boosting (well played for a few minutes at least).

Removing the second delay causes immediate reboot. 

I did notice that during frequent boosting some button inputs are skipped, although maybe that is unrelated.

Edit:  Both delays set to 10 works pretty well, will try other values:

http://mit.edu/mgg6/www/rockbox-clip_10_10delay.7z

Edit2:  diff:  http://mit.edu/mgg6/www/amsv2_scaling_v10.patch

Confirmed: For my fuzev2, both delays to 10 does _not_ work

If you're referring to the 10 delay above, thats for the ClipV2, it won't do anything on the Fuze. 

[oid_maps]

OK, first delay 19, second delay 4 works for me (fuze v2).

How I tested: Just switching on the device and see if in "hold"-position screen stays dark.

Are there more/ special conditions I should test?

[oid_maps]

Adding the delay fixes boosting (well played for a few minutes at least).

Removing the second delay causes immediate reboot. 

I did notice that during frequent boosting some button inputs are skipped, although maybe that is unrelated.

Edit:  Both delays set to 10 works pretty well, will try other values:

http://mit.edu/mgg6/www/rockbox-clip_10_10delay.7z

Edit2:  diff:  http://mit.edu/mgg6/www/amsv2_scaling_v10.patch

Confirmed: For my fuzev2, both delays to 10 does _not_ work

If you're referring to the 10 delay above, thats for the ClipV2, it won't do anything on the Fuze.

Ah, OK. That wasn't clear from your writings, and since we were discussing fuzev2 and you didn't state otherwise I assumed you meant fuze v2.

[saratoga]

I pushed the updated delays for the clipv2.  If 19,4 are the lowest values that work on the Fuzev2, should I commit 20,5 to be safe?  Or maybe even 22,6 just in case since we only tested on a single device?

[Mihail Zenkov]

I think 20,5 should be good for start. If we start with 22,6, we do not dare to reduce it in the future and do not know optimal value.

[saratoga]

One question, any idea why such a long udelay is needed with frequency scaling? I'm surprised that button read out should be so dependant on CPU frequency.

[saratoga]

Committed fuze delays and usb boost. 

[Mihail Zenkov]

One question, any idea why such a long udelay is needed with frequency scaling? I'm surprised that button read out should be so dependant on CPU frequency.

Not sure. Probably delay by udelay depends not only from CPU freq but also from PCLK. Or we need much more delay when GPIO work on boosted clock.

[saratoga]

Test builds with frequency scaling enabled but not voltage scaling:

http://mit.edu/mgg6/www/rockbox-clipv2_frequency_test.7z
http://mit.edu/mgg6/www/rockbox-fuzev2_frequency_test.7z
http://mit.edu/mgg6/www/rockbox-clip+_frequency_test.7z
http://mit.edu/mgg6/www/rockbox-clipzip_frequency_test.7z

Source for just this change:

http://gerrit.rockbox.org/r/#/c/1242/

Edit:  Updated builds.

[Mihail Zenkov]

Source for just this change:

http://gerrit.rockbox.org/r/#/c/1242/

It not critical, but I think we should change CPU_FREQ to 192000000. Also we should add changes for config/sansafuzev2.h.

[saratoga]

Thanks, overlooked both of those.