Database Users

Mounting the Xoom in Linux (as well as adb)

The xoom can mount just fine on Linux but it is an MTP not a Mass Storage device.
Disclaimer: I am not responsible for any damage to your device, computer, relationship, etc.... The following is meant as a guideline and worked for me but as always use your head.
I did this on my Kubuntu Maverick laptop, but it should apply to most *buntus plus debian. Other flavors should be similar, post a request and I will help if I can. I am familiar with Suse and RHEL/Centos as well but beyond those it will be guess work.
The first thing I would recommend doing is making the device read/write to normal users.
Code:
sudo touch /etc/udev/rules.d/51-android.rules
echo "SUBSYSTEM==\"usb\", SYSFS{idVendor}==\"22b8\", MODE=\"0666\"" |sudo tee -a /etc/udev/rules.d/51-android.rules
sudo /etc/init.d/udev restart
NOTE: This also "fixes" adb so it is useable with the xoom as a normal user. If that is all you want you can stop here.
NOTE 2: You could also set an OWNER rather than changing MODE but I chose the most common route for this example/
Now install either mtp-tools or mtpfs for mounting using FUSE. Since I went the fuse route that is what I will conver here. (I installed the mtp-tools package but beyond using it to debug getting mtpfs to work I have never used it before.)
Assuming you already have fuse configured, for (k|x)ubuntu or debian :
Code:
sudo apt-get install mtpfs
If you do not have fuse already configured then do that first. Look it up online if you have any questions. If you get stuck I will try and help but this post is not about how to configure FUSE.
After that it is simple. Plugin your xoom and from the command line type:
Code:
mtpfs mountpoint
and to dismount it
Code:
fusermount -u mountpoint
so in my case I mount it in a subdirectory under home called xoom
Code:
mtpfs /home/janetpanic/xoom
fusermount -u /home/janetpanic/xoom
I have confirmed moving files to and from the actual directories but not from the meta "playlists" directory. I hope that helps...
EDIT: Fixed Typo... had "(idVendor)" instead of the correct "{idVendor}"

Thanks for sharing your workaround. Unfortunately, it's no joy here. After following the procedure described, the terminal returned no error, but on trying to open the Xoom directory via Nautilus, I received the following message:
Code:
Error: Error stating file '/home/sog/Xoom': Transport endpoint is not connected
Please select another viewer and try again.
Unmounting proceeds without error.
Distribution: Ubuntu Lucid x64

Did you connect your xoom before or after you mounted? The most likely problem is the undeveloped configuration .
Change the line in 51-android.rules to
Code:
SUBSYSTEM=="usb", SYSFS{idVendor}=="22b8", SYMLINK+="libmtp-%k", MODE="0666"
[\code]
Restart udev and then do a "ls -lah /dev/libmtp*" with the device attached and list the output. I need to figure out if the problem is the udev rule or elsewhere.
If the ls does not show any files then send the result of "lsusb |grep Motorola" which better list a line or there is something weird going on.
Sent from my Xoom using XDA App

Updated 51-android.rules as directed, then:
[email protected]:~$ ls -lah /dev/libmtp*
lrwxrwxrwx 1 root root 15 2011-02-27 19:59 /dev/libmtp-1-4 -> bus/usb/001/004
[email protected]:~$ lsusb | grep Motorola
Bus 001 Device 004: ID 22b8:70a8 Motorola PCS

Wait, you aren't able to get the Xoom to mount as a mass storage device?
ed. The leaked Xoom manual suggests it support mass storage. Phew. You were scaring me there a bit.

as far as I know, it's been confirmed that the current stack does not support mass storage, only mtp.

sogrady said:
as far as I know, it's been confirmed that the current stack does not support mass storage, only mtp.
Click to expand...
Click to collapse
Which stack, Linux or Honeycomb's? Where is it confirmed?
Non-working mass storage is a potential deal breaker.

honeycomb's. see here or here for details.

Thanks for the links.
This is a real WTF.

Can someone try running this attached apk to see if it enables mass storage? (It just runs enable, it won't run disable, so I don't know what will happen, it might cause apps to crash but rebooting should fix it, standard disclaimers apply, you run this at your own risk, etc., etc., etc.)
I don't have a Xoom, otherwise I'd try this myself.
Relevant code snippet for those interested:
Code:
StorageManager s = (StorageManager)getSystemService(Context.STORAGE_SERVICE);
Class c = s.getClass();
Method m = null;
try
{
m = c.getMethod("enableUsbMassStorage", (Class[]) null);
m.invoke(s);
}
catch(Exception e)
{
// TODO Auto-generated catch block
e.printStackTrace();
}
There may even be an easier way to achieve this -- I can't verify for myself because Honeycomb isn't in AOSP -- it doesn't work in the sim, but it might on a device: run adb shell, then run "am start -n com.android.systemui/.usb.UsbStorageActivity".

ydaraishy said:
Can someone try running this attached apk to see if it enables mass storage? (It just runs enable, it won't run disable, so I don't know what will happen, it might cause apps to crash but rebooting should fix it, standard disclaimers apply, you run this at your own risk, etc., etc., etc.)
I don't have a Xoom, otherwise I'd try this myself.
There may even be an easier way to achieve this -- I can't verify for myself because Honeycomb isn't in AOSP -- it doesn't work in the sim, but it might on a device: run adb shell, then run "am start -n com.android.systemui/.usb.UsbStorageActivity".
Click to expand...
Click to collapse
I ran the activity manager command and it brought up the usb mass storage screen but did not mount on computer. Also ran the apk but did not mount. Awesome job though. keep fighting the good fight

