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!!
Three weeks ago I found my Moto G in this situation: http://cdn.techpp.com/wp-content/uploads/2012/08/How-to-Save-a-Bricked-Android-Smartphone-1.png. So I unlocked the bootloader and I tried to flash stock firmware but I have not been able to do this . I also tried to flash TWRP and CWM with success, but you didn't succeed to flash any ROM. I decided to send my phone to Motorola, but they didn't repair it because I unlocked the bootloader. In the end I follow this http://forum.xda-developers.com/showthread.php?t=2542219 with XT1032_RETAIL-EU_4.4.4_KXB21.14-L1.40_36_cid7_CFC_1FF.xml.zip , at each step the word "OKAY" has appeared but when i reboot the phone it return to http://cdn.techpp.com/wp-content/uploads/2012/08/How-to-Save-a-Bricked-Android-Smartphone-1.png. Can anyone help me??
That image looks like the stock recovery. When you get to that screen, press power and vol up buttons at the same time. This will take you to a menu that includes factory reset and other options.
Watch this video: http://youtu.be/vf2sOPoE2b4?list=UUWhQwvCaC2ZMkCnrC15NfAw (This should work for the 1gen as well)
DISCLAIMER: I TAKE NO RESPONSIBILITY FOR YOUR DEVICE DYING AND SUCH. YOU THE USER ARE ENTIRELY RESPONSIBLE!
I have follow the video, but after I make factory reset and reboot the phone it return to Droid with exclamation mark
I was wrong, when I type "fastboot reboot", after 10 seconds appear: - Fastboot Reason: UTAG "flashfail" configured as fastboot USB connected -
If you cut and paste the fastboot commands from the tutorial - did you change:
system.img_sparsechunk1, system.img_sparsechunk2 etcto match the actual files you have on your hard disk? For example, the firmware files might actually have been:
system.img_sparsechunk.0, system.img_sparsechunk.1The files also need to be flashed in the correct ascending order.
lost101 said:
If you cut and paste the fastboot commands from the tutorial - did you change:
system.img_sparsechunk1, system.img_sparsechunk2 etcto match the actual files you have on your hard disk? For example, the firmware files might actually have been:
system.img_sparsechunk.0, system.img_sparsechunk.1The files also need to be flashed in the correct ascending order.
Click to expand...
Click to collapse
I have already done in this way
EDIT: I would like to know is if it's possible that the damage is not reparabile...
What is the easiest option here? Can i relock it somehow? I've never fiddled with android before so please use small words . I tried using mini ADP following this tutorial. It requires me to go into fastboot but i cant go, i press the volume buttons to switch between START, Recovery Mode, Restart Bootloader and Exit but there's no FAST BOOT option. I can see the "FastBood mode" writter with red letters, then bellow it
PRODUCT_name -jd2018
VARIANT - SDM EMMC
and some other info.
thandeer said:
It requires me to go into fastboot but i cant go .... but there's no FAST BOOT option. I can see the "FastBood mode" writter with red letters, then bellow it
PRODUCT_name -jd2018
VARIANT - SDM EMMC
and some other info.
Click to expand...
Click to collapse
You contradict yourself.
You can use command fastboot flashing lock.
Make sure get_unlock_ability is set to 0.
I followed the youtube video from this guide without flashing TWRP first or doing anything else. I failed to flash TWRP before doing what's in the video and my phone wouldnt boot and would give me qualcom crashdump. I then just followed the video and i installed a the stock ROM and now Revolut works for some reason even though i did not root and i still got unlocked bootloader
A phone always have 2 pieces of software: Bootloader and Android OS. These are 2 different softwares which are independent from each other.
Read also here:
Android Booting - eLinux.org
elinux.org