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!!
Related
Is it possible to replace the "real" Android recovery mode with something like OpenRecovery .. making it bootable even if the real system is broken ? Something with ADB and Nandroid preferrable
Open Recovery for the XT720
Alternately Dexter made an APK which will install Open Recovery.
Note in both cases you will need to be rooted.
TyrionWarMage said:
Is it possible to replace the "real" Android recovery mode with something like OpenRecovery .. making it bootable even if the real system is broken ? Something with ADB and Nandroid preferrable
Click to expand...
Click to collapse
IIRC the XT720 bootloader requires successful cryptographic signature validation before it boots the next step (either "real" recovery or kernel+ramdisk). /system's signature is not checked by either the bootloader nor by boot.img, so to do anything non-Motorola endorsed we have to plant the hijacks there.
I'm not aware of any way around flashing a sbf over USB if the system partition gets too broken or if the boot image is tampered with and fails signature check.
Without a exploitable bug in the bootloader itself (none have been found for the Milestone--not sure anyone is even looking on XT720) or Motorola's private signing keys, we have no choice but to rely on normal boot+hijacked /system.
Mioze7Ae said:
IIRC the XT720 bootloader requires successful cryptographic signature validation before it boots the next step (either "real" recovery or kernel+ramdisk). /system's signature is not checked by either the bootloader nor by boot.img, so to do anything non-Motorola endorsed we have to plant the hijacks there.
I'm not aware of any way around flashing a sbf over USB if the system partition gets too broken or if the boot image is tampered with and fails signature check.
Without a exploitable bug in the bootloader itself (none have been found for the Milestone--not sure anyone is even looking on XT720) or Motorola's private signing keys, we have no choice but to rely on normal boot+hijacked /system.
Click to expand...
Click to collapse
Was afraid tho, thx for the confirmation.
@3rdstring: That is the common bootstrap loader that requires the system to work.
I I was wondering if there was another Recovery next to open recovery that one could use.
I like OR, but what bugs me is that there seems no way to flash .zip files from within the recovery (both CWM and Danger-SPL have this option)
I would very much flash a ADW.zip over the system launcher, but had no luck so far (dont really want to just install the adw app and have it and the system launcher running)
Hi there, Can anyone help me to unrick my tf300, its stuck on the logo screen.
I have try many things, some guys from hong kong tell me i have to use APX mode to sort the problems out, I manage so far.
Drivers I download the is Universal_Naked_Driver_0.7, also use nvflash drivers, both I try. i still get te samethings when I try to use the nvflash
I turn on tf300 with volume up, few seconds the screen went blank, and hear a beep from my pc, so is connect alright.
I type download.bat command, with prime 1.4 rom in the same folder. after few seconds I get
nvflash start
unknow usb found.
Can anyone tell me what i done wrong here.
can someone show me some step by step.
otherwise is a waste of money, the tf300 not working.
THankyou
acelaw said:
Hi there, Can anyone help me to unrick my tf300, its stuck on the logo screen.
I have try many things, some guys from hong kong tell me i have to use APX mode to sort the problems out, I manage so far.
Drivers I download the is Universal_Naked_Driver_0.7, also use nvflash drivers, both I try. i still get te samethings when I try to use the nvflash
I turn on tf300 with volume up, few seconds the screen went blank, and hear a beep from my pc, so is connect alright.
I type download.bat command, with prime 1.4 rom in the same folder. after few seconds I get
nvflash start
unknow usb found.
Can anyone tell me what i done wrong here.
can someone show me some step by step.
otherwise is a waste of money, the tf300 not working.
THankyou
Click to expand...
Click to collapse
You flashed a PRIME rom to your tf300?
First of all, we should know which firmware do you have before your tablet doesn't boot (Stock ICS, JB, Custom Rom).
Then, you can use fastboot to recover your tablet (i did it a lot of times). Try steps below:
1. Download latest oficial Asus firmware (V10.4.2.13). BE SURE to download your region (WW, US, etc...)
2. Extract downloaded zip and take blob file.
3. Download Android SDK and install them on C:\ (http://developer.android.com/sdk/index.html)
4. Execute SDK downloader and mark tools and platform-tool options for download.
5. OPTIONAL add tools and platform-tool folder to PATH, after that test if fastboot command runs on CMD.
6 Copy blob file on same SDK folder.
7. Connect TF300T with usb cable and put it in Download Mode (USB icon on recovery menu)
8. Wait until drivers are installed.
7. Open CMD, go to Android SDK folder and then type command below:
fastboot -i 0x0B05 flash system blob
wait 2 or 3 minutes and then you'll see a message that send and write was OK. Now type this command:
fastboot -i 0x0B05 reboot
And It should boot again.
ppmeis said:
First of all, we should know which firmware do you have before your tablet doesn't boot (Stock ICS, JB, Custom Rom).
Then, you can use fastboot to recover your tablet (i did it a lot of times). Try steps below:
1. Download latest oficial Asus firmware (V10.4.2.13). BE SURE to download your region (WW, US, etc...)
2. Extract downloaded zip and take blob file.
3. Download Android SDK and install them on C:\ (http://developer.android.com/sdk/index.html)
4. Execute SDK downloader and mark tools and platform-tool options for download.
5. OPTIONAL add tools and platform-tool folder to PATH, after that test if fastboot command runs on CMD.
6 Copy blob file on same SDK folder.
7. Connect TF300T with usb cable and put it in Download Mode (USB icon on recovery menu)
8. Wait until drivers are installed.
7. Open CMD, go to Android SDK folder and then type command below:
fastboot -i 0x0B05 flash system blob
wait 2 or 3 minutes and then you'll see a message that send and write was OK. Now type this command:
fastboot -i 0x0B05 reboot
And It should boot again.
Click to expand...
Click to collapse
but fastboot need a unlocked bootloader, no?
Sent from my ASUS Transformer Pad TF300T using xda app-developers app
Yes, that's right, but I suppost if he tries to flash a custom rom he has already unlocked his device. You can't flash any rom without unlock bootloader.
I cant do anything apart from get on to apx mode, from apx mode how do I use command to flash back.
My tf300 is ics, unlock.
when i connect usb to pc. i press power and volume up. thats only things i can do.
so what do i do next?
thanks.
The same problem.
I only see: "device is unlocked" or something like that. And nothing go on.
Is it totaly bicked or is there any chance to restore it?
Please advice.
Did anybody ever figure this out. I'm in the same boat. Can't do vol down+power to get to recovery. But if i do volume up+power it shows in device manager as transformer prime apx interface (even though it's just a tf300)
bigworm82 said:
Did anybody ever figure this out. I'm in the same boat. Can't do vol down+power to get to recovery. But if i do volume up+power it shows in device manager as transformer prime apx interface (even though it's just a tf300)
Click to expand...
Click to collapse
Try this link.
http://forum.xda-developers.com/showthread.php?t=2034866
no way to unbrick tf300t
Funny, I bricked my tf300t without doing anything. One day it just got stuck in asus screen.
tried to recover, nothing happended.
tried hard reset. Nothing.
Wipe data: result: bricked tablet.
I'm looking for information it is defintely impossible to unbrick it.
Anybody else with the same situation can tell you that.
Nobody has even been able to do it.
If you send it to Asus they provide a new tablet.
Conclusion:
TF300T is a terrible product, as any other asus product i assume. Amazing that you can brick a tablet without even trying to flash it or without even being connected to a computer.
It bricks by itself. Hundreds of other users can confirm it.
My advice: dont by asus products
If you already have one, dont use wipe data as anybody who has done it has ended up with an expensive useless brick.
Odp: [Q] How to unbrick my tf300
I don't agree witch this, only think what you not should use is t the wipe data from bootloader menu - I already flashed many times not working kernel, get really often bootloop - the problem is - much users going to made stupid things when the get a soft bootloop - If you get this first try wipe data from recovery, if this won't help, try to format data from recovery - often happends that the ext4 filessystem get broken. Recovery should allowa us to run fsck on data - I fixed my bootloops many times with it without loosing my data.
Sent from my GALAXY Cooper
OP,
I think your anger is misdirected. The device, as it comes out of the box, works 100% without issues. YOU as a user decided to make changes that could potentially brick it. YOU chose to follow the steps with the full disclaimer that it can/may brick your device. So at the end of the day, its' not the fault of ASUS or the device for "bricking itself"; the responsibility of your actions lies on your own shoulders.
That being said, Asus will not provide warranty support for a tablet that has been unlocked. This is clearly stated in their unlocker app. So no, they won't "send you a new tablet" if you send it to them (unless you pay out of pocket for the repairs).
I've done just about as bad of a brick as I possibly can on my tablet and recovered just fine. It was just a matter of being CAREFUL, reading instructions three times before l followed them, and asking lots of questions. But what ultimately saved me was the NVFlash tool, and for that I am eternally grateful.
Just my two cents.
opethfan89 said:
OP,
I think your anger is misdirected. The device, as it comes out of the box, works 100% without issues. YOU as a user decided to make changes that could potentially brick it. YOU chose to follow the steps with the full disclaimer that it can/may brick your device. So at the end of the day, its' not the fault of ASUS or the device for "bricking itself"; the responsibility of your actions lies on your own shoulders.
That being said, Asus will not provide warranty support for a tablet that has been unlocked. This is clearly stated in their unlocker app. So no, they won't "send you a new tablet" if you send it to them (unless you pay out of pocket for the repairs).
I've done just about as bad of a brick as I possibly can on my tablet and recovered just fine. It was just a matter of being CAREFUL, reading instructions three times before l followed them, and asking lots of questions. But what ultimately saved me was the NVFlash tool, and for that I am eternally grateful.
Just my two cents.
Click to expand...
Click to collapse
I have problem that my partitions won't mount at all. I have access to fastboot, CWM, and adb but no matter what i cannot access my partitions and so i cannot install zip from CWM. When i try blob within fastboot my tablet just freezes.....
Hi, what happens if I have no access to fastboot? It loops in the ASUS logo and what ever I do, can't gain access to recovery because it doesn't get into fastboot. So how to solve it via APX? Thank you.
You wont solve the problem unless youve done a nvflash backup. If you tablet is recognised as APX while plugged in PC, then you have an unrecoverable brick. If nothing appears when you plug it, then try on another PC.
Sent from my TF300T using xda premium
unbrick tf300
ilyuha1108 said:
You wont solve the problem unless youve done a nvflash backup. If you tablet is recognised as APX while plugged in PC, then you have an unrecoverable brick. If nothing appears when you plug it, then try on another PC.
Sent from my TF300T using xda premium
Click to expand...
Click to collapse
Hi,
I am having a similar problem to the one described. I have unvblocked my TF300T and installed CWM recovery (v. 6.0.2.3), but it can't mount any filesystem, so I can not flash anything. The boot menu is gone (RCK, wipe tablet, android) and when I switch the tablet on It just goes to CWM. If I connect the tablet to a PC, I can send commands with adb from my win 7 PC (for instance "adb reboot" will reboot the tablet), but fastboot doesn't work (it keeps "waiting for device"). Prior to this my android version was JB 4.2. I didn't make any backup, so I am fearing the worst outcome. Did I brick my tablet for good?
Thanks a lot for any reply.
TF300T blocked on boot screen
hello everybody,
my name is jonathan, and i have a very big problem.
My Asus TF300t is blocked on boot screen after try to install a new rom on JB 4.2.2.
>My clockworkMod reconvery is v6.0.1.0.
I tried to install several roms, offical or not but the problem is the same, "The device is unlocked" on the boot screen Asus...
I read the previously posts and :
- i installed on my pc the sdk
- i dowload the "blob" file and i placed it on tools directory
- but, the actually problem is whis the lign "fastboot -i OxOBO5.... (i have copied and paste it on schell command) and enter
load_file: could not allocate 820157833 bytes
error: cannot load "blob": not enough space
can you help me please ?
i want to resolve this problem with you to install the best rom for this model.
Thank you very much and sorry for my english, i am french but i understand your paragraph.
See you soon
Jonathan
If you have mounting / PIT errors you could try my solution as described here:
http://forum.xda-developers.com/showpost.php?p=44244313&postcount=12
no guarantee though but it basically wipes your device so that you should be able to flash the blob file back.
also if your tab still is ICS- check if you are using the correct recovery - also bear in mind that cm10.1 afaik uses the new 4.2 bootloader and probably wont work with ics based PIT devices.
gl
same problem of space
Buster99 said:
If you have mounting / PIT errors you could try my solution as described here:
http://forum.xda-developers.com/showpost.php?p=44244313&postcount=12
no guarantee though but it basically wipes your device so that you should be able to flash the blob file back.
also if your tab still is ICS- check if you are using the correct recovery - also bear in mind that cm10.1 afaik uses the new 4.2 bootloader and probably wont work with ics based PIT devices.
gl
Click to expand...
Click to collapse
Hello man,
I try your method but the problem is the same when i want to copy the blob file, "not enough space ..."
fastboot erase system OK
fastboot erase recovery OK
fastboot erase userdata OK
fastboot erase boot OK
fastboot erase misc OK
fastboot erase cache OK
fastboot -i 0x0B05 flash system c:\adb\TF300t\blob PROBLEM
The message is the same like previously, always the problem of space.
I tries the method by copy the blob file on different directory on my computer and on a usb key too.
Always the same problem of space
I think the problem is the space on the tablet but i dont' understand. I erase system, recovery, userdata, boot, misc, cache, i think the tablet is empty.
Can you help me please ?
Thank you very much
Jonathan
which blob file did you use? Was the zip appropriate for your region? also what was the last stock rom version you ran - you said you wanted to update to 4.2.2 - what was the old version?
-Buster
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 found multiple development threads that are close to this, but here's the deal...
I took Asus 4.2.1 OTA update and used that for a while.
The device was already unlocked and I decided to try TWRP 2.4.4.0 for recovery before trying any custom ROMs
I followed the big bold red instructions that said:
If you have taken the official Asus Jellybean OTA then be sure to install the '-JB' version of the recovery for your device - and only flash roms that are based on the Asus OTA.
I downloaded the -JB version (at that time, -ICS was the only other choice), and installed it via fastboot.
Upon rebooting, it will only boot into recovery and TWRP can't see any partitions. More importantly, I've spent almost a month now reading the threads that are related to this trying various suggestions in trying to break out of this, and during this time, I've realized that I can't flash anything. ADB works, but the devices says "123456789ABCDEF recovery". I can run "adb reboot bootloader" and I will get my 3-icon 4.2.1 bootloader screen with a blinking green square on RCK. Fastboot devices shows my S/N, and it acts like it is flashing (tried flashing the -4.2 version of TWRP 2.4.4.0 and a new copy of the JB 4.2.1 OTA ROM), but all the tablet does is lock-up. The green square stops blinking and, even though fastboot says it's working, the tablet is no longer responding and requires a reset to reboot, upon which it boots right back into TWRP.
I'm just asking if there is a way out of this yet that doesn't involve replacing the main logic board.
I suppose what bothers me more, is that Teamwin's website for TWRP still has the same instructions in big bold red letters, without acknowledging that there are TWO official Asus Jellybean OTA releases. One will work just fine with the -JB version they specify to download, the other will do what mine did. Anyone current with Asus releases is gonna follow these instructions and brick their pads unless they already know about the -4.2 version of TWRP.
Yo!
Have you tried flashing asus stock 4.2.1 system blob using adb?
Do you know what the command for that would be? I have the same problem. But I don't wanna flash it to the wrong partition.
Sent from my ASUS Transformer Pad TF300T using xda app-developers app
klownin5643 said:
Do you know what the command for that would be? I have the same problem. But I don't wanna flash it to the wrong partition.
Sent from my ASUS Transformer Pad TF300T using xda app-developers app
Click to expand...
Click to collapse
This is the link to the instructions i followed. http://forum.xda-developers.com/showthread.php?t=2187982
Here is the main point.
- Method 2: Update using fastboot
Notes:
You will keep all your data
This is the best method to update your tablet if you want to keep all your data, and the safest one
Ensure you have the correct drivers for the tablet installed on your computer, or you will have a "waiting for device" error
To update using fastboot, follow this steps:
If you don't have fastboot yet, download it from here an unpack it somewhere on your computer
Extract the Asus firmware file and put the blob file inside fastboot folder
Open a command line on fastboot folder (write "cmd" on Windows search bar at the Start menu, and then
Code:
cd "FOLDER WHERE YOU EXTRACTED FASTBOOT"
, or you can just use SHIFT + RIGHT CLICK on the folder and select "Open command line window here" or something like that)
Reboot the tablet holding the volume down key until you see some icons. Use the volume down key to select the USB icon and then volume up to select it
Connect the tablet to the computer if you didn't do so
Write
Code:
fastboot -i 0x0B05 flash system blob
, hit enter and wait until it completes
Write this to reboot your tablet:
Code:
fastboot reboot
or hold the power button for 10 seconds if the code doesn't work
You are now updated to Android 4.2
There are 3 things keeping this from working:
1) fastboot -i 0x0B05 flash system blob
This locks the tablet up. Fastboot thinks it's still working, but the blinking RCK has stopped blinking and...
2) fastboot reboot
... doesn't work because the tablet has locked up from the flash attempt. You have to...
3) hold the power button for 10 seconds if the code doesn't work
Which does reboot the tablet, but it goes right back into TWRP, and you have NOT been updated to anything.
Now, in my particular case, I can get it to "adb reboot bootloader" and tell it to cold boot Linux to get into my OS, but that never happens either. It's likely been wiped from one of my multiple attempts at trying others' suggestions for getting out of this.
I'm sorry, you bricked your tablet permantly... Only Asus can fix it now... You flashed a wrong recovery for your tablet... You read the wrong post! That one is for Android 4.1 and not 4.2...
joelalmeidaptg said:
I'm sorry, you bricked your tablet permantly... Only Asus can fix it now... You flashed a wrong recovery for your tablet... You read the wrong post! That one is for Android 4.1 and not 4.2...
Click to expand...
Click to collapse
I did the same thing as the OP. I'm not new at this, I've rooted and run custom ROMs for years on dozens of devices. I always do lots of research before starting the process. What the OP and I are saying is that the Team Win site doesn't state anything about the 421 patch and if you look at the file list, the patch only exists in the 2.4.4.0 version. With those two things in mind, a reasonable person would conclude that 2.5.5.0 is patched for both...as long as you use the -JB version. Obviously wrong as I now know, but certainly not clearly wrong before bricking the device.
I would never assume to blame the Dev's, but I (we) are asking that they be a bit more blatant with the fact JB v4.2 MUST USE TWRP version 2.4.4.0-4.2 and not anything else.
Now, for good or bad, so many people have now bricked their TF300's that there are many threads like this one. Any research at this point will reveal this issue. Still, Team Win should post the warning.
joelalmeidaptg said:
I'm sorry, you bricked your tablet permantly... Only Asus can fix it now... You flashed a wrong recovery for your tablet... You read the wrong post! That one is for Android 4.1 and not 4.2...
Click to expand...
Click to collapse
I wish it was as simple as reading the wrong post... When I downloaded TWRP 2.4.4.0, there were only -ICS and -JB files listed (much like TWRP 2.5.0.0 is now)... Wouldn't you have picked -JB?
Even now, Teamwin's directions tell you that, if you took the Asus JB OTA, that you need the -JB version. They don't differentiate WHICH JB OTA, and they don't mention that a -4.2 version specifically for the 4.2.1 OTA exists. Never mind mentioning that using the -JB version on the latest Asus JB OTA update will BRICK THE TABLET.
There are 192 people that have downloaded the 2.5.0.0-JB blob file as of now. How many of these folks do you suppose have taken the Asus 4.2.1 OTA update and are about to permabrick their tablets?
It sickens me to know of the 192, likely most are on 4.2.1. I only hope they catch it before pushing the ROM.
When you flash recovery its flash ix505blah recovery recovery.blob is it flash ix5o5blah system system.blob? If that makes sense? Or no.?
Sent from my ASUS Transformer Pad TF300T using xda app-developers app
The two things here centers around the fact that TWRP is the only thing that will boot, other than the bootloader (but you have to boot TWRP first).
1) If you are in TWRP, there are no partitions mounted. In fact, there are no mmcblk devices at all, which is why there are no partitions mounted. As a result, there is nothing to flash to from here (even if fastboot worked). Adb works from here, but the device serial says "123456789ABCDEF recovery". Fastboot detects no devices at all from here.
2) If you reboot bootloader from adb, you can get access to fastboot. However, any flashing from here locks up the tablet, even though the command looks like it's running and completing the first time. Adb does NOT work from here, sees no devices. Fastboot looks like it sees the right device until you try to flash something with it. Once you try to flash anything, no fastboot command completes, furthering the notion that the tablet is frozen. A reset reboots the tablet back into TWRP, and nothing has changed. Repeat the cycle ad nauseum.
Basically, you can't do squat from TWRP, and fastboot flash from the bootloader locks up the tablet so you can't flash anything. I'm pretty sure it will take a logic board replacement to fix it at this point unless someone comes up with something better.
I'm having the exact same issue as you... I had flashed the TWRP JB blob and it couldn't recognize anything so I tried to flash CWM. Now...My fastboot doesn't do a thing since the blue progress bar doesn't show up and just freezes when trying to flash the stock firmware. I don't think I can send it to Asus for warranty either since my device is unlocked.
Well, I figured there's nothing to lose, so "fastboot erase recovery" got rid of TWRP. So now, it just hangs at the Asus logo unless you hold Vol- while booting, then you get the standard 3-icon bootlader.
I still can't flash anything with fastboot without it locking up though. Not sure I got anywhere... lol.
splashg said:
Well, I figured there's nothing to lose, so "fastboot erase recovery" got rid of TWRP. So now, it just hangs at the Asus logo unless you hold Vol- while booting, then you get the standard 3-icon bootlader.
I still can't flash anything with fastboot without it locking up though. Not sure I got anywhere... lol.
Click to expand...
Click to collapse
You can't flash a recovery? And what about the stock Rom?
Sent from my WT19i using xda app-developers app
splashg said:
Well, I figured there's nothing to lose, so "fastboot erase recovery" got rid of TWRP. So now, it just hangs at the Asus logo unless you hold Vol- while booting, then you get the standard 3-icon bootlader.
I still can't flash anything with fastboot without it locking up though. Not sure I got anywhere... lol.
Click to expand...
Click to collapse
Lol did that too...I don't know if there is anything left to try. Did you try putting stock rom on an external SD card and running RCK?
Ok...so now that I won one, there is a guy on e-bay that has a bunch of TF300T-b1-bl 32gb Transformers with broken screens. He is posting pictures and they all appear (based on the picture) that they have operable firmware. Mine will be here late in the week...I'll pull the main board and put it in mine. I'll let you know how it goes.
splashg said:
Well, I figured there's nothing to lose, so "fastboot erase recovery" got rid of TWRP. So now, it just hangs at the Asus logo unless you hold Vol- while booting, then you get the standard 3-icon bootlader.
I still can't flash anything with fastboot without it locking up though. Not sure I got anywhere... lol.
Click to expand...
Click to collapse
I did the same thing and got the same result. This i very interesting because the
Code:
fastboot -i 0x0b05 flash <partition> <filename>
command which tries to write/edit something on the partition fails (maybe is due to some encryption introduced in 421) but the
Code:
fastboot -i 0x0b05 erase <partition>
which also does the write/edit, succeeds. What I'm trying to say is that either both should fail or succeed because both are trying to do some editing to the storage.
steveb05 said:
Ok...so now that I won one, there is a guy on e-bay that has a bunch of TF300T-b1-bl 32gb Transformers with broken screens. He is posting pictures and they all appear (based on the picture) that they have operable firmware. Mine will be here late in the week...I'll pull the main board and put it in mine. I'll let you know how it goes.
Click to expand...
Click to collapse
Yeah, if it's the ones I've seen the hard part there is that they go for more than a replacement logic board does. Sure, there's likely some other parts still good in there, but if it just has a bad digi, I'm too apt to fix the digi... Basically, I need one where both the digi and the LCD are shot, and goes for less than the logic board does.
Joel, yeah, we can't flash anything. Fastboot flash <any partition> <any file> locks the tablet up. As Vahid alludes to, this is very odd because we have no trouble with fastboot erase. Having a stock image on an SD card and trying to get RCK to reload it doesn't work, presumably because it can't mount the external SD card.
splashg said:
Yeah, if it's the ones I've seen the hard part there is that they go for more than a replacement logic board does. Sure, there's likely some other parts still good in there, but if it just has a bad digi, I'm too apt to fix the digi... Basically, I need one where both the digi and the LCD are shot, and goes for less than the logic board does.
Joel, yeah, we can't flash anything. Fastboot flash <any partition> <any file> locks the tablet up. As Vahid alludes to, this is very odd because we have no trouble with fastboot erase. Having a stock image on an SD card and trying to get RCK to reload it doesn't work, presumably because it can't mount the external SD card.
Click to expand...
Click to collapse
Just got my TF300 back for Asus service center. They said that they had to replace the motherboard @ a cost of $186.00 total, parts and labor. Told them to just send it back. I'll buy a Nexus 7 instead for the same price almost.
Got my broken TF300 ebay win today. Digitizer and LCD were toast. But, the main board went right in to my bricked TF300. I'm unlocked, rooted, and running 4.1.1 and life is good!
Sent from my ASUS Transformer Pad TF300T using xda app-developers app
Hey all,
I have a big problem with my TF700.
I wanted to root my device after unlocking the bootloader through the app, but by being dumb I managed to delete the OS in TWRP (thought it was factory reset) and now I'm in big trouble.
The only thing the tablet loads now is the TWRP 2.2.1 recovery. (TWRP came with a root-package, I didn't install it myself.)
Since I can't load an OS that is apparently deleted, I'm stuck with using the (latest) SDK to get the stock rom back on the tablet.
The problem is, it doesn't work, at all. The device is recognised by my (Win7) PC and the 'adb devices' command gives me the ID and 'recovery'.
If I try to push the ROM to the Sdcard folder (or any folder, for that matter) It gives me a "protocol error" with no other explanation.
If I try to sideload it it is stuck on "Waiting for device".
I tried the 'shell' command, just to see what that does, but it also gives me an error.
Other commands can also give the the "error: closed" message.
Since both of those commands don't work, I can't get anything on this tablet, since I can't get this version of TWRP to mount an external (micro) SDcard, the option simply isn't there.
Can anyone help me with this, of has my tablet been reduced to an expensive paperweight?
That's the problem with packages - you don't really know what's in it...
What root package did you use?
You have a very outdated recovery installed. I'm guessing here, since you didn't post your bootloader version and that's the first thing we need to know!
Can you still get into the bootloader?
Boot with Power and Volume Down buttons until you see the tiny script and post your bootloader version. Should be something like 10.6.1.....
Do NOT do anything else in recovery at this point!!!! If it is incompatible with your bootloader you could hard brick!
Once we know if you have fastboot access and what your bootloader version is, we can help you to flash the correct recovery in fastboot. With that installed it's a piece of cake to get you up and running.
But be patient! Don't do anything else you're not quite sure of!
*Update Below*
I believe the culprit was the 'Install recovery' method "Scott's Recovery install tool"
I tried a few but most didn't do anything. Every tool I tried comes from the xda forums and checked youtube videos explaining the steps.
If I boot using Volume down + power, nothing extra happens. I just see in the left hand corner "this device is unlocked", since I unlocked the bootloader using the ASUS app.
If I use the command adb reboot bootloader, it goes to TWRP 2.2.1.
Does this imply that I also deleted the bootloader?
Update: I deleted all drivers and software regarding the tablet from my PC and I installed the adb setup package from these forums and reinstalled the (universal?) driver package. This turned out to be a newer version of adb, and I actually managed to push a file to the tablet with no problems. I am reluctant to try anything else at the moment, since this whole ordeal had given me quite the scare (and the desire to learn more about this all)
Can anyone help me revive my tablet?
FooYoungHi said:
*Update Below*
I believe the culprit was the 'Install recovery' method "Scott's Recovery install tool"
I tried a few but most didn't do anything. Every tool I tried comes from the xda forums and checked youtube videos explaining the steps.
If I boot using Volume down + power, nothing extra happens. I just see in the left hand corner "this device is unlocked", since I unlocked the bootloader using the ASUS app.
If I use the command adb reboot bootloader, it goes to TWRP 2.2.1.
Does this imply that I also deleted the bootloader?
Update: I deleted all drivers and software regarding the tablet from my PC and I installed the adb setup package from these forums and reinstalled the (universal?) driver package. This turned out to be a newer version of adb, and I actually managed to push a file to the tablet with no problems. I am reluctant to try anything else at the moment, since this whole ordeal had given me quite the scare (and the desire to learn more about this all)
Can anyone help me revive my tablet?
Click to expand...
Click to collapse
Ok, good - you got adb working. The adb command to boot into the bootloader is
Code:
adb reboot-bootloader
Note the hyphen
Also I wonder if you pushed Power and Volume Down long enough. You should feel the tablet vibrate twice, then see some tiny script and 3 icons appear. That would be the bootloader menu and in it, you are in fastboot mode by default.
The next step would be to check if you have a fastboot connection.
The command for that is
Code:
fastboot devices
Read my guide on flashing a custom recovery and rom very carefully and follow the steps outlined to get TWRP 2.8.0.1 on your tablet.
Ask any questions you may have in that thread.
http://forum.xda-developers.com/showthread.php?t=2688891
Edit: Sorry, forgot that we have to determine your bootloader version first. So use the button combination or the adb command to boot into it and post it. Don't worry. I don't think you did anything to the bootloader - it's not that easy to mess it up...
Unfortunately, the adb code doesn't work, with or without the hyphen. The device will reboot, but will return to TWRP.
I've held down the Volume down+power button for more than a minute witout result. The device will just reboot after a while for as long as I'm holding it. I do see the screen flicker for a second.
I've also noticed, that after I push a file to the tablet, that after a reboot it loses the data I just moved.
After booting TWRP, when I look in the command line of TWRP, it tells me that it can't mount the 'system' , 'data' and 'cache' forders. (tw_mount)
And it specifically mentions (multiple times) that the /data folder failed to mount, giving the message "No such file or directory"
It seems I really managed to F'ed it up good...
My "force-boot-to-bootloader" kernel module might help you unbrick. Read this guide very carefully before you do anything:
http://forum.xda-developers.com/transformer-tf700/help/guide-t2853546
You people are my new heroes!
The last guide did the trick. The stock firmware is installed and I'm currently updating and installing all the apps.
Thank you all só much, you really saved me a ton of frustration.