sogrady said:
Updated 51-android.rules as directed, then:
[email protected]:~$ ls -lah /dev/libmtp*
lrwxrwxrwx 1 root root 15 2011-02-27 19:59 /dev/libmtp-1-4 -> bus/usb/001/004
[email protected]:~$ lsusb | grep Motorola
Bus 001 Device 004: ID 22b8:70a8 Motorola PCS
Click to expand...
Click to collapse
Well that is interesting . You have read write privileges on the xoom. Sounds like it is a fuse configuration issue. Do you have any other fuse file systems you run?
Sent from my Xoom using XDA App

bigrushdog said:
I ran the activity manager command and it brought up the usb mass storage screen but did not mount on computer. Also ran the apk but did not mount. Awesome job though. keep fighting the good fight
Click to expand...
Click to collapse
Damn it. Looks like I actually need a device to get it working, and the AOSP drop. It's so moronic why they disabled mass storage.
Hmm. Can someone run, from adb shell, the output from "mount", and "ls /sys/devices/platform" for me?

Never mind. Mass storage has been defined out of the stingray (Xoom) kernel. It's not even in the default kernel.
To get mass storage support, be prepared to build your own kernel and reflash the device (once that's done, the am command above or the enabler app will work properly).

I've founded a working(ish) solution. This Xoom forum post details an approach that permits transfer of video/music/etc to the Xoom via Linux.
Couple of caveats:
1. The gnomad2 application is very unstable. Crashes frequently.
2. It appears to be write-only: I have not been able to delete files from the Xoom using this interface.

Thanks for the instructions to connect to a xoom tablet via Linux! However, I'm using Opensuse 11.3 and 11.4 on two different systems. I did install the mtp-tools with no issues, however, there is NO file by the name of mtpfs. A search on the net does not reveal it either. Where do I get this, or what package is it part of? Thanks again. If I can't get this tablet to connect to my linux box, I will have to take it back, since I do NOT use winbloze or Mac. Pretty short sited of Motorola IMHO.

Personally, I've given up on MTP + Linux Combo. I just use a straigt FTP transfer over wifi ( FTP Server on tablet ). It's about the same speeds.

any headway on this...
i am getting the: Transport endpoint is not connected error still and i have no real experience with FUSE so im stuck to using windows for any transferring.

stlsaint said:
i am getting the: Transport endpoint is not connected error still and i have no real experience with FUSE so im stuck to using windows for any transferring.
Click to expand...
Click to collapse
try following the directions in this thread:
http://forum.xda-developers.com/showthread.php?t=981774
They are basically a superset of what I posted. If you still have trouble after that post in either thread (this one or that one) and I will try and help as best I can.

followed the thread up unto the fstab part as i dont wan to edit my fstab without confirmation that it will work. But i get the exact same error with the endpoint text. I am trying this on Crunchbang linux which is based off debain the same way ubuntu is. I am probably going wrong with FUSE somehow but i have never messed with it so i dont know how to troubleshoot it.

Droid Ultra (possible Maxx) brick recovery

I want to post my findings here. It could be useful for developers playing with bootloaders, and for users who accidentally break their Droid.
DISCLAIMER: I am not responsible for any damage, caused to your phone, when you did something using information from this thread. Be extremely careful shorting any pins (and to do at YOUR OWN RISK)
There is two types of bricked device (by bricked I mean no fastboot available):
1. Device does not boot up, but responding to USB VIDID = 05c6:9008 = QHSUSB_DLOAD mode
This is qualcomm standard emergency download mode. This device become serial port (it is required drivers for Windows), and could be flashed with special protocol.
Attached is package which successfully recover Droid Ultra.
Once you see device with VIDID = 05c6:9008 = QHSUSB_DLOAD, you should run this command:
python qdload.py MPRG8960_MOTO.bin -ptf _ultra/partitions.txt
after this you should be able to use fastboot to flash desired official image back.
Tested on Windows, drivers for QHSUSB_DLOAD now included into package, serial port auto detection added, same command use. For both windows and linux you should have Python >= 2.6 installed, and PySerial installed.
2. Device not responding to USB, but start responding after battery disconnect (you need to disassemble your phone) as VIDID = 05c6:f006 = Qualcomm modem mode.
In most cases this mean that you has HARD bricked device. I still could not provide soft way to switch from this mode to QHSUSB_DLOAD mode, so currently with this situation you has only one possibility - is to find pin, which will force device to QHSUSB_DLOAD mode. For droid Ultra (and I believe Maxx) you could find this pin marked on picture attached. On my picture you could see, that I remove shield completely, but you could reach this pin by opening shield cup only. This is the shield near display connector. This pin should be grounded to force QHSUSB_DLOAD mode. Once you see device with VIDID = 05c6:9008 - STOP shorting pin to ground and follow unbrick 1 procedure.
If you not stopping SHORT ping to gound, you may have issues with uploading images in step 1 !!!
This both unbrick tested on Droid Ultra, but I assume it should work on Droid Maxx as well (I include _maxx folder with files for maxx).
Instruction to generate partitions.txt from working phone (Note you could have different name instead of mmcblk0):
1. adb shell dd if=/dev/block/mmcblk0 of=/sdcard/pt.bin bs=1024 count=10
2. adb pull /sdcard/pt.bin .
3. ./gpt_parser.py pt.bin > partitions.txt
Edit: Split package into 5 packages: 1. Image files for MAXX, 2 Image files for ULTRA, 3. Loader .bin for Motorola_8960 4. Window drivers for QHSUSB_DLOAD mode, 5. qdload.py script
qdload.py script updated to V1.2 with lot of usefull info printed.
move gpt_parser.py script to main post

VBlack said:
I want to post my findings here. It could be useful for developers playing with bootloaders, and for users who accidentally break their Droid.
DISCLAIMER: I am not responsible for any damage, caused to your phone, when you did something using information from this thread.
There is two types of bricked device (by bricked I mean no fastboot available):
1. Device does not boot up, but responding to USB VIDID = 05c6:9008 = QHSUSB_DLOAD mode
This is qualcomm standard emergency download mode. This device become serial port (it is required drivers for Windows), and could be flashed with special protocol.
Attached is package which successfully recover Droid Ultra.
Once you see device with VIDID = 05c6:9008 = QHSUSB_DLOAD, you should run this command:
python qdload.py MPRG8960.bin _ultra/partitions.txt
after this you should be able to use fastboot to flash desired official image back.
I didn't test it on Windows, but it could work, you just need to specify COM port, by additional parameter to qdload.py:
python qdload.py -tty COM10 MPRG8960.bin _ultra/partitions.txt
2. Device not responding to USB, but start responding after battery disconnect (you need to disassemble your phone) as VIDID = 05c6:f006 = Qualcomm modem mode.
In most cases this mean that you has HARD bricked device. I still could not provide soft way to switch from this mode to QHSUSB_DLOAD mode, so currently with this situation you has only one possibility - is to find pin, which will force device to QHSUSB_DLOAD mode. For droid Ultra (and I believe Maxx) you could find this pin marked on picture attached. On my picture you could see, that I remove shield completely, but you could reach this pin by opening shield cup only. This is the shield near display connector. This pin should be grounded to force QHSUSB_DLOAD mode. Once you see device with VIDID = 05c6:9008 - follow unbrick 1 procedure.
This both unbrick tested on Droid Ultra, but I assume it should work on Droid Maxx as well (I include _maxx folder with files for maxx).
Click to expand...
Click to collapse
WOW! Nice job, bud.
I would normally ask you to add a disclaimer to be extremely careful shorting any pins (and to do at YOUR OWN RISK), but anyone who needs to do this is already in a pickle, and their device useless.
Great work, impressive.

samwathegreat said:
WOW! Nice job, bud.
I would normally ask you to add a disclaimer to be extremely careful shorting any pins (and to do at YOUR OWN RISK), but anyone who needs to do this is already in a pickle, and their device useless.
Great work, impressive.
Click to expand...
Click to collapse
Done, I also add note about stop shorting this pin to ground once you get to QDL MODE, since it will cause eMMC instability, and may forbid to flash images.
Add: Package repacked with drivers for windows and updated version of qdload.py with windows serial port auto detection.

VBlack said:
I want to post my findings here. It could be useful for developers playing with bootloaders, and for users who accidentally break their Droid.
DISCLAIMER: I am not responsible for any damage, caused to your phone, when you did something using information from this thread. Be extremely careful shorting any pins (and to do at YOUR OWN RISK)
There is two types of bricked device (by bricked I mean no fastboot available):
1. Device does not boot up, but responding to USB VIDID = 05c6:9008 = QHSUSB_DLOAD mode
This is qualcomm standard emergency download mode. This device become serial port (it is required drivers for Windows), and could be flashed with special protocol.
Attached is package which successfully recover Droid Ultra.
Once you see device with VIDID = 05c6:9008 = QHSUSB_DLOAD, you should run this command:
python qdload.py MPRG8960.bin _ultra/partitions.txt
after this you should be able to use fastboot to flash desired official image back.
I didn't test it on Windows, but it could work, you just need to specify COM port, by additional parameter to qdload.py:
python qdload.py -tty COM10 MPRG8960.bin _ultra/partitions.txt
Tested on Windows, drivers for QHSUSB_DLOAD now included into package, serial port auto detection added, same command use. For both windows and linux you should have Python >= 2.6 installed, and PySerial installed.
2. Device not responding to USB, but start responding after battery disconnect (you need to disassemble your phone) as VIDID = 05c6:f006 = Qualcomm modem mode.
In most cases this mean that you has HARD bricked device. I still could not provide soft way to switch from this mode to QHSUSB_DLOAD mode, so currently with this situation you has only one possibility - is to find pin, which will force device to QHSUSB_DLOAD mode. For droid Ultra (and I believe Maxx) you could find this pin marked on picture attached. On my picture you could see, that I remove shield completely, but you could reach this pin by opening shield cup only. This is the shield near display connector. This pin should be grounded to force QHSUSB_DLOAD mode. Once you see device with VIDID = 05c6:9008 - STOP shorting pin to ground and follow unbrick 1 procedure.
If you not stopping SHORT ping to gound, you may have issues with uploading images in step 1 !!!
This both unbrick tested on Droid Ultra, but I assume it should work on Droid Maxx as well (I include _maxx folder with files for maxx).
Click to expand...
Click to collapse
This is great!! Mind if i add it here? With proper credits of course? Or quote you?
http://forum.xda-developers.com/moto-x/general/how-to-resurrecting-bricked-moto-x-t2629057

Sure, no problem, but you need your own set of files for moto x (could be obtained from fastboot oficial image), and partitions.txt.
partitions.txt you could obtain using following instruction from working phone:
1. adb shell dd if=/dev/block/mmcblk0 of=/sdcard/pt.bin bs=1024 count=10
2. adb pull /sdcard/pt.bin .
3. ./gpt_parser.py pt.bin > partitions.txt
Edit: gpt_parser moved to main post.

VBlack said:
I want to post my findings here. It could be useful for developers playing with bootloaders, and for users who accidentally break their Droid.
DISCLAIMER: I am not responsible for any damage, caused to your phone, when you did something using information from this thread. Be extremely careful shorting any pins (and to do at YOUR OWN RISK)
There is two types of bricked device (by bricked I mean no fastboot available):
1. Device does not boot up, but responding to USB VIDID = 05c6:9008 = QHSUSB_DLOAD mode
This is qualcomm standard emergency download mode. This device become serial port (it is required drivers for Windows), and could be flashed with special protocol.
Attached is package which successfully recover Droid Ultra.
Once you see device with VIDID = 05c6:9008 = QHSUSB_DLOAD, you should run this command:
python qdload.py MPRG8960.bin _ultra/partitions.txt
after this you should be able to use fastboot to flash desired official image back.
I didn't test it on Windows, but it could work, you just need to specify COM port, by additional parameter to qdload.py:
python qdload.py -tty COM10 MPRG8960.bin _ultra/partitions.txt
Tested on Windows, drivers for QHSUSB_DLOAD now included into package, serial port auto detection added, same command use. For both windows and linux you should have Python >= 2.6 installed, and PySerial installed.
2. Device not responding to USB, but start responding after battery disconnect (you need to disassemble your phone) as VIDID = 05c6:f006 = Qualcomm modem mode.
In most cases this mean that you has HARD bricked device. I still could not provide soft way to switch from this mode to QHSUSB_DLOAD mode, so currently with this situation you has only one possibility - is to find pin, which will force device to QHSUSB_DLOAD mode. For droid Ultra (and I believe Maxx) you could find this pin marked on picture attached. On my picture you could see, that I remove shield completely, but you could reach this pin by opening shield cup only. This is the shield near display connector. This pin should be grounded to force QHSUSB_DLOAD mode. Once you see device with VIDID = 05c6:9008 - STOP shorting pin to ground and follow unbrick 1 procedure.
If you not stopping SHORT ping to gound, you may have issues with uploading images in step 1 !!!
This both unbrick tested on Droid Ultra, but I assume it should work on Droid Maxx as well (I include _maxx folder with files for maxx).
Click to expand...
Click to collapse
this should be stickied for all of android. while i realize your methods were device specific, i'm guessing there are enough similarities in your situation that it can be applied globally.

640k said:
this should be stickied for all of android. while i realize your methods were device specific, i'm guessing there are enough similarities in your situation that it can be applied globally.
Click to expand...
Click to collapse
It is Qualcomm specific. Most of current Qualcomm chips has emergency download mode. the only problem is to have proper load file MPRG8960.bin is for 8960 chips family, and looks like Motorola specific (maybe I'm wrong). So for sure not all Android device could use this, but most Qualcomm device should be fine, you just need model specific set of files, which, for example, Motorola provides with fastboot flashable images.

good points and good observations. this thread definitely shouldn't get buried in a single (aging) device. there's good info here.

I don't know if it is a problem, but I used this script to try and unbrick my phone.
When running as #1 as you state above, there is a "finished with errors" after the script. So I looked at it and saw that "MPRG8960.bin" was going to be pushed to the phone and the next line states "File not found "MPRG8960.bin." Looking at the files, the file it was looking for was named "MPRG8960_MOTO.bin," so I changed it to the file it was looking for and it worked great.
I'm a noob when it comes to the guts of programming and utilities, but it's something I spotted and figured I would let you know.

This seems really promising for my bricked xt907...

HamBone625 said:
This seems really promising for my bricked xt907...
Click to expand...
Click to collapse
Op has no fix files for the M, they have never been leaked.

HamBone625 said:
This seems really promising for my bricked xt907...
Click to expand...
Click to collapse
Since XT907 use same Qualcomm chip MSM8960 - you could try to use this utility, but first you need to obtain partitions.txt from working XT907 according to instructions.
Files needed you could take from latest firmware package (sbl1.mbn, sbl2.mbn, sbl3.mbn, tz.mbn, rpm.mbn, emmc_appsboot.mbn is aboot.mbn)

MOTO X
Hi. Can somebody post the partitions.txt for the moto X? please
To get the partition.txt from a working moto X it has to be root?
thanks

When I execute the script on my Droid Mini, with their proper partitions txt file and the MBN files from the ULTRA, I got this:
QDLoad utility version 1.2 (c) VBlack 2014
Found TTY port: com64
Requesting Params...
Params:
Version: 8
Min version: 1
Max write size: 1536 (0x00000600)
Model: 144
Device size: Invalid or unrecognized Flash device, or Flash device progr
amming not supported by this implementation
Device type: Intel 28F400BX-TL or Intel 28F400BV-TL
Requesting SoftwareVersion...
Version: PBL_DloadVER2.0
Requesting SerialNumber...
Serial number: 00,00,48,03
Requesting HW Id...
HW Id: 00,00,48,03,e1,10,7e,00
Requesting PublicKey...
PublicKey: 39,c4,ee,3e,b5,be,eb,87,8e,2f,e3,b8,53,4d,14,6f,91,ca,fd,bb,94,2a,0d
,aa,d0,1e,b0,87,62,d4,b9,b8
Uploading file 'MPRG8960_MOTO.bin' to addr 0x2a000000...
Executing...
Found TTY port: com64
Sending MAGIC ...
QCOM fast download protocol targ:
Version: 7
Compatible version 2
Maximum block size 1024 (0x00000400)
Base address of Flash 0x00000000
Flash: eMMC
Window size: 30
Number of sectors: 128
First sector size: 2097152 (0x00200000)
Feature bits: 09
Sending secureMode...
Sending openMulti ...
LOG: Open multi failed, unknown error
ERROR: 0x00000007: Open multi failed, unknown error
Sending SBL Reset...
Done, with errors!!!

Where I can get the MBN files for a Droid Mini?

Hi, you could try to find it inside one of official (fastboot) package for empty flashing like in Ultra package. It fails in very strange place - I will look at it on Monday.
Sent from my XT1080 using Tapatalk

VBlack said:
Hi, you could try to find it inside one of official (fastboot) package for empty flashing like in Ultra package. It fails in very strange place - I will look at it on Monday.
Sent from my XT1080 using Tapatalk
Click to expand...
Click to collapse
I tried the MBN files from a 4.4 fastboot from an Ultra and from the Droid Mini too, but i'm getting this errors, I don't know what's wrong or what I'm doing worng.
My phone powers up and can enter to fastboot, but it fails to boot, when i use "fastboot reboot" it reboot to QHSUSB_DLOAD... but well, something is wrong,,,

HELP
When i do the third step yo obtain partitions.txt (./gpt_parser.py pt.bin > partitions.txt)
i got a message
can't create partitions.txt: Read-only file system
any help?

C:\droid_ultra>python qdload.py MPRG8960_MOTO.bin -ptf _ultra/partitions.txt
'python' is not recognized as an internal or external command,
operable program or batch file.

BUZZAPT said:
When i do the third step yo obtain partitions.txt (./gpt_parser.py pt.bin > partitions.txt)
i got a message
can't create partitions.txt: Read-only file system
any help?
Click to expand...
Click to collapse
You should execute it on PC in writable folder.
Sent from my XT1080 using Tapatalk

D802 bricked, tried everything

Hello everyone. Here's my story
I've been using CM13. After installing their OTA update it ruined my android. So I downloaded new cm13 rom, wiped everything, accidentally clicked reboot (without flashing new rom) and it was over (At least I think this happened, it was some time ago and I'm already trying to fix this for a long).
I am stuck in LG logo. Can't access recovery (I've had this issue before. Could get to recovery only by command from adb).
I can get to Download mode. But PC can't see my device. Tried several PC's, windows, ubuntu. I flashed other phones with this method, only G2 is not visible. I'm doing here everything fine.
Also I tried this:
http://forum.xda-developers.com/lg-g2/general/lg-g2-unbrickable-fix-real-hard-brick-t2904404
Success but my phone keeps flashing on and off. I've got access to partitions like every 5 seconds and only for a second. I think I managed to flash those 3 partitions, but there's no difference, pc still can't see phone when in download mode.
Should I trow it to the ocean?

