Related
I'm having trouble getting back to a regular non locked down firmware. I flashed whispercore without fully understanding that it was actually in fact changing my entire rom.
I didnt even think to try and install CWM first to create a recovery image I need help getting out of this mess. I've used the Whispercore installer to unlock fastboot because whispercore relocks your fastboot after it does its thing.
Seems as though the stock sdk tools hated me for a while there and wouldnt detect my device than I later realised it was just because the sdk downloads itself all fragmented it basically took fastboot and adb and separated the two even though fastboot requires adb to function properly. I wont even begin to speculate as to why that happened, as thats beyond the scope of my question.
I basically have gotten to the point where i have Clock work mod (CWM) installed on my droid and the fastboot oem unlocked but am currently stuck at trying to get Cyanogenmod 7 stable on here.
***UPDATE**
Ok. This situation has been resolved. If you are having trouble with leaving whisper core and you've flashed a bunch of stuff trying desperately trying to fix this issue. Recognize the nexus S is a very easy device to fix. Fastboot is your saviour and the WhisperCore installer will even be kind enough to install all the drivers required to OEM unlock fastboot and do it for you.
Anyways the solution was: Re run the whispercore installer. Let it do its automagic.
Than flash a new Clockwork Mod recovery image this thread provided some clean Clockwork Mod images for flashing with fastboot that link is also for rooting but provides a good example for how to flash a new recovery.
Than Just reboot into recovery and use it to mount your phone via the Clockwork Mod recovery console to your computer, upload your favorite flavor of rom and than unmount the device. Once unmounted go back to the main menu in Clockwork mod and "Flash zip from SD" look for your rom in my case it was update-cm-7.0.3-NS-signed.zip Latest stable at the time. let it do its job.
Basically my issue was a combination of several factors. A bad Clockwork mod and a semi corrupt installation of SDK tools and Whispercore.
Possibly a stock firmware might be required first I just know that trying to straight flash cm7 stable from cwm is not working out.
you can get adb and the 2 dll files and fastboot in the same folder and cd to that directory. fastboot oem unlock should unlock your bootloader. then you should be able to flash a recovery if you want. might also want to check out the 1 click stock thread to see if that works.
I will probably have trouble finding this thread but I will look and if i come up with anything I will certainly post my findings.
This should work. But we shall see I will update the original post if I find a full solution.
Just flash a stock full rom (for i9023 you can use the one in my signature, don't forget get to use the wipe options in cwm recovery before) and the root should be gone. Afterwards, boot into bootloader and use fastboot command "fastboot oem lock" to lock the bootloader again. Than you can do a factory reset (and delete usb storage) to fully restore stock "experience".
__________________
Nexus S running Official 2.3.4 ROM (for i9023) with XTEUV92 Trinity kernel
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?t=1214705&highlight=one+click+stock
I'm getting an error in the zip files no matter what one I use and its "Status 7" whatever that means.
chamunks said:
***UPDATE**
Ok. This situation has been resolved. If you are having trouble with leaving whisper core and you've flashed a bunch of stuff trying desperately trying to fix this issue. Recognize the nexus S is a very easy device to fix. Fastboot is your saviour and the WhisperCore installer will even be kind enough to install all the drivers required to OEM unlock fastboot and do it for you.
Anyways the solution was: Re run the whispercore installer. Let it do its automagic.
Than flash a new Clockwork Mod recovery image this thread provided some clean Clockwork Mod images for flashing with fastboot that link is also for rooting but provides a good example for how to flash a new recovery.
Than Just reboot into recovery and use it to mount your phone via the Clockwork Mod recovery console to your computer, upload your favorite flavor of rom and than unmount the device. Once unmounted go back to the main menu in Clockwork mod and "Flash zip from SD" look for your rom in my case it was update-cm-7.0.3-NS-signed.zip Latest stable at the time. let it do its job.
Basically my issue was a combination of several factors. A bad Clockwork mod and a semi corrupt installation of SDK tools and Whispercore.
Click to expand...
Click to collapse
I am trying to follow what you did and i am completely lost... I have a nexus s g that i am trying to get whispercore off it!
The "Automagic" you talk about. Isnt that just whispercore putting it in fast boot??? If so then then how do you use the recover image?
I have a moto XT711 which is a chinese version of XT720 and still android 2.1.
Miserably, most users in china buy XT720 which is from overseas, there are no custom roms or open recovery for XT711 in chinese android phone forum.
I've found Skrilax_CZ or Mioze7Ae's OpenRecovery for XT720 and I don't know how to edit their open recovery to let it fit for XT711. And I found no big difference between Skrilax_CZ's OpenRecovery for XT720 and OpenRecovery for XT701. Who can nicely help me to do this?
Simultaneously, I'm very much puzzled by another question. The bootloader of XT720 is still locked. Why XT720 can flash third-party ROMs such as andriod 2.3.7? Does XT711 can do the same thing?
Thanks a lot in advance！
I've found an explaination about bootloader as below:"Because moto locked bootloader, bootstrap is the only way to install third party recovery."
Since XT720 can install open recovery via bootstrap, XT711 can install too.
Who can nicely tell me how to change the open recovery to install it successfully?
Does anyone knows？
Please help me, give a reply anyway.
The very first thing to do is to make sure you have a sbf and that you can restore your phone to factory state. I have more to post later, but I don't have time at the moment. Basically, we need to figure out how to port the switch part.
Does "fastboot boot" work on XT711? If so try the fastboot recovery (but don't do anything once booted, just check if you get to the OpenRecovery menu). If that works, it should be really easy.
http://forum.xda-developers.com/showthread.php?t=1477752
[REF] Fastboot to OpenRecovery and how to dump more partitions
Mioze7Ae said:
The very first thing to do is to make sure you have a sbf and that you can restore your phone to factory state. I have more to post later, but I don't have time at the moment. Basically, we need to figure out how to port the switch part.
Does "fastboot boot" work on XT711? If so try the fastboot recovery (but don't do anything once booted, just check if you get to the OpenRecovery menu). If that works, it should be really easy.
http://forum.xda-developers.com/showthread.php?t=1477752
[REF] Fastboot to OpenRecovery and how to dump more partitions
Click to expand...
Click to collapse
Mioze7Ae，thank you for timely reply!
I did have a version of STOCK ROM for XT711 which is "XT711_V10.16.0_ROM" . It includes two files:
the bootloader:BL_8099_umts_sholestabletcu_refresh_Consumer_replacer.sbf
the Full Flash:RSTCU_U2_10.16.0_SIGNED_USASHLSTAB125P2XAPCNCU035.0R_HWp3_1FF.sbf
And I've tried to flash this two file to my XT711 successfully using RSD_Lite.
The bootloader version of XT711 before that is already 80.99
I don't understand some technical terms below:
The first, "and that you can restore your phone to factory state" . Does it means flash 'the Full Flash' as I did? Or just restore to factory state in setting?
The second, "port the switch part". Does it means "dump_image system /sdcard/system.img"?
The third, "fastboot boot". How to enter it? By press some button and then power on? Do you mean this command:
1) Enable USB Debugging
2) adb reboot bootloader
3) fastboot boot openrecovery-fastboot.img
The fourth, " You still need to put the relevant parts of OpenRecovery on the sdcard", which version of OpenRecovery should be put to sdcard? OpenRecovery_v1_46_STR.rar or OpenRecovery-XT720-01.zip? Anyone is ok?
The fifth,if openrecovery-fastboot.img can work on XT711, which command should be executed? And what's the meaning of reconstruct a sbf? What's the relationship between this work and editing OpenRecovery-XT720-01.zip to let it fit for XT711?
BTW, I've a friend who has upgrade XT711 to 2.3.5 with the help of a XDA's expert. But it can't reboot. There appears 'boot loader err'. They used img files of XT701 android 2.1
Have you tried installing the XT720 OpenRecovery? What happens?
telnet777 said:
Mioze7Ae，thank you for timely reply!
I did have a version of STOCK ROM for XT711 which is "XT711_V10.16.0_ROM" . It includes two files:
the bootloader:BL_8099_umts_sholestabletcu_refresh_Consumer_replacer.sbf
the Full Flash:RSTCU_U2_10.16.0_SIGNED_USASHLSTAB125P2XAPCNCU035.0R_HWp3_1FF.sbf
And I've tried to flash this two file to my XT711 successfully using RSD_Lite.
The bootloader version of XT711 before that is already 80.99
I don't understand some technical terms below:
The first, "and that you can restore your phone to factory state" . Does it means flash 'the Full Flash' as I did? Or just restore to factory state in setting?
Click to expand...
Click to collapse
That's all I wanted--just to make sure you can recover your phone if it becomes unbootable.
The second, "port the switch part". Does it means "dump_image system /sdcard/system.img"?
Click to expand...
Click to collapse
No, there's a script called switch.sh--part of the openrecovery bootstrap that "switches" from openrecovery lite to full openrecovery from the sdcard. Part of that detects which device you're on and runs the next step. XT720 is detected as "STR". Others are "SHOLS" and "STCU". I'm trying to figure out if XT711 is already detected as "STR".
The third, "fastboot boot". How to enter it? By press some button and then power on? Do you mean this command:
1) Enable USB Debugging
2) adb reboot bootloader
3) fastboot boot openrecovery-fastboot.img
Click to expand...
Click to collapse
Yes. Your bootloader is newer than XT720's, it may not work.
The fourth, " You still need to put the relevant parts of OpenRecovery on the sdcard", which version of OpenRecovery should be put to sdcard? OpenRecovery_v1_46_STR.rar or OpenRecovery-XT720-01.zip? Anyone is ok?
The fifth,if openrecovery-fastboot.img can work on XT711, which command should be executed? And what's the meaning of reconstruct a sbf? What's the relationship between this work and editing OpenRecovery-XT720-01.zip to let it fit for XT711?
Click to expand...
Click to collapse
Ignore the dump/reconstruct stuff. I just want to know if you see the OpenRecovery menu. Don't do anything there especially on the fastboot one, it's hardcoded for XT720 partition structure (they may be the same on XT711, but I don't know).
telnet777 said:
BTW, I've a friend who has upgrade XT711 to 2.3.5 with the help of a XDA's expert. But it can't reboot. There appears 'boot loader err'. They used img files of XT701 android 2.1
Click to expand...
Click to collapse
I'm not too surprised by that. XT701 has disabled bootloader security and doesn't sign partitions.
Mioze7Ae said:
Have you tried installing the XT720 OpenRecovery? What happens?
That's all I wanted--just to make sure you can recover your phone if it becomes unbootable.
No, there's a script called switch.sh--part of the openrecovery bootstrap that "switches" from openrecovery lite to full openrecovery from the sdcard. Part of that detects which device you're on and runs the next step. XT720 is detected as "STR". Others are "SHOLS" and "STCU". I'm trying to figure out if XT711 is already detected as "STR".
Yes. Your bootloader is newer than XT720's, it may not work.
Ignore the dump/reconstruct stuff. I just want to know if you see the OpenRecovery menu. Don't do anything there especially on the fastboot one, it's hardcoded for XT720 partition structure (they may be the same on XT711, but I don't know).
I'm not too surprised by that. XT701 has disabled bootloader security and doesn't sign partitions.
Click to expand...
Click to collapse
hhcat had tried installing the XT720 OpenRecovery. But he failed, and I don’t know what happens because he has not mentioned and I've no XT711 in hand at the moment.
hhcat said he'll try to enter the OpenRecovery menu using the way you mentioned in these two days. I'm waiting for a good news from him.
I've three question about OpenRecovery and switch.sh
First:"STR" is a parameter transferred by updater-script when running switch.sh
Why do you say XT720 is detected as "STR"？Does the phone itself will detect it is which device when switch.sh is running?
Second:How does the OpenRecovery works? I've reviewed install_script.sh under directory orbootstrap. I don't understand why it can “hijack” boot procedure when reboot. Someone said it utilized a defect of XT720's recovery.
Third:The bootloader is not unlocked. Why can we flash custom roms such as 2.3.7 via OpenRecovery? Why bootloader not check signature?
Thank you!
telnet777 said:
First:"STR" is a parameter transferred by updater-script when running switch.sh
Why do you say XT720 is detected as "STR"？Does the phone itself will detect it is which device when switch.sh is running?
Click to expand...
Click to collapse
I re-checked and you're right. I was remembering a different step where it runs "/system/persistent/orbootstrap/utils/install.%s.btsh" and the %s is detected. I think that is always install.mapphone_umts.rc. The STR is selected when you run the OpenRecovery install.sh, so it's not probed. Sorry for incorrect info.
Second:How does the OpenRecovery works? I've reviewed install_script.sh under directory orbootstrap. I don't understand why it can “hijack” boot procedure when reboot. Someone said it utilized a defect of XT720's recovery.
Click to expand...
Click to collapse
The hijack is done in /system/bin/sh
Basically if you look at /init.mapphone_umts.rc, very early in boot it runs a script called /init_prep_keypad.sh. init_prep_keypad.sh is a shell script that is run by /system/bin/sh (the first line of /init_prep_keypad.sh is #!/system/bin/sh, so /system/bin/sh is started to read the commands from /init_prep_keypad.sh). This is the first time during boot that anything from /system is executed (/system isn't signature checked). Skrilax_CZ's hijacked /system/bin/sh does the following things:
1. If the volume up key is down *or* /cache/.boot_to_or file is present it runs /system/persistent/orbootstrap/utils/install.mapphone_umts.btsh
2. (On my version) if volume down is pressed -- reboot to fastboot bootloader
3. Check if /system/bin/sh_hijack.sh exists, if so run that
4. Otherwise it just runs /init_prep_keypad.sh
/system/persistent/orbootstrap/utils/install.mapphone_umts.btsh defaults to "OpenRecovery Lite". If /sdcard/OpenRecovery.zip is available that is applied and it "switches" to full OpenRecovery.
/system/bin/sh_hijack.sh reconfigures the / filesystem (on XT720 and A853 usually just by copying the contents of /system/etc/rootfs) and eventually calls /system/bin/2nd-init which restarts /init. This is how we get around the signature check. The / filesystem comes from boot.img so we can't modify it. But it is read into RAM at boot and we can modify it in RAM once we have control.
The source for the hijacked sh is here:
http://gitorious.org/droid/openrecovery/blobs/master/src/bootable/open_recovery/btsh/main.c
There's a somewhat confusing description of what 2nd-init does by cvpcs here: http://cvpcs.org/blog/2011-06-14/2nd-init._what_it_is_and_how_it_works
NOTE: which binary to hijack varies by phone--some hijack mot_boot_mode, some hijack logwrapper--it all depends on what the stock boot does. On Milestone A853, Milestone XT720 and Motoroi XT720, the sh-hijack is the correct one.
I hope that makes sense, but I may be too comfortable with it.
Third:The bootloader is not unlocked. Why can we flash custom roms such as 2.3.7 via OpenRecovery? Why bootloader not check signature?
Click to expand...
Click to collapse
/system is only check during the first boot after sbf flash of the system partition. The init_prep_keypad.sh script in particular can modify /system so signatures there can be quickly invalid under normal operation.
There's a lot of very good information about the bootloader security on www.droid-developers.org
I also like this blog post by [mbm] http://blog.opticaldelusion.org/2010/08/clearly-you-have-no-idea-what-efuse-is.html -- this is what cleared things up for me initially.
In the CDT partition table, partitions that are "type 1" are checked each boot, and "type 5" is only checked once immediately after sbf flash:
http://www.droid-developers.org/wiki/CDT_Milestone
I think that information about whether the type 5 partitions have been checked is stored in sp (CG41). Anyway, the take away message is boot.img is always checked, system.img is checked once and may be modified afterwards.
Mioze7Ae, I'm digesting what your said. It is out of my range to understand all of these.
Thank you for your detailed reply and the effort for XT711.
Take your time and ask questions. It took me many months to figure it out. Hopefully we can help you understand it much faster.
Hi,Mioze7Ae, I've a good news to tell you. It will spirit up those peoples who brought XT711.
We tried "fastboot boot openrecovery-fastboot.img" and entered into the open recovery!
With the help of "小⑨一只", We installed open recovery for XT720 on XT711 and tested fastboot mode successfully on XT711. Much thanks to her. She is now studying in high school.
Details below：
The first thing we do is installing open recovery for XT720 on XT711 which is "OpenRecovery-XT720-01.zip" originally from Mioze7Ae.
The installation is successful.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
But error occurs when entering open recovery.
"E:Can't open /cache/recovery/command" appears on the screen.
The second thing wo do is testing fastboot mode with command "fastboot boot openrecovery-fastboot.img" successfully.
Mioze7Ae, how to edit the openrecovery to work on XT711? Do you need any further information? What shall we do?
And I've two questions to ask.
The first: XT720's BL is locked. Its kernel is still 2.2 or 2.1. Why some custom ROMs named android 2.3.7? Does the rom is "pseudo-" android 2.3.7?Why some rom contains boot.img? If XT711 entered open recovery, can we upgrade it to android 2.2 although XT711's kernel is still android 2.1?What things can we do with XT711 after entering open recovery?
The second:where can I find the boot procedure of moto's Android phone? I want to know what is the phone doing step one by one（or which script it execute？） when in bootloader mode, recovery mode, fastboot mode and normal reboot or power on.
Thank you in advance.
telnet777 said:
With the help of "小⑨一只", We installed open recovery for XT720 on XT711 and tested fastboot mode successfully on XT711. Much thanks to her. She is now studying in high school.
Details below：
The first thing we do is installing open recovery for XT720 on XT711 which is "OpenRecovery-XT720-01.zip" originally from Mioze7Ae.
The installation is successful.
But error occurs when entering open recovery.
"E:Can't open /cache/recovery/command" appears on the screen.
Click to expand...
Click to collapse
Great! That's good news. That "E:Can't open /cache/recovery/command" always happens on XT720. It's harmless. The /cache/recovery/command file passes command line parameters from Android to recovery. It's used to auto-install OTA updates. ROM Manager (doesn't work on XT720) uses a similar file on other phones.
The second thing wo do is testing fastboot mode with command "fastboot boot openrecovery-fastboot.img" successfully.
Click to expand...
Click to collapse
Good!
telnet777 said:
Mioze7Ae, how to edit the openrecovery to work on XT711? Do you need any further information? What shall we do?
Click to expand...
Click to collapse
It sounds like it already works, so I don't think you need to do anything more.
And I've two questions to ask.
The first: XT720's BL is locked. Its kernel is still 2.2 or 2.1. Why some custom ROMs named android 2.3.7? Does the rom is "pseudo-" android 2.3.7?Why some rom contains boot.img?
Click to expand...
Click to collapse
On Milestone XT720, there are essentially two versions of the kernel. The old one with lower default clock rate (550MHz) and the newer one at higher clock rate (720MHz). Actually, in OpenRecovery, flashing boot.img does nothing...
Don't use the fastboot recovery until I get a chance to double check the partition structure. There are two ways that the phone gets partitions:
(1) passed as command line parameters (tags) from the CDT partition
(2) hard coded into the kernel
Normal boot uses the tags to get the partition structure dynamically from the partition table. Stock recovery's kernel has hardcoded partition structure. The dynamic tags don't include all partitions and the boot partition is marked read-only. Since bootstrapped openrecovery uses normal boot, it doesn't see some partitions and the boot partition is read-only.
The fastboot recovery also uses normal boot, but it includes a custom kernel module that modifies the kernel's partition data structures. The changes are hard coded for Milestone XT720 and there's a good chance those changes are incorrect on XT711. Don't use fastboot OpenRecovery on XT711 until I know more about your partition structure--it could send you back to RSD if they don't match. There should be no problems using bootstrap OpenRecovery.
If XT711 entered open recovery, can we upgrade it to android 2.2 although XT711's kernel is still android 2.1?What things can we do with XT711 after entering open recovery?
Click to expand...
Click to collapse
Yes. In fact, Motorola's 2.2 for the Korean Motoroi XT720 used the eclair kernel. The kernel is a very small part of things. On Milestone XT720 we're stuck with 2.1 kernel.
At this point, I think I would just try one of the XT720 CyanogenMods (fjfalcon's latest CM7 or my CM 6.3.6.2) and see what happens. The Motoroi XT720 and Milestone XT720 have slightly different sensors. So, if it boots check the sensors. If it doesn't boot we'll have to do some debugging using adb.
The second:where can I find the boot procedure of moto's Android phone? I want to know what is the phone doing step one by one（or which script it execute？） when in bootloader mode, recovery mode, fastboot mode and normal reboot or power on.
Thank you in advance.
Click to expand...
Click to collapse
The best place to learn about this is on www.droid-developers.org in pages about the booting chain. http://www.droid-developers.org/wiki/Booting_chain
The Milestone A853 people have reverse-engineered their bootloaders and put their findings there. From what I can tell XT720's bootloader is similar, except the Milestone A853 doesn't have working "fastboot boot".
Thank you for your timely reply!
You mentioned "There should be no problems using bootstrap OpenRecovery."
Do you mean the open recovery works well on XT711? We got no further for safety when seeing error occurs. How to entering open recovery? Does press camera button when selecting "apply sdcard:update.zip " ? So I can backup my phone using open recovery?
If this is true, then the next step is to test a rom which can works well on XT711. I think hhcat is the best one who can play a part in it because his wife has a XT711. Who can help us to develop a stable rom for XT711? I can't wait for it! It's a very good news to those who had brought it because MOTO has disappointed us for a long time. They are unwilling to unlock BL and never considering upgrade phones they had selled out.
telnet777 said:
Thank you for your timely reply!
You mentioned "There should be no problems using bootstrap OpenRecovery."
Do you mean the open recovery works well on XT711? We got no further for safety when seeing error occurs. How to entering open recovery? Does press camera button when selecting "apply sdcard:update.zip " ? So I can backup my phone using open recovery?
Click to expand...
Click to collapse
Hmm. That doesn't sound like OpenRecovery--that sounds like Motorola's stock recovery. If you press and hold volume-up while powering on (hold until you see the boot animation or OpenRecovery menu), does your phone boot to Android or OpenRecovery? OpenRecovery will say
Motorola MILESTONE XT720 Open Recovery
Version 1.46
Created by Skrilax_CZ
on the top and boots straight to the main menu.
Mioze7Ae said:
Hmm. That doesn't sound like OpenRecovery--that sounds like Motorola's stock recovery. If you press and hold volume-up while powering on (hold until you see the boot animation or OpenRecovery menu), does your phone boot to Android or OpenRecovery? OpenRecovery will say
Motorola MILESTONE XT720 Open Recovery
Version 1.46
Created by Skrilax_CZ
on the top and boots straight to the main menu.
Click to expand...
Click to collapse
Do you mean it is not the time to say open recovery for XT720 works well on XT711? Because I don't know how to enter open recovery when reboot, we press media button and power on which entered stock recovery. I will retry to enter it by volume up and power on asap.
Does the fastboot boot works on XT711 is still a good news? I think it can help to do something.
We are trying to enter open recovery.
It seems that we entered a lite version of open recovery.
The installation is successful. Then power off. Press and hold volumn-up then power on. The phone stopped at moto logo. Release all button, then the screen is off and the phone reboot normally. Then we power off and try again. It still stopped at moto logo.It is all we can see.
Then we tried OpenRecovery.apk.
Hi,
I'm considering buying an used TF700 and installing Ubuntu on it (see this thread). I'm hesitating because of the possibility to brick the tablet, so I want to get a clarification about what the exact risks are.
As far as I understand, the Tegra 3 on TF700 firstly boots into some internal, non-reflashable bootloader that supports nvflash (APX mode) on certain circumstances. If everything is OK, the tablet then boots into the general bootloader on the flash that supports fastboot protocol. This bootloader can either boot to Android or to recovery, possibly verifying the cryptographic signature of the kernel if the tablet is not yet unlocked. Can anyone confirm that my understanding is correct?
In general, any problem with software installation can be solved by a "lower level" layer. So, in case of TF700, does the following hold true under ALL circumstances?
1) An invalid linux kernel flash or an invalid system partition can be fixed using the tools in the recovery partition.
2) The above plus a bad recovery partition can be fixed using fastboot protocol of the bootloader.
3) The above plus a bad bootloader can be fixed using nvflash utility, but only if authentication data was retrieved beforehand.
So, if I ensure that the bootloader is never replaced, there's no chance to brick the tablet. Am I correct?
Thanks!
pvka13 said:
As far as I understand, the Tegra 3 on TF700 firstly boots into some internal, non-reflashable bootloader that supports nvflash (APX mode) on certain circumstances.
Click to expand...
Click to collapse
Yes, when you hold down "volume up". And you need the wheelie tool and your personal blob.bin file to use nvflash.
pvka13 said:
If everything is OK, the tablet then boots into the general bootloader on the flash that supports fastboot protocol. This bootloader can either boot to Android or to recovery, possibly verifying the cryptographic signature of the kernel if the tablet is not yet unlocked. Can anyone confirm that my understanding is correct?
Click to expand...
Click to collapse
Confirmed correct, from what I read about all this (and it was a lot). Or we are both wrong.
pvka13 said:
In general, any problem with software installation can be solved by a "lower level" layer. So, in case of TF700, does the following hold true under ALL circumstances?
1) An invalid linux kernel flash or an invalid system partition can be fixed using the tools in the recovery partition.
2) The above plus a bad recovery partition can be fixed using fastboot protocol of the bootloader.
3) The above plus a bad bootloader can be fixed using nvflash utility, but only if authentication data was retrieved beforehand.
Click to expand...
Click to collapse
Almost. See below.
pvka13 said:
So, if I ensure that the bootloader is never replaced, there's no chance to brick the tablet. Am I correct?
Click to expand...
Click to collapse
No. There is at least one known bricking situation, and it works like this:
- You have an old TWRP version installed, from pre-JB times.
- You have the JB bootloader installed.
- You select "wipe data" in the bootloader menu.
Now your tablet is bricked, because the bootloader will try to start the recovery, which does not work because it cannot access the internal storage for some reason. However the bootloader will also refuse to start anything else, so you cannot use fastboot to recover.
Some developer said that the inability of the old recovery to access the eMMC has to do with the TF platform (Trusted Foundation) that was enabled for the TF700 in 9.4.5.30 or 10.4.4.16. It seems to be some DRM-related stuff.
So be careful with bootloader instructions to boot into the recovery - always make sure that your recovery is able to work with your current bootloader (using the manual method of holding Volume-down while powering up) before using "wipe data" or any "boot to recovery" tools.
_that said:
No. There is at least one known bricking situation, and it works like this:
- You have an old TWRP version installed, from pre-JB times.
- You have the JB bootloader installed.
- You select "wipe data" in the bootloader menu.
Now your tablet is bricked, because the bootloader will try to start the recovery, which does not work because it cannot access the internal storage for some reason. However the bootloader will also refuse to start anything else, so you cannot use fastboot to recover.
Some developer said that the inability of the old recovery to access the eMMC has to do with the TF platform (Trusted Foundation) that was enabled for the TF700 in 9.4.5.30 or 10.4.4.16. It seems to be some DRM-related stuff.
So be careful with bootloader instructions to boot into the recovery - always make sure that your recovery is able to work with your current bootloader (using the manual method of holding Volume-down while powering up) before using "wipe data" or any "boot to recovery" tools.
Click to expand...
Click to collapse
Too bad the bootloader doesn't support fastboot at all times. That's a bit stupid decision, since the bootloader should, by design, be the last resort option that always works.
i have a rooted/unlocked TF700t
TWRP 2.2.2.1 installed
alright, so i wanted to do a factory reset (through android, not twrp) but every time i tried it would boot me into TWRP and not actually do anything.
at some point i did all the wipe options in TWRP and even did the wipe option in recovery menu (pwr+voldown)
now i have no idea what happened.
I cannot boot up my pad at all. it immediately goes from the asus splash into TWRP every single time.
recovery mode (power+voldown) does not work at all. nothing comes up. just straight to TWRP.
I cannot install anything. an error with /cache and kills the install every time
I can only mount /system. the rest do not check for me (sdcard,data,cache are my only other options to mount)
I cannot even adb/fastboot. just says "waiting for device" and the list of connected devices is empty (however my pc does detect an adb device under the device manager when i plug in)
I have ZERO access to anything other than TWRP.
I am really on my last legs here
bark00000 said:
i have a rooted/unlocked TF700t
TWRP 2.2.2.1 installed
alright, so i wanted to do a factory reset (through android, not twrp) but every time i tried it would boot me into TWRP and not actually do anything.
at some point i did all the wipe options in TWRP and even did the wipe option in recovery menu (pwr+voldown)
now i have no idea what happened.
Click to expand...
Click to collapse
You bricked your tablet - TWRP 2.2 is ancient and not compatible with current bootloaders.
There is hope - if you can get access to TWRP via adb shell, it should be possible to recover.
Edit: Read this thread: http://forum.xda-developers.com/showthread.php?t=2291974
I hope you didn't successfully wipe your Android system, otherwise it may be hard or impossible to fix this. The first step is to determine if you even have access to your storage from the recovery. If not, read post #14 in that thread (the related instructions are in post #10) and see if you can get to the bootloader menu and use fastboot or cold boot Android.
As said due to you being on a very old version of twrp there's a possibility you have bricked it. Try _that's suggestion and let us know.
sbdags said:
As said due to you being on a very old version of twrp there's a possibility you have bricked it. Try _that's suggestion and let us know.
Click to expand...
Click to collapse
[/COLOR]
_that said:
You bricked your tablet - TWRP 2.2 is ancient and not compatible with current bootloaders.
There is hope - if you can get access to TWRP via adb shell, it should be possible to recover.
Edit: Read this thread: http://forum.xda-developers.com/showthread.php?t=2291974
I hope you didn't successfully wipe your Android system, otherwise it may be hard or impossible to fix this. The first step is to determine if you even have access to your storage from the recovery. If not, read post #14 in that thread (the related instructions are in post #10) and see if you can get to the bootloader menu and use fastboot or cold boot Android.
Click to expand...
Click to collapse
I'm in the same boat as the OP. Did try bootit.ko and the tab did boot to Android. Ran into the same problem as the person in the thread referred to above with the CWM recovery. Mine reported
loop1
loop2
loop3
loop4
loop5
loop6
loop7
mmcblk0
Did try hex dump as instructed in the thread but returned nothing. What should I do, if anything? Help, please.
Note: As there was _that's question about access to internal storage from TWRP recovery, I've enclosed a thumb for perusal.
graphdarnell said:
[/COLOR]
I'm in the same boat as the OP. Did try bootit.ko and the tab did boot to Android.
Click to expand...
Click to collapse
If your Android is rooted, this can be fixed:
Boot Android, and in Terminal or via adb shell, run the following commands:
Code:
su
dd if=/dev/zero of=/dev/block/mmcblk0p3 bs=32 count=1
This should break the forced reboot to recovery, and it will enable the boot menu and normal booting to Android again.
Your picture only shows the contents of the recovery's ramdisk but not anything from the internal storage - you'd have to navigate to /dev/block and see if mmcblk0p1 to mmcblk0p8 appear there.
_that said:
If your Android is rooted, this can be fixed:
Boot Android, and in Terminal or via adb shell, run the following commands:
Code:
su
dd if=/dev/zero of=/dev/block/mmcblk0p3 bs=32 count=1
This should break the forced reboot to recovery, and it will enable the boot menu and normal booting to Android again.
Your picture only shows the contents of the recovery's ramdisk but not anything from the internal storage - you'd have to navigate to /dev/block and see if mmcblk0p1 to mmcblk0p8 appear there.
Click to expand...
Click to collapse
Su command returns "not found" though superuser was installed before. Su binaries are not found in /system/bin/sh, and I can't find a way to root it now since twrp doesn't see the zip from where it is. Is there a way to copy the zip anywhere in internal storage to permit twrp to access it, or a rooting method from inside android? I tried chainfire su with the same result - no su binaries installed.
/dev/block shows mmc0blck0p3. That's it. However, running ls /dev/block shows as captured in the enclosed thumb.
graphdarnell said:
Su command returns "not found" though superuser was installed before. Su binaries are not found in /system/bin/sh, and I can't find a way to root it now since twrp doesn't see the zip from where it is.
Click to expand...
Click to collapse
OK, that means it is not rooted. Which Android version is that? Stock? If it's build 10.6.1.14.8 or earlier, it can be rooted with Motochopper.
_that said:
OK, that means it is not rooted. Which Android version is that? Stock? If it's build 10.6.1.14.8 or earlier, it can be rooted with Motochopper.
Click to expand...
Click to collapse
Thanks a million, it resurrected my tab. You're the devil!
_that said:
OK, that means it is not rooted. Which Android version is that? Stock? If it's build 10.6.1.14.8 or earlier, it can be rooted with Motochopper.
Click to expand...
Click to collapse
A question of purely academic (or un-academic) at this point. So if you have custom recoveries installed, you'd have access to ADB on the intial screen, but not when the tab's on official recovery? Even if you have custom recoveries installed and you cannot access it - as when volume down + power or any other jump-start method would still take you to the booting process that wouldn't complete - you'd still have access to ADB or fastboot or not?
graphdarnell said:
So if you have custom recoveries installed, you'd have access to ADB on the intial screen, but not when the tab's on official recovery? Even if you have custom recoveries installed and you cannot access it - as when volume down + power or any other jump-start method would still take you to the booting process that wouldn't complete - you'd still have access to ADB or fastboot or not?
Click to expand...
Click to collapse
The fastboot protocol is implemented by the bootloader and is available while the bootloader menu is shown (or after selecting "USB" in old bootloaders that had that icon).
The adb protocol is implemented by the adbd program (adb daemon), which requires at least a running Linux kernel, a running Android init, and a configuration that starts adbd. The stock recovery doesn't start adbd, but both known custom recoveries (TWRP and CWM) do. Android starts adbd if "USB debugging" is enabled in Settings.
_that said:
The fastboot protocol is implemented by the bootloader and is available while the bootloader menu is shown (or after selecting "USB" in old bootloaders that had that icon).
The adb protocol is implemented by the adbd program (adb daemon), which requires at least a running Linux kernel, a running Android init, and a configuration that starts adbd. The stock recovery doesn't start adbd, but both known custom recoveries (TWRP and CWM) do. Android starts adbd if "USB debugging" is enabled in Settings.
Click to expand...
Click to collapse
If I strike you as an ignoramus, that's because I'm one when it comes to this type of software setup. I know a bit more about hardware than soft. But to clarify, when you have a tab that's stuck in the initial screen (Asus logo with "device unlocked") without more - commonly referred to as being "bricked" - like so many with a TF300 who effected OTA updates that never finished, the bootloader was then gone and there was absolutely no way to rewrite it unless you have NVflash files generated prior?
The difference in our case at hand is what? Here we still have the bootloader that doesn't show because of that glitch that triggered booting straight into the custom recovery instead? And your instructions break the cycle?
Last but not least, thank you again for taking the time to respond. If this involves too much technical stuff for someone like me, please ignore.
graphdarnell said:
But to clarify, when you have a tab that's stuck in the initial screen (Asus logo with "device unlocked") without more - commonly referred to as being "bricked" - like so many with a TF300 who effected OTA updates that never finished, the bootloader was then gone and there was absolutely no way to rewrite it unless you have NVflash files generated prior?
Click to expand...
Click to collapse
I don't know the situation on the TF300 and why they have 3 different and incompatible bootloader/recovery combinations. I also don't know what "Unrecoverable bootloader error" means (other than "you're screwed").
graphdarnell said:
The difference in our case at hand is what? Here we still have the bootloader that doesn't show because of that glitch that triggered booting straight into the custom recovery instead? And your instructions break the cycle?
Click to expand...
Click to collapse
Correct. The bootloader has a nasty "feature" that if the misc partition (mmcblk0p3) contains the command to boot to recovery, there is no way to activate fastboot. With some version of the bootloader they changed something so that older kernels - like those in older recoveries - can no longer access the internal eMMC storage (error -110), so there is no way to clear that command in the misc partition from the recovery.
In this situation there are only 2 possible ways to recover: NVflash (with wheelie and the matching blob for your device), or a rooted Android system and some way to boot it. Not aware of "adb reboot bootloader" at that time I wrote a loadable kernel module for someone else a while ago, but today it was confirmed that apparently the module works better than adb reboot bootloader: http://forum.xda-developers.com/showthread.php?t=2528313
graphdarnell said:
Last but not least, thank you again for taking the time to respond. If this involves too much technical stuff for someone like me, please ignore.
Click to expand...
Click to collapse
Don't hesistate to ask if you want to know more.
Recommended precautions on Asus tablets with a custom recovery:
* Know your bootloader version.
* Read XDA and always use a recovery compatible with your bootloader version.
* Make blobs for nvflash and the recommended backups *before* you brick your device.
Avoiding writing the "reboot to recovery" command to misc:
* Don't use "reboot to recovery" features a custom ROM or recovery installer might offer, especially after flashing a new version of the recovery - always always start it the via power/volume button combination at least for the first time to test if it works.
* Avoid "Wipe data" in the bootloader menu and "Factory reset" in Android settings.
_that said:
I don't know the situation on the TF300 and why they have 3 different and incompatible bootloader/recovery combinations. I also don't know what "Unrecoverable bootloader error" means (other than "you're screwed").
Correct. The bootloader has a nasty "feature" that if the misc partition (mmcblk0p3) contains the command to boot to recovery, there is no way to activate fastboot. With some version of the bootloader they changed something so that older kernels - like those in older recoveries - can no longer access the internal eMMC storage (error -110), so there is no way to clear that command in the misc partition from the recovery.
In this situation there are only 2 possible ways to recover: NVflash (with wheelie and the matching blob for your device), or a rooted Android system and some way to boot it. Not aware of "adb reboot bootloader" at that time I wrote a loadable kernel module for someone else a while ago, but today it was confirmed that apparently the module works better than adb reboot bootloader: http://forum.xda-developers.com/showthread.php?t=2528313
Don't hesistate to ask if you want to know more.
Recommended precautions on Asus tablets with a custom recovery:
* Know your bootloader version.
* Read XDA and always use a recovery compatible with your bootloader version.
* Make blobs for nvflash and the recommended backups *before* you brick your device.
Avoiding writing the "reboot to recovery" command to misc:
* Don't use "reboot to recovery" features a custom ROM or recovery installer might offer, especially after flashing a new version of the recovery - always always start it the via power/volume button combination at least for the first time to test if it works.
* Avoid "Wipe data" in the bootloader menu and "Factory reset" in Android settings.
Click to expand...
Click to collapse
I don't know if I'm gyrating sur place,or pushing the envelope here, but with the acer A500 (which of course uses the same Tegra T20 as the TF101), the released NVFlash Code allows for erasure of the partitions, and then while in APX mode, enables rewriting of the partition table, which in turn allows reloading of a bootloader in place of that which has been corrupted. This, I've done: the apx command returns the particular SBK of the tab, which opens the door for reflashing of whatever.
Apparently, a bricked TF101 can be similarly unbricked with the help of a comparable software tool, though I've never had to resort to it. The situation with Tegra 3 is that Asus encrypted the code, which makes it impossible to rewrite the bootloader. Am I assuming correctly so far? If yes, then 2 questions:
(1) Nvflash for JB is now possible,which indicates some “inadvertent” leak somewhere to someone. If the code is now available for an Nvflash exploit, why can't the same thing be done as with the Tegra T20 chip? Therein, one doesn't need Nvflash files generated beforehand to extricate from a “brick”;
(2) Asus must have a decrypt tool to unlock that impasse (to us) embedded in Tegra chips they installed on their tabs. I assume the same code is used for all Tegra chips, or at least a batch of them, because Flatline.img works across the board regardless of individual SBKs.
If they do have this tool (they must have it), theoretically, there's no need to replace the motherboard where the tab “bricks” as a result of an OTA gone awry. Asus can just reflash the bootloader. Am I off the mark?
I realize this is a lot to ask of a member who participates gratuitously. You've done more than your share of giving and helping. I evidently would prefer a response from you, since that way, I can benefit from your insights. However, I'd equally appreciate a referral for further readings. Thanks again.
graphdarnell said:
I don't know if I'm gyrating sur place,or pushing the envelope here, but with the acer A500 (which of course uses the same Tegra T20 as the TF101), the released NVFlash Code allows for erasure of the partitions, and then while in APX mode, enables rewriting of the partition table, which in turn allows reloading of a bootloader in place of that which has been corrupted. This, I've done: the apx command returns the particular SBK of the tab, which opens the door for reflashing of whatever.
Apparently, a bricked TF101 can be similarly unbricked with the help of a comparable software tool, though I've never had to resort to it. The situation with Tegra 3 is that Asus encrypted the code, which makes it impossible to rewrite the bootloader. Am I assuming correctly so far? If yes, then 2 questions:
(1) Nvflash for JB is now possible,which indicates some “inadvertent” leak somewhere to someone. If the code is now available for an Nvflash exploit, why can't the same thing be done as with the Tegra T20 chip? Therein, one doesn't need Nvflash files generated beforehand to extricate from a “brick”;
(2) Asus must have a decrypt tool to unlock that impasse (to us) embedded in Tegra chips they installed on their tabs. I assume the same code is used for all Tegra chips, or at least a batch of them, because Flatline.img works across the board regardless of individual SBKs.
If they do have this tool (they must have it), theoretically, there's no need to replace the motherboard where the tab “bricks” as a result of an OTA gone awry. Asus can just reflash the bootloader. Am I off the mark?
I realize this is a lot to ask of a member who participates gratuitously. You've done more than your share of giving and helping. I evidently would prefer a response from you, since that way, I can benefit from your insights. However, I'd equally appreciate a referral for further readings. Thanks again.
Click to expand...
Click to collapse
Yes your correct with the tf101 and other tegra 2 devices, NvFlash is available without having to generate blobs etc. This is because the SBK or secure boot key which encrypts nvflash communication is known so generic nvflash binary's can be used.
However from the Transformer Prime and onwards, The SBK is not known so work arounds are required to access NvFlash communication. Im a bit fuzzy with the details here on im sure _that will correct me if im wrong .
It requires a patched bootloader, it seems this patched bootloader can manipulate the devices AES encryption engine (This engine is the only thing that can read the SBK directly, its used to encrypt the boot partition after an OTA update) to encrypt wheelie blobs (wheelie is a pre-loader for NvFlash aka it opens the door for nvflash communication) Now you have signed wheelie blobs (with a unique signature to your device) you can use them to authenticate NvFlash and gain access. And we didnt need to know the SBK! And once this process has been done, you can swap back the official non patched bootloader, in fact you could completely wipe nand, with NvFlash be able to re-write these partitions.
But this method requires an unbricked and unlocked device, since we need to flash the patched bootloader, and use a modified recovery to generate those wheelie blobs. The good thing about this is once you've done it thats it. Asus cant do anything about it. Since the SBK is embedded deep in one-time programmable memory they cant change your devices SBK meaning those wheelie blobs will always be vaild.
If you send a bricked device back to Asus for repair AFAIK know they will have to replace the motherboard to repair it. Otherwise they would have had to leave a writable bus somewhere on the motherboard to let you re-write nand. Some kind of JTAG exploit might be possible, but thats far out of my league
JoinTheRealms said:
Yes your correct with the tf101 and other tegra 2 devices, NvFlash is available without having to generate blobs etc. This is because the SBK or secure boot key which encrypts nvflash communication is known so generic nvflash binary's can be used.
However from the Transformer Prime and onwards, The SBK is not known so work arounds are required to access NvFlash communication. Im a bit fuzzy with the details here on im sure _that will correct me if im wrong .
It requires a patched bootloader, it seems this patched bootloader can manipulate the devices AES encryption engine (This engine is the only thing that can read the SBK directly, its used to encrypt the boot partition after an OTA update) to encrypt wheelie blobs (wheelie is a pre-loader for NvFlash aka it opens the door for nvflash communication) Now you have signed wheelie blobs (with a unique signature to your device) you can use them to authenticate NvFlash and gain access. And we didnt need to know the SBK! And once this process has been done, you can swap back the official non patched bootloader, in fact you could completely wipe nand, with NvFlash be able to re-write these partitions.
But this method requires an unbricked and unlocked device, since we need to flash the patched bootloader, and use a modified recovery to generate those wheelie blobs. The good thing about this is once you've done it thats it. Asus cant do anything about it. Since the SBK is embedded deep in one-time programmable memory they cant change your devices SBK meaning those wheelie blobs will always be vaild.
If you send a bricked device back to Asus for repair AFAIK know they will have to replace the motherboard to repair it. Otherwise they would have had to leave a writable bus somewhere on the motherboard to let you re-write nand. Some kind of JTAG exploit might be possible, but thats far out of my league
Click to expand...
Click to collapse
Thanks for the very instructive information, if only relatively so to me (lol). In any case, let's see how low-IQ I can get here: the SBK is particular to every motherboard, but the tool that encrypts and conversely decrypts and read it is not; it can be manipulated to retrieve the SBK of any MB, if available. Am I right? If there's a way out, there must be a way in, eh?
“... AES encryption engine (This engine is the only thing that can read the SBK directly, its used to encrypt the boot partition after an OTA update...” According to this scenario, we have something that could read the SBK directly, or at least can manipulate AES to do so, right?
If the SBK, whether burned into or not, is known, refashioning the NAND is possible through some software tools, like say Bab Sector? Then why does Asus have to replace the MB? It looks like every time you troll an OTA, a new bootloader is rewritten!
Where the brick is caused by the bootloader being corrupt or effaced, how is rewriting it different from an OTA doing it? I mean, how did they initially program the bootloader onto a virgin mmc anyway?
At any rate, we should wait to see if Merlin would respond and whether it'd shed anymore light onto this before going on, or not.
graphdarnell said:
“... AES encryption engine (This engine is the only thing that can read the SBK directly, its used to encrypt the boot partition after an OTA update...” According to this scenario, we have something that could read the SBK directly, or at least can manipulate AES to do so, right?
Click to expand...
Click to collapse
Maybe "read the SBK" is the wrong term here. As far as I understand, the AES engine *uses* the SBK to encrypt or decrypt data, but there is no way to extract the SBK from the engine.
As JoinTheRealms explained, wheelie allows us to use nvflash without knowing the SBK at all, but we need a pre-encrypted blob that was encrypted by our own device with its unique key. Flatline is just another way to work around the bootloader signature so that this blob can be created, there is still no way to read the SBK directly.
graphdarnell said:
Then why does Asus have to replace the MB?
Click to expand...
Click to collapse
Because I assume the service centers that do the repairs don't have the access to the SBKs either. And it's more profitable for them to charge for a new mainboard than just for reflashing the firmware anyway.
_that said:
Because I assume the service centers that do the repairs don't have the access to the SBKs either. And it's more profitable for them to charge for a new mainboard than just for reflashing the firmware anyway.
Click to expand...
Click to collapse
No kidding!!
I have a Honor 8/FRD-L14 (US model) which I purchased a couple months back. I decided I wanted to root it, so I unlocked the bootloader, installed TWRP (version 3.1.1-1 for FRD-L14) and magisk. To cut to the chase, a lot of my apps didn't work after restoring my backup so I thought I would start over from scratch.
So I had the brilliant idea to wipe all my partitions in TWRP, thinking it would be easy to restore from a blank slate. Nope.
I have obtained a copy of B389 (FRD-L14C567B389b) firmware, both update.zip and update_full_FRD-L14_hw_usa.zip. The first is about 1.3 GB, and the latter is 683 MB..
Here's what I can do:
1. I can unlock and "oem relock" the phone, using TWRP or stock recovery as appropriate.
2. I can boot into Huawei eRecovery, but it always reports "Getting package info failed". It's done this all along.
3. I can boot into TWRP, and attempt to sideload. If I try to sideload the larger "update.zip", it fails immediately. If I try to sideload the smaller "update_full_FRD-L14_hw_usa.zip", it fails at 50%. In both cases the display shows the following:
Code:
Updating partition details...
...done
Full SELinux support is present.
MTP Enabled
Starting ADB sideload feature...
Installing zip file '/sideload/package.zip'
Verifying current userdata...
mountencrypt: failed to mount /data: No such file or directory
Removing unneeded files...
Patching userdata files...
Removing empty directories...
Unpacking data new files...
add link type file...
write radio image...
check_write_data_to_partition,write data error
[COLOR="red"]E:unknown command [errno][/COLOR]
update_huawei_pkg_from_ota_zip: update package from zip failed
[COLOR="Red"]Updater process ended with ERROR: 7[/COLOR]
4. I can "fastboot flash" system SYSTEM.img, boot BOOT.img, cust CUST.img, and recovery RECOVERY.img extracted from the UPDATE.APPs mentioned earlier.
5. HiSuite restore reports that my device is not supported, whether locked or relocked.
6. I have a 128 GB SDXC, and I have attempted to load the two UPDATE.APP files from the aforementioned zip files. Either UPDATE.app, whether placed at root level or in a directory called "dload", gives the same error when trying the 3-button flash function: "Software install failed!", always at 5%.
At no point have I been able to actually boot the OS. If I do not select one of the various recovery modes, the phone never progresses past the unlocked warning message with orange text. (If the phone is locked, it warns that it has "failed verification" with red text, but still won't proceed.)
It really seems like I must simply be doing something wrong here. Apparently I have all the tools I should need available and functional. And yet, I cannot restore the phone to stock firmware.
* Does anyone know what I'm doing wrong? And, does anyone know anything about whether I should be using some particular firmware version for this, and if so which one?
* Is the problem the /data directory? How do I repair/restore that?
marshaul said:
I have a Honor 8/FRD-L14 (US model) which I purchased a couple months back. I decided I wanted to root it, so I unlocked the bootloader, installed TWRP (version 3.1.1-1 for FRD-L14) and magisk. To cut to the chase, a lot of my apps didn't work after restoring my backup so I thought I would start over from scratch.
So I had the brilliant idea to wipe all my partitions in TWRP, thinking it would be easy to restore from a blank slate. Nope.
I have obtained a copy of B389 (FRD-L14C567B389b) firmware, both update.zip and update_full_FRD-L14_hw_usa.zip. The first is about 1.3 GB, and the latter is 683 MB..
Here's what I can do:
1. I can unlock and "oem relock" the phone, using TWRP or stock recovery as appropriate.
2. I can boot into Huawei eRecovery, but it always reports "Getting package info failed". It's done this all along.
3. I can boot into TWRP, and attempt to sideload. If I try to sideload the larger "update.zip", it fails immediately. If I try to sideload the smaller "update_full_FRD-L14_hw_usa.zip", it fails at 50%. In both cases the display shows the following:
4. I can "fastboot flash" system SYSTEM.img, boot BOOT.img, cust CUST.img, and recovery RECOVERY.img extracted from the UPDATE.APPs mentioned earlier.
5. HiSuite restore reports that my device is not supported, whether locked or relocked.
6. I have a 128 GB SDXC, and I have attempted to load the two UPDATE.APP files from the aforementioned zip files. Either UPDATE.app, whether placed at root level or in a directory called "dload", gives the same error when trying the 3-button flash function: "Software install failed!", always at 5%.
At no point have I been able to actually boot the OS. If I do not select one of the various recovery modes, the phone never progresses past the unlocked warning message with orange text. (If the phone is locked, it warns that it has "failed verification" with red text, but still won't proceed.)
It really seems like I must simply be doing something wrong here. Apparently I have all the tools I should need available and functional. And yet, I cannot restore the phone to stock firmware.
* Does anyone know what I'm doing wrong? And, does anyone know anything about whether I should be using some particular firmware version for this, and if so which one?
* Is the problem the /data directory? How do I repair/restore that?
Click to expand...
Click to collapse
I had written this guide a long time back. It didn't recieve any attention but holds true for your device. If you restore by rollback you can relock the bootloader with the "LOCKED" status rather than the "RELOCKED" which means your warranty won't be void.
Here's the guide:
https://forum.xda-developers.com/honor-8/how-to/restoring-relocking-bricked-frd-l04-t3666360
The only difference is download the rollback packages from this thread:
https://forum.xda-developers.com/ho...users-how-to-restore-downgrade-t3537433/page1
Sent from my Honor 8 using XDA Labs
Thanks for the response.
Is there any reason I should rollback to the version you discuss?
I looked at the backup I made before unlocking, and it was FRD-L14C567B391. So I downloaded this and have been attempting to use it.
Flashing the recovery.img and attempting to 3-button install UPDATE.app doesn't work. It does the same thing it's done all along: immediately stops at 5%.
If I attempt to sideload this I do get a new error (I'll share it when I get home).
BTW, is every android phone so fussy about this stuff? I will never consider this platform again after how unwilling it seems to do basic restore procedures -- not sure if that's just Huawei or all androids. Either way there's really no excuse -- just flash the damn software and try to run it.
marshaul said:
Thanks for the response.
Is there any reason I should rollback to the version you discuss?
I looked at the backup I made before unlocking, and it was FRD-L14C567B391. So I downloaded this and have been attempting to use it.
Flashing the recovery.img and attempting to 3-button install UPDATE.app doesn't work. It does the same thing it's done all along: immediately stops at 5%.
If I attempt to sideload this I do get a new error (I'll share it when I get home).
BTW, is every android phone so fussy about this stuff? I will never consider this platform again after how unwilling it seems to do basic restore procedures -- not sure if that's just Huawei or all androids. Either way there's really no excuse -- just flash the damn software and try to run it.
Click to expand...
Click to collapse
Nope this is only on Huawei phones. The reason I recommend the rollback process is because it helps you restore your phone to the state you bought it (Including a "LOCKED" not "RELOCKED" bootloader). A TWRP flash will get you on the stock ROM but future OTAs might be a pain and safetynet will not pass without Magisk. Using this method you will be on the right recovery and latest firmware with everything official. Also if you have warranty this method restores it.
On phones from Google, Samsung, etc restoring is insanely simple. Huawei doesn't encourage third party development.
Sent from my Honor 8 using XDA Labs