Related
Hi all,
Here I'll describe every Hack/Mod/Discovery i'll do on my phone,
the Samsung Galaxy Next/Mini/Pop GT-S5570.
ASSUMPTION : I will not install CWM.
I've already made some experiments, and bricked the phone...
... but i'm still going on.
I'll log every step i made - while expecting a repaired device from service.
Every suggestion from other experience are welcome!
Summary & Status
--------------------------------------------------------------------------------------------------
This is the summary/status of the work i made - direct on the phone (Configuration, APKs, Mods, ...)
1) Root the phone AND ADB demon. [post 3]
2) Add Essential APKs. [post 3]
3) Remove/Replace Stock applications. [post 6]
4) Got a personalized Restore. [post 6]
5) my device is back, with new GB ROM ... and personalized /system. [post 58]
--------------------------------------------------------------------------------------------------
This is the summary/status of every experiment i do with the ROM ...
1) use of ADB and related tools. [post 7]
2) backup copy of /system folder [post 7]/URL]
3) dump of partitions. [URL="http://forum.xda-developers.com/showpost.php?p=17900113&postcount=7"][post 7]
4) extract the list of partitions. [post 8]
Analizing the dumped files...
5) the dumped images can be flashed with odin !!! [post TODO]
6) extract the /system filesystem. [post 9]
7) extract the boot & recovey images. [post 12]
8) after extracting boot images...rebuild them (thanks to Doc_cheilvenerdi.org ) [post 32] and [post 40]
9) add ext4 FileSystem and busybox! (thanks to Doc_cheilvenerdi.org ) [post 44]
10) moved /data to SD !! (thanks to Doc_cheilvenerdi.org ) [post 50] and [post 52]
after explaining here how to modify the boot.img, Doc_cheilvenerdi.org wrote some exellent guides to describe his methods to to add ext4 support and move /data to SD and then move /system to SD. He also guides you in hacking the initial logos and animations and gaining root privileges on every ROM(here the IT source). Since he's not only a master in hacking and developing, but he explain it all, this 3ds are a must read !!Only... they're in italian languages... (need help in translation, please)
ToDo
...) share my PC connection to device (Reverse-Tethering) - investigation starts in [post 59]
...) understand and investigate init*** files in ramdisk ( apart from init.rc, when are they started? what they'll do ?).
...) understand and investigate the APK install process
...) understand and investigate the android framework.
...) move /data/apps/ /data/data and /data/dal***-cache to SD (should be simple, after Doc effort !!)
...) load and adapt my dumped images to androind_x86 (porting to PC/VM of android) [post ...]
--------------------------------------------------------------------------------------------------
>>> OPENED QUESTIONS <<<
1.a) why some apk copied in /system/app/ does not work ? they do not appere in the apps list ...
1.b) why some apk removed from /system/app/ cannot be installed after the delete ?
2) where in ROMS are stored the set up of the Launcher ? i.e. the widget and icons appearing after a wipe ?
3) why bloatware removed from /system are present in the dumped BML12 ? where the 'they are removed' inormation are stored ?
please see also my considerations in [post27]
4) how files inside BML13 for /data and BL14 for /cache can be extracted ?
please see also my considerations in [post27]
5) what are MIBIB, QCSBL, OEMSBL, AMSS, EFS2, NVBACKUP, APPSBL, PARAM, FOTA partitions ?
6) why the kernel has a gziped part in it ?
=======================================================================================
stepph said:
1) Root the phone AND ADB demon.
Click to expand...
Click to collapse
I used SuperOneClick tool. Its easy.
Only remeber to root also the adb shell, in order to be able to acess as super user.
As you use the tool, the SuperUser.apk is added to your ROM.
This tool make a window appear every time an apps need root access, and you have a log.
Even if you reset the device, the rooting and SU will survive.
=======================================================================================
stepph said:
2) Add Essential APKs.
Click to expand...
Click to collapse
I install RootExplorer, ES_FileManager in order to be able to navigate in the filesystem.
With rooting, i can also mount /system as R/W... and RootExplorer also indicate the mountpoint of some folders...
Eploring the FS, I notice :
/system/apps - where the preloade apks are. Some are systems apps (unknow), some are apps that i have in the apps folder.
/cache - where tempoarary data are stored.
/data - where apps save info
=======================================================================================
... continue in [post 6]...
3x. Would you like to tell how you modify the recovery.img and boot.img?
dongbincpp said:
3x. Would you like to tell how you modify the recovery.img and boot.img?
Click to expand...
Click to collapse
at now i'm studing on that...
... reading "HOWTO: Unpack, Edit, and Re-Pack Boot Images".
stepph said:
3) Remove/Replace Stock applications.
Click to expand...
Click to collapse
So I manage to remove (and backup on SD and then o my PC) the unused apk
from /systems/apps/
Some APKs have odex file (that are a way to speed up loading...) - the unused one to be removed too.
After a wipe - I noticed that the apks are DEFINITELY removed - WOW i delete something from the ROM of my phone...
If i put the backup copy of the removed files back, they still work.
Instead, if i try to install them, some of them does not work anymore (why?)
I notice the SuperUser apks too... so I try to add different apk here, or change the old one with an updated version...
So when i'll wipe the phone i'll get it with what i want.
Sometimes it works, sometimes i got errors on startup, sometimes the device ignore the new apps (??)
=======================================================================================
stepph said:
4) Got a personalized Restore.
Click to expand...
Click to collapse
When I wipe the phone, widget and links are the defult ones... how can i modify this ??
I notice dat inside /data/ folder are stored the Launcher dta & options - inside a *.db file.
So i can save & restore what i set.
But i still not understand where the setting are recorder on wipe...
=======================================================================================
... continue in [post 7]...
stepph said:
1) use of ADB and related tools.
Click to expand...
Click to collapse
great ... it is like a shell working on my terminal...
i'm not so experienced with linux command, buti'll try
I also use adb mask control, thas has a GUI to rapidly make some operation.
so i push sqlite and a new version of busybox on my device
stepph said:
2) backup copy of /system folder
Click to expand...
Click to collapse
playing with mount and my adb shell, i found:
Code:
d rwx r-x r-x root root 2011-09-09 10:10 acct
d r-x --- --- root root 2011-09-09 10:10 config
d rwx r-x r-x root root 1970-01-01 01:00 lib
d rwx --- --- root root 2011-05-02 04:40 root
d rwx r-x --- root root 1970-01-01 01:00 sbin
d rwx rwx --x system system 2011-09-09 10:10 persist
d rwx r-x r-x root root 2011-09-09 10:12 dev mount from tmpfs
d r-x r-x r-x root root 1970-01-01 01:00 proc mount from proc
d rwx r-x r-x root root 1970-01-01 01:00 sys mount from sysfs
d rwx rwx --- system cache 2011-09-09 10:10 cache mount from /dev/stl14 (rfs)
d rwx rwx --x system system 2011-09-09 10:10 data mount from /dev/stl13 (rfs)
d rwx r-x r-x root root 2011-09-09 10:10 system mount from /dev/stl12 (rfs)
d rwx rwx r-x root system 2011-09-09 10:10 mnt
/mnt/asec ??
/mnt/sdcard ??
/mnt/secure ??
l rwx rwx rwx root root 2011-09-09 10:10 d link from /sys/kernel/debug
l rwx rwx rwx root root 2011-09-09 10:10 etc link from /system/etc
l rwx rwx rwx root root 2011-09-09 10:10 sdcard link from /mnt/sdcard
i simply make a backup of files in / and of /system/ on my PC...
since other folders have 'strange' mountpoints... i let them apart for now.
stepph said:
3) dump of partitions.
Click to expand...
Click to collapse
i found this list: cat proc/partition/
Code:
major minor #blocks name
137 0 513024 bml0/c
137 1 1536 bml1
137 2 512 bml2
137 3 768 bml3
137 4 25600 bml4
137 5 9216 bml5
137 6 5120 bml6
137 7 2048 bml7
137 8 8192 bml8
137 9 8192 bml9
137 10 768 bml10
137 11 6144 bml11
137 12 222464 bml12
137 13 192768 bml13
137 14 29696 bml14
138 12 214784 stl12
138 13 185600 stl13
138 14 25856 stl14
179 0 1927168 mmcblk0
179 1 1926144 mmcblk0p1
so i start with cat /dev/bml0 >/sdcard/bml0.img
and so on for each BML to 14.
Then i try with STL... and I brick my PHONE !!!
Reading around...
>>>> DO NOT TRY TO ACCESS TO STL5<<<<
Now my phone is at service for repairing - i hope they accept warranty -
I'll continue my investigations on the BMLxx.img files...
=======================================================================================
... continue in [post 8] - without phone - ...
Now, i have the segunt dumped images:
Code:
0 513024 bml0/c
1 1536 bml1
2 512 bml2
3 768 bml3
4 25600 bml4
5 9216 bml5
6 5120 bml6
7 2048 bml7
8 8192 bml8
9 8192 bml9
10 768 bml10
11 6144 bml11
12 222464 bml12
13 192768 bml13
14 29696 bml14
an easy check prove me that the first and bigger one is simply the join on the others... so first of all i look for some indication about the partitioning of BML0, from which the others are derived.
With a hex editor, I found :
Code:
00081000h: AA 73 EE 55 DB BD 5E E3 03 00 00 00 0E 00 00 00 ªsîUÛ½^ã........
00081010h: 30 3A 4D 49 42 49 42 00 00 00 00 00 00 00 00 00 0:MIBIB.........
00081020h: 00 00 00 00 06 00 00 00 12 10 FF 00 30 3A 51 43 ..........ÿ.0:QC
00081030h: 53 42 4C 00 00 00 00 00 00 00 00 00 06 00 00 00 SBL.............
00081040h: 02 00 00 00 12 10 FF 00 30 3A 4F 45 4D 53 42 4C ......ÿ.0:OEMSBL
00081050h: 31 00 00 00 00 00 00 00 08 00 00 00 03 00 00 00 1...............
00081060h: 12 10 FF 00 30 3A 41 4D 53 53 00 00 00 00 00 00 ..ÿ.0:AMSS......
00081070h: 00 00 00 00 0B 00 00 00 64 00 00 00 12 10 FF 00 ........d.....ÿ.
00081080h: 30 3A 45 46 53 32 00 00 00 00 00 00 00 00 00 00 0:EFS2..........
00081090h: 6F 00 00 00 24 00 00 00 01 11 FF 00 30 3A 4E 56 o...$.....ÿ.0:NV
000810a0h: 42 41 43 4B 55 50 00 00 00 00 00 00 93 00 00 00 BACKUP......“...
000810b0h: 14 00 00 00 01 11 FF 00 30 3A 41 50 50 53 42 4C ......ÿ.0:APPSBL
000810c0h: 00 00 00 00 00 00 00 00 A7 00 00 00 08 00 00 00 ........§.......
000810d0h: 12 10 FF 00 30 3A 41 50 50 53 00 00 00 00 00 00 ..ÿ.0:APPS......
000810e0h: 00 00 00 00 AF 00 00 00 20 00 00 00 12 10 FF 00 ....¯... .....ÿ.
000810f0h: 30 3A 52 45 43 4F 56 45 52 59 00 00 00 00 00 00 0:RECOVERY......
00081100h: CF 00 00 00 20 00 00 00 12 10 FF 00 30 3A 50 41 Ï... .....ÿ.0:PA
00081110h: 52 41 4D 00 00 00 00 00 00 00 00 00 EF 00 00 00 RAM.........ï...
00081120h: 03 00 00 00 12 10 FF 00 30 3A 46 4F 54 41 00 00 ......ÿ.0:FOTA..
00081130h: 00 00 00 00 00 00 00 00 F2 00 00 00 18 00 00 00 ........ò.......
00081140h: 01 10 FF 00 30 3A 53 59 53 41 50 50 53 00 00 00 ..ÿ.0:SYSAPPS...
00081150h: 00 00 00 00 0A 01 00 00 65 03 00 00 01 11 FF 00 ........e.....ÿ.
00081160h: 30 3A 44 41 54 41 00 00 00 00 00 00 00 00 00 00 0:DATA..........
00081170h: 6F 04 00 00 F1 02 00 00 01 11 FF 00 30 3A 43 41 o...ñ.....ÿ.0:CA
00081180h: 43 48 45 00 00 00 00 00 00 00 00 00 60 07 00 00 CHE.........`...
00081190h: 74 00 00 00 01 11 FF 00 FF FF FF FF FF FF FF FF t.....ÿ.ÿÿÿÿÿÿÿÿ
i.e.
Code:
[I]name[/I] [I]start[/I] [I]len[/I] [I]??[/I]
MIBIB 00000000 00000600 12 10
QCSBL 00000600 00000200 12 10
OEMSBL 00000800 00000300 12 10
AMSS 00000B00 00006400 12 10
EFS2 00006F00 00002400 01 11
NVBACKUP 00009300 00001400 01 11
APPSBL 0000A700 00000800 12 10
APPS 0000AF00 00002000 12 10
RECOVERY 0000CF00 00002000 12 10
PARAM 0000EF00 00000300 12 10
FOTA 0000F200 00001800 01 10
SYSAPPS 00010A00 00036500 01 11
DATA 00046F00 0002F100 01 11
CACHE 00076000 00007400 01 11
that is not only the list of the partition of BML0 in BML1..14, with the correspondant sizes, but also the name of each - they match with what i read in some posts !!
Here it is also some binary tags for ech BML; and adding a quick examiation of the head of each file, i get the following table of preliminary infos:
Code:
Disk MB KB bytes Name flags FSR_STL note Start Lenght
/dev/bml0: 525 513.024 525.336.576
/dev/bml1: 1 1.536 1.572.864 MIBIB 12 10 00000000 00000600
/dev/bml2: 0 512 524.288 QCSBL 12 10 00000600 00000200
/dev/bml3: 0 768 786.432 OEMSBL 12 10 00000800 00000300
/dev/bml4: 26 25.600 26.214.400 AMSS 12 10 ELF 00000B00 00006400
/dev/bml5: 9 9.216 9.437.184 EFS2 01 11 X dev/stl5 ! Attento! 00006F00 00002400
/dev/bml6: 5 5.120 5.242.880 NVBACKUP 01 11 X dev/stl6 (empty) 00009300 00001400
/dev/bml7: 2 2.048 2.097.152 APPSBL 12 10 arm11boot ? 0000A700 00000800
/dev/bml8: 8 8.192 8.388.608 APPS 12 10 ANDROID! - boot image 0000AF00 00002000
/dev/bml9: 8 8.192 8.388.608 RECOVERY 12 10 ANDROID! - recovery image 0000CF00 00002000
/dev/bml10: 1 768 786.432 PARAM 12 10 0000EF00 00000300
/dev/bml11: 6 6.144 6.291.456 FOTA 01 10 empty 0000F200 00001800
/dev/bml12: 217 222.464 227.803.136 SYSAPPS 01 11 X /dev/stl12 - /system (rfs) 00010A00 00036500
/dev/bml13: 197 192.768 197.394.432 DATA 01 11 X /dev/stl13 - /data (rfs) 00046F00 0002F100
/dev/bml14: 30 29.696 30.408.704 CACHE 01 11 X /dev/stl14 - /cache (rfs) 00076000 00007400
================================================== =====================================
... continue in post 9 - without phone - ...
First, i work on the BML12, that is the file related to /system folder.
I read a lot of stuff about Samsung BML, STL, RFS, and so on...
My understanding is that BML is the layer of block level devices,
and STL is the 'file system like' layer on it. I read also that STL are FAT compatible, and that images can be opened with MagicISO.
So i found in BML12.img file the signature MSWIN4.1, cut the previus part (two byte more) and i get a fat-12 image.
MagicISO was able to extract this files.
I compare the extracted /system folder wit the backup i done directly from the phone ... SURPRISE... the files i removed from ROM are there again !! why this ??
On the other side i wander where the others files in original filesystem are...
Same tecnich on BML13 & BML14 for /data and /cach partition does'n work at all -- why ?
=======================================================================================
... continue in post 12 - without phone - ...
stepph
wat ur doing here is great.
but didn u notice a few other mini threads here already..a few roms n cm7?
http://forum.xda-developers.com/showthread.php?t=1167750
http://forum.xda-developers.com/showthread.php?t=1176927
there are other threads too
---------- Post added at 02:01 PM ---------- Previous post was at 01:52 PM ----------
stepph said:
1.a) why some apk copied in /system/app/ does not work ? they do not appere in the apps list ...
Click to expand...
Click to collapse
I dont think u can install any app as a system, think u can only replace an already existing system app with another of ur wish by renaming the app correctly and replacing it in /system/app
1.b) why some apk removed from /system/app/ cannot be installed after the delete ?
Click to expand...
Click to collapse
u cannot install app as a system app. as said abv u can only replace them.
3) why bloatware removed from /system are present in the dumped BML12 ? where the 'they are removed' inormation are stored ?
Click to expand...
Click to collapse
maybe u need to remove them frm the dalvik-cache too
----edit------
clearly I have not played with my phone enough to be answering such questions.
roofrider said:
stepph wat ur doing here is great.
but didn u notice a few other mini threads here already..a few roms n cm7?
http://forum.xda-developers.com/showthread.php?t=1167750
http://forum.xda-developers.com/showthread.php?t=1176927
there are other threads too
Click to expand...
Click to collapse
Thank you for the links,
I notice that already...but none of them talk about HOW it was made...
... i don't want a " download and install " work, but explain to everybody what i do.
roofrider said:
I dont think u can install any app as a system, think u can only replace an already existing system app with another of ur wish by renaming the app correctly and replacing it in /system/app
u cannot install app as a system app. as said abv u can only replace them.
maybe u need to remove them frm the dalvik-cache too
Click to expand...
Click to collapse
Ok, it was what i think about 1st & 2nd point...I'll look for technical infos about those 'system' apps.
About the 3rd, you may be right if it was about a running device; but i worked on dumped images, so VM cache should not be involved... i'll investigate.
About Boot.img and Recovery.img
I tested this method on my duped BML files, and on some downloaded ROM.
in bootimg.h - from Android SDK (so i suppose, but i found in this forum)
Code:
#define BOOT_MAGIC "ANDROID!"
#define BOOT_MAGIC_SIZE 8
#define BOOT_NAME_SIZE 16
#define BOOT_ARGS_SIZE 512
struct boot_img_hdr
{
unsigned char magic[BOOT_MAGIC_SIZE];
unsigned kernel_size; /* size in bytes */
unsigned kernel_addr; /* physical load addr */
unsigned ramdisk_size; /* size in bytes */
unsigned ramdisk_addr; /* physical load addr */
unsigned second_size; /* size in bytes */
unsigned second_addr; /* physical load addr */
unsigned tags_addr; /* physical addr for kernel tags */
unsigned page_size; /* flash page size we assume */
unsigned unused[2]; /* future expansion: should be 0 */
unsigned char name[BOOT_NAME_SIZE]; /* asciiz product name */
unsigned char cmdline[BOOT_ARGS_SIZE];
unsigned id[8]; /* timestamp / checksum / sha1 / etc */
};
/*
** +-----------------+
** | boot header | 1 page
** +-----------------+
** | kernel | n pages
** +-----------------+
** | ramdisk | m pages
** +-----------------+
** | second stage | o pages
** +-----------------+
**
** n = (kernel_size + page_size - 1) / page_size
** m = (ramdisk_size + page_size - 1) / page_size
** o = (second_size + page_size - 1) / page_size
**
** 0. all entities are page_size aligned in flash
** 1. kernel and ramdisk are required (size != 0)
** 2. second is optional (second_size == 0 -> no second)
** 3. load each element (kernel, ramdisk, second) at
** the specified physical address (kernel_addr, etc)
** 4. prepare tags at tag_addr. kernel_args[] is
** appended to the kernel commandline in the tags.
** 5. r0 = 0, r1 = MACHINE_TYPE, r2 = tags_addr
** 6. if second_size != 0: jump to second_addr
** else: jump to kernel_addr
So i opened my file, and found
Code:
414E4452 4F494421 C8F42E00 00806013 0E143000 00006014 00000000 00005014 00016013 00100000 00000000 ...
that is
Code:
00000000 struct BOOT_IMG_HDR
00000000 magic[8] ANDROID!
00000008 DWORD kernel_size 3077320
0000000C DWORD kernel_addr 325091328
00000010 DWORD ramdisk_size 3150862
00000014 DWORD ramdisk_addr 341835776
00000018 DWORD second_size 0
0000001C DWORD second_addr 340787200
00000020 DWORD tags_addr 325058816
00000024 DWQRD page_size 4096
00000028 unused[2] 0
00000030 name[16] 0
00000040 cmdline[512] 0
00000240 id[8] xxxxxxx
so i calculate
Code:
n = (3077320 + 4096 - 1) / 4096 = 752
m = (3150862 + 4096 - 1) / 4096 = 770
o = (0 + 4096 - 1) / 4096 = 0
** +-----------------+
** | boot header | 1 page = 0 to 4095 (h00000FFF)
** +-----------------+
** | kernel | 752 pages = 4096 to 4096+752*4096 = 3084287 (h002F0FFF)
** +-----------------+
** | ramdisk | 770 pages = 3084288 to 3084288+770*4096 = 2378055679 (h8DBE3FFF)
** +-----------------+
so i spli the file in 3 parts : header, kernel, and ramdisk.
NOTE: at offset 18825 (h4989) i find 1F 8F that is the head of a gzipped file..
so i split kernel in kernel.head and kernel.gz => decompressed in kernel.tail.
This worked, sinc in decompressed part i found readable strings...
Ramdisk is ramdisk.cpio.gz, so i was able to decompress it and get the filesystems loaded on start.
There are many interesting files...
TASS.rle and TASS-HUI.rle (the original logo, and the logo for italy - HUI is my region)
init and init.rc - and some other script file, that i saw on root folder of my devices
some folders with bins, and so on...
When i use this method with dumped Recovery.img and downloaded ClockWorkMod_recovery.img, i get i working...
So i'll investigate about differences in ramdisk files of those...
=======================================================================================
... continued in [post 14] - without phone - ...
I'm neither an Android, nor a Linux expert but I'll try to answer your questions to the best of my knowledge:
1.a) why some apk copied in /system/app/ does not work ? they do not appere in the apps list ...
Click to expand...
Click to collapse
Some system apks don't have a registered activity (meaning they don't have a UI), so they won't appear in your launcher, also (and take this with a grain of salt), I've personally found that some of the apks placed in /system/app/ need to be installed too.
1.b) why some apk removed from /system/app/ cannot be installed after the delete ?
Click to expand...
Click to collapse
Dunno about this one, but I'd dare say that it has something to do with the extra files that are placed in other folders, What apps have you had this problem with?, maybe we can find out why they have that behavior
2) where in ROMS are stored the set up of the Launcher ? i.e. the widget and icons appearing after a wipe ?
Click to expand...
Click to collapse
If they're not wiped they have to be either in the system partition or in the SD
3) why bloatware removed from /system are present in the dumped BML12 ? where the 'they are removed' inormation are stored ?
Click to expand...
Click to collapse
Taken from the link you put on the BML mapping thread:
What you generally see is that BML partitions contain 'static' data (bootloaders, boot / recovery images) and STL partitions contain 'live' filesystem (on android: /system, /data, /cache, /efs, /dbdata). The idea is that things directly on an BML partition don't change very often and wear leveling isn't required. Read/write filesystems however, do benefit from wear leveling and are thus placed on an STL partition.
Click to expand...
Click to collapse
4) how files inside BML13 for /data and BL14 for /cache can be extracted ?
Click to expand...
Click to collapse
You'd have to find out the partition's filesystem, I believe it's a Samsung propietary FS so you're out of luck with that one
5) what are MIBIB, QCSBL, OEMSBL, AMSS, EFS2, NVBACKUP, APPSBL, PARAM, FOTA partitions ?
Click to expand...
Click to collapse
Way above my paygrade!!
6) why the kernel has a gziped part in it ?
Click to expand...
Click to collapse
See 5
Great !!
thank you Akath19 for your contribution....
I want to continue this discussion with details on some topics...if you or someone else is able to contribute.
-------------------------------------------------------------------------
1.a) why some apk copied in /system/app/ does not work ? they do not appere in the apps list ...
A : Some system apks don't have a registered activity (meaning they don't have a UI), so they won't appear in your launcher, also (and take this with a grain of salt), I've personally found that some of the apks placed in /system/app/ need to be installed too.
Click to expand...
Click to collapse
1.b) why some apk removed from /system/app/ cannot be installed after the delete ?
A: Dunno about this one, but I'd dare say that it has something to do with the extra files that are placed in other folders, What apps have you had this problem with?, maybe we can find out why they have that behavior
Click to expand...
Click to collapse
In /system/apps i find some different kind of apps...
- those without icon, not appearing in the 'GUI' - (the app folder in launche) - i call them of 'system type' and i do not touch them.
- apps with icon, implementing important functions - gallery, phone, launcher, etc...
- Google Apps
- some other samsung/provider apps
- some 'generic' app - Analog clock, Dual clock, some widget... (i think they are inserted as demo of capabilities)
Many of those apps have related .odex file.
REMOVING Apps - and restore them
I removed the apps that i do not need - and backup the on my sdcard.
If i want to restore them, i can adb push them a their previus place, and this is the only method for odexed ones.
As alternative to reinstall i tried to do 'normal' install for the apps without .odex ... this also mean that they will be installed in /data/apps,
and they are moved from system STL12 to data STL13 - different partitions, with impact on free space)
This doesn't work for many of the apps - ??
ADDING Apps
I want to add some apps - in order to find them installed after a wipe.
This works with some apps, doesnot with others... some apps (TitaniumBackup) generate a force close on power on...
I suppose that apps in system/apps have to be differrent from those in /data/apps...
-------------------------------------------------------------------------
2) where in ROMS are stored the set up of the Launcher ? i.e. the widget and icons appearing after a wipe ?
A: If they're not wiped they have to be either in the system partition or in the SD
Click to expand...
Click to collapse
They do are wiped... so the infos are written in /data/data/(somefolder)...
But the preloade info - those appearing after a wipe - where are they ?
I suppose that a wipe completely erase /data and not preload its contents...or a part of /data is restored after a wipe ? how ??
-------------------------------------------------------------------------
3) why bloatware removed from /system are present in the dumped BML12 ? where the 'they are removed' inormation are stored ?
a: Taken from the link you put on the BML mapping thread:
What you generally see is that BML partitions contain 'static' data (bootloaders, boot / recovery images) and STL partitions contain 'live' filesystem (on android: /system, /data, /cache, /efs, /dbdata). The idea is that things directly on an BML partition don't change very often and wear leveling isn't required. Read/write filesystems however, do benefit from wear leveling and are thus placed on an STL partition.
Click to expand...
Click to collapse
This is the description of 'driver level' to access to the phisical chip...
STL are a layer up the BML, adding a wear leveling services, enabling secure r/w of bits...
I understand that in a BML dump is contained the STL dump.
This does'n explain why the apps i removed are still present in dump
(unless i make a mistake, and dumepd before removing ??)
-------------------------------------------------------------------------
4) how files inside BML13 for /data and BL14 for /cache can be extracted ?
A: You'd have to find out the partition's filesystem, I believe it's a Samsung propietary FS so you're out of luck with that one
Click to expand...
Click to collapse
You are right... unless we find the source of RFS, in order to be compiled for linux, the only way i have to correctly mount, is on my device - that support RFS.
RFS is reported to be FAT compatible, in fact i was able to extract files form BML12 - aftre some editing - with MagicISO. I suppose that this SW read it as a FAT12 partition - or at least, I found a valid FAT12 heder.
This method does'not work with BML13 and BML14, thas seem to have many FAT12 section in it - but each unreadable.
-------------------------------------------------------------------------
... continue in [post 24] - with Doc_cheilvenerdi.org great contribution
No worries man, I'm also really interested in learning and this is a much better way than just downloading and flashing files.
Anyways, on to the discussion:
stepph said:
REMOVING Apps - and restore them
I removed the apps that i do not need - and backup the on my sdcard.
If i want to restore them, i can adb push them a their previus place, and this is the only method for odexed ones.
As alternative to reinstall i tried to do 'normal' install for the apps without .odex ... this also mean that they will be installed in /data/apps,
and they are moved from system STL12 to data STL13 - different partitions, with impact on free space)
This doesn't work for many of the apps - ??
Click to expand...
Click to collapse
Well if the apps are odexed, they won't work (not even if you install them), 'cause you'd need to deodex them first before trying to install them (learned this the hard way while theming my stock Phone.apk)
For the other apps I guess trying on a case by case basis would be the answer, give me a list of the apps that don't work I'll try to figure out why.
stepph said:
ADDING Apps
I want to add some apps - in order to find them installed after a wipe.
This works with some apps, doesnot with others... some apps (TitaniumBackup) generate a force close on power on...
I suppose that apps in system/apps have to be differrent from those in /data/apps...
Click to expand...
Click to collapse
Personally I don't use TB, I think manually saving apks and configs works better, also I've heard numerous horror stories regarding TB.
What I do in order to keep stuff after a wipe is, I make a small CWM flashable zip that has all the info that I want to keep, and I just flash it after wiping.
stepph said:
They do are wiped... so the infos are written in /data/data/(somefolder)...
But the preloade info - those appearing after a wipe - where are they ?
I suppose that a wipe completely erase /data and not preload its contents...or a part of /data is restored after a wipe ? how ??
stepph said:
I don't exactly know if this is true but I'd dare say some settings are saved inside the apk itself, so that the user has some "default" settings ready available
Also, no part of /data/ is restored after a wipe.
stepph said:
This is the description of 'driver level' to access to the phisical chip...
STL are a layer up the BML, adding a wear leveling services, enabling secure r/w of bits...
I understand that in a BML dump is contained the STL dump.
This does'n explain why the apps i removed are still present in dump
(unless i make a mistake, and dumepd before removing ??)
Click to expand...
Click to collapse
I guess this question would need someone extremely knowledgeable about the underlying subsystem (someone like Darky), but IMHO the phone must copy the STL contents into BML every certain amount of time or something like that.
stepph said:
You are right... unless we find the source of RFS, in order to be compiled for linux, the only way i have to correctly mount, is on my device - that support RFS.
RFS is reported to be FAT compatible, in fact i was able to extract files form BML12 - aftre some editing - with MagicISO. I suppose that this SW read it as a FAT12 partition - or at least, I found a valid FAT12 heder.
This method does'not work with BML13 and BML14, thas seem to have many FAT12 section in it - but each unreadable.
Click to expand...
Click to collapse
If the partitions have a true RFS FS you could just mount them as a loopback device, that's what I did in order to check the contents of BML5, if there are mutliple partitions I guess you would need to find that start and end of each and split them in order to read them
Click to expand...
Click to collapse
Click to expand...
Click to collapse
This is really what I expected from this 3d !!
Akath19 said:
For the other apps I guess trying on a case by case basis would be the answer, give me a list of the apps that don't work I'll try to figure out why.
Click to expand...
Click to collapse
I'll post the list of the removed apps... but need to wait for it since i'm without phone and - don't ask too much to my memory - i have to re-check the ones loading.
Akath19 said:
What I do in order to keep stuff after a wipe is, I make a small CWM flashable zip that has all the info that I want to keep, and I just flash it after wiping.
Click to expand...
Click to collapse
Good ... else - i do not want to use CWM - i was unable to prepare update.zip for original recovery. This could be another discussion...
Akath19 said:
I don't exactly know if this is true but I'd dare say some settings are saved inside the apk itself, so that the user has some "default" settings ready available
Also, no part of /data/ is restored after a wipe.
Click to expand...
Click to collapse
this is also my guess.
-->> and now the important part... <<---
Akath19 said:
I guess this question would need someone extremely knowledgeable about the underlying subsystem (someone like Darky), but IMHO the phone must copy the STL contents into BML every certain amount of time or something like that.
If the partitions have a true RFS FS you could just mount them as a loopback device, that's what I did in order to check the contents of BML5, if there are mutliple partitions I guess you would need to find that start and end of each and split them in order to read them
Click to expand...
Click to collapse
I tried mounting with loopback - my experiments are slowly migrating to linux - but it works only for STL12 /system. It doesn't work for others, nor splitted parts - they result in unreadbles files with unreadable filenames.
Does'n work even with bml5 ... but i probably have a corrupted dump, since after that - by reading STL5 - the phone is gone...
.
Have you gotten your phone back yet stepph, 'cause I'm eager to start tinkering with our phones but I can't do it alone!!
I got it yesterday... with a russian gingerbread FW (who knows where it was downloaded ), but without radio FW, and shutting down every minute...
... The guy of the service was not so able... and he doesn't work with 'official' FW... I have to take the phone back to him - for warranty at least.
I'm tempted to do it by myself - but if EFS is gone ?
Meanwhile, i'm working with androidx86 - a porting for PC - on a virtual machine... it seems great for testing some mods on /system - but kernel, executables, and libraries are recompiled...
And i'm tryng revskill - in order to understand AMSS - the free version seem good... but is limited...
If i get some new results, i'll post it...
(interested in matlab scripts for codig/decoding RLE logos ?)
Download the official Euro FW via checkfusdownloader and flash it through ODIN, those FWs come directly from Samsung servers so you shouldn't have a problem.
I checked out that port but I didn't quite like it (too slow for my taste).
What's revskill (forgive my ignorance)
Meanwhile I'm looking into porting voodoo kernel (from SGS) into our minis, mainly to get better audio support through voodoo sound.
(Ewww, I hate matlab!!)
Akath19 said:
Download the official Euro FW via checkfusdownloader and flash it through ODIN, those FWs come directly from Samsung servers so you shouldn't have a problem.
Click to expand...
Click to collapse
just tried...ODIN reported success, but now the phone does'nt boot anymore...
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.
On Fire HD 2014 I started looking at md5sum for partitions for different OS versions, and it seems that on Fire 2015 one can figure out which partition gets screwed up by 5.1.1 bootloaders, and perhaps restore it to pre-5.1.1 state. If this fails, the warranty should kick in (all of the Fire 2015s are still under warranty !!!)
Please see this link for some details :
http://forum.xda-developers.com/fire-hd/help/trying-to-undo-bricking-5-2-2u2-t3301374
Basically, the idea is simple. First one captures all the partitions while running 5.0.1 bootloaders. Then the bootloaders are updated to 5.1.1 version. At this point the partitions are captured again. This is the code to capture partitions to be run on PC via adb:
Code:
adb shell
su
mkdir /sdcard/tmp/
dd if=/dev/block/mmcblk0p1 of=/sdcard/tmp/01_kb.img
dd if=/dev/block/mmcblk0p2 of=/sdcard/tmp/02_dkb.img
dd if=/dev/block/mmcblk0p3 of=/sdcard/tmp/03_expdb.img
dd if=/dev/block/mmcblk0p7 of=/sdcard/tmp/07_misc.img
dd if=/dev/block/mmcblk0p8 of=/sdcard/tmp/08_logo.img
cd /sdcard/tmp
md5 *.img
Then one can simply exit, and do "adb pull /sdcard/tmp/" to get all these *.img files off the device.
Then those partitions that changed (KB,DKB,EXPDB,MISC) are dd'ed back under 5.1.1, and bootloaders are dd'ed back to 5.0.1 versions. If it reboots OK, this means that the device is effectively restored to pre-5.1.1 state. If failure, warranty return.
The next step to try would be to transplant this offending partition from a different Fire to a device with 5.1.1, along with 5.0.1 bootloaders.
Here is the list of partitions for reference:
http://forum.xda-developers.com/amazon-fire/development/partitions-list-t3236213
When one tires to downgrade to 5.0.1, it's the preloader stage which the Fire keeps cycling at. We have already tried flashing the 5.0.1 bootloader & preloader onto a 5.1.1 Fire.
blueberry.sky said:
When one tires to downgrade to 5.0.1, it's the preloader stage which the Fire keeps cycling at. We have already tried flashing the 5.0.1 bootloader & preloader onto a 5.1.1 Fire.
Click to expand...
Click to collapse
But this would not make sense. Are you saying that the preloader does not even try to call the 5.0.1 bootloaders ? But then why ?
Since the preloader stays the same, the only difference is that 5.0.1 bootloaders are trying to run after 5.1.1 bootloaders already ran on the device. At this stage 5.0.1 cannot proceed normally, which must be due to some changes sitting on some of the partitions that the bootloaders are reading early on.
We have no indication that 5.0.1 bootloaders do not run at all, they may run a bit, and then crash, and the device is back at the preloader stage.
So restoring additional partitions together with 5.0.1 bootloaders may enable 5.0.1 to function again after 5.1.1, as per my original post.
bibikalka said:
Since the preloader stays the same, the only difference is that 5.0.1 bootloaders are trying to run after 5.1.1 bootloaders already ran on the device.
Click to expand...
Click to collapse
Have you verified that the 5.0.1 and 5.1.1 preloaders are the same?
bibikalka said:
Are you saying that the preloader does not even try to call the 5.0.1 bootloaders ?
Click to expand...
Click to collapse
Just know that when plugged into a pc you will see the preloader cycle endlessly. Connect, disconnect, repeat. And someone did try to flash the both the bootloader & preloader extracted from 5.0.1.
It could be that 5.1.1 is blowing a fuse which tell older versions to refuse to boot.
bibikalka said:
On Fire HD 2014 I started looking at md5sum for partitions for different OS versions, and it seems that on Fire 2015 one can figure out which partition gets screwed up by 5.1.1 bootloaders, and perhaps restore it to pre-5.1.1 state. If this fails, the warranty should kick in (all of the Fire 2015s are still under warranty !!!)
Please see this link for some details :
http://forum.xda-developers.com/fire-hd/help/trying-to-undo-bricking-5-2-2u2-t3301374
Basically, the idea is simple. First one captures all the partitions while running 5.0.1 bootloaders. Then the bootloaders are updated to 5.1.1 version. At this point the partitions are captured again. This is the code to capture partitions to be run on PC via adb:
Code:
adb shell
su
mkdir /sdcard/tmp/
dd if=/dev/block/mmcblk0p1 of=/sdcard/tmp/01_kb.img
dd if=/dev/block/mmcblk0p2 of=/sdcard/tmp/02_dkb.img
dd if=/dev/block/mmcblk0p3 of=/sdcard/tmp/03_expdb.img
dd if=/dev/block/mmcblk0p7 of=/sdcard/tmp/07_misc.img
dd if=/dev/block/mmcblk0p8 of=/sdcard/tmp/08_logo.img
cd /sdcard/tmp
md5 *.img
Then one can simply exit, and do "adb pull /sdcard/tmp/" to get all these *.img files off the device.
Then those partitions that changed (KB,DKB,EXPDB,MISC) are dd'ed back under 5.1.1, and bootloaders are dd'ed back to 5.0.1 versions. If it reboots OK, this means that the device is effectively restored to pre-5.1.1 state. If failure, warranty return.
The next step to try would be to transplant this offending partition from a different Fire to a device with 5.1.1, along with 5.0.1 bootloaders.
Here is the list of partitions for reference:
http://forum.xda-developers.com/amazon-fire/development/partitions-list-t3236213
Click to expand...
Click to collapse
Thanks Bibikalpa. The problem is, to try your solution we have to be able to use adb. We are stuck at fastboot. :crying:
rongweiss said:
Thanks Bibikalpa. The problem is, to try your solution we have to be able to use adb. We are stuck at fastboot. :crying:
Click to expand...
Click to collapse
What he is proposing is not a solution for people who are bricked. Rather it would help prevent people on 5.1.1 from getting bricked in the first place. It would allow downgrading to 5.0.1, restoring the ability to load twrp recovery from fastboot.
---------- Post added at 09:53 PM ---------- Previous post was at 09:11 PM ----------
Here are the md5 checksums from my 5.0.1 Fire
Code:
e1c2e27a6dae694cbf14594b6d963f11 ./01_kb.img
175ec1eea0b65b15ea6ee455531f154d ./02_dkb.img
1d837a219b515afae6c19d9126168f5c ./03_expdb.img
00ff461906b45fc4af74f81839a30069 ./07_misc.img
c414b0be43b26efb5009639be06a74e2 ./08_logo.img
926c891ba8bc265d5dfeabe1ba3838c8 ./09_tee1.img
926c891ba8bc265d5dfeabe1ba3838c8 ./10_tee2.img
Perhaps some of them are the same even between different Fires.
I've already had to get a warranty replacement for my Fire due to a cluster of stuck pixels. Don't want to try upgrading to 5.1.1, risk having to try for a 2nd replacement.
Here are my md5 checksums from 5.1.1 (with 5.1,0 bootloaders, so may not help much, but you didn't ask for bootloaders)
Code:
d47ae72b30dd03c08d0c41883ac219f4 01_kb.img
8b50c460e75aef889840a9077b12c20a 02_dkb.img
4af5655b4a4f2b36ffb81b20605bb75d 03_expdb.img
00ff461906b45fc4af74f81839a30069 07_misc.img
c414b0be43b26efb5009639be06a74e2 08_logo.img
926c891ba8bc265d5dfeabe1ba3838c8 09_tee1.img
926c891ba8bc265d5dfeabe1ba3838c8 10_tee2.img
83b74c9782b889e246bc7b7cfa184d64 04_uboot.img
I'm OK with testing, starting from scratch and rooting my unadultered 5.1.0.
DoLooper said:
Here are my md5 checksums from 5.1.1 (with 5.1,0 bootloaders, so may not help much, but you didn't ask for bootloaders)
Code:
I'm OK with testing, starting from scratch and rooting my unadultered 5.1.0.
Click to expand...
Click to collapse
These look like 5.0.1 checksums for TEE1/TEE2, the same as @blueberry.sky post.
Only the 1st 3 partitions seem to differ. If you run "adb shell; idme print" with root, it actually prints the first few lines of KB & DKB, at least on Fire HD 2014. Does this work on Fire 2015 ?
bibikalka said:
These look like 5.0.1 checksums for TEE1/TEE2, the same as @blueberry.sky post. Only the 1st 3 partitions seem to differ.
Click to expand...
Click to collapse
As said, I'm running 5.0.1 bootloaders.
If you run "adb shell; idme print" with root, it actually prints the first few lines of KB & DKB, at least on Fire HD 2014. Does this work on Fire 2015 ?
Click to expand...
Click to collapse
I get no output with either "idme print /dev/block/kb.img" or "idme print /dev/block/dkb.img" while in su. I assume this is correct syntax.
DoLooper said:
As said, I'm running 5.0.1 bootloaders.
I get no output with either "idme print /dev/block/kb.img" or "idme print /dev/block/dkb.img" while in su. I assume this is correct syntax.
Click to expand...
Click to collapse
It's just straight "idme print", nothing else after that.
bibikalka said:
It's just straight "idme print", nothing else after that.
Click to expand...
Click to collapse
Cool!
Code:
[email protected]:/ # idme print
. . .
KB:
4b 42 50 46 18 0e 00 00 28 0e
00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
DKB:
30 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
. . .
Have you tried to connect your device to a computer running SP Flash Tool? If that works, and you manage to get data from the Fire (using the readback window), you may be able to unbrick your tablet.
@RO.maniac ask how to relock his v37 bootloader on another thread:
RO.maniac said:
I have a little situation here. on a D6603.
Was running LP, unlocked, andropluskernel, root, xposed. happy.
Relocked bootloader with flashtool.
Updated to N preview using xperia companion.
Unlocked bootloader with flashtool.
That new bootloader, nexus style, was telling me safe boot off and unlocked bootloader.
Wasn't satisfied with the lack of root on N preview, so I decided to go back to stock LP via Xperia Companion. Then I found out the lastest update Xperia would flash is MM. I said fine.
Tried to relock bootloader with flashtool, I got ok message but it didn't relock the bootloader. tried a lot of times, different pc, flashtool version, regenerated code. nothing. so no Xperia Companion - no big deal, I just have an obsession with latest official builds, since my main device is a Nexus5. oh, what a nice girl that is. and easy to undress.
flashed a LP .ftf, tried to relock bootloader, no success.
[...]
What the heck happened with the relocking of the bootloader??!!
I'm thinking it has something to do with the new bootloader from N preview which I was running when I unlocked it. Now it won't relock on any version.
Click to expand...
Click to collapse
The idea of this dev-thread is understanding why S1 v37 is not re-lockable and if there is a way to relock it or downgrade it then relock, without bricking the phone obviously.
@RO.maniac can you, please, provide
- the S1boot part of your cmdline,
- backups of your TA partition before, after upgrading the bootloader,
- any flashtool log?
Thanks in advance.
N preview TA backup & flashtool log
Here you have the flashtool log and two backups of the current TA partition. One is pulled with ADB and one is from TWRP.
https://drive.google.com/file/d/0B0YzIybNxHcQa3E0Q1JJZlBkUU0/view?usp=sharing - TWRP ver.
https://drive.google.com/file/d/0B0YzIybNxHcQRXR2MjQ0Y3UzOWM/view?usp=sharing - ADB ver.
I don't have a TA backup of my old bootloader.
https://drive.google.com/file/d/0B0YzIybNxHcQcWNMMUtWeF9RNFk/view?usp=sharing - flashtool log. Tried to relock three times.
https://drive.google.com/file/d/0B0YzIybNxHcQVk1CZ1RISmhLMWM/view?usp=sharing - current bootloader mode photo.
I am now running N Preview 3, rooted, permissive.
RO.maniac said:
Here you have the flashtool log and two backups of the current TA partition. One is pulled with ADB and one is from TWRP.
Click to expand...
Click to collapse
Thanks! And no worries for the old TA. Just we can't revert to old version without it.
Can you send me your s1boot partition and the cmdline part with 's1boot'?
Also can you provide me your oem unlock code? (I should be able to find it in your ta partition)
P.S. your name is in plain text in your flashtool log.
nailyk said:
Thanks! And no worries for the old TA. Just we can't revert to old version without it.
Can you send me your s1boot partition and the cmdline part with 's1boot'?
Also can you provide me your oem unlock code? (I should be able to find it in your ta partition)
P.S. your name is in plain text in your flashtool log.
Click to expand...
Click to collapse
My name is no secret.
I'm not familiar with pulling s1boot partition and the cmdline part with 's1boot'. Do you need anything more than the photo I just popped in the post? - oh, you mean the boot partition and the code in the photo. That s1 upfront blinded me.
https://drive.google.com/open?id=0B0YzIybNxHcQMGxSTUdtdzBzTjQ - boot TWRP backup
Unlock code: C88FB2FFCCE72540
RO.maniac said:
My name is no secret.
I'm not familiar with pulling s1boot partition and the cmdline part with 's1boot'. Do you need anything more than the photo I just popped in the post?
Unlock code: C88FB2FFCCE72540
Click to expand...
Click to collapse
Awesome! I miss the picture, sorry.
Your fastbootlog also says: S1_Boot_MSM8974AC_LA3.0_L_Hero_17 which make me doubt....
Never read this version before. and never seen the screen you post before....
For me, fastboot mode was only blue light.... on this bootloader version.
I will start re with this elements, thank you.
Do you know exactly when this Hero_L17 version get installed on your phone? Is it coming from a custom rom?
nailyk said:
Awesome! I miss the picture, sorry.
Your fastbootlog also says: S1_Boot_MSM8974AC_LA3.0_L_Hero_17 which make me doubt....
Never read this version before. and never seen the screen you post before....
For me, fastboot mode was only blue light.... on this bootloader version.
I will start re with this elements, thank you.
Do you know exactly when this Hero_L17 version get installed on your phone? Is it coming from a custom rom?
Click to expand...
Click to collapse
This is the bootloader mode from N preview. Just like the Nexus line. I was really surprised to see it just as on my Nexus5.
Other than stock LP and MM , the only custom rom I've had is RXSW 3.0 which is MM.
I think this Hero_L17 is coming with N preview.
This is what I may seem not to understand. When I flash a complete .ftf doesn't EVERYTHING change, including the bootloader?
You are asking like it's there for some time, surviving .ftf flashes.
---------- Post added at 06:19 PM ---------- Previous post was at 06:17 PM ----------
nailyk said:
Awesome! I miss the picture, sorry.
Your fastbootlog also says: S1_Boot_MSM8974AC_LA3.0_L_Hero_17 which make me doubt....
Never read this version before. and never seen the screen you post before....
For me, fastboot mode was only blue light.... on this bootloader version.
I will start re with this elements, thank you.
Do you know exactly when this Hero_L17 version get installed on your phone? Is it coming from a custom rom?
Click to expand...
Click to collapse
Also, you should watch my past posts here because I tend to edit them a lot and add things instead of writing a new reply. I will let go of this habit, I promise.
RO.maniac said:
This is what I may seem not to understand. When I flash a complete .ftf doesn't EVERYTHING change, including the bootloader?
You are asking like it's there for some time, surviving .ftf flashes.
Click to expand...
Click to collapse
afaik ftf files are almost the same that flashable zip files: partition binaries and script files.
To check that, some tools give you the ability of unpack ftf files.
So some ftf custom rom only flash kernel and system, some other flash everything on the phone. Some other add ta partitions modifying.
But as the full boot process is signed, maybe other process are in cause. That's why i'm digging on.
I hope i didn't miss the point. (my English is really bad )
RO.maniac said:
Also, you should watch my past posts here because I tend to edit them a lot and add things instead of writing a new reply. I will let go of this habit, I promise.
Click to expand...
Click to collapse
No worries, but as I'm really slow to write my answers I miss some edits From now I will double check
Your English is not that bad. Yes, you got the point and I got it about the .ftf files.
From what I can remember when I flashed a .ftf of N preview 3, the flashtool log listed everything, from boot to some TA. I'll do a backup and reflash just to check. Will post log.
---------- Post added at 07:20 PM ---------- Previous post was at 06:49 PM ----------
nailyk said:
afaik ftf files are almost the same that flashable zip files: partition binaries and script files.
To check that, some tools give you the ability of unpack ftf files.
So some ftf custom rom only flash kernel and system, some other flash everything on the phone. Some other add ta partitions modifying.
But as the full boot process is signed, maybe other process are in cause. That's why i'm digging on.
I hope i didn't miss the point. (my English is really bad )
Click to expand...
Click to collapse
https://drive.google.com/open?id=0B0YzIybNxHcQNVA3OTZCM2ZqTm8 - flashtool log of N preview 3 flash
You can continue this little study but just so you know, the screen just died on me. It started flicking all of a sudden and in under an hour is gave away for good. Now is backlit but no color.
So the test object is dead.
For the second time, after the main board water damage. I'm officially done with it. When my friend gets back in the country he'll find out his phone died again. ))
As I've said, my screen died. So I decided to dump the phone and cleaned my pc of flashtool, xperia companion and all that.
Some minutes ago I decided to try another flash because my mind was running scenarios about the facts before the screen just died. What happened exactly before: TWRP backup, updated flashtool at startup, flashed N preview 3, in order to get the log so I can see if that Hero7 bootloader is coming with N preview. And it is indeed.
Booted and the screen was flicking with white flashes on the edges. In a few minutes I saw a vertical black line and then it turned black, but backlight on.
Today I thought, what the hell, flash it again, maybe it's not a hw problem. But now I know it is
So I installed an older version of flashtool, 0.9.18.6, and flashed N preview. Still dead screen
But this version of flashtool RELOCKED my bootloader. I could see the code written to TA and I can flash with Xperia Companion. Too bad I don't have a screen.
One in all, just dump this discussion and everything about my friend's damned Z3. Just close the drawer, as I've done.
RO.maniac said:
https://drive.google.com/open?id=0B0YzIybNxHcQNVA3OTZCM2ZqTm8 - flashtool log of N preview 3 flash
Click to expand...
Click to collapse
I see from the github there is a branch 0.9.16 so that is a good idea to test with this version.
First, we see the ta block between your two tries are different. First try block n° 8B2, second try 8FD. I can't understand why (same version of flashtool used).
It take me a lot of time because that was not a hexadecimal place in the ta partition but an unit in the ta partition.
Investigations:
For memory, your unlock code is C88FB2FFCCE72540 (in hex: 43 38 38 46 42 32 46 46 43 43 45 37 32 35 34 30),
my unlock code is 481FD30094B6F2FC (in hex: 34 38 31 46 44 33 30 30 39 34 42 36 46 32 46 43)
If we look in the 8B2 unit we found that:
my ta partition after unlocking
Code:
[COLOR="Magenta"]B2 08 00 00[/COLOR] [COLOR="SeaGreen"]10 00 00 00[/COLOR] [COLOR="Blue"]C1 E9 F8 3B FF FF FF FF[/COLOR] 34 38 31 46 44 33 30 30 39 34 42 36 46 32 46 43
your ta partition after unlocking:
Code:
[COLOR="magenta"]B2 08 00 00[/COLOR] [COLOR="SeaGreen"]10 00 00 00[/COLOR] [COLOR="Blue"]C1 E9 F8 3B FF FF FF FF[/COLOR] 43 38 38 46 42 32 46 46 43 43 45 37 32 35 34 30
So our unlock code is present. Why it doesn't work?
If I take a look in my ta partition, before unlocking my bootloader, there is no 8b2 unit.
For the 8FD unit, i cannot find it.
So I cannot understand why your first try did not lock the bootloader. Maybe an issue with the usb cable and/or the booted mode, or just with the download of flashtool.
RO.maniac said:
You can continue this little study but just so you know, the screen just died on me. It started flicking all of a sudden and in under an hour is gave away for good. Now is backlit but no color.
So the test object is dead.
For the second time, after the main board water damage. I'm officially done with it. When my friend gets back in the country he'll find out his phone died again. ))
Click to expand...
Click to collapse
That's sad. I read some thread about dead backlights but not about screen. Did you think software cause this?
RO.maniac said:
As I've said, my screen died. So I decided to dump the phone and cleaned my pc of flashtool, xperia companion and all that.
Some minutes ago I decided to try another flash because my mind was running scenarios about the facts before the screen just died. What happened exactly before: TWRP backup, updated flashtool at startup, flashed N preview 3, in order to get the log so I can see if that Hero7 bootloader is coming with N preview. And it is indeed.
Booted and the screen was flicking with white flashes on the edges. In a few minutes I saw a vertical black line and then it turned black, but backlight on.
Today I thought, what the hell, flash it again, maybe it's not a hw problem. But now I know it is
So I installed an older version of flashtool, 0.9.18.6, and flashed N preview. Still dead screen
But this version of flashtool RELOCKED my bootloader. I could see the code written to TA and I can flash with Xperia Companion. Too bad I don't have a screen.
One in all, just dump this discussion and everything about my friend's damned Z3. Just close the drawer, as I've done.
Click to expand...
Click to collapse
Maybe it is just a connection problem between the motherboard and the screen. I read your other post so it maybe is 'just' a bad connection (cleaning or flyed-up)?
Anyway thanks a lot for your time, I learn a lot with information you provide! I will mostly help me for this project.
P.S.: don't forget I'm looking for a dev z3, broken screen is not a big deal for me Contact me privately if your friend is ok to sell that phone to me.
P.S.2: just for fun:
if you take a look in the (critical) 7DA ta unit it look like:
Code:
hexdump -C TA.img -s 0x0002073c -n 664
0002073c [COLOR="Magenta"]da 07 00 00[/COLOR] [COLOR="SeaGreen"]87 02 00 00[/COLOR] [COLOR="Blue"] c1 e9 f8 3b ff ff ff ff[/COLOR] |...........;....|
0002074c 73 eb 3d 40 59 80 18 1a 68 1a 33 84 5b a6 ad c3 |[email protected][...|
0002075c 45 d3 66 47 02 00 05 0a 02 00 00 00 0a db 37 24 |E.fG..........7$|
0002076c 02 0c b2 c4 85 f4 c9 6c 21 f1 84 33 29 4d 27 ff |.......l!..3)M'.|
0002077c 81 20 a3 65 b6 40 3c 80 16 c9 4a e3 1b 59 d6 54 |. [email protected]<...J..Y.T|
0002078c fa 50 37 82 f9 50 53 ce 1c dc aa fb 0b 98 96 e3 |.P7..PS.........|
0002079c 22 6a 02 00 00 00 0a d2 d9 95 24 b0 77 2b 91 59 |"j........$.w+.Y|
000207ac 59 f2 ee 30 a1 dc d9 88 c7 79 51 20 a2 19 73 0e |Y..0.....yQ ..s.|
000207bc 30 4c a1 29 94 4c 43 2b 8a cd 23 e9 3a 09 0b 03 |0L.).LC+..#.:...|
000207cc 06 74 6a 86 1f ce 97 ea 6c d0 b7 ba 00 90 4f 50 |.tj.....l.....OP|
000207dc 5f 49 44 3d 22 34 33 35 22 3b 4f 50 5f 4e 41 4d |_ID="435";OP_NAM|
000207ec 45 3d 22 43 75 73 74 6f 6d 69 7a 65 64 22 3b 43 |E="Customized";C|
000207fc 44 41 5f 4e 52 3d 22 31 32 38 38 2d 35 30 32 38 |DA_NR="1288-5028|
0002080c 22 3b 52 4f 4f 54 49 4e 47 5f 41 4c 4c 4f 57 45 |";ROOTING_ALLOWE|
0002081c 44 3d 22 31 22 3b 52 43 4b 5f 48 3d 22 46 41 45 |D="1";RCK_H="FAE|
0002082c 46 35 31 39 39 31 34 31 39 34 36 38 43 41 37 38 |F51991419468CA78|
0002083c 43 39 43 33 37 30 38 35 36 31 36 43 42 33 31 39 |C9C37085616CB319|
0002084c 42 39 46 36 36 45 30 35 30 45 34 33 31 38 34 37 |B9F66E050E431847|
0002085c 41 39 41 34 36 46 43 33 39 44 42 41 34 22 00 43 |A9A46FC39DBA4".C|
0002086c 53 45 52 56 45 52 49 44 3d 22 62 6d 63 73 65 63 |SERVERID="bmcsec|
0002087c 73 30 33 22 3b 41 55 54 48 43 45 52 54 3d 22 55 |s03";AUTHCERT="U|
0002088c 4e 4b 4e 4f 57 4e 22 3b 54 49 4d 45 53 54 41 4d |NKNOWN";TIMESTAM|
0002089c 50 3d 22 31 35 30 34 30 39 20 32 30 3a 33 31 3a |P="150409 20:31:|
000208ac 35 38 22 00 09 00 07 30 30 31 30 31 2d 2a 00 00 |58"....00101-*..|
000208bc 00 00 00 00 00 00 00 00 00 00 02 00 00 00 0a 4e |...............N|
000208cc d0 29 6b 2c bf 7b ec 14 0b bb 94 f5 9c fa 62 6a |.)k,.{........bj|
000208dc 1c 02 61 20 6d 79 f5 a7 3e ca c6 6e 30 69 30 f7 |..a my..>..n0i0.|
000208ec c3 a4 80 1e 60 bc ba e8 59 7d 5e 99 55 c4 47 e9 |....`...Y}^.U.G.|
000208fc f5 f5 58 be 02 00 00 00 0a 36 04 d9 c2 fd 86 a1 |..X......6......|
0002090c a1 3c 91 c1 d0 8d bb 35 ab a6 b1 10 f0 20 67 0e |.<.....5..... g.|
0002091c dc a5 62 dd 45 db 51 1e eb 6e f7 c6 95 58 f1 d4 |..b.E.Q..n...X..|
0002092c 39 73 5d 53 c5 22 14 b2 06 be 0c 01 ea 5f 02 00 |9s]S."......._..|
0002093c 00 00 0a 22 39 fe 4a f7 2e 93 6d a7 70 5d 3e 53 |..."9.J...m.p]>S|
0002094c a3 11 6c 96 70 84 18 20 3a 17 7b 00 05 63 1b fc |..l.p.. :.{..c..|
0002095c 6b 96 a4 e2 22 33 e2 05 7a 38 7b 72 81 60 ee ec |k..."3..z8{r.`..|
0002096c f9 da 55 c8 c1 81 e7 bd 02 00 00 00 0a cc 10 ff |..U.............|
0002097c a1 49 75 63 f3 c9 ee 40 fa d8 ac 09 65 b6 e6 dc |[email protected]|
0002098c a3 20 9c 57 33 bf 51 c3 ff 29 20 78 fa 57 2c 69 |. .W3.Q..) x.W,i|
0002099c a5 97 52 fc 33 fa 97 f6 3d 5d 38 89 e0 d7 34 1c |..R.3...=]8...4.|
000209ac 95 eb 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000209bc 00 00 14 57 0a e6 ee af 30 a1 e8 57 69 59 10 22 |...W....0..WiY."|
000209cc 6f 78 32 5c 5c f4 0b ff |ox2\\...|
000209d4
There is a RCK_H key. With the script provided here i enter your unlock code and the script answer that:
Code:
RCK_H="FAEF51991419468CA78C9C37085616CB319B9F66E050E431847A9A46FC39DBA4"
When you enter 'fastboot oem unlock <key>' the key is computed by s1 and compared to this information.