Related
Hi,
I intend to flash a cooked ROM (ITsPapa20748) to my Herald. From reading some sticky posts here I learned that at first I have to install a hacked bootloader - so I downloaded HardSpl_WM6.rar
My procedure was as follows:
1. install canonyang, ASerg_Policies and Disable_Security (in this order)
2. softreset
3. start RUU
My mobile then enters bootloader mode and ends up with error message "Error [270]: Update Error" (progress bar freezes at 3pct)
My config is as follows:
PC: is running WindowsXP (with SP2), ActiveSync v4.5 is in Guest Mode
Mobile: Model-Nr. Hera100
ROM version 4.17.402.102 GER
IPL 4.17.0001
SPL 4.17.0000
I had to UNcheck the start/system/advanced_networking-box in order to establish USB-connection.
After spending some hours going through existing threads I'm pretty sure that this is a common situation. But I didn't find any hint that helped me to flash successfully.
So any comments and suggestions are welcome.
thx!
1aladdin1
it works now
sorry for posting too early - now it worked.
I basically performed the same steps as listed in my previous post. Two differences:
1. softreset between installation of canonyang/aserpolicy/disable_security
2. while performing the RUU I had FILEMON running (a great tool from mark russinovich)
Finally I don't know, which step was the decisive one - bot anyhow it works now.
Hope this helps other guys in a similar situation.
please guys help me
my htc touch p3452 is dead becoz i flash but something is wrong and then it was dead now it will on on bootloder mode(red,green,blue) here is my detail please tell ,me what to do
it show..
IPL 3.07.0002
SPL 3.07.0000
DEVICE ID= ELF010050
CID= DOPOD001
45 4C 46 30 31 30 30 35 30 00 00 00 00 00 00 00 ELF010050.......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
44 4F 50 4F 44 30 30 31 00 00 00 00 00 00 00 00 DOPOD001........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..............
i also tryed to flash "DID-ELF010050_CID-DOPOD001_ROM-2.20.721.2B" but is not flashed it gave "error 270 update error" something please tell me where is the problem and how to solve please guys
Wwwwwweeeellllllll....YOU HAVE AN ELF, NOT A HERALD. Seriously, if you tried to HardSPL your Elf with the Herald HardSPL...I don't even know. These are the Herald forums, NOT the Elf forums, as such, more than likely no one that frequents here will know what to do to help you.
When looking at RUU_signed.nbh extracted out of RUU_BlackStone_HTC_WWE_EastEurope_1.14.479.3_Radio_52.49a.25.26_1.09.25.14_Ship
I find at
00 00 00 00 40h BLAC10000
00 00 00 1e 0hh HTC__032
00 00 00 20 00h 1.14.479.3
00 00 00 21 10h USA
It looks like the ModelID, CID, Rom Version and the Country code.
How can I find out what those values are of my device so that I can match a shipped rom with it ??
Model ID should be under the battery.
Have you tried using ATCommander to query the CID with the:
[email protected]? command?
Ta
Dave
MDAIIIUser said:
When looking at RUU_signed.nbh extracted out of RUU_BlackStone_HTC_WWE_EastEurope_1.14.479.3_Radio_52.49a.25.26_1.09.25.14_Ship
I find at
00 00 00 00 40h BLAC10000
00 00 00 1e 0hh HTC__032
00 00 00 20 00h 1.14.479.3
00 00 00 21 10h USA
It looks like the ModelID, CID, Rom Version and the Country code.
How can I find out what those values are of my device so that I can match a shipped rom with it ??
Click to expand...
Click to collapse
could perhaps help cmonex, when she has gained enough...
DaveShaw said:
Model ID should be under the battery.
Have you tried using ATCommander to query the CID with the:
[email protected]? command?
Ta
Dave
Click to expand...
Click to collapse
No I did the old approach based on the blueangel.
Here flashing software gave you a getdevicedata.exe so I had a look at an extracted HD_ship.exe and found RUUGetInfo.exe.
So I put it on my device, ran it and sorted my windows dir by date.
I found:
RUUImei.txt ---- > contains the IMEI of my device
RUUInfo.txt-----> Gives me the same info the rom version under Divice info
here is how
gd day
here is how
put your phone into boot loader model by pressing power and volume down till 3 color s screen comes.
in active sync right click the mouse and go into connection settings and move the v from allow us connection
connect your phone and run mtty software
http://rapidshare.com/files/173474965/mtty_0513.zip.html
after your install it just go in and chose usb instead of com port
when its open press one time enter and you can see answer back cmd>
then key in cmd2
u can see the details
gd luck
he means "info 2" for CID.
but DaveShaw is right too.
anyway. it won't flash that way without hardspl.
MDAIIIUser said:
00 00 00 00 40h BLAC10000
00 00 00 1e 0hh HTC__032
00 00 00 20 00h 1.14.479.3
00 00 00 21 10h USA
Click to expand...
Click to collapse
What if I change cid in that nbh file? To match cid of my device. Will I be able to flash that rom?
lipa47 said:
What if I change cid in that nbh file? To match cid of my device. Will I be able to flash that rom?
Click to expand...
Click to collapse
Unless you can sign the NBH file with the Private Key of the Carrier (or whoevers signs them), you won't have much luck.
The HardSPL is patched so it doesn't check the signature on the file.
Ta
Dave
Now that is cool
Here is a working link
http://wiki.xda-developers.com/uploads/mtty.exe
So do we know the other codes for the rest of the stuff I found in the nbh ??
May I know that the CID will be changed or not if the hardspl is install? As I know, HTC will check the CID if it is taken for repair, and they will not repair if the CID is not valid.
CID will not be changed. Hard-spl only bypasses checking CID, signature, overwriting spl etc.
It means that there is a CID stored in the phone and also in the ROM file so that the SPL will check between them during ROM upgrade. If it is that case, is there any means to change the CID & country code stored in the phone?
Yes it is but is not available for HD at the moment.
Anyway hard-spl is bit better method because you can flash custom roms, radios only etc.
If you only change cid you can only flash HTC signed roms.
Determine CID from mtty 'info 2' output
Hi guys,
If you consider this useful keep it if not delete it ...
When issued the 'info 2' command, I got:
Cmd>info 2
Card inserted
SD clk rate 19MHz
Cmd5 CMD_TIMEOUT
SD clk rate 144KHZ
SD 2.0 HC card
SD Clk rate 24 MHz
SD Init OK
-- The
Card inserted
...
SD Init OK
-- was repeated 2 more time.
HTCSHTC__032ðúÔ•HTCE
Cmd>
Then it was not clear for me which was the CID. But http://wiki.xda-developers.com/index.php?pagename=Hermes_BootLoader was quite useful. It is stated "Returns "HTCS" + CID + (4-byte checksum) + "HTCE"" so I presume the CID is 'HTC__032'. HTCS/HTCE (Start/End) seems to be only control strings.
As written on the mentioned page 'info 4' would have shorter output and still providing the CID.
Thanks for the good doc.
I tried to install (german) images but it always freezes when the installer says
"Schreibe neues Betriebssystem...
Copying C:\Users\Max\Desktop\Projekte\PocketPC\WM65_C~1.6_D\itsutils.dll to WCE:\windows\ItsUtils.dll
3 partitions, 2 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 94 3a 02 06 21 06 17 b0 1c 07 06 09
CopyFileToTFFS(os.nb:0, 0, 037f0000)"
It was the same problem with all images i tried to install:
WM 6.5 Chome by cYBERdEL
WM 6.5 M2D by cYBERdEL
WM 6.1 Diamond
TouchFlo WM 6 by Ridingshark
If I cancel the installation and reset the Charmer the appearing ROM-Number is right but it holds at the splash screen.
What am I doing wrong?
(P.S.: Excuse my bad English)
It doesn't freeze. That is normal! Wait 20 min. The screen will tell you that it was sucsesfull then.
Thank you, it works now. There should be a warning like "This can take up to half an hour. Please be patient".
There is a warning that it can take 20 minutes. At least in my English Version.
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.