Keep it
Here is my story
Bricked my device (d802) with your stuation no recovey no download mode
My phone's partition table deleted any way, tried wire method which you've already tried
Tried several times and release this wire method put in 2 seperate modes
Found the mode it shows in ubuntu a sda block (with several tries with wire method)
I've got full 32 gig backup, thats my advantage between your stuation
In ubuntu fdisk - l shows all disk and shows my phone as a disk but no information about disk or partitions etc. only sda block
In the end pushed the 32 gig backup with dd if=/(path of my backup) of=/dev/block/sd* bs=4k
Wait some time until process done (30-45 minutes I guess)
Thats all, phone boots normally everything is fine
If you're using 32 gig version I can send you my backup (with imei deleted) so you can boot your device and install kdz
Or I can show you how to backup another LG phone and recover from that backup. http://forum.xda-developers.com/lg-g2/general/how-to-backup-data-16-gb-32-gb-size-t3236558

Thank you for your reply lynxrz
I've got bigger problem. When I enter qhsusb mode, backlight of my screen keeps switching on and off every 3-4 seconds. I can see partition only for a second.

Vergil333 said:
Thank you for your reply lynxrz
I've got bigger problem. When I enter qhsusb mode, backlight of my screen keeps switching on and off every 3-4 seconds. I can see partition only for a second.
Click to expand...
Click to collapse
Not necesaary to see partitions
In ubuntu or any linux enviroment open up a teeminal emulator and "sudo fdisk -l" and it will be like that;
Code:
$ sudo fdisk -l
Disk /dev/sda: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00008ec7
Device Boot Start End Blocks Id System
/dev/sda1 * 1 1013 8136891 8e Linux LVM
/dev/sda2 1014 1044 249007+ 5 Extended
/dev/sda5 1014 1044 248976 83 Linux
sda sdb sdc means a phisicial disk. sda1 sda2 sda3 means partitions of "sda" disk. My process depends on overwriting sda disk not partitions, so you don't need to see partitions
Just type "sudo fdisk -l" and tell me you can see any sdb sdc phisical disk permenately. We must know connection can be dropped or not(it can be bootloop). Partitions might disappear but phisical disk have to be there. Look for it.
If you can't see in qhsusb mode try another mode, this is the lucky part of tring the wire method. I don't know exactly how to swich "another" mode but you can detect in window device manager, then switch to linux (Don't be afraid to losing this mode it stays when you plug off usb if you connected battery)
Sorry I don't remember that "another" mode's name but it is exists
Firstly you need to know qhsusb mode can see a "phisical" disc or not?

I'm in work now, but I tried this yesterday.
Phone appears as sdc when I typed
Code:
$ ls /dev/sd*
while in qhsusb mode. (I had to type it several times repeatedly to catch the right moment)
I can get to download mode, so I typed
Code:
$ sudo fdisk -l
and couldn't see sdc there.

Vergil333 said:
I'm in work now, but I tried this yesterday.
Phone appears as sdc when I typed
Code:
$ ls /dev/sd*
while in qhsusb mode. (I had to type it several times repeatedly to catch the right moment)
Click to expand...
Click to collapse
Probably it can be bootloop.
Did you plug off the battery when touching capacitor ? Just asking to be sure.

Sure, I unplugged the battery So qhsusb not stable and download mod not visible to computers.
I already gave up of hope

Ok I will solve how to enter "another" mode (not qhsusb)
But I need time to backup all my data in any case
If I solve, prepare a backup for you and it'll be 32 GB
Edit: Can not find out "another" mode because of data cable problem (severed usb cable charging but not transferring data) You're on your own now to find another usb mode, It can be the "holding time" of cable on capacitor.
Good luck with that
Prepairing your backup with otg

Really thanks for your help lynxrz. I appreciate all effort

Vergil333 said:
Really thanks for your help lynxrz. I appreciate all effort
Click to expand...
Click to collapse
You're welcome
PS: Did I send pm the download link?

You did. 29.1GB rar file. I have no use for it till I find another mode to be able to flash partition.
I already bought G3. Probably I will sell G2 for parts

Uploading now and it was %17 maybe tomorrow will be uploaded %100
20,4 GB and compressed seperated 1 GB rar parts (21 parts)
Realised by you broken usb, I'll solder it but no time for that now, 2 days later I'll try it.
I'm stuborn as hell with that Just wait we'll fix it don't sell
Maybe I can make a tutorial and help the others
UPDATE: Usb works I'll try it tomorrow

How I unbricked my Hard-Bricked Samsung Galaxy Tab 4 SM-T337A...

Hello, my name is Marc-Yvan from Douala, Cameroon and I will tell you the whole story about how I successfully unbrick my Android Tablet. My aim is to share with you some tips about how to recover from a desperate situation of having an unusable tablet.
How I hard-bricked my Tablet:
First of all, let me tell you how I hard-bricked my beloved tablet after trying to unlock it from its original network lock. I got this tablet from a relative who live in USA but it was unfortunately network locked to the AT&T network. So I tried to unlock it by multiple means (by myself). I found a cracked software called “Octopus for Samsung” who was said able to unlock any kind of Samsung phones/tablet. When I tried to unlock my Tablet, the software starts the work and then told me that the device will turn off and turn on after a short time. But the Tablet did not turn on anymore and I spend 02 months trying to bring it back from the grave.
Definition:
Let me explain to you what is called a hard-bricked smartphone/tablet. It’s simply a smartphone/tablet which is unusable, doesn’t turn on (desperate black screen) and doesn’t react to any stimulation. But you have to know that these hard-bricked devices are displayed as unrecognized devices when plugged onto a computer. So a hard-bricked device is not a physically damaged device but is a sort of hardly logically damaged device which cannot boot at all and is not recognized by common flash tools such as Odin, etc.
How I unbricked my tablet:
Lucky Context (GOD’s help):
Fortunately, GOD helps me by guiding me through this situation in order to recover from it in a miraculous manner. I will explain it to you in a couple of points:
1- My Tablet was rooted before the incident. I did it by using an application found in play store: “Kingroot.apk”.
2- My Tablet was equipped with some tools like “Es explorer” and “Terminal Emulator”. You will understand how it fortunately helped me before the incident.
3- The real hand of GOD: In my quest of finding a mean to network unlock my tablet, I tried a method which was asking to save some partitions of the eMMC (A kind of processor memory. Sorry but I’m not an expert ). So I saved it to the memory of my Tablet and then transfered it to a folder in my computer (By using command lines with “Terminal Emulator”). This actually helped me after to revive my tablet.
Advice N° 1 (Prevention)
Before trying to explore the whole abilities of your Tablet by flashing it or trying to network unlock it; Do a backup of the primary boot partition of your eMMC by executing this command in the “Terminal Emulator” of your rooted device:
cat /dev/block/mmcblk0> sdcard/mmcblk0.img
Be careful, this command could save the life of your beloved Tablet. This command will actually copy the primary boot partition of your eMMC in a disk image which has the same name. So you have to keep that disk image in a safe place such as your computer or an external removable disk.
Advice N° 2 (Resolution)
The Story:
In my desperate actions trying to revive my hard-bricked tablet, I read tremendous forum posts and tried countless methods. Which lead me to install a new OS in my computer. It was actually Linux Ubuntu 16.4. I found a method which told me to try to write some kind of partitions images down to an SDCard to boot my Tablet with. But the partitions images proposed by the method didn’t succeed in recovering my Tablet. So some days later, when I turn on my computer, I fortunately found a file opened; it was the primary boot partition image file of my tablet that I saved before the incident (The real hand of GOD). So I decided (Inspired by the Holy Spirit) to try the previous method with the original boot partition image file of my tablet.
The Tip:
You will need an SDCard with a correct format (FAT32) and size (16Gb or 32Gb). You will also need to work in a Linux command line terminal. To write the boot partition image in your SDCard you will have to execute this command line:
sudo dd if=mmcblk0.img of=/dev/sdb bs=1024k status=progress
Note: The sd card may not be sdb though. In order to confirm, before writing, browse to /Dev and look at the properties of sdb to ensure it is in fact there (it might be sda, sdb, sdc, etc...). You can also try to unplug and then plug the SDCard to see the changes.
The Last Step (Eureka!!!)
The last step is just to insert the SDCard into the slot of your Hard-Bricked device, Turn it on and then feel its vibration that will let you know that your mission is completed. Your device is alive again.
Conclusion
The only conclusion that I can give is to NEVER GIVE UP when you are trying to solve a problem. You can be closer to the solution than you think.
Good Luck!

What are the chances you would upload the boot partition for me?
I hard bricked mine also, but unfortunately I didn't make a backup. Would you be kind enough to upload the bin file you dumped? I've looked everywhere and no one seems to have an emmc dump of this thing. lol

Saving Dead Shield Pro 500gb

I wanted to share my experience in reviving my 2017 Shield Pro 500gb. I was at the point that it wouldn’t even turn on and all I would get is a black screen then after some time I would get 3 green flashes then the Shield would power off.
I was at the stage in which I couldn’t even backup the device and starting from scratch seemed very unlikely from my reading online. I had tried so many different things before I finally came to what follows.
Things I used
Samsung Evo 500GB
Nvidia shield TV pro files (someone kindly uploaded online) https://forum.xda-developers.com/t/nvidia-shield-tv-ssd-done.3402580/page-2#post-67426622
nv-recovery-image-shield-atv-pro-7.2.3-dev_rooted https://drivers.softpedia.com/get/g...Android-TV-Pro-Developer-Firmware-7-2-1.shtml
DD command line using Linux ( you can use Windows)
Rufus
OTG cable
ADB and Fastboot Drivers
SATA Adapter
First up I dismantled the Shield which although not overly complicated, you just have to be careful with the wires as the must be unplugged and SATA connector from the HDD.
So the HDD being completely dead I decided if I was going to successfully revive the shield I would use a SSD instead. I plugged the SSD into my windows laptop and reformatted it to a GPT partition scheme with a FAT32 filesystem using Rufus.
Now I would switch from Windows to Linux (I know you can do this with windows but all my previous successes have been through Linux) and find the folder containing – start.bin and end_976574630.bin and open your terminal. Plug your ssd into your linux running computer. Here I would use the command $sudo su and then the command fdisk -l to find what letter your drive is identified by. Let’s say the drive is identified as sdd.
Next write the command $dd if=start.bin of=/dev/sdd bs=4M
This process can take around 15 minutes give or take. Once the process has been completed enter $dd if=end_976574630.bin of=/dev/sdd seek=976574630. This will not take as long as the previous process. Make sure that you can see no errors once the process is complete and safely eject the drive.
Now it’s time to reassemble the Shield making sure again not to damage any wires and everything is correctly reconnected.
After I plugged it bag into power I just let it sit trying to boot for about ten minutes before turning it off.
For the next part I used Windows and you need to make sure you have the ADB and fastboot drivers installed on your computer. Find the folder named nv-recovery-image-shield-atv-pro-7.2.3-dev_rooted and open terminal, PowerShell etc here.
Fastboot reboot the hardware way
- Disconnect power cable
- Connect Shield to a computer using an USB cable connected to the micro USB port of the Shield.
- Connect power cable to SHIELD
- As soon as the green LED turns on -BUT NOT BEFORE- hold down the power button
- Count to three, then immediately release the power button
- i.e. one-one thousand, two-one thousand, three-one thousand.. LIFT!
- You should now see the fastboot menu on the screen.
To confirm the device is in fastboot mode type the command $fastboot devices and you should see your device listed. Now one at a time type the following commands.
fastboot flash staging blob
fastboot flash boot boot.img
fastboot flash recovery recovery.img
fastboot flash system system.img
fastboot flash vendor vendor.img
fastboot reboot
Your Shield will begin to boot and will probably appear to stay on the four dots that turn into the Android logo for a little while. Give it 15 min and then unplug the power and repower the Shield. Now you will see your past boot and next setting the language and internet settings. Once you’ve done that you will be asked for Google credentials and the moment you’ve been waiting for the Nvidia Shield home screen. When I did it there was an update for 8.0 available which I did and everything worked fine. I then noticed an update for 9.0. Do not do this you will be back to square one which I found the hard way. For some reason it seems 8.0 that is compatible for this Shield model.
I just want to say a lot of this in formation has come from sources and articles I have read and have put together to suit my needs.
Big thanks to Tilator from XDA Developers and to Yaneca XDA Developer

Hey.. I have a nvidia shield 2017 Pro (I think? Not sure if the 2017 has a pro or not).
When I try and flash anything in TWRO with adb sideload I get error:
failed to read 16777216 bytes data at offset xxxx: I/O error
Im unable to to anything with it.. tried to format and tried a lot of things.. But I suspect disk is basically dead..
Do you think I can open it up and exchange drive to a regular 2.5" SSD and solve it?

Riverphoenix said:
I wanted to share my experience in reviving my 2017 Shield Pro 500gb. I was at the point that it wouldn’t even turn on and all I would get is a black screen then after some time I would get 3 green flashes then the Shield would power off.
I was at the stage in which I couldn’t even backup the device and starting from scratch seemed very unlikely from my reading online. I had tried so many different things before I finally came to what follows.
Things I used
Samsung Evo 500GB
Nvidia shield TV pro files (someone kindly uploaded online) https://forum.xda-developers.com/t/nvidia-shield-tv-ssd-done.3402580/page-2#post-67426622
nv-recovery-image-shield-atv-pro-7.2.3-dev_rooted https://drivers.softpedia.com/get/g...Android-TV-Pro-Developer-Firmware-7-2-1.shtml
DD command line using Linux ( you can use Windows)
Rufus
OTG cable
ADB and Fastboot Drivers
SATA Adapter
First up I dismantled the Shield which although not overly complicated, you just have to be careful with the wires as the must be unplugged and SATA connector from the HDD.
So the HDD being completely dead I decided if I was going to successfully revive the shield I would use a SSD instead. I plugged the SSD into my windows laptop and reformatted it to a GPT partition scheme with a FAT32 filesystem using Rufus.
Now I would switch from Windows to Linux (I know you can do this with windows but all my previous successes have been through Linux) and find the folder containing – start.bin and end_976574630.bin and open your terminal. Plug your ssd into your linux running computer. Here I would use the command $sudo su and then the command fdisk -l to find what letter your drive is identified by. Let’s say the drive is identified as sdd.
Next write the command $dd if=start.bin of=/dev/sdd bs=4M
This process can take around 15 minutes give or take. Once the process has been completed enter $dd if=end_976574630.bin of=/dev/sdd seek=976574630. This will not take as long as the previous process. Make sure that you can see no errors once the process is complete and safely eject the drive.
Now it’s time to reassemble the Shield making sure again not to damage any wires and everything is correctly reconnected.
After I plugged it bag into power I just let it sit trying to boot for about ten minutes before turning it off.
For the next part I used Windows and you need to make sure you have the ADB and fastboot drivers installed on your computer. Find the folder named nv-recovery-image-shield-atv-pro-7.2.3-dev_rooted and open terminal, PowerShell etc here.
Fastboot reboot the hardware way
- Disconnect power cable
- Connect Shield to a computer using an USB cable connected to the micro USB port of the Shield.
- Connect power cable to SHIELD
- As soon as the green LED turns on -BUT NOT BEFORE- hold down the power button
- Count to three, then immediately release the power button
- i.e. one-one thousand, two-one thousand, three-one thousand.. LIFT!
- You should now see the fastboot menu on the screen.
To confirm the device is in fastboot mode type the command $fastboot devices and you should see your device listed. Now one at a time type the following commands.
fastboot flash staging blob
fastboot flash boot boot.img
fastboot flash recovery recovery.img
fastboot flash system system.img
fastboot flash vendor vendor.img
fastboot reboot
Your Shield will begin to boot and will probably appear to stay on the four dots that turn into the Android logo for a little while. Give it 15 min and then unplug the power and repower the Shield. Now you will see your past boot and next setting the language and internet settings. Once you’ve done that you will be asked for Google credentials and the moment you’ve been waiting for the Nvidia Shield home screen. When I did it there was an update for 8.0 available which I did and everything worked fine. I then noticed an update for 9.0. Do not do this you will be back to square one which I found the hard way. For some reason it seems 8.0 that is compatible for this Shield model.
Riverphoenix said:
I wanted to share my experience in reviving my 2017 Shield Pro 500gb. I was at the point that it wouldn’t even turn on and all I would get is a black screen then after some time I would get 3 green flashes then the Shield would power off.
I was at the stage in which I couldn’t even backup the device and starting from scratch seemed very unlikely from my reading online. I had tried so many different things before I finally came to what follows.
Things I used
Samsung Evo 500GB
Nvidia shield TV pro files (someone kindly uploaded online) https://forum.xda-developers.com/t/nvidia-shield-tv-ssd-done.3402580/page-2#post-67426622
nv-recovery-image-shield-atv-pro-7.2.3-dev_rooted https://drivers.softpedia.com/get/g...Android-TV-Pro-Developer-Firmware-7-2-1.shtml
DD command line using Linux ( you can use Windows)
Rufus
OTG cable
ADB and Fastboot Drivers
SATA Adapter
First up I dismantled the Shield which although not overly complicated, you just have to be careful with the wires as the must be unplugged and SATA connector from the HDD.
So the HDD being completely dead I decided if I was going to successfully revive the shield I would use a SSD instead. I plugged the SSD into my windows laptop and reformatted it to a GPT partition scheme with a FAT32 filesystem using Rufus.
Now I would switch from Windows to Linux (I know you can do this with windows but all my previous successes have been through Linux) and find the folder containing – start.bin and end_976574630.bin and open your terminal. Plug your ssd into your linux running computer. Here I would use the command $sudo su and then the command fdisk -l to find what letter your drive is identified by. Let’s say the drive is identified as sdd.
Next write the command $dd if=start.bin of=/dev/sdd bs=4M
This process can take around 15 minutes give or take. Once the process has been completed enter $dd if=end_976574630.bin of=/dev/sdd seek=976574630. This will not take as long as the previous process. Make sure that you can see no errors once the process is complete and safely eject the drive.
Now it’s time to reassemble the Shield making sure again not to damage any wires and everything is correctly reconnected.
After I plugged it bag into power I just let it sit trying to boot for about ten minutes before turning it off.
For the next part I used Windows and you need to make sure you have the ADB and fastboot drivers installed on your computer. Find the folder named nv-recovery-image-shield-atv-pro-7.2.3-dev_rooted and open terminal, PowerShell etc here.
Fastboot reboot the hardware way
- Disconnect power cable
- Connect Shield to a computer using an USB cable connected to the micro USB port of the Shield.
- Connect power cable to SHIELD
- As soon as the green LED turns on -BUT NOT BEFORE- hold down the power button
- Count to three, then immediately release the power button
- i.e. one-one thousand, two-one thousand, three-one thousand.. LIFT!
- You should now see the fastboot menu on the screen.
To confirm the device is in fastboot mode type the command $fastboot devices and you should see your device listed. Now one at a time type the following commands.
fastboot flash staging blob
fastboot flash boot boot.img
fastboot flash recovery recovery.img
fastboot flash system system.img
fastboot flash vendor vendor.img
fastboot reboot
Your Shield will begin to boot and will probably appear to stay on the four dots that turn into the Android logo for a little while. Give it 15 min and then unplug the power and repower the Shield. Now you will see your past boot and next setting the language and internet settings. Once you’ve done that you will be asked for Google credentials and the moment you’ve been waiting for the Nvidia Shield home screen. When I did it there was an update for 8.0 available which I did and everything worked fine. I then noticed an update for 9.0. Do not do this you will be back to square one which I found the hard way. For some reason it seems 8.0 that is compatible for this Shield model.
I just want to say a lot of this in formation has come from sources and articles I have read and have put together to suit my needs.
Big thanks to Tilator from XDA Developers and to Yaneca XDA Developer
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Riverphoenix said:
I just want to say a lot of this in formation has come from sources and articles I have read and have put together to suit my needs.
Big thanks to Tilator from XDA Developers and to Yaneca XDA Developer
Click to expand...
Click to collapse
Hello,
which exact model EVO 500gb did you use ?
I have tried with the EVO 950, EVO 960 and the EVO 970 500Gb drives and neither of them are able to finish the second image file end_976574630.bin
The disk runs out of capacity. I had even tried to alter the seek sector value but then drive remains dead.
Here is my output as I posted in Tilator’s original thread
dd if=end_976574630.bin of=/dev/sdb seek=976574630
dd: writing to '/dev/sdb': No space left on device
198535+0 records in
198534+0 records out
101649408 bytes (102 MB, 97 MiB) copied, 27.1625 s, 3.7 MB/s

@Riverphoenix, I tried to write those 2 files to my ssd the other day and I am getting the "permissions denied" error. I am on a mac using terminal. Shouldn't be too different. I didn't use the sudo command though. Is that something I need to do? I am "newish" at this sort of thing and trying to understand it all. Also did you just plop the 2 files on your linux desktop or how did you access those files after you moved from your windows machine to your linux machine? Do i need to terminal into the folder with those files or terminal into the drive I am writing those files to?