Related
Hi!
I can't turn on wifi. When I touch in switch it do not on. I already made several hard resets and this does not result.
How I can resolve this?
I have the same problem, anyone help us ?
1
must install slp-1.40.olinex
2
enter into bootloader
3
connect to usb (disable activesync usb)
3
open eprom.nb with an hex editor and replace 78 with your mac adress in revers mode :
for exaple
real mac is 00 - 18 - 41 - c0 - 68 - f1
be written f1 68 c0 41 18 00
at 50h - 60h
Code:
00 00 01 0D 56 40 00 00 - 00 02 6D 54 [COLOR="Red"]78 78 78 78 [/COLOR]| [email protected][COLOR="red"]xxxx[/COLOR]
[COLOR="Red"]78 78[/COLOR] 00 00 01 15 58 A4 - 00 00 00 01 31 56 01 02 | [COLOR="red"]xx[/COLOR]....X.....1V..
so will become
Code:
00 00 01 0D 56 40 00 00 - 00 02 6D 54 [COLOR="Red"]F1 68 C0 41 [/COLOR]| [email protected][COLOR="red"]ñhÀA[/COLOR]
[COLOR="Red"]18 00[/COLOR] 00 00 01 15 58 A4 - 00 00 00 01 31 56 01 02 | [COLOR="red"]..[/COLOR]....X.....1V..
4
copy eprom.nb into directory of mtty
5
open mtty
command :
task 32
lnb eprom.nb 880fc000 320
lnb eprom.nb 8839d9c0 320
reset
Tell me if solved
hi all
I have done exactly as laid out above but its doesn't seem to work. would it make any difference if the spl is signed or unsigned version?
Also does it matter what version of mtty you use?
any help you could shed on this would be great.
thanks in advance.
mrlard12 said:
hi all
I have done exactly as laid out above but its doesn't seem to work. would it make any difference if the spl is signed or unsigned version?
Also does it matter what version of mtty you use?
any help you could shed on this would be great.
thanks in advance.
Click to expand...
Click to collapse
i use unsigned version
i have the same problem, except that wifi can recive a small part of the signal..
I have a 300n router and i can see its signial only staying next to it...tne phone gives a low level data reception and has difficulties to get the ip....
i 'll change hard spl soon
LucaAL said:
i have the same problem, except that wifi can recive a small part of the signal..
I have a 300n router and i can see its signial only staying next to it...tne phone gives a low level data reception and has difficulties to get the ip....
i 'll change hard spl soon
Click to expand...
Click to collapse
but this solution is only wlan not turn on
not to turn on it is very similar to not to connect....by the way no changes after having installed the radio 1.17... i donnow if i have installed the hard spl 1.93 ..i did it but he is always 1.4...
LucaAL said:
not to turn on it is very similar to not to connect....by the way no changes after having installed the radio 1.17... i donnow if i have installed the hard spl 1.93 ..i did it but he is always 1.4...
Click to expand...
Click to collapse
ita :
allora da quello che ho capito
hai un router sitecom 300n
e il diamond non si connette anche se lo vede come segnale ?
eng :
then from what I understand
you have a router Sitecom 300N
and the diamond does not connect even though it sees as a signal?
I am sorry for my error....i have solved my problem disassembling the device and reassembling the cpu zone; there were a cple not enough plugged in his hole
Ita: inoltre ciao e scusate per il disturbo
gruptnt said:
1
must install slp-1.40.olinex
2
enter into bootloader
3
connect to usb (disable activesync usb)
3
open eprom.nb with an hex editor and replace 78 with your mac adress in revers mode :
for exaple
real mac is 00 - 18 - 41 - c0 - 68 - f1
be written f1 68 c0 41 18 00
at 50h - 60h
Code:
00 00 01 0D 56 40 00 00 - 00 02 6D 54 [COLOR="Red"]78 78 78 78 [/COLOR]| [email protected][COLOR="red"]xxxx[/COLOR]
[COLOR="Red"]78 78[/COLOR] 00 00 01 15 58 A4 - 00 00 00 01 31 56 01 02 | [COLOR="red"]xx[/COLOR]....X.....1V..
so will become
Code:
00 00 01 0D 56 40 00 00 - 00 02 6D 54 [COLOR="Red"]F1 68 C0 41 [/COLOR]| [email protected][COLOR="red"]ñhÀA[/COLOR]
[COLOR="Red"]18 00[/COLOR] 00 00 01 15 58 A4 - 00 00 00 01 31 56 01 02 | [COLOR="red"]..[/COLOR]....X.....1V..
4
copy eprom.nb into directory of mtty
5
open mtty
command :
task 32
lnb eprom.nb 880fc000 320
lnb eprom.nb 8839d9c0 320
reset
Tell me if solved
Click to expand...
Click to collapse
It don't work...
People, pls another solution?
I did as mention but honestly I don`t know where to find the MAC address of my device. In wireless, because it cannot be turned on, I cannot see the MAC address. Anyway, I try and change it like in your example, using the same MAC as you provided, but nothing happens. Any help appreciated!
EDIT 12/8/2015 - THIS THREAD IS NOW OBSOLETE.
In Early April 2015, Google retroactively changed a large number of prior factory images for nakasi/grouper (possibly nakasig too). Read this thread from post #57 onward.
Thank to wugfresh for noticing the changes.
Note that because previous binary images are now "in the wild" (or, you might have retained your own archives) you still need to be aware of what you are flashing - cross-check your checksums, folks.
Executive Summary:
1) There are at least THREE different bootloader files from Google/Asus that are all labeled with the identical version number "4.23". The versions distributed with the JWR66Y, KOT49H, KUT48L, KUT48P, and LRX21P Google factory images are INVALID. If you want a 4.23 bootloader ".img" file, get it from any of the (JWR66V, KRT16O, KRT16S) Google factory images
2) The "bootloader.raw" files contained in the OTA update .zip files ARE PREFIXED WITH A 76-byte PREAMBLE, and thus are NOT identical to the bootloader ".img" files distributed by Google in their full factory image distros. They should never be used with fastboot.
3) Somebody from Google/Asus screwed up royally and put the OTA (preamble-prefixed) bootloader file into the JWR66Y (full) factory Image; similarly the bootloader ".img" file in the KOT49H image is also screwed up - it starts with "BOOTLDR!" rather than an arm objcode near branch ("ea000010 == b[ranch] 48"). It is also a wildly different size than prior bootloader .img files. What's up Google?
I didn't examine any of the tilapia full factory images or OTA zip files to check them. You've been warned!
details:
Code:
GROUPER (N7 Wifi-Only, 2012) BOOTLOADERS
DERIVED FROM Google "Factory Images":
BYTES MD5SUM ROM FACTORY_IMAGE_FILENAME strings *.img | grep BOOTLOADER
2142784 f5f8c0dd160ef92c601311a0c9054118 JZO54K ./nakasi-jzo54k/bootloader-grouper-3.41.img BOOTLOADER VERSION - 3.41
2146892 a119629c89ad06c7e49bebd260df9cf3 JOP40C ./nakasi-jop40c/bootloader-grouper-4.13.img BOOTLOADER VERSION - 4.13
2146892 a119629c89ad06c7e49bebd260df9cf3 JOP40D ./nakasi-jop40d/bootloader-grouper-4.13.img BOOTLOADER VERSION - 4.13
2146892 bffa744a6847b5bede2bf445427ef80e JDQ39 ./nakasi-jdq39/bootloader-grouper-4.18.img BOOTLOADER VERSION - 4.18
2150992 df53028033c9eccf4fe5ba7bc198ce24 JWR66V ./nakasi-jwr66v/bootloader-grouper-4.23.img BOOTLOADER VERSION - 4.23
[color=red]2151068 5bdb2e87370cdb1a7ea14bb0c3e21390[/color] JWR66Y ./nakasi-jwr66y/bootloader-grouper-4.23.img BOOTLOADER VERSION - 4.23
2150992 df53028033c9eccf4fe5ba7bc198ce24 KRT16O ./nakasi-krt16o/bootloader-grouper-4.23.img BOOTLOADER VERSION - 4.23
2150992 df53028033c9eccf4fe5ba7bc198ce24 KRT16S ./nakasi-krt16s/bootloader-grouper-4.23.img BOOTLOADER VERSION - 4.23
[color=red]4005632 797a8ddfe19bfe4c485f8a8c119f1bdd[/color] KOT49H ./nakasi-kot49h/bootloader-grouper-4.23.img BOOTLOADER VERSION - %s
[color=red]2151068 5bdb2e87370cdb1a7ea14bb0c3e21390[/color] KTU84L ./nakasi-ktu84l/bootloader-grouper-4.23.img BOOTLOADER VERSION - 4.23
[color=red]2151068 5bdb2e87370cdb1a7ea14bb0c3e21390[/color] KTU84P ./nakasi-ktu84p/bootloader-grouper-4.23.img BOOTLOADER VERSION - 4.23
[color=red]2151068 5bdb2e87370cdb1a7ea14bb0c3e21390[/color] LRX21P ./nakasi-lrx21p/bootloader-grouper-4.23.img BOOTLOADER VERSION - 4.23
What sloppiness. Hard to say whether this is a Google fumble or an Asus fumble; perhaps something fell in the cracks between them.
What are the OTA 76-byte preambles of the "bootloader.raw" files? I'm not sure exactly. Perhaps they are nothing more than a signature used to "alert" the existing bootloader that a replacement bootloader has been dropped into the USP partition. (I suppose that all versions of the bootloader look at the USP partition when they first boot up to check for the presence of an update; the same technique may also be used by tilapia devices for radio firmware, but that's speculation) These prefixes are also not identical to each other; they seem to vary in only a few bytes from version to version, e.g.:
Code:
nakasi-JZO54K-from-JRO03S.d41da8f6 bootloader.raw (v 3.41)
00000000 4d 53 4d 2d 52 41 44 49 4f 2d 55 50 44 41 54 45 |MSM-RADIO-UPDATE|
00000010 00 00 01 00 3c 00 00 00 3c 00 00 00 01 00 00 00 |....<...<.......|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 45 42 54 00 |............EBT.|
00000040 4c 00 00 00 [color=red]40 b2 20 00[/color] 01 00 00 00 |[email protected] .....|
0000004c
nakasi-JOP40D-from-JZO54K.c01f18e0 bootloader.raw (v 4.13)
00000000 4d 53 4d 2d 52 41 44 49 4f 2d 55 50 44 41 54 45 |MSM-RADIO-UPDATE|
00000010 00 00 01 00 3c 00 00 00 3c 00 00 00 01 00 00 00 |....<...<.......|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 45 42 54 00 |............EBT.|
00000040 4c 00 00 00 [color=red]4c c2 20 00[/color] 01 00 00 00 |L...L. .....|
0000004c
nakasi-JDQ39-from-JZO54K.da55f917 bootloader.raw (v 4.18)
00000000 4d 53 4d 2d 52 41 44 49 4f 2d 55 50 44 41 54 45 |MSM-RADIO-UPDATE|
00000010 00 00 01 00 3c 00 00 00 3c 00 00 00 01 00 00 00 |....<...<.......|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 45 42 54 00 |............EBT.|
00000040 4c 00 00 00 [color=red]4c c2 20 00[/color] 01 00 00 00 |L...L. .....|
0000004c
nakasi-JWR66V-from-JDQ39.ab67ca07 bootloader.raw (v "4.23" rev0)
00000000 4d 53 4d 2d 52 41 44 49 4f 2d 55 50 44 41 54 45 |MSM-RADIO-UPDATE|
00000010 00 00 01 00 3c 00 00 00 3c 00 00 00 01 00 00 00 |....<...<.......|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 45 42 54 00 |............EBT.|
00000040 4c 00 00 00 [color=red]50 d2 20 00[/color] 01 00 00 00 |L...P. .....|
0000004c
The differences that appear in these preambles are the 4-bytes sequence (shown highlighted above) which are exactly the (little-endian) length of the corresponding (non-preamble-prefixed) bootloader of the same "version".
Recommendations:
- Be extremely aware of where you get bootloader files from. The authoritative place to get the unadorned (no preamble) bootloaders are from the Google Factory Images. In the event you need older factory images which are not available from Google any longer, oldblue910 maintains a historical archive of both the factory images and individual OTA patch bundles.
- "bootloader.raw" files should NEVER be flashed with fastboot.
- bootloader ".img" files from the factory full-image distros won't do anything if flashed to the USP - they don't have the preamble that the (pre-existing) bootloader looks for.
- If you must flash a bootloader, avoid the "4.23" bootloader .img files from the JWR66Y and KOT49H factory images. A valid 4.23 bootloader ".img" file has an MD5 signature of df53028033c9eccf4fe5ba7bc198ce24
cheers
* not sure what this file is; but it isn't a bootloader. While there is plenty of arm object code in there, It has almost 0% overlap of ascii strings greater than length 8 with the valid 4.23 bootloader from (e.g.) JWR66V. Possibly worth a look by folks that enjoy disassembly?
Thank you Sir for this fine explanation and hints. You prooven my thoughts I had about flashing bootloaders with fastboot. (See my signature ; the posts are still need to be updated for your hints)
I think, that we should "flash" the bootloader only at one point: if we get via ota. Flashing the bootloader is so damn risky... I think, it shouldn't be done three times day and only if there is an update...
Yes, I agree, flashing bootloaders is the most risky part, but flashing by OTA has always been more risky than flashing it by fastboot. Using fastboot you can control the flashing process and try to re-flash if anything fails, OTA is out of your control ...
Sent from my Nexus 7 using xda app-developers app
AndDiSa said:
Yes, I agree, flashing bootloaders is the most risky part, but flashing by OTA has always been more risky than flashing it by fastboot. Using fastboot you can control the flashing process and try to re-flash if anything fails, OTA is out of your control ...
Sent from my Nexus 7 using xda app-developers app
Click to expand...
Click to collapse
This is maybe right, but as bftb0 stated, the bootloaders packed in the factory images can't really be trusted trusted anymore. You will never know what you get. I also can remember, that there were faulty JWR66(V/Y ? I don't know) nexus 7 factory image, which google replaced later. So I think, flashing via OTA is safer. Don't you think google tested this ota-flashing thing till the last bit? Don't you think google tested their ota-packages?
Is there a known ota-fail on stock, always-unmodified device (especially, with bootloader-dead devices following an ota-bootloader-flash)? I made recently a lot of updates of the stock ROM with ota - from Android 4.2.2 till 4.4.2 - none failed. I trust the google-ota mechanism more then all custom-recovery-flashes.... but only, if the device is completly unmodified.
I am excited about your answer! :good:
vorcers said:
This is maybe right, but as bftb0 stated, the bootloaders packed in the factory images can't really be trusted trusted anymore. You will never know what you get. I also can remember, that there were faulty JWR66(V/Y ? I don't know) nexus 7 factory image, which google replaced later. So I think, flashing via OTA is safer. Don't you think google tested this ota-flashing thing till the last bit? Don't you think google tested their ota-packages?
Is there a known ota-fail on stock, always-unmodified device (especially, with bootloader-dead devices following an ota-bootloader-flash)? I made recently a lot of updates of the stock ROM with ota - from Android 4.2.2 till 4.4.2 - none failed. I trust the google-ota mechanism more then all custom-recovery-flashes.... but only, if the device is completly unmodified.
I am excited about your answer! :good:
Click to expand...
Click to collapse
It's your decision to trust OTA more than flashing system image files by fastboot, but I think you are missing the point: If you are flashing a corrupt / wrong / ... image then the results by OTA and fastboot are the same. A bootloader update by OTA is nothing else then flashing an image file (like you do with fastboot) , only that it is done automatically on the next reboot of your device while a fastboot flash is done immediately.
I agree that the quality check of Google's system images does not take place at the moment and that the probability of getting a working OTA (at least for the moment) is most likely higher, but this does not influence the flashing process itself. fastboot is more secure than OTA ... if he file you are flashing is working ...
vorcers said:
This is maybe right, but as bftb0 stated, the bootloaders packed in the factory images can't really be trusted trusted anymore. You will never know what you get. I also can remember, that there were faulty JWR66(V/Y ? I don't know) nexus 7 factory image, which google replaced later. So I think, flashing via OTA is safer. Don't you think google tested this ota-flashing thing till the last bit? Don't you think google tested their ota-packages?
Is there a known ota-fail on stock, always-unmodified device (especially, with bootloader-dead devices following an ota-bootloader-flash)? I made recently a lot of updates of the stock ROM with ota - from Android 4.2.2 till 4.4.2 - none failed. I trust the google-ota mechanism more then all custom-recovery-flashes.... but only, if the device is completly unmodified.
I am excited about your answer! :good:
Click to expand...
Click to collapse
Hi, vorcers...
Yep... I also think that flashing via OTA is safer. Given that this is how 99.9% of all Android users get their updates, (ie, not via the factory images). I would imagine there would have been a bit of an outcry, had faulty bootloaders delivered by OTA updates, bricked a lot of devices.
Also, it's my understanding that OTA's updates bootloaders by 'dropping' a temporary copy (BOOTLOADER.RAW) into a sort of a temporary 'holding' partition (USP/Staging)... prior to it being 'copied' to the bootloader partition proper. I'm guessing some sort of checksum or other similar test is performed on the two bootloaders... the current (old) one, and the (potentially) new one (held in the USP partition), to ensure compatibility.
However, when you fastboot flash a bootloader, you're directly writing OVER the current one... if it's garbage you're writing, you have a dead Nexus. Still, having said that, it's probably a bit more complicated than my possibly over simplified account.
One things for sure, though... never fastboot flash a bootloader... unless you really need to.
I ran the flatline procedure a couple of months ago, and it was a hugely nerve wracking experience. Fortunately, it went without a hitch, and I'm back on bootloader v4.23 (from build JWR66V)... and I now have my 'wheelie' blobs, safely stashed away in a variety of locations.
Testing them though, is something I won't be doing... for tolerably obvious reasons.
Rgrds,
Ged.
GedBlake said:
...
Also, it's my understanding that OTA's updates bootloaders by 'dropping' a temporary copy (BOOTLOADER.RAW) into a sort of a temporary 'holding' partition (USP/Staging)... prior to it being 'copied' to the bootloader partition proper. I'm guessing some sort of checksum or other similar test is performed on the two bootloaders... the current (old) one, and the (potentially) new one (held in the USP partition), to ensure compatibility.
Click to expand...
Click to collapse
Flashing a bootloader by fastboot will not overwrite the current one immediately, but it will be flashed on reboot, i.e. the bootloader updating process between fastboot and OTA is almost the same ... beside the possibility to correct a mistake (i.e. flashed a wrong bootloader) as log as you do not reboot your device.
AndDiSa said:
Flashing a bootloader by fastboot will not overwrite the current one immediately, but it will be flashed on reboot, i.e. the bootloader updating process between fastboot and OTA is almost the same ... beside the possibility to correct a mistake (i.e. flashed a wrong bootloader) as log as you do not reboot your device.
Click to expand...
Click to collapse
Thanks, AndDiSa...
You know... I'd quite forgotten about that.
But isn't that because the new faulty bootloader (or some other random garbage) HAS actually been written to the eMMC chip, but the old working bootloader is still loaded into memory/RAM (ie., you're still in fastboot mode)... affording you a very slight window of opportunity to reverse or correct the mistake... providing the device isn't rebooted.
The old bootloader is still there, but it's now only stored in 'volatile' memory...
Rgrds,
Ged.
Hi Ged
First, I should say that your comments here were what encouraged me to check all the (grouper) bootloader images from the Google "factory images" - it triggered a recollection that I had noticed a length difference between the OTA and fastboot versions of the bootloader files some time ago, so I went back and took a look. Thanks for giving me the incentive.
Warning - a bit of a [thread-jack] ahead:
GedBlake said:
I ran the flatline procedure a couple of months ago, and it was a hugely nerve wracking experience. Fortunately, it went without a hitch, and I'm back on bootloader v4.23 (from build JWR66V)... and I now have my 'wheelie' blobs, safely stashed away in a variety of locations.
Click to expand...
Click to collapse
There is a comment in that Flatline - Unbrickable Nexus 7 (Wi-Fi + 3G) thread to the effect of:
Xcandescent said:
There should also be a warning that flashing the bootloader with nvflash prevents it from ever being flashed with fastboot again. I found that out the hard way. I suspect there's a way to get that working again (i.e. flashing in secure boot mode), but you would need to post instructions for doing that.
-XCN-
Click to expand...
Click to collapse
... but trying to read between the lines, I can not determine if Xcandescent's claims only apply if you leave the "patched" version of the AndroidRoot.Mobi bootloader on the device, rather than using nvflash itself to put back a "stock" bootloader. Reading between the lines, it sounds like subsequently you have not tried using fastboot for flashing a bootloader... do I have that right?
I guess I will put up a question on that thread and see if rayman or lilstevie respond... [/thread-jack]
bftb0 said:
Hi Ged
First, I should say that your comments here were what encouraged me to check all the (grouper) bootloader images from the Google "factory images" - it triggered a recollection that I had noticed a length difference between the OTA and fastboot versions of the bootloader files some time ago, so I went back and took a look. Thanks for giving me the incentive.
There is a comment in that Flatline - Unbrickable Nexus 7 (Wi-Fi + 3G) thread to the effect of:
... but trying to read between the lines, I can not determine if Xcandescent's claims only apply if you leave the "patched" version of the android.mobi bootloader on the device, rather than using nvflash itself to put back a "stock" bootloader. Reading between the lines, it sounds like subsequently you have not tried using fastboot for flashing a bootloader... do I have that right?
I guess I will put up a question on that thread and see if rayman or lilstevie respond...
Click to expand...
Click to collapse
Hi, bftb0...
It's good to see you around again. I must admit, that most of the stuff you post, I really, really don't understand... but I always learn something new.
Concerning flatline... Well, I ran it sometime back in October...
I knew beforehand that there where known issues concerning fastboot flashing the bootloader from build JWR66Y (ie, it won't fastboot flash) so now I ALWAYS keep a copy of the v4.23 bootloader from build JWR66V stored on my laptop... which came in useful for the flatline procedure.
The whole procedure revolves around flatlines Custom Recovery...
Once I'd fastboot flashed the specially modified Flatline Custom Recovery (which is based on CWM) to the recovery partition, I then went into the ADVANCED option... and selected option 1: flash AndroidRoot BL... this flashes the AndroidRoot Custom Bootloader - (you don't actually flash this yourself - the Flatline Custom Recovery does it for you).
Following the instructions to the letter, I then booted normally into Android.
I shutdown my Nexus 7 completely, and rebooted into this modified AndroidRoot bootloader in fastboot mode... to discover that the version number had been 'downgraded' to v4.13. Nothing there signifies or indicates it is in fact the flatline AndroidRoot BL... it just looks like a regular v4.13 bootloader.
After selecting the RECOVERY option in this modified bootloader, as you would normally, to get into either standard CWM or TWRP, it boots back into the Flatline Custom Recovery again.
Selecting the ADVANCED option again... I now choose option 2: generate wheelie blobs... these blobs were then generated, which I subsequently found in /data/media/AndroidRoot on the Nexus 7 itself. Having made multiple copies of them, it was then just a matter of closing the operation by doing two things...
*** fastboot flashed back to the normal v4.23 bootloader from build JWR66V...
...and after a normal reboot...
*** fastboot flashed back to the version of TWRP I was using at the time...
A summary
1). I fastboot flashed the special Flatline Custom Recovery.
2). In this special Custom Recovery, in the Advanced menu option, I selected option no.1... it flashed the AndroidRoot v4.13 bootloader.
3). I rebooted normally into Android.
4). I rebooted into the Flatline Custom Recovery again (via the bootloader).
5). In the Advanced menu option, I selected 'generate wheelie blobs'.
6). Once generated, I copied them from /data/media/AndroidRoot .
-- Now to return everything back to normal...---
7). I fastboot flashed the regular v4.23 bootloader from build JWR66V.
8). I fastboot flashed the version of TWRP I was using at the time.
I didn't need to use nvFlash to restore the standard bootloader... I just used the standard fastboot flash bootloader bootloader.img syntax, to reflash v4.23.
And that's pretty much it really... obviously I haven't had the opportunity to test out those 'blobs'... and hopefully, I'll never have cause to.
Hope this helps.
Rgrds,
Ged.
GedBlake said:
I didn't need to use nvFlash to restore the standard bootloader... I just used the standard fastboot flash bootloader bootloader.img syntax, to reflash v4.23.
Click to expand...
Click to collapse
Thanks!
bftb0 said:
- If you must flash a bootloader, avoid the "4.23" bootloader .img files from the JWR66Y and KOT49H factory images. A valid 4.23 bootloader ".img" file has an MD5 signature of df53028033c9eccf4fe5ba7bc198ce24
Click to expand...
Click to collapse
A download of that file can be found here, just as an FYI.
i have fastboot flashed the bootloader image from KOT49H, and it *seems* to be working fine..
what could be the potential issue here, a possible future brick?
is it better to flash back the bootloader image from KRT16S as suggested by the OP?
tia..
iamelton said:
i have fastboot flashed the bootloader image from KOT49H, and it *seems* to be working fine..
what could be the potential issue here, a possible future brick?
is it better to flash back the bootloader image from KRT16S as suggested by the OP?
tia..
Click to expand...
Click to collapse
Are you sure it actually got flashed?
Others have reported "signing errors" relating to bootloader flashing in the past, so I suppose it is possible that some form of sanity checking is performed by the existing bootloader. Meaning, that the fastboot flash command actually does transfer the image file to the tablet (probably into RAM because it is a fairly small file) but if it doesn't pass those sanity checks, it never really gets burned to the eMMC chip by the pre-existing bootloader. Unfortunately, because the bootloader is proprietary, we don't really know what is checked and what isn't.
(I think most folks who hard-bricked their tablet either *erased* their bootloader using fastboot and then rebooted before they had flashed something, or else they accidentally over-wrote /dev/block/mmcblk0p{0,1} from a root-privileged process inside a booted ROM or recovery)
If your tablet is working I wouldn't fix something that isn't broke.
But as I said, I'm pretty confident that whatever that thing is in the KOT49H factory image, it is NOT a valid bootloader.
Code:
$ strings -8 nakasi-kot49h/bootloader-grouper-4.23.img > kot49h-strings.txt
$ strings -8 nakasi-krt16o/bootloader-grouper-4.23.img > krt16o-strings.txt
$ wc -l *-strings.txt
4363 kot49h-strings.txt
1935 krt16o-strings.txt
6298 total
$ cat kot49h-strings.txt | sort | uniq > kot49h-strings-unique.txt
$ cat krt16o-strings.txt | sort | uniq > krt16o-strings-unique.txt
$ rm *-strings.txt
$ wc -l *-strings-unique.txt
3839 kot49h-strings-unique.txt
1797 krt16o-strings-unique.txt
5636 total
$ cat *-strings-unique.txt | sort | uniq | wc -l
5611
$ cat *-strings-unique.txt | sort | uniq -d | wc -l
25
(Interpreting the above: there are 1797 unique ASCII strings (out of 1935) of length 8 or greater in the KRT16O version of the file; and there are 3839 unique ASCII strings (out of 4363) of length 8 or greater in the KOT49H version. And only 25 matching strings between the two of them!)
There's really only two plausible explanations for that:
- That Google/Asus completely replaced their bootloader code - and gave it the same name! -OR-
- That blob in KOT49H isn't a bootloader.
cheers
the strange thing is that i flashed both the JWR66Y and KOT49H version bootloaders..
the JWR66Y one did give me a flash error (something like unable to overwrite) during the process, however, the KOT49H gave me a success result..
therefore before finding this thread i was under the impression that my n7 was using the KOT49H bootloader happily..
but now im a bit confused..
anyway as u suggested, theres no need to fix something thats not broken..
and probably in future i shall not flash bootloaders so promptly (or maybe better not to flash at all unless necessary..)
Hi, this weekend I flashed bootloader to my own N7 2012 3G(tilapia) many times.
Describes in summary (but too looong), attached full report.
I found JDQ39(4.2.2) and KRT16S(4.4) are only correct bootloader file?
Grouper and Tilapia uses same bootloader.img?
What happen google / asus software release?
Code:
TILAPIA (N7 3G, 2012) BOOTLOADERS
DERIVED FROM Google "Factory Images":
BYTES MD5SUM ROM FACTORY_IMAGE_FILENAME strings *.img | grep BOOTLOADER
2146892 bffa744a6847b5bede2bf445427ef80e JDQ39 ./nakasig-jdq39/bootloader-tilapia-4.18.img BOOTLOADER VERSION - 4.18
- - - - - - JWR66V (I don't have this factory image) - - -
2151068 5bdb2e87370cdb1a7ea14bb0c3e21390 JWR66Y ./nakasig-jwr66y/bootloader-tilapia-4.23.img BOOTLOADER VERSION - 4.23
- - - - - - KRT16O bootloader & radio image didn't contain!! - - -
2150992 df53028033c9eccf4fe5ba7bc198ce24 KRT16S ./nakasig-krt16s/bootloader-tilapia-4.23.img BOOTLOADER VERSION - 4.23
4005632 797a8ddfe19bfe4c485f8a8c119f1bdd KOT49H ./nakasig-kot49h/bootloader-tilapia-4.23.img BOOTLOADER VERSION - %s
JDQ39, KRT16S succeeded flash bootloader
Code:
nakasig-jdq39# fastboot flash bootloader bootloader-tilapia-4.18.img
sending 'bootloader' (2096 KB)...
OKAY [ 0.338s]
writing 'bootloader'...
OKAY [ 1.230s]
finished. total time: 1.569s
(bootloader screen left-top) "Signature match."
JWR66Y, KOT49H failed flash bootloader
Code:
nakasig-jwr66y# fastboot flash bootloader bootloader-tilapia-4.23.img
sending 'bootloader' (2100 KB)...
OKAY [ 0.335s]
writing 'bootloader'...
FAILED (remote: (InvalidState))
finished. total time: 0.469s
"Signature mismatch."
Thanks @s107ken
It is reassuring to know that the pre-existing bootloader performs signature checking against the file blobs when using fastboot.
I presume the same thing happens when the OTA version of the bootloader is dropped into the staging partition - the pre-existing bootloader has the opportunity to examine it for validity.
But if someone were to flash a bad blob directly from a root shell using "dd" they will certainly hard-brick their N7.
Doubts
Hey guys, I've got a few questions relating to the bootloader, its versions and nvflash.
Hopefully by the next week I'm going to be a proud owner of the Nexus 7. I'm not new to the android world or flashing. But, it'll be a new experience for me to own a nexus device. I own a Xperia Mini Pro (Sony Ericsson) where the only fastboot command used is the command used to flash kernels, so all this talk about using fastboot to flash bootloaders, baseband etc. is definitely a big change. So pardon me if make a mistake or ask a wrong question.
I'm confused about a few things :
i) If I update my android version using the OTA feature to 4.4.2 (KOT49H), it would also flash/update my bootloader, right? So, according to this thread the bootloader included in that update is not right (or doesn't work properly? ) and then would I be required to flash the bootloader image from the KRT16S update?
ii)I was reading through the flatline thread, and initially it seemed amazing that by generating a few blobs, you could unbrick your device. But, after reading a few pages ahead it seemed that many people were facing problems and it now seems a dangerous procedure. So my question is: Is it really recommended that an individual generate those blobs and by doing so, follow that nerve racking procedure?
iii)If I were to flash a custom kernel, would it include a custom recovery or would I have to install a custom recovery using fastboot. And if the custom kernel will include a custom recovery, will overwrite the existing custom recovery?
Thanks a lot.
@andogeek10
Some preliminaries - are 2012 versions of the N7 still being sold? If you are talking about the 2013 N7, then you are in the wrong forum. A lot of this stuff is device dependent (as you are finding out), so you should consult owners who have experience with the specific device you intend to purchase.
andogeek10 said:
i) If I update my android version using the OTA feature to 4.4.2 (KOT49H), it would also flash/update my bootloader, right?
Click to expand...
Click to collapse
Well, you didn't say which version of bootloader you will be on. The OTAs are patch bundles, so if you already had the most recent bootloader, the OTA process would not apply it again.
Having said that, there is no evidence that Google/Asus got any of the OTA bundles wrong - they are different from the "factory images" hosted by Google. So, first: this thread doesn't apply to OTAs, and second (see posts just above), the pre-existing bootloaders appear to do a sanity/crypto signing check before they allow the bootloader to be flashed into place for reals, so there is very little danger involved in an OTA. (Based on the recent reports, it isn't even obvious to me how folks would have been able to bork their bootloaders, unless they manually flashed it into place using a root shell and the dd command (either with the OS running or with a custom recovery running).
andogeek10 said:
So, according to this thread the bootloader included in that update is not right (or doesn't work properly? ) and then would I be required to flash the bootloader image from the KRT16S update?
Click to expand...
Click to collapse
See above. If you were somehow able to flash a dud bootloader to the device, as soon as you power-cycled it, it would be a hard brick. I haven't been paying attention to the 2012 N7 forum recently, but I think the only thing that will save someone in that situation is that if they had previously prepared for the eventuality of a hard brick by using the flatline method.
andogeek10 said:
ii)I was reading through the flatline thread, and initially it seemed amazing that by generating a few blobs, you could unbrick your device. But, after reading a few pages ahead it seemed that many people were facing problems and it now seems a dangerous procedure. So my question is: Is it really recommended that an individual generate those blobs and by doing so, follow that nerve racking procedure?
Click to expand...
Click to collapse
Folks will have different opinions about this, but honestly the only people who bork their bootloader are people that have extremely sloppy habits*. (Grab files from anywhere, never check file MD5 sigs, etc). Given that the set of instructions provided by the flatline devs are frankly quite vague on several points, you have to wonder if it is a good idea for folks with sloppy habits to be performing vaguely-described procedures, especially since the procedures involve the dangerous operation in question (flashing a bootloader).
[Edit]* There is one high risk way a borking can happen that is probably easy for even skilled folks to accidentally perform; but only if they are in a hurry and not paying attention. And that is to accidentally do a "fastboot erase bootloader" when the intended command was "fastboot erase boot". Even in this case though, the existing bootloader is still present an running in memory; so as long as the tablet continues to run and you can communicate with it in fastboot mode, this type of mishap is correctable if you immediately flash back into place a valid bootloader. But if you turn the tablet off, it's a brick at that point. I don't really know why fastboot allows you to perform the erasure of the bootloader partition - it should be sufficient to simply flash something over the pre-existing bootloader. Something could still go wrong - as erasure of blocks always happens when flashing new data into flash memory; otoh, there is no delay between wiping and replacement with a valid image in the normal case. [/Edit]
andogeek10 said:
iii)If I were to flash a custom kernel, would it include a custom recovery or would I have to install a custom recovery using fastboot. And if the custom kernel will include a custom recovery, will overwrite the existing custom recovery?
Click to expand...
Click to collapse
Custom kernels and recoveries are independent bootable images stored in different partitions. You don't get one with the other**, nor does one overwrite the other**. Generally, a conservative and safe 2012 N7 rooting sequence is
0) Install the Android SDK and necessary drivers on your PC (no drivers needed for OS/X or Linux)
1) unlock the bootloader using fastboot (this wipes any user data on the entire tablet)
2) soft-boot a custom recovery image using fastboot, e.g.
"fastboot boot openrecovery-twrp-2.6.3.1-grouper.img"
3) use the soft-booted recovery to immediately take a FULL STOCK Nandroid backup - including the STOCK recovery!
4) hard flash the custom recovery image (e.g. this time "fastboot flash recovery openrecovery-twrp-2.6.3.1-grouper.img", instead of "fastboot boot openrecovery-twrp-2.6.3.1-grouper.img")
5) Use a "flashable zip" install of SuperSU (push the file to the device using adb with the recovery running, or put it on a USB key and plug that to the device with a OTG cable)
6) If you want, you can make yet another Nandroid at this point to capture a baseline "lightly rooted Stock" backup.
7) Immediately - before you do anything else - get copies of those full stock & lightly rooted stock backups someplace off of the tablet. (Note: TWRP supports OTG USB devices - you could have written the Nandroids to a USB thumb drive in steps 3 and 6 if you had wanted to.)
8) Start doing what you will as far as rooting goes.
Now, why did I give you the instructions above? Simple - the only way I have ever updated my bootloader is by taking a Nandroid backup of my current ROM, restoring the FULL STOCK Nandroid backup - INCLUDING THE FACTORY RECOVERY. This results in a device which is 100% stock and not even rooted... (but the bootloader is still unlocked). Then I take the OTA, and let the OTA do the dirty business.
And when that completes, I repeat steps 2) - 6) all over - FOR THE NEW VERSION OF 100% STOCK INCLUDING THE STOCK RECOVERY.
And check this out - I don't even use stock or lightly rooted stock as a daily driver.
So why all the above nonsense?
First because the OTA process has a bunch of crypto checks built in that protect you from hazards like the one you are anticipating. Second because running OTAs against modified ROMs will many times result in OTA failure.
And third, so that I will have 100% stock Nandroid backups (including the stock recovery) for every stock release that has ever been issued for the tablet while I owned it. When I go to sell the thing, I can roll it back to 100% stock - for any release I want, lock the bootloader, perform a factory reset... and it will be as if it just came from the factory.
Fourth, those stock releases will be fully capable of accepting future OTAs - unlike customized ROMs.
good luck with your device(s)
** a boot image is = kernel + ramdisk. Both the "boot" and "recovery" images are boot images. In stock devices, the kernel used by the stock recovery is identical to the kernel used by the OS boot - they differ only in their ramdisk. So that means that when an OTA comes along that modifies the kernel used in the regular (Android) boot, the stock recovery partition will also get updated.
In the recovery, the booting does not depend on anything in the /system or /data partition (kinda), whereas the regular boot image chains into full-up Android UI, apps, etc. So the recovery allows you to do offline maintenance of /system and (portions of) /data. What you might have seen on other devices, is that during application of the OTA, the recovery image is actually generated by a patch set that operates on the stock boot image. Quite literally, the recovery is generated from the boot image with a process that looks like
/boot (image) + boot-to-recovery-patch.p -> recovery (image)
Some older android phones would flash the stock recovery back into place (using the above method or similar) *every time the phone booted*. This was done via some scripts in /system. IIRC, something similar to this is present in Stock N7 releases, perhaps at /system/boot-from-recovery.p (and related init.d scripts) It is possible that the custom recoveries are aware of this and will relocate or remove this gearing for you (in the same way that they will offer to install SuperSU for you). But, if you notice that your custom recovery keeps getting replaced with the stock recovery when you use lightly-rooted-stock, this is the mechanism that does this.
.
Thanks a lot for clearing these doubts of mine. Yes, the 2012 version is still sold ( at least in India it is ) and is much cheaper than the 2013 version.
2012 Nexus 7 - INR 9100
2013 Nexus 7 - INR 21000
And yes, i do know the difference between Nexus 7 2012 and 2013 (at least the major ones ).
About the nvflash blobs generation, I've decided to not do it as I would be directly updating via OTA to 4.4.2 and then unlock the bootloader. Also, I would be updating via OTA only in the future, so I will not flash the bootloader by fastboot ( and hopefully reducing the risk of achieving a brick).
I was confused about the kernel and recovery as in the 2011 Xperia devices, there is no separate recovery partition and thus the recovery changes with every kernel flash.
I had read through most of the sticky topics and these were the only doubts remaining. Thanks again for clearing them.
Sent from my Xperia Mini Pro using XDA Premium 4 mobile app
A little while ago, I had problems with my phone not reading the SIM. When I tried to flash the stock firmware, the application crashed, resulting in a (hopefully) softbricked phone. I tried these methods trying to get it back to life:
http://forum.xda-developers.com/showthread.php?t=1843830 (post 4)
http://forum.xda-developers.com/showthread.php?t=2069723
And I also tried the LG R&D test tool to fash the kdz (I can't find the corresponding thread right now).
I've tried all of these methods on Win7 x64, Vista x64 and XP 32bit. The all did the same thing: they got stuck at wParam=2010 Iparam=210, so I think the phone is the problem and not the computers.
I was running CM11 with an unlocked bootloader. I can turn the phone on (and not off) but I can't get it out of the update mode. I can still update the phone until wParam=2010 Iparam=210, when it gets stuck. (I also tried waiting about an hour, nothing happened). As far as I know the phone is not a developer edition.
My question is, what do I try next?
Beunhof said:
I was running CM11 with an unlocked bootloader. I can turn the phone on (and not off) but I can't get it out of the update mode. I can still update the phone until wParam=2010 Iparam=210, when it gets stuck. (I also tried waiting about an hour, nothing happened). As far as I know the phone is not a developer edition.
Click to expand...
Click to collapse
Hello, and good day,
I have the same problem as you,
I also tried several guides ranging from installing KDZ files, through adb consoles and with a program (unfortunately I've forgotten the name) that caused the LG software to detect the KDZ files as an update for the phone, like it was from their servers, so it was 'intalled in an original way'.
But whatever, none of them worked.
Also, very important, mine gets also stuck on wParam=2010 Iparam=210,
I took the phone to a service store, where they repair cellphones through "boxes", but without success, they just mentioned that it would get stuck everytime at 15-25% of the installation process.
My Optimus 4X HD status is: can only access the S/W Update screen, or, if I turn the phone On it just shows and gets stuck on the LG logo.
It has no OS or recovery...
:crying:
Edit: I forgot to mention, I tried on Win 7 x64, x32 and on Win XP sp3 x32. So obviously the problem is on the phone.
Sounds like we have the same problem, except my phone doesn't show the boot logo at all, it instantly jumps to S/W mode when I turn it on.
After some searching, I found 3 methods I haven't tried yet:
http://forum.xda-developers.com/showthread.php?t=2475045
http://forum.xda-developers.com/showthread.php?t=2085344
http://forum.xda-developers.com/showthread.php?t=2797190
When I get back from work I'll give these a try, I will report back with results.
Does anyone have more suggestions or ideas? Should I contact LG for a fix?
Beunhof said:
After some searching, I found 3 methods I haven't tried yet:
http://forum.xda-developers.com/showthread.php?t=2475045
http://forum.xda-developers.com/showthread.php?t=2085344
[*]http://forum.xda-developers.com/showthread.php?t=2797190
Does anyone have more suggestions or ideas? Should I contact LG for a fix?
Click to expand...
Click to collapse
Hello again, I checked the three methods listed above,
i didn't like the first two really, but the third one got me so I'm doing it.
This is what I did and the result (on Win XP sp3 x32)
- Downloaded a fresh P880 V20A_00.kdz
- Downloaded and Installed fresh LGUnitedMobileDriver_S50MAN311AP22_ML_WHQL_Ver_3.11.3.exe
- During the drivers Installation, XP asked me to download and install this WMFDist11-WindowsXP-X86-ENU.exe (as suposedly I needed an mtp 11 runtime whatever). All good.
- Downloaded the LG Flash Tool 2014 from the guide, and moved the .kdz into that folder.
- Opened the program following the instructions on the post and started flashing my Optimus 4X with that Tool using CSE Flash.
- The second window named LG Mobile Support Tool that poped up started the process and had 4 modules
On the third module, the program started the Installation of the firmware on my device, on the S/W Update screen, after a while it reached 10%
Well.... it's been on 10% of the Installation progress for 43 minutes now (even while writing this response...).
The phone is perfectly recognized by the PC, I just dont get why it won't progress!....
Thanks tho, that LG Tool 2014 seemed really helpful. But still bricked.
Status:
After several investigation, I've also tried the following:
- Using P880_HK_V20B_00.kdz version, didn't work.
- Flashing thru kdz-update UpTestEX_mod2_marwin.exe, didn't work.
- Once LGMobile Support Tool is open, on the Tab "Additional Characteristics" I clicked on Recovery from Update Error.
The Tool asked for the Model & Serial Number of my device, which I entered and after the program tried to connect to the phone, said that it couldn't connect to the device.
I'm now totally sure that the problem is somewhere between the communication of the Computer and the P880, because:
Either KDZ-Update or LG Mobile Support Tool always gets stuck at what seems the 10% of the process.
Any method of flashing the device gets stuck and asks to remove battery and disconnect the usb, then replace and reconnect (an attempt to re-enable connection IMO)
Changing USB port on the PC always 'reinstall' the drivers, but with no avail.
Another thing I forgot to mention before, even tho every guide on XDA says that on the flashing process we should first "Install the drivers of the LG P880 from the list on the LG Mobile Support Tool", my tool (any version downloaded) never displayed LG P880 on the list, I've always had to use the UnitedDrivers package instead.
Any thoughts?
alessocf said:
Well.... it's been on 10% of the Installation progress for 43 minutes now (even while writing this response...).
Click to expand...
Click to collapse
I got to 10% in 52 seconds and then I got a disconnect error. I gave it a try with windows enabled just to make sure but the same thing happened. Seems like a nice and fast tool, too bad it couldn't do the trick.
This attempt also failed, but I might have some usefull information now:
Code:
[22:56:11.593]Selected 7 Binary : c:\users\beunhof\desktop\fix\lgp880at-00-v20b-eur-xxx-jul-17-2013+0.dz
[22:56:11.594]DoDownload : Retry(1)
[22:56:11.595]###### Port Opend(41) ######
[22:56:11.595]Opened COM41
[22:56:11.595]=====================================================
[22:56:11.596]= DLL Info : Dec 12 2012 11:01:58
[22:56:11.596]=====================================================
[22:56:11.602] MODEL:P880
[22:56:11.605] IMEI:000000000031
[22:56:11.611] PID:0000000003001721
[22:56:11.614] SWV:LGP880AT-00-V20b-EUR-XXX-JUL-17-2013+0
[22:56:11.617][VerReq]
[22:56:11.618]Model Name : Target(P880)
[22:56:11.618][FeatureQuery]
[22:56:11.633]This firmware supports the following features:
[22:56:11.633] - Protocol Version : 3
[22:56:11.633] - CP Download : TRUE
[22:56:11.633] - AP Download : TRUE
[22:56:11.633] - ROM Download : TRUE
[22:56:11.633] - MaxPacketLength : 0x40000
[22:56:11.633] - Battery Level : 37%
[22:56:11.633] - OperatingMode : 4
[22:56:11.633] - AutoUpdateBuffer : 1
[22:56:11.633] - ThreadOn : 1
[22:56:11.633] - Flashless : 0
[22:56:11.633] - UpdateBct : 0
[22:56:11.636] Dz Information
[22:56:11.636] - Model Name : Binary(P880)
[22:56:11.636] - SWV : LGP880AT-00-V20b-262-000-JUL-17-2013+0
[22:56:11.636] - BuildTime : 2013-07-18 01:35:51
[22:56:11.636] - SecureType : 1
[22:56:11.636] - TotalFiles : 10
[22:56:11.636] Loading FLS
[22:56:11.729]IntelFlash::GetDownloadSize
[22:56:11.729] - PSI : 35316
[22:56:11.729] - EBL : 157172
[22:56:11.729] - Hardware : 172
[22:56:11.729] - Security : 2048
[22:56:11.729] - DownloadData : 20572
[22:56:11.729] - Security : 2048
[22:56:11.729] - DownloadData : 167768
[22:56:11.729] - Security : 2048
[22:56:11.729] - DownloadData : 697892
[22:56:11.729] - Security : 2048
[22:56:11.729] - DownloadData : 356380
[22:56:11.729] - Security : 2048
[22:56:11.729] - DownloadData : 7864428
[22:56:11.729] Loading CFG
[22:56:11.733]NvidiaFlash::GetDownloadSize
[22:56:11.733] - BCT : 6128
[22:56:11.733] - EBT : 1132440
[22:56:11.733] - EKS : 684
[22:56:11.733] - SOS : 8228864
[22:56:11.733] - LNX : 7120896
[22:56:11.733] - APP : 925208920
[22:56:11.733]TotalSize : 83624509
[22:56:11.733]CP Download Starting : 0
[22:56:11.733]CP Binary has been loaded(9349476)
[22:56:11.733][Intel] MemoryMap
[22:56:11.733] FlashStartAddr : 0x40000000
[22:56:11.733] CUST : StartAddress(0x63000000), Length(0x00500000) : LINUX
[22:56:11.734] CUST : StartAddress(0x38000000), Length(0x08400000) : CLONE
[22:56:11.734] CUST : StartAddress(0x30000000), Length(0x08400100) : PREFLASH
[22:56:11.734] CUST : StartAddress(0x20000000), Length(0x00500000) : USBRO_ISO
[22:56:11.734] CUST : StartAddress(0x90000000), Length(0x001FE000) : CUSTDATA
[22:56:11.734][CMD_Intel_DownloadMode]
[22:56:12.294] - Device synchronized
[22:56:12.294][Injecting PSI RAM] : 35316
[22:56:12.294] - Sending PSI RAM
[22:56:15.354] - Receiving CRC
[22:56:15.367] - Received CRC OK : 01
[22:56:15.367] - Receiving ACK
[22:56:15.379] - Received ACK : 01 00 AA
[22:56:15.379] - PSI RAM Running
[22:56:15.379][Injecting EBL] : 157172
[22:56:15.379] - Sending EBL Length
[22:56:15.389] - Receiving ACK
[22:56:15.401] - Received ACK : 0xCCCC
[22:56:15.401] - Sending EBL : 157172
[22:56:29.112] - Sending CRC : FA
[22:56:29.121] - Receiving ACK
[22:56:29.169] - Received OK : 51 A5
[22:56:29.169] - Receiving Capabilities : 76
[22:56:29.184] - Boot-loader is active
[22:56:29.184] - EBL version: XMM6260_20.21_M1S1
[22:56:29.184] - Boot mode is: 00BB
[22:56:29.184] - EBL Running
[22:56:29.184][ReqSetProtConf]
[22:56:29.184] == prot_capabilities_t ==
[22:56:29.184] - protocol_version : 11
[22:56:29.184] - package_size : 2 -> 8
[22:56:29.184] - crc_type : 1
[22:56:29.184] - skip_writeblock_tx : 0
[22:56:29.184] - compression : 11 -> 10
[22:56:29.184] - compression : 10
[22:56:29.184] - flags : 1
[22:56:29.184] - erase_sector_verify : 0
[22:56:29.185] - flash_debug : 0
[22:56:29.185] - protocol_crc : 0
[22:56:29.185] - skip_erase : 1 -> 0
[22:56:29.185] - skip_wr_pack_crc : 0
[22:56:29.185] - Sending capabilities
[22:56:29.194] - Receiving ACK
[22:56:29.208] - Received : ACK 0100
[22:56:29.208][CnfBaudChange] : 3250000
[22:56:29.208] - Sending BaudRate
[22:56:29.217] - Receiving ACK
[22:56:29.254] - Received BaudRate : 3250000
[22:56:29.254] - Changing BaudRate
[22:56:29.267] - Changed BaudRate : 3250000
[22:56:29.267][ReqFlashId]
[22:56:29.267] - Platform : 14
[22:56:29.267] - ProjectName : XMM6260
[22:56:29.267] - Sending HardWare Info
[22:56:29.276] - Receiving ACK
[22:56:29.358] - Received ACK : 0000
[22:56:29.358][ReqCfiInfo_1]
[22:56:29.358] - Sending CfiInfo1
[22:56:29.368] - Receiving CfiInfo2
[22:56:29.406] - Received CfiInfo2 : 256
[22:56:29.406][ReqCfiInfo_2]
[22:56:29.406] - Sending CfiInfo2
[22:56:29.415] - Receiving ACK
[22:56:29.429] - Received ACK : FFFF
[22:56:29.429][Downloading BOOT CORE PSI(0)] : psi.fls
[22:56:29.429][ReqSecStart]
[22:56:29.429] - BootCoreVersion : 131072
[22:56:29.429] - Sending Security Start
[22:56:29.444] - Receiving ACK
[22:56:29.529][ERROR] Type : 0041 <> 0204
[22:56:29.529] - IndErrorMsg
[22:56:29.542]File_id(34), Line_number(415), Error_class(1), Error_code(79)
[22:56:29.542]File_id(16), Line_number(617), Error_class(1), Error_code(10)
[22:56:29.542]File_id(0), Line_number(0), Error_class(0), Error_code(0)
[22:56:29.542]File_id(0), Line_number(0), Error_class(0), Error_code(0)
[22:56:29.542]File_id(0), Line_number(0), Error_class(0), Error_code(0)
[22:56:29.542]File_id(0), Line_number(0), Error_class(0), Error_code(0)
[22:56:29.542]File_id(0), Line_number(0), Error_class(0), Error_code(0)
[22:56:29.542]File_id(0), Line_number(0), Error_class(0), Error_code(0)
[22:56:29.542] - Failure!
[22:56:29.542]ERROR : _Func_03_Ebl_0_ReqSecStart - Line(300)
[22:56:29.543]__Proc_NormalDownload : 0
[22:56:29.543]Error! IntelFlash:__Proc_NormalDownload
[22:56:29.544]_DoDownload : 0
[22:56:29.544]
-----------------------------------------Trace Last 100 Message-------------------------------------------------
[22:56:29.169][T000015] 43 01 00 00 4C 00 00 00 88 13 00 00 15 19 7E C...L..........
[22:56:29.184][R000086] 43 00 00 00 4C 00 00 00 BB 00 00 00 14 00 00 00 15 00 00 00 58 4D 4D 36 32 36 30 5F 32 30 2E 32 C...L...............XMM6260_20.2
[22:56:29.184] - Boot-loader is active
[22:56:29.184] - EBL version: XMM6260_20.21_M1S1
[22:56:29.184] - Boot mode is: 00BB
[22:56:29.184] - EBL Running
[22:56:29.184][ReqSetProtConf]
[22:56:29.184] == prot_capabilities_t ==
[22:56:29.184] - protocol_version : 11
[22:56:29.184] - package_size : 2 -> 8
[22:56:29.184] - crc_type : 1
[22:56:29.184] - skip_writeblock_tx : 0
[22:56:29.184] - compression : 11 -> 10
[22:56:29.184] - compression : 10
[22:56:29.184] - flags : 1
[22:56:29.184] - erase_sector_verify : 0
[22:56:29.185] - flash_debug : 0
[22:56:29.185] - protocol_crc : 0
[22:56:29.185] - skip_erase : 1 -> 0
[22:56:29.185] - skip_wr_pack_crc : 0
[22:56:29.185] - Sending capabilities
[22:56:29.185][T000101] 44 00 00 00 56 00 00 00 20 4E 00 00 CE 88 7E 02 00 86 00 4C 00 BB 00 00 00 14 00 00 00 15 00 00 D...V....N.........L............
[22:56:29.194][R000010] 44 00 00 00 56 00 00 00 D0 6E D...V....n
[22:56:29.194] - Receiving ACK
[22:56:29.196][T000015] 43 01 00 00 0C 00 00 00 88 13 00 00 E4 7C 7E C............|.
[22:56:29.208][R000022] 43 00 00 00 0C 00 00 00 02 00 86 00 02 00 01 00 89 00 03 00 B5 2C C....................,
[22:56:29.208] - Received : ACK 0100
[22:56:29.208][CnfBaudChange] : 3250000
[22:56:29.208] - Sending BaudRate
[22:56:29.208][T000029] 44 00 00 00 0E 00 00 00 20 4E 00 00 FB 9B 7E 02 00 82 00 04 00 50 97 31 00 9E 01 03 00 D........N...........P.1.....
[22:56:29.217][R000010] 44 00 00 00 0E 00 00 00 1E 5E D........^
[22:56:29.217] - Receiving ACK
[22:56:29.218][T000015] 43 01 00 00 06 00 00 00 10 27 00 00 EF B4 7E C........'.....
[22:56:29.230][R000016] 43 00 00 00 06 00 00 00 02 00 82 00 04 00 C7 FA C...............
[22:56:29.230][T000015] 43 01 00 00 04 00 00 00 88 13 00 00 58 51 7E C...........XQ.
[22:56:29.242][R000014] 43 00 00 00 04 00 00 00 50 97 31 00 9E D9 C.......P.1...
[22:56:29.242][T000015] 43 01 00 00 04 00 00 00 10 27 00 00 80 BF 7E C........'.....
[22:56:29.254][R000014] 43 00 00 00 04 00 00 00 9E 01 03 00 B7 96 C.............
[22:56:29.254] - Received BaudRate : 3250000
[22:56:29.254] - Changing BaudRate
[22:56:29.254][T000011] 45 00 00 00 50 97 31 00 F3 0E 7E E...P.1....
[22:56:29.267][R000010] 45 00 00 00 50 97 31 00 F3 0E E...P.1...
[22:56:29.267] - Changed BaudRate : 3250000
[22:56:29.267][ReqFlashId]
[22:56:29.267] - Platform : 14
[22:56:29.267] - ProjectName : XMM6260
[22:56:29.267] - Sending HardWare Info
[22:56:29.267][T000197] 44 00 00 00 B6 00 00 00 20 4E 00 00 2D 90 7E 02 00 01 08 AC 00 0E 00 00 00 00 00 00 02 00 C2 01 D........N..-...................
[22:56:29.276][R000010] 44 00 00 00 B6 00 00 00 5A DA D.......Z.
[22:56:29.276] - Receiving ACK
[22:56:29.277][T000015] 43 01 00 00 0C 00 00 00 88 13 00 00 E4 7C 7E C............|.
[22:56:29.358][R000022] 43 00 00 00 0C 00 00 00 02 00 01 08 02 00 00 00 0B 00 03 00 4F 25 C...................O%
[22:56:29.358] - Received ACK : 0000
[22:56:29.358][ReqCfiInfo_1]
[22:56:29.358] - Sending CfiInfo1
[22:56:29.359][T000027] 44 00 00 00 0C 00 00 00 20 4E 00 00 94 90 7E 02 00 84 00 02 00 00 00 86 00 03 00 D........N.................
[22:56:29.368][R000010] 44 00 00 00 0C 00 00 00 68 67 D.......hg
[22:56:29.368] - Receiving CfiInfo2
[22:56:29.369][T000015] 43 01 00 00 06 00 00 00 10 27 00 00 EF B4 7E C........'.....
[22:56:29.381][R000016] 43 00 00 00 06 00 00 00 02 00 84 00 00 01 B4 C7 C...............
[22:56:29.381][T000015] 43 01 00 00 00 01 00 00 88 13 00 00 53 D8 7E C...........S..
[22:56:29.394][R000266] 43 00 00 00 00 01 00 00 00 00 00 00 AD 00 B1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C...............................
[22:56:29.394][T000015] 43 01 00 00 04 00 00 00 10 27 00 00 80 BF 7E C........'.....
[22:56:29.406][R000014] 43 00 00 00 04 00 00 00 E3 01 03 00 7D 47 C...........}G
[22:56:29.406] - Received CfiInfo2 : 256
[22:56:29.406][ReqCfiInfo_2]
[22:56:29.406] - Sending CfiInfo2
[22:56:29.406][T000281] 44 00 00 00 0A 01 00 00 20 4E 00 00 F0 12 7E 02 00 85 00 00 01 00 00 00 00 AD 00 B1 00 00 00 00 D........N......................
[22:56:29.415][R000010] 44 00 00 00 0A 01 00 00 2E 76 D........v
[22:56:29.415] - Receiving ACK
[22:56:29.417][T000015] 43 01 00 00 0C 00 00 00 88 13 00 00 E4 7C 7E C............|.
[22:56:29.429][R000022] 43 00 00 00 0C 00 00 00 02 00 85 00 02 00 FF FF 85 02 03 00 0B 76 C....................v
[22:56:29.429] - Received ACK : FFFF
[22:56:29.429][Downloading BOOT CORE PSI(0)] : psi.fls
[22:56:29.429][ReqSecStart]
[22:56:29.429] - BootCoreVersion : 131072
[22:56:29.429] - Sending Security Start
[22:56:29.429][T002073] 44 00 00 00 0A 08 00 00 20 4E 00 00 C9 53 7E 02 00 04 02 00 08 00 00 00 00 00 00 00 00 00 00 00 D........N...S..................
[22:56:29.444][R000010] 44 00 00 00 0A 08 00 00 30 EA D.......0.
[22:56:29.444] - Receiving ACK
[22:56:29.445][T000015] 43 01 00 00 0C 00 00 00 88 13 00 00 E4 7C 7E C............|.
[22:56:29.529][R000022] 43 00 00 00 0C 00 00 00 02 00 41 00 40 00 22 00 9F 01 01 00 19 1D [email protected]".......
[22:56:29.529][ERROR] Type : 0041 <> 0204
[22:56:29.529] - IndErrorMsg
[22:56:29.529][T000015] 43 01 00 00 3E 00 00 00 88 13 00 00 03 9A 7E C...>..........
[22:56:29.542][R000072] 43 00 00 00 3E 00 00 00 4F 00 10 00 69 02 01 00 0A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C...>...O...i...................
[22:56:29.542]File_id(34), Line_number(415), Error_class(1), Error_code(79)
[22:56:29.542]File_id(16), Line_number(617), Error_class(1), Error_code(10)
[22:56:29.542]File_id(0), Line_number(0), Error_class(0), Error_code(0)
[22:56:29.542]File_id(0), Line_number(0), Error_class(0), Error_code(0)
[22:56:29.542]File_id(0), Line_number(0), Error_class(0), Error_code(0)
[22:56:29.542]File_id(0), Line_number(0), Error_class(0), Error_code(0)
[22:56:29.542]File_id(0), Line_number(0), Error_class(0), Error_code(0)
[22:56:29.542]File_id(0), Line_number(0), Error_class(0), Error_code(0)
[22:56:29.542] - Failure!
[22:56:29.542]ERROR : _Func_03_Ebl_0_ReqSecStart - Line(300)
[22:56:29.543]__Proc_NormalDownload : 0
[22:56:29.543]Error! IntelFlash:__Proc_NormalDownload
[22:56:29.544]_DoDownload : 0
[22:56:29.544]
-----------------------------------------Trace Last 100 Message-------------------------------------------------
[22:56:29.547]
------------------------------------------Trace Last 100 Message-------------------------------------------------
[22:56:29.547] ErrorCode(210)
Anyone an idea on what the strange hex-ish lines are? they show up just after the first error. Maybe something is encrypted? I'll google error code 10, 79 and 210 in a minute.
I lost hope and I can't bother to try the last link I posted, maybe tomorrow
Any thoughts on the log?
EDIT:
Searching the errors in the log led me here:
http://forum.xda-developers.com/showthread.php?t=2287267
http://forum.xda-developers.com/showthread.php?t=2786001
http://forum.xda-developers.com/showthread.php?t=2737915
The last one is identical to my problem, my phone also couldn't read my SIM. Sadly no one ever solved the problem here.
I think these solutions are the last resort:
http://forum.xda-developers.com/showthread.php?t=1448803
http://forum.xda-developers.com/showthread.php?t=1861942
I will give these a try later today when I get home.
Hello again,
I've checked the threads you mentioned above, as well as I've been googling to another forums. Yet no success.
Every thread where P880 gets stuck at param:207, Failure:207 or the infamous 10%; have no final solutions.
I've tried LGFlash Tool, LGFlash Tool 2014, LGSupport Tool, SmartFlash, KDZ-Update, each one w/o success and stopping at the same point.
The last and only solution I haven't yet manage to do, is using the program LGNPST v_2.2.3
I have it installed, it does recognize my P880 only on the "Emergency" tab, and automatically recognize it on COM19.
To make the flash procedure it requires a DLL and a BIN or CAB firmware, which I do not possess (I've only found .kdz and .dz firmwares)
Also, as far as I've read, the .kdz files when decrypted become .dz which when decrypted become .fls & .bin files.
That is my last hope... nobody seem to have an answer. Wish we had an ODIN for LG.
alessocf said:
To make the flash procedure it requires a DLL and a BIN or CAB firmware, which I do not possess (I've only found .kdz and .dz firmwares)
Also, as far as I've read, the .kdz files when decrypted become .dz which when decrypted become .fls & .bin files.
Click to expand...
Click to collapse
I used this method to create a .cab or .dz from a .kdz for this attempt.
Do you have a guide for the LGNPST? I can only find this thread.
A zeroed MEID could also be (part of) the problem:
If you encounter problems during flashing, upgrading or downgrading you may fall victim to your MEID/ESN being zeroed out.
The usual cause is pulling your battery while stuck on the white LG Software Update screen.
Click to expand...
Click to collapse
Thats exacly how I got bricked.
Beunhof said:
I used this method to create a .cab or .dz from a .kdz for this attempt.
Click to expand...
Click to collapse
Gonna try with that method for a.cab to use in the LGNPST, thanks.
Also, I'll try using the P880.dll that is inside the KDZ-Update folder.
Beunhof said:
Do you have a guide for the LGNPST? I can only find this thread.
Click to expand...
Click to collapse
Sorry, I can't remember where I got it, but I uploaded it to my dropbox for you, here is the link:
https://dl.dropboxusercontent.com/u/52565427/LGNPST v2.2.3.rar
It contains a Readme.txt with the instructions, its quite easy, the program looks like a suite.
Gonna report later the status. Good luck to both of us, lol.
EDIT: STATUS:
- Made a .cab file and used the P880.dll contained on the kdz-update folder for the LGNPST, the program instantly said "Finish!" and obviously, did nothing.
I'm probably doing something wrong there... but I've ran out of ideas.
Exact Same Problem!
Hi.
Looking all over the internet, the XDA forum in particular, to find a solution to my issue with my 4xHD.
It seems that I have the exact same problem as you describe; SIM not being recognised (out of the blue), eventually decided to re-flash to fix the issue (last resort after trying everything else I could find). Followed all instructions word for word; drivers installed, etc... etc... but when flashing stopped on 210... (not fully explaining, but essentially the same place it stopped for you). Waited hours, nothing happened, so forced to unplug phone. Therefore stuck on S/W mode after a failed/partial flash.
I have also attempted to complete this via every method I can find on here, but stops at the 210/10% point (depending on software being used), every time!
I love this phone and need it back up and running. If you have any luck sorting yours please update and let me know how the issue was resolved. Similarly, let me know if you have had no further luck and if I make any progress I will update you.
Cheers!
aaron_gavin said:
Hi.
Looking all over the internet, the XDA forum in particular, to find a solution to my issue with my 4xHD.
It seems that I have the exact same problem as you describe; SIM not being recognised (out of the blue), eventually decided to re-flash to fix the issue (last resort after trying everything else I could find). Followed all instructions word for word; drivers installed, etc... etc... but when flashing stopped on 210... (not fully explaining, but essentially the same place it stopped for you). Waited hours, nothing happened, so forced to unplug phone. Therefore stuck on S/W mode after a failed/partial flash.
I have also attempted to complete this via every method I can find on here, but stops at the 210/10% point (depending on software being used), every time!
I love this phone and need it back up and running. If you have any luck sorting yours please update and let me know how the issue was resolved. Similarly, let me know if you have had no further luck and if I make any progress I will update you.
Cheers!
Click to expand...
Click to collapse
Someone managed to solve. Already tried and everything.
Sup
Hello,
there is no software solution (at least known to me) for fixing this issue.
I've searched and scavenged all over the internet for a solution or at least AN EXPLANATION on why it does get stuck no matter what at 10% or Param:207.
My last resort (I'm trying it this weekend, will post later if it worked) is
a method called JTAG, where they kinda force-fix the boot software of the device connecting directly to the cellphone MoBo (for more explanation look on youtube)
Well, thats it... if it works, cheers, otherwise I'm throwing my Optimus 4X on a drawer.
Till' later.
alessocf said:
Hello,
there is no software solution (at least known to me) for fixing this issue.
I've searched and scavenged all over the internet for a solution or at least AN EXPLANATION on why it does get stuck no matter what at 10% or Param:207.
My last resort (I'm trying it this weekend, will post later if it worked) is
a method called JTAG, where they kinda force-fix the boot software of the device connecting directly to the cellphone MoBo (for more explanation look on youtube)
Well, thats it... if it works, cheers, otherwise I'm throwing my Optimus 4X on a drawer.
Till' later.
Click to expand...
Click to collapse
I will research this 'force-fix' and see if i can make any progress when i get some time off work. please update how you get on with this iff/when you try!
im feeling the same way with the phone; getting close to giving up, having tried all the software solutions word for word as described in the forums to fix it.
its strange that on all the guides when people have had similar problems as we are facing the response is usually to remove drivers+software and try again/follow the guide properly (not that im saying that a simple human error is not at fault the majority of the time). but i have not seen any posts were people have accepted that all methods have been attempted correctly and advice given regarding possible hardware faults and/or this 'force-fix' you mention.
if i am not able to fix myself i think i will consider posting a plea for someone more competent with this kind of stuff to have my phone posted to them in order to try and fix it for me. im sure that someone who is really into this kind of thing would like to have a go out of general interest, and the worst case scenario would be that i dont get my phone back (which is no use to me in its current state anyway).
cheers!
---------- Post added at 11:43 AM ---------- Previous post was at 11:22 AM ----------
aaron_gavin said:
I will research this 'force-fix' and see if i can make any progress when i get some time off work. please update how you get on with this iff/when you try!
im feeling the same way with the phone; getting close to giving up, having tried all the software solutions word for word as described in the forums to fix it.
its strange that on all the guides when people have had similar problems as we are facing the response is usually to remove drivers+software and try again/follow the guide properly (not that im saying that a simple human error is not at fault the majority of the time). but i have not seen any posts were people have accepted that all methods have been attempted correctly and advice given regarding possible hardware faults and/or this 'force-fix' you mention.
if i am not able to fix myself i think i will consider posting a plea for someone more competent with this kind of stuff to have my phone posted to them in order to try and fix it for me. im sure that someone who is really into this kind of thing would like to have a go out of general interest, and the worst case scenario would be that i dont get my phone back (which is no use to me in its current state anyway).
cheers!
Click to expand...
Click to collapse
UPDATE:
had a look at this JTAG repair method (also found a youtube video of some company touting for work, showing repair of a 4x hd - http://www.youtube.com/watch?v=5NRXhJxbtYY).
im not sure that i would want to go down that route, as they explain that it delves further into the phones software to fix issues caused by people bricking due to messing about to much after gaining root access. but i dont feel that this is the reason for the issues with my phone; had it set-up how i liked it for ages (without any real messing about after root), the issue with nonrecognition of my SIM came completely out of the blue (i attempted to re-flash to fix this; causing the stuck in s/w mode issue i now have, but the issue could quite easily be due to failing hardware as it could be an issue with the software).
in the case that it is damaged/failing hardware at fault JTAG would not be able to repair the phone, and even if it got my firmware back up and running there is no guarantee that it would recognise my SIM when i got it back.
so im not sure that i would be happy either paying someone to perform this 'fix' on my phone or paying for the hardware to attempt to fix myself, if its possible that the phone may still not work afterwards due to broken hardware. especially when you can buy a working model of our phone from places like ebay for under £100.
any thoughts or advice?
any luck/updates?
i think that i may just call it a day trying to fix this thing.
from what i have read it may be possible to fix the bootloader, thus allow to boot into recovery/fastboot/adb (hence not remaining stuck in an unflashable s/w update mode) in order to fix the phone, by using nvflash/apx mode. but it does not seem that our phones allow us access to do this.
have you had any luck with your mentioned jtag fix or otherwise?
had to get a new phone anyway (as was fed up using my old phone while trying to fix my 4x hd) - got a moto g 4g. am pretty chuffed with it for the price (enjoying screen mirroring through a miracast dongle and kitkat, etc...), but to be honest would go back to using my 4x hd if someone was able to find a fix.
any response/update would be appreciated, and if anyone thinks they can fix this issue please let me know.
cheers!
It's been a while!
Hey!
Long time since we had this issure with our 4X HD's, in fact almost a year since I had touched mine.
Was clearing out a drawer and found the brick. Which made me think, did anyone actually succeed in fixing their phone/solve this issue?
If so, I may have a bash just for the hell of it. If not, I think it's time for the bin.
:silly:
Whats Up
aaron_gavin said:
Hey!
Long time since we had this issure with our 4X HD's, in fact almost a year since I had touched mine.
Was clearing out a drawer and found the brick. Which made me think, did anyone actually succeed in fixing their phone/solve this issue?
If so, I may have a bash just for the hell of it. If not, I think it's time for the bin.
:silly:
Click to expand...
Click to collapse
Same here, didn't tried much since my last update. JTAG didn't work "cause Tegra based devices don't support it" or something like that.
Also tried with a homemade USB Jig Method, nothing happened.
My X4 is in my desktop, I use it mostly as a luxury paper holder.
Bless !.
alessocf said:
Same here, didn't tried much since my last update. JTAG didn't work "cause Tegra based devices don't support it" or something like that.
Also tried with a homemade USB Jig Method, nothing happened.
My X4 is in my desktop, I use it mostly as a luxury paper holder.
Bless !.
Click to expand...
Click to collapse
Guys, we may have a working solution: http://forum.xda-developers.com/optimus-4x-hd/general/maybe-nvflash-method-t3159853
I am currently testing it right now and until now it seems to work.
Update: It worked! My phone is booting again. Now i need to fix the IMEI and I am good.
Code:
C:\LG\\nvflash>nvflash --blob blob.bin --bct flash.bct.encrypt --setbct --configfile flash_encrypt.cfg --create --bl bootloader.bin.encrypt --go
Nvflash v1.7.75664 started
Using blob v1.1.57813ngs\Adm
rcm version 0X30001
System Information:
chip name: unknown
chip id: 0x30 major: 1 minor: 3
chip sku: 0x81
chip uid: 0x015d441469040a07
macrovision: disabled
hdcp: enabled
sbk burned: true
dk burned: true
boot device: emmc
operating mode: 4
device config strap: 0
device config fuse: 17
sdram config strap: 0
sending file: flash.bct.encrypt
- 6128/6128 bytes sent
flash.bct.encrypt sent successfully
downloading bootloader -- load address: 0x80108000 entry point: 0x80108000
sending file: bootloader.bin.encrypt
\ 1142880/1142880 bytes sent
bootloader.bin.encrypt sent successfully
waiting for bootloader to initialize
bootloader downloaded successfully
setting device: 2 3
creating partition: BCT
creating partition: PT
creating partition: EBT
creating partition: LGE
creating partition: EKS
creating partition: GP1
creating partition: SOS
creating partition: LNX
creating partition: APP
creating partition: CAC
creating partition: MSC
creating partition: USP
creating partition: NVA
creating partition: UDA
creating partition: DRM
creating partition: MLT
creating partition: FOT
creating partition: CAL
creating partition: UDB
creating partition: GPT
Formatting partition 2 BCT please wait.. done!
Formatting partition 3 PT please wait.. done!
Formatting partition 4 EBT please wait.. done!
Formatting partition 5 LGE please wait.. done!
Formatting partition 6 EKS please wait.. done!
Formatting partition 7 GP1 please wait.. done!
Formatting partition 8 SOS please wait.. done!
Formatting partition 9 LNX please wait.. done!
Formatting partition 10 APP please wait.. done!
Formatting partition 11 CAC please wait.. done!
Formatting partition 12 MSC please wait.. done!
Formatting partition 13 USP please wait.. done!
Formatting partition 14 NVA please wait.. done!
Formatting partition 15 UDA please wait.. done!
Formatting partition 16 DRM please wait.. done!
Formatting partition 17 MLT please wait.. done!
Formatting partition 18 FOT please wait.. done!
Formatting partition 19 CAL please wait.. done!
Formatting partition 20 UDB please wait.. done!
Formatting partition 21 GPT please wait.. done!
done!
sending file: bootloader.bin.encrypt
\ 1142880/1142880 bytes sent
bootloader.bin.encrypt sent successfully
sending file: eks.dat
- 684/684 bytes sent
eks.dat sent successfully
sending file: recovery.img
/ 7577600/7577600 bytes sent
recovery.img sent successfully
sending file: boot.img
/ 6496256/6496256 bytes sent
boot.img sent successfully
sending file: system.img
- 687920496/687920496 bytes sent
system.img sent successfully
GoodSoul said:
Guys, we may have a working solution: http://forum.xda-developers.com/optimus-4x-hd/general/maybe-nvflash-method-t3159853
I am currently testing it right now and until now it seems to work.
Update: It worked! My phone is booting again. Now i need to fix the IMEI and I am good.
[/code]
Click to expand...
Click to collapse
Greetings :fingers-crossed:, love to hear some good news and that it worked out for you.
I'm currently downloading the software and reading on how to use it, i'll be updating on how does it go for me.
Thank you for sharing this info with us.:highfive:
UPDATE: I T - W O R K E D !, after doing the process it automatically restarted and the LG Boot Logo reanimated, and started just as factory reset.
I had some issues installing the NvidiaUsb.inf, because I'm running on Windows 10 AMD x64 bits.
Steps I followed (in case someone needs them):
1) I had to open Command Prompt using the command: shutdown /r /o /f /t 00
THIS WILL RESTART YOUR COMPUTER
2)Then go through the options: Troubleshoot > Advanced Options > and look to "Disable Driver Signature Enforcement" using F7 key.
This allowed my W10 to Install the NVIDIA USB Boot-recovery driver for Mobile devices, which later allowed me to run NvFlash succesfully.
Current Status: LG P880 Boots and Runs!, doesn't have Baseband Version or IMEI, but this is something easier to fix.
Mostly appreciated.
UPDATE: I T - W O R K E D !, after doing the process it automatically restarted and the LG Boot Logo reanimated, and started just as factory reset.
Click to expand...
Click to collapse
Yippie!
Current Status: LG P880 Boots and Runs!, doesn't have Baseband Version or IMEI, but this is something easier to fix.
Click to expand...
Click to collapse
If you know how please let me know. I tried for serveral hours to fix that problem but had no luck yet.
Mostly appreciated.
Click to expand...
Click to collapse
You are welcome.
While playing with AFTV2 tools quite a bit, I thought it'd be convenient to have some way to identify what bootloader version one has (given bricking implications & all). Doing checksums on the full TEE1 & UBOOT partitions is not very useful, because the empty area in the partitions may have junk, and that would impact the checksum. So something slightly different is needed.
Here is what I propose, one can read the first few bytes of TEE1 & UBOOT partitions, and then look at them with a hex editor. Fairly low tech, but there you go ... Unfortunately, "hexdump" is not present by default on Fire, so a few more manipulations are required. First, run this with adb (can also be read with AFTV2 tools):
Code:
adb shell
su
mkdir /sdcard/tmp/
dd if=/dev/block/mmcblk0p4 of=/sdcard/tmp/04_uboot.img
dd if=/dev/block/mmcblk0p9 of=/sdcard/tmp/09_tee1.img
cd /sdcard/tmp
md5 *.img
exit
exit
adb pull /sdcard/tmp
Then, with a hex editor (such as Frhed), look at the first few bytes of these images on your PC. On linux it's even easier, just do "cat -c 8 *.img | hexdump". You should see something like the following:
Code:
04_uboot.img: UBOOT: 88 16 88 58 [COLOR="Red"]b4 33 06 00[/COLOR] 4c 4b 00 00 "LK"
09_tee1.img: TEE1: 88 16 88 58 [COLOR="Red"]00 3c 10 00[/COLOR] 54 45 45 00 "TEE"
The 4 bytes in red are key to identify the version. Please see the table below for the data I've compiled so far. Let's add to it as more versions become available/known (if your combination is not listed, please post here):
Code:
UBOOT
d8 27 06 00 Unreleased, 5.0.0, (Build date Saturday, August 1, 2015, 10:39 PM GMT)
b4 33 06 00 5.2.2_053820 5.0.1
54 3f 06 00 5.2.2_055120 5.0.1
e4 3b 06 00 5.4.1_112720 5.1.1
38 34 06 00 5.4.2_168620 5.1.2
78 34 06 00 5.4.4_271020 5.1.4
b8 3c 06 00 5.5.2_153420 5.3.1.0
TEE1
00 3c 10 00 Unreleased, 5.0.0, (Build date Saturday, August 1, 2015, 10:39 PM GMT)
00 3c 10 00 5.2.2_053820 5.0.1
00 3c 10 00 5.2.2_055120 5.0.1
00 3c 10 00 5.4.1_112720 5.1.1
00 3c 10 00 5.4.2_168620 5.1.2
00 3c 10 00 5.4.4_271020 5.1.4
90 84 11 00 5.5.2_153420 5.3.1.0
@DoLooper, @kirito9, @sd_shadow, @Kramar111, @zeroepoch, @hwmod, @Tomsgt
unknown 5.0.1
Code:
UBOOT
54 3f 06 00 5.2.2_055120 5.0.1
TEE1
00 3c 10 00 5.2.2_055120 5.0.1
Fire originally with 5.1.3 - downgraded to 5.1.2 . uboot and tee1 are consistent with 5.1.2 .
fmc000 said:
Fire originally with 5.1.3 - downgraded to 5.1.2 . uboot and tee1 are consistent with 5.1.2 .
Click to expand...
Click to collapse
Indeed, when you downgraded, the bootloaders got overwritten and so you see 5.1.2 ! But luckily, this combination does not brick.
fmc000 said:
Fire originally with 5.1.3 - downgraded to 5.1.2 . uboot and tee1 are consistent with 5.1.2 .
Click to expand...
Click to collapse
bibikalka said:
Indeed, when you downgraded, the bootloaders got overwritten and so you see 5.1.2 ! But luckily, this combination does not brick.
Click to expand...
Click to collapse
Hence the 'special' procedure for upgrading FireOS while leaving the current bootloader intact. A standard sideload/OTA update refreshes bootloader, kernel, rom, etc.
Davey126 said:
Hence the 'special' procedure for upgrading FireOS while leaving the current bootloader intact.
Click to expand...
Click to collapse
In a strict sense, the procedure doesn't leave the bootloader intact - it first writes the newer version (which is part of the stock ROM) to later replace it back with the original one. And this "later" may be crucial - if in-between something bad happens (bad battery level, bad cable, power outage on the PC side), game over.
What's the ratio of successful vs. bricking here?
Unfortunately, nobody seems to have followed the path @Vlasp had suggested a year ago: to trim down stock ROMs to explicitly exclude bootloader files and install instructions (and possibly add su, and disable ota and ads). I understand that with FF we're no longer limited to signed ROMs, so this should be feasible, and scriptable for future ROM versions, no? (If I could extend days to 36 hours...)
steve8x8 said:
In a strict sense, the procedure doesn't leave the bootloader intact - it first writes the newer version (which is part of the stock ROM) to later replace it back with the original one. And this "later" may be crucial - if in-between something bad happens (bad battery level, bad cable, power outage on the PC side), game over.
Click to expand...
Click to collapse
True. Didn't expect a literal interpretation but appreciate the clarification and associated cautions for others.
steve8x8 said:
Unfortunately, nobody seems to have followed the path @Vlasp had suggested a year ago: to trim down stock ROMs to explicitly exclude bootloader files and install instructions (and possibly add su, and disable ota and ads).
Click to expand...
Click to collapse
This has been done for other Amazon devices (eg: 3rd gen HDX) but garnished little user interest as an alternative to custom ROMs. The misunderstanding/misuse of custom stock builds actually created bigger headaches and a few unfortunate bricks. Eventually the images stopped being maintained.
steve8x8 said:
If I could extend days to 36 hours...
Click to expand...
Click to collapse
Still searching for those elusive hours! . Same can be said for developers who struggle to maintain what is already out there. Witness the cracks in several custom ROMs that have not seen recent updates.
Great and easy way to identify bootloader version. Disappointed to find that I was on 5.3.1 bootloader, but at least I know now
Quick update (although useless since reading off the timestamps would require root which isn't available yet for 5.3.2.1 and higher - that's why I won't merge this into the checker tool yet):
Code:
fireOS-5.0.0/images/preloader.img: 20150728-232738
fireOS-5.0.1/images/preloader_prod.img: 20150730-164940
fireOS-5.1.1/images/preloader_prod.img: 20150923-180133
fireOS-5.0.1/images/preloader.img: 20150930-051243
fireOS-5.1.1/images/preloader.img: 20151202-052945
fireOS-5.1.2/images/preloader_prod.img: 20160120-094719
fireOS-5.1.4/images/preloader_prod.img: 20160217-183554
fireOS-5.1.2/images/preloader.img: 20160227-021828
fireOS-5.1.4/images/preloader.img: 20160506-045524
fireOS-5.3.1.0/images/preloader_prod.img: 20160603-023745
fireOS-5.3.2.0/images/preloader_prod.img: 20160603-023745
fireOS-5.3.1.0/images/preloader.img: 20160624-191357
fireOS-5.3.2.1/images/preloader_prod.img: 20161102-031807
fireOS-5.3.2.0/images/preloader.img: 20161104-214024
fireOS-5.3.2.1/images/preloader.img: 20161201-113631
fireOS-5.3.3.0/images/preloader_prod.img: 20170116-085533
fireOS-5.3.3.0/images/preloader.img: 20170328-012523
---------- Post added at 01:58 PM ---------- Previous post was at 01:11 PM ----------
Um, by the way, there had been reports that 5.1.3 had been rooted without downgrading to 5.1.2, if I remember correctly.
If that's your last FireOS version, may I ask you to run the bootloader tool and report back the result? Same for 5.1.2.1... Thanks
After an adventure in updating to 5.3.3.0 I have :
uboot : b0 99 0e 00
tee : not recognisable
The tablet boots, I can reload TWRP if needed but if I flash the previous bootloader I had 541 it bricks and I have to recover using the linux ISO. It looks like my tee1 partition is corrupted. Any advice on how to proceed would be good ! Thanks.
jpearn said:
After an adventure in updating to 5.3.3.0 I have :
uboot : b0 99 0e 00
tee : not recognisable
The tablet boots, I can reload TWRP if needed but if I flash the previous bootloader I had 541 it bricks and I have to recover using the linux ISO. It looks like my tee1 partition is corrupted. Any advice on how to proceed would be good ! Thanks.
Click to expand...
Click to collapse
Reflash the partition with DD?
Download the firmware update, rename it to *.zip from *.bin, and there should be something called TEE.img or something similar. Then push it to the device with "adb push /path/to/TEE.img /sdcard" Then, on the tablet or in adb shell, run 'dd if=/sdcard/TEE.img of=/dev/block/mmcblk0p9'
PorygonZRocks said:
Reflash the partition with DD?
Download the firmware update, rename it to *.zip from *.bin, and there should be something called TEE.img or something similar. Then push it to the device with "adb push /path/to/TEE.img /sdcard" Then, on the tablet or in adb shell, run 'dd if=/sdcard/TEE.img of=/dev/block/mmcblk0p9'
Click to expand...
Click to collapse
I thought this however I noted in the other gapps / root thread that it should be dd if=453_tee1.img of=/dev/block/mmcblk0p3
I'm on Ariel Fire 7 4th, so I guess the partitions are different ?
jpearn said:
I thought this however I noted in the other gapps / root thread that it should be dd if=453_tee1.img of=/dev/block/mmcblk0p3
I'm on Ariel Fire 7 4th, so I guess the partitions are different ?
Click to expand...
Click to collapse
Yes, they would be different. Make sure to use a TEE from the correct device, not one from this model.
jpearn said:
After an adventure in updating to 5.3.3.0 I have :
uboot : b0 99 0e 00
tee : not recognisable
The tablet boots, I can reload TWRP if needed but if I flash the previous bootloader I had 541 it bricks and I have to recover using the linux ISO. It looks like my tee1 partition is corrupted. Any advice on how to proceed would be good ! Thanks.
Click to expand...
Click to collapse
This thread pertains to the 5th gen Fire 7 (Ford) not the 4th gen HD 7 (Ariel).
Identifying the bootloader version is one thing, being able to decide whether a downgrade would result in a brick is another...
Is there a way, on a Fire 7 (5th), to extract the anti-r* "stepping numbers" from bootloader files/partitions that get compared with entries in RPMB (which is only accessible by the bootloader, but not the kernel)? This might save a lot of guesswork and bricks.
In lk.bin, there's "androidboot.rpmb_state=%d" right next to "androidboot.unlocked_kernel=true" and "androidboot.unlocked_kernel=false". Access seems to happen via device numbers.
OTOH, preloader_prod.img contains strings like "[RPMB] Invalid magic, re-creating..." and "[RPMB] RPMB provisioning disabled" or even a message about a skipped, invalid anti-r* state.
Too bad it seems to be impossible to watch the device boot at such an early stage. Half a MB of ARM code is not what I'd want to trace manually... extracting the preloader from its MTK wrapper seems to be the easiest part...
steve8x8 said:
Too bad it seems to be impossible to watch the device boot at such an early stage.
Click to expand...
Click to collapse
https://forum.xda-developers.com/am...bootloader-unlock-ideas-t3289721/post65585385 and some previous/next post
Thanks for the pointer to one of the missing links! Being able to track the messages down might limit the amount of machine code to be parsed...
uboot - 88 16 88 58 B8 3C 06 00 4C 4B 00 00 00 00 00
tee1 - 88 16 88 58 90 84 11 00 54 45 45 00 00 00 00
5.3.1, lol. whats a good rom for this amazon fire 5th gen?
2WR3505 said:
uboot - 88 16 88 58 B8 3C 06 00 4C 4B 00 00 00 00 00
tee1 - 88 16 88 58 90 84 11 00 54 45 45 00 00 00 00
5.3.1, lol. whats a good rom for this amazon fire 5th gen?
Click to expand...
Click to collapse
[ROM][AOSP] Fire Nexus ROM - LMY49M [22 JULY 2017] - XDA Developers
https://forum.xda-developers.com/amazon-fire/orig-development/rom-fire-nexus-rom-lmy49f-t3300714
[ROM] Lineage-12.1 [12 SEP 2017] - XDA Developers
https://forum.xda-developers.com/amazon-fire/orig-development/rom-lineage-12-1-t3639447
Thanks, i went with the nexus rom, it runs nicely
Ok so transferring large videos to my windows 10 machine over usb3 and over wifi (phone is connected at 866mbps pc is on gigabit ether net) either way the transfer rate was only about 10-12MB/s. This can't be the max the phone storage runs at right? What is slowing this down? I was thinking more along the lines of 30+MB/s and I'd be happy lol, my galaxy s5 can swing that. Transfer is from internal storage on phone, I don't have a SD card in it. USB is done with drag and drop, phone in MTP mode, wifi is done with es file explorer using a basic smb connection I'm pretty sure.
Someone wanna check and see what they get?
I have the Samsung T5 and transferred roughly 60GB of data to my S10+ in about 15 minutes. My PC (Windows 10 with a SSD installed) also transferred data to my phone at roughly the same speeds. I got on average about 250MB/s. A bunch of small files actually slowed down the transfer for me, but large files sped up the transfer. I don't think it matters that my phone was transferring to/from SSD's but it's good to give all the details because it's not impossible that it could not be the issue.
That's a good point I tried to give as much detail as possible. But yeah I was transferring to a raid0 of Samsung 840ssd's so the pc hard drive wasn't the limiting factor. Was also using the USB cord that came with the phone. I wonder what's going on.
skydeaner said:
That's a good point I tried to give as much detail as possible. But yeah I was transferring to a raid0 of Samsung 960ssd's so the pc hard drive wasn't the limiting factor. Was also using the USB cord that came with the phone. I wonder what's going on.
Click to expand...
Click to collapse
Is yours NVME? If so you'd be the 2nd person on the forums that seems to have issues with transfer speeds...
No but I don't see that being too relevant but who knows. The system is a few generations old Asus sabertooth z87, i7 4770k[email protected], 16gb of 2400mhz ddr3, the aforementioned raid 0 with Samsung 840 evo ssds and a 4tb wd blue label for storage.
Since reading previously I also tried transferring to the 4tb magnetic drive with the same results. And the same transfer speed over wifi has me really thinking it is something with the phone. The test transfer files are 1gb episodes of a TV show x264 compression format, 30 of them.
I will probably be transferring such items often enough I need to get this fixed darn it.
I can transfer stuff from a ****ty SanDisk usb3 jump drive (years old) to the pc at over 50MB/s
Well I messed around on the pc and apparently it won't connect at usb3. Says it is usb3 and superspeed capable but won't negotiate to it for some reason. My jump drive has no problem with it so it's not the port. Maybe Samsung sends a ****ty cord but I don't have another to test with. Going to my amd machine and trying it there, maybe it's an Intel driver problem. But then again, it not going any faster over wifi... This is escalating quickly lol
Meh, same transfer speeds on the amd system, no hub, direct to motherboard usb3 ss labeled blue ports. I don't even want to take the time grabbing the debug info, I'm sure it is the same usb2 fast mode not usb3 ss.
Tried removing and deleting samsung drivers, installing proprietary samsung usb drivers from their development site and connecting phone again, same thing, here is the usb info
=========================== USB Port2 ===========================
Connection Status : 0x01 (Device is connected)
Port Chain : 3-2
Properties : 0x01
IsUserConnectable : yes
PortIsDebugCapable : no
PortHasMultiCompanions : no
PortConnectorIsTypeC : no
ConnectionIndex : 2
CompanionIndex : 0
CompanionHubSymLnk : USB#ROOT_HUB30#4&1ed8c4ae&0&0#{f18a0e88-c30c-11d0-8815-00a0c906bed8}
CompanionPortNumber : 17
======================== USB Device ========================
+++++++++++++++++ Device Information ++++++++++++++++++
Device Description : SAMSUNG Mobile USB Composite Device
Device Path : \\?\usb#vid_04e8&pid_6860#r58m236x6hx#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
Device ID : USB\VID_04E8&PID_6860\R58M236X6HX
Hardware IDs : USB\VID_04E8&PID_6860&REV_0400 USB\VID_04E8&PID_6860
Driver KeyName : {36fc9e60-c465-11cf-8056-444553540000}\0010 (GUID_DEVCLASS_USB)
Driver : \SystemRoot\system32\DRIVERS\ssudbus.sys (Version: 2.11.11.0 Date: 2014-12-02)
Driver Inf : C:\WINDOWS\inf\oem56.inf
Legacy BusType : PNPBus
Class : USB
Class GUID : {36fc9e60-c465-11cf-8056-444553540000} (GUID_DEVCLASS_USB)
Interface GUID : {a5dcbf10-6530-11d2-901f-00c04fb951ed} (GUID_DEVINTERFACE_USB_DEVICE)
Service : dg_ssudbus
Enumerator : USB
Location Info : Port_#0002.Hub_#0003
Location IDs : PCIROOT(0)#PCI(1400)#USBROOT(0)#USB(2), ACPI(_SB_)#ACPI(PCI0)#ACPI(XHC_)#ACPI(RHUB)#ACPI(HS02)
Container ID : {4f888293-db1a-5203-8af9-13e37d32f8f3}
Manufacturer Info : SAMSUNG Electronics Co., Ltd.
Capabilities : 0x94 (Removable, UniqueID, SurpriseRemovalOK)
Status : 0x0180600A (DN_DRIVER_LOADED, DN_STARTED, DN_DISABLEABLE, DN_REMOVABLE, DN_NT_ENUMERATOR, DN_NT_DRIVER)
Problem Code : 0
Address : 2
Power State : D0 (supported: D0, D3, wake from D0)
Child Device 1 : Galaxy S10e (SM-G970U)
DevicePath : \\?\usb#vid_04e8&pid_6860&ms_comp_mtp&samsung_android#6&1bf836f8&2&0000#{6ac27878-a6fa-4155-ba85-f98f491d4f33}
KernelName : \Device\000000f3
Device ID : USB\VID_04E8&PID_6860&MS_COMP_MTP&SAMSUNG_ANDROID\6&1BF836F8&2&0000
Class : WPD
Child Device 2 : SAMSUNG Mobile USB Modem
DevicePath : \\?\usb#vid_04e8&pid_6860&modem#6&1bf836f8&2&0001#{2c7089aa-2e0e-11d1-b114-00c04fc2aae4}
KernelName : \Device\000000f4
Device ID : USB\VID_04E8&PID_6860&MODEM\6&1BF836F8&2&0001
Class : Modem
COM-Port : COM3 (\Device\ssudmdm0000)
+++++++++++++++++ Registry USB Flags +++++++++++++++++
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\UsbFlags\04E868600400
osvc : REG_BINARY 01 01
SkipContainerIdQuery : REG_BINARY 01 00
---------------- Connection Information ---------------
Connection Index : 0x02 (2)
Connection Status : 0x01 (DeviceConnected)
Current Config Value : 0x02
Device Address : 0x1C (28)
Is Hub : 0x00 (no)
Number Of Open Pipes : 0x06 (6)
Device Bus Speed : 0x02 (High-Speed)
Pipe0ScheduleOffset : 0x00 (0)
Pipe1ScheduleOffset : 0x00 (0)
Pipe2ScheduleOffset : 0x00 (0)
Pipe3ScheduleOffset : 0x00 (0)
Pipe4ScheduleOffset : 0x00 (0)
Pipe5ScheduleOffset : 0x00 (0)
Data (HexDump) : 02 00 00 00 12 01 10 02 00 00 00 40 E8 04 60 68 [email protected]`h
00 04 07 08 09 02 02 02 00 1C 00 06 00 00 00 01 ................
00 00 00 07 05 81 02 00 02 00 00 00 00 00 07 05 ................
01 02 00 02 01 00 00 00 00 07 05 82 03 1C 00 06 ................
00 00 00 00 07 05 84 03 0A 00 09 00 00 00 00 07 ................
05 83 02 00 02 00 00 00 00 00 07 05 02 02 00 02 ................
00 00 00 00 00 .....
--------------- Connection Information V2 -------------
Connection Index : 0x02 (2)
Length : 0x10 (16 bytes)
SupportedUsbProtocols : 0x03
Usb110 : 1 (yes)
Usb200 : 1 (yes)
Usb300 : 0 (no)
ReservedMBZ : 0x00
Flags : 0x02
DevIsOpAtSsOrHigher : 0 (Is not operating at SuperSpeed or higher)
DevIsSsCapOrHigher : 1 (Is SuperSpeed capable or higher)
DevIsOpAtSsPlusOrHigher : 0 (Is not operating at SuperSpeedPlus or higher)
DevIsSsPlusCapOrHigher : 0 (Is not SuperSpeedPlus capable or higher)
ReservedMBZ : 0x00
Data (HexDump) : 02 00 00 00 10 00 00 00 03 00 00 00 02 00 00 00 ................
This usb stuff is all very interesting and I'd like to get i fixed, but it still doesn't explain why the slow transfer over wifi either. Weird.
::rollseyes::
Possibly the OEM cable. I have the cable from Samsung's T5, can't remember if I used that or not. The WiFi though, that I'm unsure of because I never transfer data that way.
The cable supplied in the box with the phone is usb 2.0, I think you need to try with an usb 3.0 capable cable.