Harscode, something you didnt tell (maybe you didnt read my question) will OTG be available with all this? Thanks in advance 
Sent from my KFTT using xda premium
Sent from my KFTT using xda premium
[RECOVERY/BOOTSTRAP] Safestrap for Kindle Fire HD 7" (ON HOLD)
- Thread starter Hashcode
- Start date
I havent had any experience with dual boot or anything similar to this. So do I understand this correctly both custom and stock roms will have to be running at the same time, I know this was kind of asked a couple posts ago but just wanted more clarification? If so will this cause any noticible lag or reduction in performance?
Sent from my SCH-I500 using xda app-developers app
Sent from my SCH-I500 using xda app-developers app
Last edited:
They will both exist on your device, but you will be able to choose which one loads. There is no lag from this at all.
Thanks
This is great news,waiting impatiently lol...also if any futher beta testing is needed id be more then happy to help...
This is great news,waiting impatiently lol...also if any futher beta testing is needed id be more then happy to help...
For now, my focus is getting a custom recovery to allow for custom ROMs.
If OTG isn't setup in the stock kernel, then I'd have to work on a kexec kernel loaded during the boot. But that's very involved.
Sent from my XT894 using Tapatalk 2
If OTG isn't setup in the stock kernel, then I'd have to work on a kexec kernel loaded during the boot. But that's very involved.
Sent from my XT894 using Tapatalk 2
Thanks for the answer ^^ just knowing that there is a possibility makes me glad Thanks for your hard work
Sent from my KFTT using xda premium
Thanks for your hard workSent from my KFTT using xda premium
Will this work with the KindleFire2 when done?
The backup/restore process doesn't work for the KindleFire2. It saves the system.img as the same size as a KF HD.
Sent from my Galaxy Nexus using xda app-developers app
Read the OP
If you're referring to the backup.sh script posted by kinfauns, I think you may be mistaken. The script reads each partition bit by bit, creates a disk image (.img) based on that information and compresses it using gzip. Whatever it's saved as is relative to the size of those partitions.
I don't want to hijack this thread anymore than I already have, so if you want, you can PM me and I'll see if I can't help you find the root of the problem.
N
Nardholio
Guest
There's quite a bit you can do with a stock based ROM, but yes, kernel-jacking has not been developed yet
Hello all,
I know this thread has been quiet for a few days and it's mainly due to a big I'm trying to work around during the entry to recovery.
What happens is the old init process is somehow still lingering long enough to trigger the "omap watchdog" driver in the kernel. it's a driver designed to reset the device when the process thinks it's hung up.
Turns out we killed the old init process off on purpose, so that we can re-start it with new rootfs files. But, that doesn't change the fact that recovery reboots about 20 seconds after you enter.
I'm tinkering with various solutions atm.
I know this thread has been quiet for a few days and it's mainly due to a big I'm trying to work around during the entry to recovery.
What happens is the old init process is somehow still lingering long enough to trigger the "omap watchdog" driver in the kernel. it's a driver designed to reset the device when the process thinks it's hung up.
Turns out we killed the old init process off on purpose, so that we can re-start it with new rootfs files. But, that doesn't change the fact that recovery reboots about 20 seconds after you enter.
I'm tinkering with various solutions atm.
Since this is a bootstrap will a OTA kill it? Hello? Yea I'm here.
Sent from my KFTT using xda app-developers app
Last edited:
Thanks Hashcode for the update. I can't wait to see the outcome of this project, good or bad.
Thanks for the update. Hope for the best ^^ Maybe is an stupid idea... but what if you can make the recovery remember its last state? Then even if it resets, when it comes up again you'll be in the same point... I know nothing of this.. but is just an idea.. I think its naive xp but its actually you should decide that
Sent from my KFTT using xda premium
Sent from my KFTT using xda premium
Similar threads
- Sticky
Top Liked Posts
-
There are no posts matching your filters.
-
37I've decided to put this project on hold as the bootloader has been fixed for the HD8.9/7 (and in theory can be fixed for the KFire2's)
SAFESTRAP v3.05 BETA (2nd-System Bootstrap / Recovery)
** DISCLAIMER: THIS IS A SERIOUS HACK YOU ARE ABOUT TO PERFORM TO THE DEVICE.
DUE TO THE WAY THIS BOOTSTRAP WORKS, THERE IS A POSSIBILITY OF SOFT-BRICKING.
I'M NOT RESPONSIBLE FOR ANY DAMAGE YOU DO TO YOUR KINDLE BY USING THIS TOOL.
YOU DO SO AT YOUR OWN RISK.
If you bypassed the BIG RED letters above, make sure you re-read it and understand that you're installing a hijack which affects the normal boot process of the Kindle Fire HD. If that process is changed in anyway it could lead to a soft-bricked device which will need to be fastboot restored.
FOR NOW THIS IS FOR THE KINDLE FIRE HD 7", LATER I ALSO HAVE A VERISON WHICH WILL WORK ON THE KFIRE2.
Download the APK Here
md5sum: 9e409cf3a9d7d510b5bf19262ecfb6d5
Brief Overview / Instructions for how to use Safestrap:
http://blog.hash-of-codes.com/how-to-safestrap/
KNOWN ISSUES:
- Currently there's a bug where when you create and activate a rom-slot, the /sdcard is pointed at the rom-slots "/data" partition. This of course won't have all of your content in it. I'll release an update once that's fixed.
CHANGES:
- [11/14] Initial release for KFireHD7
- [10/30] Begin testing tablet interface for Kindle Fire's
- [10/17] (3.05) Fixed SD card / emmc sharing in recovery (UMS)
- [10/17] (3.05) Fixed recovery installation/removal from ROM-slots
- [10/14] Updated to v3.04 BETA.
- [10/14] Recovery is now based off TWRP 2.2.2.1 (fully featured touch-based recovery)
- [10/14] Can create up to 4 Virtual ROM-slots to flash ROMs to and when "Active" ALL TWRP functions affect that ROM-slot (For example: Flashing .zips, Backup and Restore)
- [10/14] Nearly instant swapping from ROM to ROM
- [10/14] User selectable data partition sizes during ROM slot creation: 1GB, 2GB or 3GB
- [10/14] ROM slots are saved on the internal emmc space so that preinstall and webtop partitions are no longer used and shouldn't break OTAs.
- [10/14] Charging in recovery
- [10/14] Supports "Reboot Recovery" from Android OS
Entry to recovery via Splashscreen on boot-up. The screen stays up for around 8-10 seconds and if you hit the "Recovery" button, it takes you to Safestrap Recovery. You can skip the wait by touching the "Continue" button.
KNOWN ISSUES:
- Stock flashing is currently disabled. And this will probably remain this way for the foreseeable future.
SPECIAL THANKS TO:
- The entire TWRP team who has built an AMAZING recovery system.
- The testers which have helped in past and present versions of Safestrap, knowing that it could mean they brick their devices.
[ SCREENSHOTS COMING SOON ]12Hello all,
I know this thread has been quiet for a few days and it's mainly due to a big I'm trying to work around during the entry to recovery.
What happens is the old init process is somehow still lingering long enough to trigger the "omap watchdog" driver in the kernel. it's a driver designed to reset the device when the process thinks it's hung up.
Turns out we killed the old init process off on purpose, so that we can re-start it with new rootfs files. But, that doesn't change the fact that recovery reboots about 20 seconds after you enter.
I'm tinkering with various solutions atm.11Testing Update: We have a solid boot after Safestrap installation which is a plus since we're now injecting the recovery splashscreen into the boot process.
My last test (#3) didn't have a working touch controller during the splashscreen, but I have test #4 ready which *could* load the touch driver and allow for entry, but since it's Halloween and we all have families, I won't know how that works till later tonight.
TODO: I'm working on re-doing the Safestrap theme for 800x1280. I had previously been running a 1280x800 theme but the screen is vertical not horizontal. So the layout will be more phone-style than tablet looking.
But even if it's the default TWRP theme with a few missing images, I'll know if we're in a usable state soon.
Verifying Device: I think we can turn on asserts before flashing ROMs. However, it could be that every single Kindle Fire device is named "blaze_tablet" or "blaze" so that might be less than useful. It will take some testing probably to come up with a solution. The Safestrap APK performs a model check when you click "Install Recovery" (KFTT == KindleFireHD-7) and instantly bails if that's not true, so at least you can't install the wrong devices' recovery.
On the donations: There should be a button under my name on any post which links to my paypal.
However, let's hold off donations till we see some actual results and have a working stock-based ROM to flash which devs can tweak w/o fear of bricking. At that point I'll call it a successful bootstrap/recovery and we can move on to AOSP builds.
I'm not against donations (tho I don't do this for money obviously), I just feel you should already have something in your hands and be happy with it before you give any hard earned money to a dev.10Just a quick note....
Progress has been made. Stuff is starting to work.
Stay Tuned.
:highfive:10OP updated with the beta APK.
** BECAREFUL **
KNOWN ISSUES:
- Currently there's a bug where when you create and activate a rom-slot, the /sdcard is pointed at the rom-slots "/data" partition. This of course won't have all of your content in it. I'll release an update once that's fixed.
As with any locked device this tool allows you to mess up your stuff. Just use common sense for now, maybe make a backup and get used to Safestrap.
Enjoy
More to do, to get custom ROMs on their way. Thank you for being patient.
