PROJECT OTTER X DISCUSSION
It's a major change to the device. If you choose to update, it won't be easy to flash back the stock files and use your device as a Kindle again. The device name will actually change to "otterx", so that the 2 sets of files can be kept clearly distinct as well as provide a safety net for those who accidentally download the wrong thing and try to flash it.
GOALS OF THIS PROJECT: Make everyone happy of course.
- [DONE] Update the bootloader (u-boot). And I don't mean "tweaks" to the bootloader, I mean: the current code was based on a 2011 release. The newer bootloader will be based on a 2014 release. Changes to be included in the update:
- [DONE] A much better text driven menu system laid on-top of the initial boot graphic (as opposed to the image-only menus currently)
- [DONE] Cleaned up device initialization / charging loop for extreme low battery situations
- [DONE] Support devtree binary loading (native support for newer kernels)
- [DONE] Support for decompessing kernels in new formats
- [DONE] Native "reboot recovery" support no more hacky idme/sticky values
- [DONE] Device "handling" changes like a longer button press to fully power on the device. Avoids "accidental" power ons while traveling.
- [DONE--NEED NEW OTTERX ROM] Built in support for "charger" mode. IE: plug the device in while it's off and it boots into the native Android charger screen, vs a full boot of Android.
- [DONE] I'm guessing a new initial power-on logo as well (it says "KINDLE" -- I lied.. but you can change it!)
- [DONE] Partition layout change to support 5 to 6gb of combined app / sdcard storage.
- [DONE] Rebuild a new TWRP to support combined data/storage
- [DONE] The process for changing the partition layout is be handled in the bootloader menu. Users will need to pull everything off the internal storage prior to performing the change as it will wipe system, cache and userdata partitions out during the process.
- [DONE] Kernel and userspace now support F2FS format for userdata. This is a new filesystem specifically designed for devices which use EMMC style storage.
- Kernel update. A lot has happened to the OMAP kernel world over the last year. Much of the code needed to run newer kernels has been merged into the mainline. However, much has not. So I'm riding the line between: 1) finishing the 3.4 kernel using the new bootloader and partition layout, with an option for upgrading later to an even newer one. Drawback: I don't have a 512MB based ducati binary to process HD codecs for the 3.4 kernel. Or, 2) starting a newer kernel to go hand in hand with the other portions of this update (it would be 3.8 or newer). Why upgrade the kernel? Besides the typical "bigger better faster" mentality, I want some specific solutions to current problems: our graphics layer has been outdated for 1-2 versions of Android, and we still use a TI supplied ducati binary for HD codecs. If we update to a 3.8+ kernel, I can then attempt to build a custom ducati binary which would work better with our 512MB memory requirements and leave more free space to the OS.
Of course, the REAL end goal: to keep this device current and usable using today and future OS updates. And yes, maybe even get OTG and the MIC functions working.