[bootloader][05-26] FFF 1.4A bugfixes + new look + recovery boot [.zip file size]

NEW BOOTLOADER INSTALL METHOD: FLASH.ZIP. SAFER. USE IN RECOVERY JUST LIKE ANY OTHER ROM .ZIP


This is an UPDATED version of FIREFIREFIRE by Pokey9000

CREDITS and THANKS GO TO:
- Pokey9000: For getting this going. Hard to dev at all w/o a way of getting to recovery.
- eldarerathis: Menu code was used from the Extended FIREFIREFIRE github
- Icemank121: All splash/menu screens


Version 1.5 of FIREFIREFIRE changes:

• [1.5] Better handling for lower power / charging screen
• [1.4a] Reprioritized the different boot options so that regardless of idme bootmode, the options chosen from the menu would be used first.
• [1.4] Support for a single boot directly to Recovery for applying ROM updates, etc via "Reboot Recovery" menu in Android. Works with any recovery that is installed. All existing ROM devs need to update their BoardConfig.mk to support this by adding the following:
  TARGET_RECOVERY_PRE_COMMAND := "idme postmode 1;"
  Your builds will need to also have a working "idme" binary and the "libidme.so" lib for the reboot recovery option to work.
  
  Both of these are in the prebuilts of the device tree on github:
  https://github.com/KFire-Android/android_device_amazon_otter/tree/cm-11.0/prebuilt
  
• Fixed Charging Mode which will pause the boot process and let the device charge if the current capacity is under 3%. If you connect it to the stock charger, the boot can proceed.[/B]
• Added a Boot Menu which is accessed by pressing the power button after a the initial splash screen is displayed. You then press the menu button again to navigate through each option. If you wait after an option is highlighted, it will automatically be selected after a few seconds.:
  • Normal: Standard boot into your installed ROM
  • Recovery: Boot to recovery
  • Reset Boot Mode: This is a normal bootup but resets "idme bootmode" to 4000 for those that are stuck and can't access idme for whatever reason.

NOTES:
Currently the handling of the power button is a bit sloppy, takes 1-2 presses for it to register each press to navigate through the menu.

Download the recovery-flashable .zip file here:

http://goo.im/devs/hashcode/otter/bootloader/flash-zip
v1.5 md5sum: 4e9d277a31a2a26d33156edf5abbf0e4
v1.4a md5sum: 419c53b922c963082454b14b7de75a90

Apply this flash.zip from recovery just like any other ROM or kernel .zip file. This is by far the safest way to upgrade your bootloader. It does a sha1sum check on the file before applying.


GitHub source (forked from Pokey9000's original) here:
https://github.com/KFire-Android/kf_u-boot

acax456 said:

Can u make a gscript file for us?

Sent from my Amazon Kindle Fire using Tapatalk 2

Click to expand...

Click to collapse

*recommended method*
http://xdaforums.com/showthread.php?p=22608974

hope hashcode doesn't mind.

teegale said:

Not sure if this has been asked before or if this is even relevant to FFF but will we ever have a working "Shutdown" from Android OS?

Click to expand...

Click to collapse

This is being worked on. But it not an obvious fix. So its taking a while.

Lately ive been testing a new clockwork recovery.. and its working great, except that it doesnt power off correctly, so im hesitant to put it out just yet.

And im rewriting the charger driver.

Sent from my DROID4 using Tapatalk 2

Added a padfile to the .zip to make it larger than the bootloader partition per kinfauns suggestion.

I'll get back to the bootloader and make some more changes here in a bit(tm)

While I applaud the move to have the bootloader flashed through recovery, distributing it as a zip file has had an unintended, but somewhat foreseeable side effect. There's a certain group of users who do not care to read warnings or follow directions, so they charge ahead and flash the zip file with fastboot. No matter how big and prominent you make the directions, there will always be those who need to be protected from themselves and doing harm to their device.

I swear... even if you warned people in big, red neon lights that flashing something will make the device blow up, they'd still come back the next day and ask if a factory cable will fix it. I've come to believe that posting directions and warnings is just not enough. There's another thread today from a user who flashed the zip archive and I'm sure that won't be the last if there's no guardrail in place to keep them from going over the cliff. That's my long-winded prelude to my suggested fix...

Hashcode... could you place an extraneous pad file inside the distribution so the zip archive exceeds the 256KB mark in size? Fastboot will do a sanity check and compare the size of the file to the size of the partition. If the file is too big, it will balk and stop the flash procedure. Like this...


That should effectively stop people from shooting themselves in the foot.