Support and General Use > Hardware
Sansа Clip Zip - Improve battery life
saratoga:
--- Quote from: oid_maps on January 15, 2016, 07:54:31 AM ---Well, but I observe that also when compiling the bootloader, the file 'button-fuzev2.c' get's compiled:
--- End quote ---
The bootloader includes button drivers (and most other drivers).
--- Quote from: oid_maps on January 15, 2016, 07:56:56 AM --- Why is it not sufficient to just have a small bootloader ("fuzpa.bin") without the original firmware?
--- End quote ---
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.
--- Quote from: oid_maps on January 15, 2016, 07:56:56 AM ---Does it fallback to the original firmware automagically if we don't have the .rockbox-tree on the device?
--- End quote ---
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:
--- Quote from: Mihail Zenkov on January 15, 2016, 09:03:36 AM ---
--- Quote from: saratoga on January 14, 2016, 06:10:57 PM ---I did notice that during frequent boosting some button inputs are skipped, although maybe that is unrelated.
--- End quote ---
For fuse v2 we disable irq when check hold/power buttons, probably we should do same for clip v2.
--- End quote ---
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:
--- Quote from: saratoga on January 15, 2016, 01:47:56 PM ---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.
--- End quote ---
Probably we can enable irq before second delay.
--- Quote from: saratoga on January 15, 2016, 01:47:56 PM ---I think we should think about committing this in parts.
--- End quote ---
Good. At first step I suggest test and commit frequency changes and related fix for buttons .
oid_maps:
--- Quote from: saratoga on January 14, 2016, 06:10:57 PM ---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
--- End quote ---
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:
--- Quote from: oid_maps on January 16, 2016, 06:27:55 PM ---
--- Quote from: saratoga on January 14, 2016, 06:10:57 PM ---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
--- End quote ---
Confirmed: For my fuzev2, both delays to 10 does _not_ work
--- End quote ---
If you're referring to the 10 delay above, thats for the ClipV2, it won't do anything on the Fuze.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version