Sansа Clip Zip - Improve battery life

[Mihail Zenkov]

fuzpa.bin - bootloader + original firmware, you should update it only if you need changes in bootloader or need new original firmware. Don't update it without good reasons - you can brick player if something going wrong.
For regular update to new rockbox revision - just replace .rockbox/* .
For small internal changes (like you doing with this patch) just replace one file - .rockbox/rockbox.sansa

[oid_maps]

fuzpa.bin - bootloader + original firmware, you should update it only if you need changes in bootloader or need new original firmware. Don't update it without good reasons - you can brick player if something going wrong.
For regular update to new rockbox revision - just replace .rockbox/* .
For small internal changes (like you doing with this patch) just replace one file - .rockbox/rockbox.sansa

Ah OK, thanks. But why then is the bootloader 15 MB big? So it's much more than just a loader. Or does it still have the original firmware for some reason -- which just doesn't get executed?

[saratoga]

The bootloader is a few kilobytes, the rest is the OF.

[saratoga]

So if the Fuze v2 is fixed by delay changes () the only device that absolutely does not work is the Clipv2. 

[Mihail Zenkov]

Probably we have similar problem with hold/power buttons in clipv2. Can you test attached patch? If it work - try remove second delay.

[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

[oid_maps]

First, try find lower value for first delay. Then try same for second delay.

So, I narrowed the things down to get to know the shortest possible delays where the hold-switch still works on my Sansa fuzev2.

Here are the results:


+-------------+--------------+--------+
| First delay | Second delay | works? |
+-------------+--------------+--------+
|          20 |           10 |  yes   |
+-------------+--------------+--------+
|          18 |           09 |   no   |
+-------------+--------------+--------+
|          19 |           10 |  yes   |
+-------------+--------------+--------+
|          18 |           40 |   no   |
+-------------+--------------+--------+
|          20 |           05 |  yes   |
+-------------+--------------+--------+
|          19 |           05 |  yes   |
+-------------+--------------+--------+
|          19 |           01 |   no   |
+-------------+--------------+--------+
|          19 |           03 |   no   | (first, seemed to work, but every few seconds flickers very short)
+-------------+--------------+--------+
|          19 |           02 |   no   |
+-------------+--------------+--------+
|          19 |           04 |  yes   |
+-------------+--------------+--------+


So, shortest possible delays which still work for my device:
1. udelay(): 19, 2. udelay(): 4.

Corresponding patch attached.

@ Mihail Zenkov: Can you include that one in your patchset?

And: Is there a way to make this patches upstream? If not, it would be nice to host it somewhere (that people do not have to dig through all the forum posts to find the correct versions), if hosting is not possible and we have to resort to the forum, then putting everything into one file (.tar-archive, or a single patch file) makes things still more easy.


EDIT 2016-01-15, modified on 2016-01-17: First I thought, first delay 19, second delay 03 are good. But then I noticed very short flickering-on of the screen every few seconds, so I abandoned it.

EDIT 2016-01-17: 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]

fuzpa.bin - bootloader + original firmware, you should update it only if you need changes in bootloader or need new original firmware. Don't update it without good reasons - you can brick player if something going wrong.
For regular update to new rockbox revision - just replace .rockbox/* .
For small internal changes (like you doing with this patch) just replace one file - .rockbox/rockbox.sansa

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

Code: [Select]

$ ./configure --no-ccache --target=63 --type=b
  [...]
$ make
  [...]
  CC firmware/target/arm/as3525/sansa-fuzev2/button-fuzev2.c
  [...]

So, what's the reason that the bootloader takes into account that file?

[oid_maps]

The bootloader is a few kilobytes, the rest is the OF.

.. and we still need to append the original firmware when we want to change the bootloader, right? (That's what is documented -- to use "mkamsboot" to patch the original firmware with the rockbox bootloader) Why is it not sufficient to just have a small bootloader ("fuzpa.bin") without the original firmware?

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

[oid_maps]

First, try find lower value for first delay. Then try same for second delay.

So, I narrowed the things down to get to know the shortest possible delays where the hold-switch still works on my Sansa fuzev2.

[...]

So, shortest possible delays which still work for my device:
1. udelay(): 19, 2. udelay(): 5. (19, 4 still needs to be tested!)

Corresponding patch attached.

A user asked me if I can provide a working build. The forum does not allow to upload archive files. Is there a way I can upload it somewhere to a subpage of rockbox.org? I feel uncomfortable with hosting it by myself ... I did not dig into the legal issues yet (impressum of the website would be needed, warranty-disclaimer maybe, maybe some attribition to property rights I need to make).

Otherwise, I would email the .tar.xz-archive if people ask me directly (private message, and include your email address).

[Mihail Zenkov]

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.

[Mihail Zenkov]

So, I narrowed the things down to get to know the shortest possible delays where the hold-switch still works on my Sansa fuzev2.

Here are the results:

Ok, thanks!

@ Mihail Zenkov: Can you include that one in your patchset?

Yes, it should by included in next update.

And: Is there a way to make this patches upstream?

We should fix all know issues before.

If not, it would be nice to host it somewhere (that people do not have to dig through all the forum posts to find the correct versions), if hosting is not possible and we have to resort to the forum, then putting everything into one file (.tar-archive, or a single patch file) makes things still more easy.

Probably you right and we should provide single patch for user.

[oid_maps]

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

OK, for me first delay set to 18 and second to 09, but also second to 40, didn't even work (as well as 10, 05 did not work, neither did 12, 06; 14, 07; 16, 08). So maybe either the individual devices differ, or 10, 10 is a combination which would work again? Strange.

Cannot test right now.

[Mihail Zenkov]

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

So, what's the reason that the bootloader takes into account that file?

We check button state in bootloader - to boot in original firmware or boot recovery mode.

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

We can't do separate update for bootloader and original firmware.

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

No, it fallback to recovery mode (usb flash drive).

[[Saint]]

A user asked me if I can provide a working build. The forum does not allow to upload archive files. Is there a way I can upload it somewhere to a subpage of rockbox.org? I feel uncomfortable with hosting it by myself ... I did not dig into the legal issues yet (impressum of the website would be needed, warranty-disclaimer maybe, maybe some attribition to property rights I need to make).

Otherwise, I would email the .tar.xz-archive if people ask me directly (private message, and include your email address).

Why would you not simply host it on one of the many sites like Data File Host or so?

The only real requirement you _must_ undertake is that you need to be able to supply the full source code that generated that binary when asked to do so, as a requirement of the GPL license (note: technically speaking just supplying a patch file and pointing to the Rockbox sources and a given commit that the binary was built from is not actually good enough to satisfy this requirement).


[Saint]