I bricked my phone (XT2041-1 "sofiar") by flashing an unnoficial build of TWRP 3.5.0 downloaded from a Telegram channel by doing:
$ fastboot flash recovery_a twrp-3.5.0-0-rav-sofia.img
$ fastboot flash recovery_b twrp-3.5.0-0-rav-sofia.img
$ fastboot reboot recovery
Since then, my phone is hard bricked - won't boot, recognized on Linux in EDL Mode only (i.e. ID 05c6:9008).
I got the latest official stock firmware, named SOFIAR_RETAIL_11_RPES31.Q4U-47-35-12_subsidy-DEFAULT_regulatory-DEFAULT_CFC.xml.zip, from lolinet, and in its contents there's boot.img and recovery.img (among others).
I have qdl on my Arch Linux, and am wondering whether I can use it to flash the stock recovery image back to both slots and get my phone booting again.
How should I approach it?
P.s. I also got a blankflash from https://forum.xda-developers.com/t/...equest-solicitud-blankflash-g8-power.4431193/ that is supposed to get the phone working again, but am unsure whether using it will cause loss of data.
I absolutely cannot lose any data from internal storage.
Any help appreciated. Thanks in advance.
Ok, now we're rolling...
First things first. Motorola sucks because they only give you restricted Firehose loaders.
That means of the 70-odd partitions that you have you can only read/write about 1/3 of them using EDL.
If you post your Firehose loader I can tell you which ones you can read/write.
Second, are you sure that the only damage you did was by writing recovery_a and recovery_b?
And you're on Linux, *sad face*.
I was disassembling the Motorola Firehose for my Moto G (2021) and I discovered that they have more reboot options than stock.
There's reset-to-edl and reset-to-fastboot.
I've added those options to my edl.exe (in the sig) this morning. You need to download the very latest.
What may have happened is that you wrote a bad recovery which may have set the boot option in the BCB or misc.
Since the recovery is good enough to be recognized as an image but not good enough to reset this boot option you're stuck.
Your first recourse is flashing a proper recovery.
I'm not sure whether "blank flash" tries to wipe everything. In any case I wouldn't risk it.
Your first try should be to fix the broken things, not everything.
Yes, any edl client that supports ad-hoc xml should be able to get you to fastboot but I'll only answer for my code.
I've tested it.
Code:
C:\>edl /lwhatever.bin
C:\>edl /zf
C:\>fastboot flash recovery_a good_recovery.img
C:\>fastboot flash recovery_b good_recovery.img
C:\>fastboot reboot
I admit to not properly understand what a firehose loader is. :x
Second, are you sure that the only damage you did was by writing recovery_a and recovery_b?
Click to expand...
Click to collapse
Yes, 100%.
So, for now, I should try booting Windows, installing the 9008 driver and following your instructions... Will let you know how it goes.
Thanks a lot.
marc.2377 said:
I admit to not properly understand what a firehose loader is. :x
Click to expand...
Click to collapse
A Firehose loader is a replacement xbl/sbl secondary loader that has special sauce added to it to make it interactive.
It is not to be confused with a Windows driver (which, in this case is Zadig, as per the instructions on my web page).
In this case, your Firehose loader is packed in singleimage.bin in the RPE here: https://mirrors.lolinet.com/firmware/motorola/sofiar/blankflash/
I extracted it for you. I renamed it sofiar.bin
The extension name does not matter.
Code:
C:\>edl /lsofiar.bin
That's slash-ell-sofiar.bin
Edit: And yes, your Firehose loader has the reset-to-fastboot.
Right, thanks for the explanation. I figured that was programmer.elf from my files.
Ok, I got as far as:
> edl /l
Found EDL 9008
Serial: 69cccc95
HWID: 0010a0e102e80000, QC: 0010a0e1, OEM: 02e8, Model: 0000
Hash: 974359c4290cac7f-9f0dc9a802815b5e-2b376b7a7c1be92c-1e816b5287f18610
> edl /lsofiar.bin
Found EDL 9008
Resetting Sahara
Serial: 69cccc95
HWID: 0010a0e102e80000, QC: 0010a0e1, OEM: 02e8, Model: 0000
Hash: 974359c4290cac7f-9f0dc9a802815b5e-2b376b7a7c1be92c-1e816b5287f18610
Sending sofiar.bin 100% Ok
Waiting for Firehose... Ok
> edl.exe /zf
Found EDL 9008
Requesting reset to fastboot... Ok
But it doesn't boot to fastboot.
It seems to me that your tool, edl could be used to write the recovery partition directly, no?
I tried this:
> edl /w /precovery_a recovery.img
Found EDL 9008
Configuring... Ok
Requesting GPT 0 header... Ok, receiving... Ok, requesting entries... Ok, receiving... Ok
Requesting write recovery.img...
<log value="ERROR: range restricted: lun=0, start_sector=1591552, num_sectors=131072" />
Nope
P.s. curiously, the file I downloaded from https://raw.githubusercontent.com/b...a/0010a0e102e80000_974359c4290cac7f_fhprg.bin wasn't accepted as a valid firehose loader file.
Edit: nevermind. Had to restart the phone.
I believe that's an older loader, anyway.
How shall I proceed?
marc.2377 said:
But it doesn't boot to fastboot.
Click to expand...
Click to collapse
Hmm, the screen stays black?
Is it still in EDL mode or some other mode?
Does Windows "bong" when you pull the USB cable?
It's possible that this goes to a fastboot without a screen?
Try holding various buttons, both by long power button reset and /zf
marc.2377 said:
It seems to me that your tool, edl could be used to write the recovery partition directly, no?
Click to expand...
Click to collapse
Yes, it could if Motorola wasn't such a pain with the "range restricted".
They've really clamped down (that other file you mentioned is the same):
Code:
qcomview /r sofiar.bin
Addr LUN Start Count
------ --- -------- --------
007f10 0 0 256
007f28 0 256 78336
007f40 0 1609948 512
007f58 0 1610496 512
007f70 1 1 1
You can do this to see which partitions this means:
Code:
C:\>edl /lsofiar.bin
C:\>edl /g
I have a feeling that the Motorola "Blankflash" stuff writes something to those 3 areas that allow it to write everything.
But it probably wipes the userdata.
I'm not an expert on their tools.
Tell me what the GPT says (you only need to quote stuff in the area of that table).
Edit: It looks like in the multi GB zip there are two "instruction" files, flashfile.xml and servicefile.xml
They are mostly the same except that flashfile will wipe userdata!
Curious. The partition table is as follows:
Code:
Found EDL 9008
Configuring... Ok
Requesting GPT 0 header... Ok, receiving... Ok, requesting entries... Ok, receiving... Ok
# Name Start Count Type
-- ---------------- ---------- ---------- --------------------
1 xbl_a 256 9216 Inactive
2 xbl_b 9472 9216 Bootloader
3 tz_a 18688 8192 Inactive
4 tz_b 26880 8192 TrustZone
5 rpm_a 35072 1024 Inactive
6 rpm_b 36096 1024 Resource/power mgmt
7 hyp_a 37120 1024 Inactive
8 hyp_b 38144 1024 Hypervisor
9 devcfg_a 39168 256 Inactive
10 devcfg_b 39424 256 Device config
11 xbl_config_a 39680 256 Inactive
12 xbl_config_b 39936 256 Boot config
13 abl_a 40192 2048 Inactive
14 abl_b 42240 2048 Android bootloader
15 uefisecapp_a 44288 4096 Inactive
16 uefisecapp_b 48384 4096 be8a7e08
17 qupfw_a 52480 160 Inactive
18 qupfw_b 52736 160 QUP firmware
19 cmnlib_a 52992 1024 Inactive
20 cmnlib64_a 54016 1024 Inactive
21 cmnlib_b 55040 1024 Common lib
22 cmnlib64_b 56064 1024 Common lib64
23 keymaster_a 57088 1024 Inactive
24 keymaster_b 58112 1024 Key master
25 storsec_a 59136 256 Inactive
26 storsec_b 59392 256 Store secure
27 spunvm 59648 16384 Spun VM
28 uefivarstore 76032 1024 165bd6bc
29 multiimgoem_a 77056 64 Inactive
30 multiimgoem_b 77120 64 e126a436
31 multiimgqti_a 77184 64 Inactive
32 multiimgqti_b 77248 64 846c6f05
33 prov_a 77312 512 Inactive
34 prov_b 77824 512 d05e0fc0
35 modem_a 78336 368640 Inactive
36 modem_b 446976 368640 FAT32
37 fsc 815616 256 FSC
38 ssd 815872 16 Secure SW download
39 dsp_a 816128 65536 Inactive
40 dsp_b 881664 65536 DSP
41 ddr 947200 2048 DDR
42 utags 949248 1024 1dd40d18
43 utagsBackup 950272 1024 c490f39c
44 modemst1 951296 8192 Modem ST1
45 modemst2 959488 8192 Modem ST2
46 fsg_a 967680 49152 Inactive
47 fsg_b 1016832 49152 Modem storage
48 persist 1065984 65536 Persist
49 prodpersist 1131520 16384 Persist
50 frp 1147904 1024 FRP
51 cid 1148928 256 459abd04
52 carrier 1149184 32768 c63d32d8
53 metadata 1181952 32768 988a98c9
54 kpan 1214720 16384 56465e10
55 boot_a 1231104 131072 Inactive
56 boot_b 1362176 131072 Boot
57 dtbo_a 1493248 49152 Inactive
58 dtbo_b 1542400 49152 DTBO
59 recovery_a 1591552 131072 Inactive
60 recovery_b 1722624 131072 Recovery
61 misc 1853696 2048 Misc
62 logfs 1855744 16384 Log FS
63 apdp 1872128 512 APDP
64 msadp 1872640 512 MSADP
65 dpo 1873152 2 DPO
66 devinfo 1873160 8 Device info
67 bluetooth_a 1873168 9216 Inactive
68 bluetooth_b 1882384 9216 Bluetooth
69 logo_a 1891600 66848 Inactive
70 logo_b 1958448 66848 Splash
71 vbmeta_a 2025296 128 Inactive
72 vbmeta_b 2025424 128 Verified Boot meta
73 padA 2025552 6064 Empty
74 hw 2031616 16384 b2d77ec0
75 padB 2048000 16384 Empty
76 sp 2064384 16384 40aef62a
77 padC 2080768 16384 Empty
78 padD 2097152 32768 Empty
79 super 2129920 16973824 System
80 userdata 19103744 103038943 User data
Doesn't seem to match the output of qcomview.
Also, the file 0010a0e102e80000_974359c4290cac7f_fhprg.bin lists the following codenames:
Code:
QCA6390
QCS605
SA8150
SDA670
SDA845
SDA855
SDA855A
SDA865
SDC830
SDM450
SDM670
SDM830
SDM845
SDM855
SDM855A
SDM1000
SDX24
SDX24M
SDX55
SM6150
SM6150P
SM7150
SM7150P
SM_NICOBAR
While programmer.elf (same as sofiar.bin that you uploaded) lists, additionally, QCM_NICOBAR and QCS_NICOBAR.
I wonder whether this is actually the correct file for me...
Btw, before attempting any further writing strategies, I confess to being interested in pulling userdata. As I understand the real decryption key is stored in the TEE functionality of the chipset and such an image would be unreadable for me, except if I were to restore it later.
With your tool I got the "range restricted" for edl /r /puserdata parts\userdata.img /t too.
Code:
Addr LUN Start Count
------ --- -------- --------
007f10 0 0 256 - GPT
007f28 0 256 78336 - xbl_a to prov_b
007f40 0 1609948 512 - ??? random spot in recovery_a
007f58 0 1610496 512 - ??? random spot in recovery_a
007f70 1 1 1
So, basically, you have free read/write access to partions 1 to 34
Reading is always safe.
Also, you're on the B slot.
So why does reboot to fastboot fail?
It could be that it was never implemented correctly in this Firehose
It could be that this Firehose is not for your device
It could be that xbl and/or abl was damaged somehow
I'd do some checking, xbl_b and abl_b to start with.
Read 'em then compare them to the xbl and abl you have in your big packages.
Code:
C:\>edl /lsofiar.bin
C:\>edl /r /t /pxbl_b xblb.img
C:\>edl /r /t /pabl_b ablb.img
The /t will copy these ELF files only as big as they need to be (not all the blank space).
OTOH, they will enlarge to an exact number of 512 byte sector.
So they could be 511 bytes bigger than what comes out of that package.
If things are wacky, try without /t, but they'll be padded with all the zeroes in the partition.
If those files aren't in the big package, here's ones I extracted from the blankflash.
Check 'em all.
Also, it's possible that somehow the slots got switched.
While you're at it, look at xbl_a and abl_a also.
Hey, thanks for the continued efforts to help me. Sorry for absence for the past days, real life caugh in ^^
I'm glad to report that, amidst some binary checking and all that, I managed to resuscitate my phone using the blankflash strategy, after carefully revising it.
Strangely, it seems that TWRP got installed in the boot partition, such as that "normal boot" kept entering TWRP, despite I having flashed the stock recovery images to both recovery slots. I'll detail this all later.
At this point my phone is on and I backed up what I needed, and have been using it. A few strange glitches are present, i.e. battery charging is acting weird. I plan on doing a clean flashing of the stock ROM soon. Maybe I should take the opportunity to study how to make a fully working port of the latest LineageOS for this device, too.
Will get back within a few days with a detailed report of the endeavour
marc.2377 said:
Will get back within a few days with a detailed report of the endeavour
Click to expand...
Click to collapse
I'm looking forward to hearing how you got EDL mode working.
I bricked XT2041-3 Sofiar (downgrade to A10) and am stuck trying the phone to succeed at qboot blank-flash, but it hangs (on linux):
Code:
< waiting for device >
Motorola qboot utility version 3.86
[ 0.000] Opening device: /dev/ttyUSB0
[ 0.000] Detecting device
[ 0.002] ...cpu.id = 266 (0x10a)
[ 0.002] ...cpu.sn = 3773339940 (0xe0e89924)
[ 0.002] Opening singleimage
[ 0.002] Loading package
[ 0.004] ...filename = pkg.xml
[ 0.005] Loading programmer
[ 0.005] ...filename = programmer.elf
[ 0.005] Sending programmer
[ 0.178] Handling things over to programmer
[ 0.178] Identifying CPU version
[ 0.178] Waiting for firehose to get ready
With --debug=2 there can be seen some parsing errors in xmls being passed for about 13 more seconds. On Windows VM phone is recognized as a single QDLoader 9008 device, but qboot fails after half a minute with IO Errors. Is this even EDL mode?
A tried without luck Renate's edl tool. edl.exe /lsingleimage.bin:
Code:
Found EDL 9008
Could not open device
I was growing increasingly desperate, so I opened the phone and played with EDL points according to
MatiasLopezxD. No combination of vol-, power, shorting points, plugging usb seem to make a difference. I must be missing something simple.
Any help would be appreciated.
@ybea: Quick answer for now - I got into EDL mode by holding down VolDown+Power for about 8-10 seconds. Let me know if it works for you. What's your output for lsusb?
Same as yours - ID 05c6:9008 (Qualcomm, Inc. Gobi Wireless Modem (QDL mode)). It reconnects after pressing power for 9 seconds (with or without vol-), nothing new.
Try restarting it into EDL mode while it's plugged. I found that to be necessary sometimes.
Edit: Btw, I don't remember why exactly, but I only had success running the blankflash from Windows. Linux didn't do the magic, nor a Windows VM with USB redirection...
marc.2377 said:
Edit: Btw, I don't remember why exactly, but I only had success running the blankflash from Windows. Linux didn't do the magic, nor a Windows VM with USB redirection...
Click to expand...
Click to collapse
That was it! I didn't event try it on the metal, because Motorola driver installer and uninstaller crash for me for some reason. Should be straightforward from now.
Thank you so much. You saved the day.
ybea said:
A tried without luck Renate's edl tool. edl.exe /lsingleimage.bin
Click to expand...
Click to collapse
Sorry. edl.exe uses the generic Zadig (i.e. WinUsb) driver).
If you have the Qualcomm driver loaded it's stealing the poor WinUsb interface and forcing it into some bogus virtual com port.
Also, singleimage is Motorola's completely morally bankrupt idea of packing stuff in a file.
It is not a Firehose loader, although it contains one.
Add to all your miseries, Motorola is crap and releases only restricted Firehose loaders.
If you're still stuck, ship me the "single-and-totally-bogus.bin" and I'll extract the Firehose loader for you.
Better poke me or I won't see it.
No longer stuck. The problem for me was neither VM USB passthrough nor blankflash tools for linux did work, although both showed proper EDL mode. It seems it only works on native Windows. Thanks for your interest.
Related
First of all i must thank @Shelnutt2 from lg-g2 irc channel who helped me to unbrick my phone and get it back alive. The whole process described bellow came from him.
Description of the problem:
Your LG G2 D802 is living this situation:
1- Rooted and got OTA
2- No Download mode
3- No recovery mode
4- Secure booting error
5- LG detected as qhsusb_bulk in device manager
6- When you boot your device it shows only LG logo with secure booting error, then the screen goes black while your phone is still on.
7- Other symptoms
The only solution for you is the following.
I'll explain the solution for an LG G2 D802 10a, then you can apply it for your device model by downloading the appropriate files.
You will need to use linux.
Ubuntu is good enough to make the job. You can use a virtual machine, live cd or a bootable usb stick.
So lets start.
Files to download from here
VERY IMPORTANT!!!!!!!
You must use the img files that correspond to the ROM you have installed before getting the problem to avoid breaking your phone. The link above is for 10b_EUR_16G firmware version. So don't use those files if your firmware version was not that one. Instead you should look for img files corresponding to the current version installed in your phone. If you don't know what version you've installed then don't use this method because you will break your phone.
1- sbl1.img
2- aboot.img
3- rpm.img
4- tz.img
5- openrecovery-twrp-2.6.3.2-g2d802
Thanks to @sabooakhte who has shared his experience:
IMPORTANT: NEVER FLASH ORIGINAL RECOVERY.IMG TO THE RECOVERY PARTITION!!!
Click to expand...
Click to collapse
Now just boot into ubuntu and plug your LG G2 to the computer.
Put the downloaded files in the desktop or wherever you want. You just need to know the path to your files.
unplug any other usb device except your mouse, keyboard and lg g2.
Open terminal in ubuntu then type:
Code:
ls /dev/sd*
It should return something like this:
/dev/sda /dev/sda1 /dev/sda2 /dev/sda5
/dev/sdb1 /dev/sdb2 /dev/sdb3 /dev/sdb4
/dev/sdb5 .......... /dev/sdb36
Click to expand...
Click to collapse
In this case your device is detected under sdb. you may have it under sdc. just look for the biggest number, in this case /dev/sdb36 so it is sdb.
Linux keeps poping up error message "unable to mount..."? follow this solution by @priority3
priority3 said:
You can stop the "unable to mount..." error messages from popping up by disabling
the automount feature of Ubuntu.
"To enable or disable automount open a terminal and type dconf-editor followed by the [Enter] key.
Browse to org.gnome.desktop.media-handling."
Click to expand...
Click to collapse
now, according to the result of the first command type the following:
Code:
gdisk -l /dev/sdb
you will get result:
Code:
Number Start (sector) End (sector) Size Code Name
1 32768 163839 64.0 MiB 0700 modem
[COLOR="Red"]2 163840 165887 1024.0 KiB FFFF sbl1[/COLOR]
3 165888 166911 512.0 KiB FFFF dbi
4 196608 197631 512.0 KiB FFFF DDR
[COLOR="red"]5 229376 231423 1024.0 KiB FFFF aboot[/COLOR]
[COLOR="red"] 6 231424 233471 1024.0 KiB FFFF rpm[/COLOR]
7 262144 294911 16.0 MiB FFFF boot
[COLOR="red"] 8 294912 296959 1024.0 KiB FFFF tz[/COLOR]
9 296960 296961 1024 bytes 0700 pad
10 327680 333823 3.0 MiB FFFF modemst1
11 333824 339967 3.0 MiB FFFF modemst2
12 339968 339969 1024 bytes FFFF pad1
13 360448 393215 16.0 MiB FFFF misc
14 393216 458751 32.0 MiB 0700 persist
[COLOR="red"]15 458752 491519 16.0 MiB FFFF recovery[/COLOR]
16 491520 497663 3.0 MiB FFFF fsg
17 524288 525311 512.0 KiB FFFF fsc
18 525312 526335 512.0 KiB FFFF ssd
19 526336 526337 1024 bytes FFFF pad2
20 526338 527361 512.0 KiB FFFF encrypt
21 557056 573439 8.0 MiB 0700 drm
22 573440 589823 8.0 MiB 0700 sns
23 589824 655359 32.0 MiB FFFF laf
24 655360 720895 32.0 MiB FFFF fota
25 720896 786431 32.0 MiB 0700 mpt
26 786432 787455 512.0 KiB FFFF dbibak
27 787456 789503 1024.0 KiB FFFF rpmbak
28 789504 791551 1024.0 KiB FFFF tzbak
29 791552 791567 8.0 KiB FFFF rct
30 819200 6488063 2.7 GiB 0700 system
31 6488064 7733247 608.0 MiB 0700 cache
32 7733248 7897087 80.0 MiB 0700 tombstones
33 7897088 7929855 16.0 MiB 0700 spare
34 7929856 8028159 48.0 MiB 0700 cust
35 8028160 30703615 10.8 GiB 0700 userdata
36 30703616 30777310 36.0 MiB 0700 grow
We will be interested by lines marked by red color here. those lines show us the partitions numbers of each file we have downloaded at the begining.
I'm talking about
1- sbl1.img
2- aboot.img
3- rpm.img
4- tz.img
5- openrecovery-twrp-2.6.3.2-g2d802
in our case the sbl1.img is located under sdb2
aboot.img under sdb5
rpm.img under sdb6
tz.img under sdb8
recovery under sdb15
now be careful and try to make it the right way.
we will use dd commands to push img files inside the right partitions.
So lets start:
if youare not logged on as root in ubuntu just open terminal and type
Code:
sudo -i
then type your password
now you must be under root access.
then type the following dd command:
Code:
dd if=[COLOR="Red"]/home/med/Desktop/[/COLOR]sbl1.img of=/dev/sdb2
i put files in the desktop, so the path to the img files for me is /home/med/Desktop/. just replace this path by the appropriate path to your files. one done you will get some information about the file size you pushed and maybe time of the operation.
keep doing the samething for the other files:
Code:
dd if=/home/med/Desktop/aboot.img of=/dev/sdb5
dd if=/home/med/Desktop/rpm.img of=/dev/sdb6
dd if=/home/med/Desktop/tz.img of=/dev/sdb8
dd if=/home/med/Desktop/openrecovery-twrp-2.6.3.2-g2d802 of=/dev/sdb15
Once you finish just reboot your phone, if you did things as described you must boot into twrp recovery.
now just use twrp to flash your ROM and follow this tutorial to reboot into your ROM
http://forum.xda-developers.com/showthread.php?t=2451696
Good Luck.
If you have fixed your your phone you can consider to pay me a coffee cup
paypal: [email protected]
Thank you, My D800 is working after two weeks
Sent from my LG-D800 using Tapatalk
geodano said:
Thank you, My D800 is working after two weeks
Sent from my LG-D800 using Tapatalk
Click to expand...
Click to collapse
Glade to know that.:good:
This process is the same on Verizon LG G2 (VS980). Thanks to Shelnutt2 and Automprime for helping me do the same and great job posting a clear set of instructions Partage!
swagner53 said:
This process is the same on Verizon LG G2 (VS980). Thanks to Shelnutt2 and Automprime for helping me do the same and great job posting a clear set of instructions Partage!
Click to expand...
Click to collapse
nice to see you here swr. :laugh:
swagner53 said:
This process is the same on Verizon LG G2 (VS980). Thanks to Shelnutt2 and Automprime for helping me do the same and great job posting a clear set of instructions Partage!
Click to expand...
Click to collapse
I'm trying to do this on my Verizon LG G2. When I plug the device into Ubuntu runing in live mode. I geta bunch errors poping up that it's not able to connect the partitions. Is there a way to stop this so i can continue with the process?
toopty said:
I'm trying to do this on my Verizon LG G2. When I plug the device into Ubuntu runing in live mode. I geta bunch errors poping up that it's not able to connect the partitions. Is there a way to stop this so i can continue with the process?
Click to expand...
Click to collapse
is it detected as Qualcomm HSUSB_BULK or something else?
Partager.info said:
is it detected as Qualcomm HSUSB_BULK or something else?
Click to expand...
Click to collapse
Under windows yes that is what it was showing up as. When i plugged the phone into a windows box i get the same thing with it trying to connect a whole bunch of drives if that helps any.
toopty said:
Under windows yes that is what it was showing up as. When i plugged the phone into a windows box i get the same thing with it trying to connect a whole bunch of drives if that helps any.
Click to expand...
Click to collapse
I'm talking about linux.
Partager.info said:
I'm talking about linux.
Click to expand...
Click to collapse
Yes i am working from a live linux disk now and it was throwing up a lot of windows about unmounted disks. I was just letting you know about the partitoins in Windows as well as Linux. I've tried to flash the recovery partitoin. Even with the messages coming up. After reboot now i get a Fastboot mode started message on my phone. How should i procede?
@Partager.info the phone is turned off when you connect it to the pc or it have to be turned on once then wait to screen goes off? In qhsusb_bulk mode we can see the partitions in linux, or in linux the phone is not in qhsusb_bulk mode. qhsusb_bulk and Qualcomm HS-USB QDLoader 9008 are the same?
toopty said:
Yes i am working from a live linux disk now and it was throwing up a lot of windows about unmounted disks. I was just letting you know about the partitoins in Windows as well as Linux. I've tried to flash the recovery partitoin. Even with the messages coming up. After reboot now i get a Fastboot mode started message on my phone. How should i procede?
Click to expand...
Click to collapse
Did you use the described method in this tutorial to flash recovery?
If yes, then you should know that it is not enough to push only recovery. you should push all files in the tutorial.
bitdomo said:
@Partager.info the phone is turned off when you connect it to the pc or it have to be turned on once then wait to screen goes off? In qhsusb_bulk mode we can see the partitions in linux, or in linux the phone is not in qhsusb_bulk mode. qhsusb_bulk and Qualcomm HS-USB QDLoader 9008 are the same?
Click to expand...
Click to collapse
actually once you plug your phon to PC it should start automaticallly if it is shutdown. Then the screen goes black whil the phone is still on.
If you have installed qshusb_dload drivers then it is detected as Qualcomm HS-USB QDLoader 9006 or 9008.
and yes you can see partitions in linux but you can't see their content. that's why we use dd commands to push img files inside the appropriate partitions.
Partager.info said:
actually once you plug your phon to PC it should start automaticallly if it is shutdown. Then the screen goes black whil the phone is still on.
If you have installed qshusb_dload drivers then it is detected as Qualcomm HS-USB QDLoader 9006 or 9008.
and yes you can see partitions in linux but you can't see their content. that's why we use dd commands to push img files inside the appropriate partitions.
Click to expand...
Click to collapse
So if there is some whose phone doesn't turn on at all, just goes to directly to qhsub_dload becuase he/she killed the bootloader, then we can dd the bl images to the phone in linux? Am I correct? .
Sorry for asking such things, but this is really an interesting thing.
Sent from my Nexus 5 using xda app-developers app
bitdomo said:
So if there is some whose phone doesn't turn on at all, just goes to directly to qhsub_dload becuase he/she killed the bootloader, then we can dd the bl images to the phone in linux? Am I correct? .
Sorry for asking such things, but this is really an interesting thing.
Sent from my Nexus 5 using xda app-developers app
Click to expand...
Click to collapse
If you are experiencing the problem just give it a try.
Partager.info said:
If you are experiencing the problem just give it a try.
Click to expand...
Click to collapse
No I am not, but there are lot of people with different devices stucked in that qhsusb_dload mode.
You have a half bricked bootloader, since your phone gave sime sort sign of life when it turned on showed you that error. But i dont know what if it is totaly bricked.
Sent from my Nexus 5 using xda app-developers app
can i use cygwin in windows ?
Partager.info said:
Did you use the described method in this tutorial to flash recovery?
If yes, then you should know that it is not enough to push only recovery. you should push all files in the tutorial.
Click to expand...
Click to collapse
I did push all the files, but it was very difficult because my device kept disconnecting while it was trying to connect all the drives on the phone. One of them must have not successfully pushed. I was able to flash all the files I needed via fastboot. Your method got me to that point. I was then able to get into Twrp and run the command at this link to get my phone to boot. http://forum.xda-developers.com/showthread.php?t=2451696. Now I have a working phone.
Thank you for all your help. Without guys like you I would not have been able to recover my phone.
Is there any way this can work on windows? I have this problem and just got back home and ready to jump on any fixes available
I almost finished the process in ubuntu but now when my phone is plugged in it keeps flashing on and off it seems and ubuntu seems to freeze while doing so like the phone is opening up a lot of files.. Im just going to call verizon or something tomorrow to see if i can get a replacement nothing seems to be working did anyone have this problem? ? or is it just me
good morning,
I've got 3 galaxy S4 (I-9505) and for some purpose (and testing) I want to clone one into another one (just to test strange different behaviours between two of them, apparently with same android version etc).
I dumped the full internal eeprom, as a 16GB file, with dd throw adb, and now I'm trying to restore this image in another phone.
the destination phone has CWM recovery installed and booted, the image is visible from external sd, but I've tried with netcat as well...
what happens is that after writing to /dev/block/mmcblk0, after average 30MB I receive an input/output error, and adb crashed. on the phone the recovery appears active, but not fully working... if I choose any menu it waits forever. phone is not detected ltil I restart it in recovery again.
I tried moving ahead with "dd seek & skip" to start a bit further and the same happens.
it works only if I start from the efs partition.
this is my layout:
Number Start End Size File system Name Flags
1 8192s 33735s 25544s apnhlos
2 33736s 139263s 105528s mdm
3 139264s 139519s 256s sbl1
4 139520s 140031s 512s sbl2
5 140032s 141055s 1024s sbl3
6 141056s 145151s 4096s aboot
7 145152s 146175s 1024s rpm
8 146176s 147199s 1024s tz
9 147200s 180991s 33792s pad
10 180992s 208895s 27904s ext4 efs
11 208896s 215039s 6144s modemst1
12 215040s 221183s 6144s modemst2
13 221184s 222743s 1560s m9kefs1
14 222744s 224303s 1560s m9kefs2
15 224304s 225863s 1560s m9kefs3
16 225864s 5878343s 5652480s ext4 system
17 5878344s 5894727s 16384s persist
18 5894728s 10134087s 4239360s ext4 cache
19 10134088s 10146375s 12288s param
20 10146376s 10166855s 20480s boot
21 10166856s 10187335s 20480s recovery
22 10187336s 10207815s 20480s fota
23 10207816s 10220103s 12288s backup
24 10220104s 10226247s 6144s fsg
25 10226248s 10226263s 16s ssd
26 10226264s 10244695s 18432s ext4 persdata
27 10244696s 11268695s 1024000s ext4 hidden
28 11268696s 11309655s 40960s carrier
29 11309656s 30765655s 19456000s ext4 userdata
so if I start writing from sector 180992 it goes up to the end and the phone boots.
what could be the cause of not being able to write from the beginning?
david
I suppose it's the bootloader protecting from writing operation in sensible area. but I thought it was not acting while raw writing the block device.
guess it fails when trying to write in the same area where odin refuses non-signed .bin files.
I've two jtag boxes... so the only way to flash the whole mmcblk0 image is through jtag interface (luckily confortable on the S4)?
guess so as well. but as you said I thought it didn't act like that raw writing.
I've got 2 jtag box as well, and will give a try with them. yes S4 is nice with that, with large confortable pads.
david
Are there any tools / is it possible to download partitions (img files) from a Qualcomm device using emergency download mode? Simply boot_a / boot_b as I assume user will be encrypted.
I know there is QPST, but from hours of trying and what I have read, it seems to only support older MSM devices not newer Snapdragon? Am I wrong?
Well, if you have the firehose file for that particular soc and the rawprogram0.xml, you can. Usually the firehose file get leaked after the phone is released.
What model are you trying to work on?
HTC U19e
Snapdragon 710
outrage_uk said:
HTC U19e
Snapdragon 710
Click to expand...
Click to collapse
I found a link to a list of programmers. If you see your phone here, which I didn't (but try ctrl-f the processor, that should be in the filename, it's a good bet you'll be able to find it. As far as I know, my phone's MSM8998 does not have a leaked programmer. It's not as universally applicable as a lot of guides make it seem. If you do have the programmer and correct patches, they allow arbitrary read/write to a phone in edl mode. It's a major security backdoor, but very useful for users like us too. However, neither users like us, nor malicious agents are thought very highly of by American phone manufacturers.
Here's how to access partitions without rawprogram0.xml or patch0.xml
Hi,
If you have the correct prog_emmc_firehose_xxxx.mbn file for your QualComm SoC, you can extract the partition table and all partitions without having access to any rawprogram0.xml or patch0.xml.
The basics are in the excellent guide at https://forum.xda-developers.com/android/general/guide-how-to-dump-write-storage-t3949588
Summary:
- trigger EDL mode, which you have if your phone shows up as USB vendor 05c6, product 9008. Make sure you have "Qualcomm HS-USB QDLoader 9008" as the active driver, giving you a virtual COM port.
- use QFIL to load the prog_emmc_firehose_xxx.mbn file - chose Flat Build
- use QPST's fh_loader.exe to talk to the firehose to read or write the emmc at arbitrary sector offsets
With all that working, you can start by reading the GPT partition table, 34 sectors starting from sector 0:
"C:\Program Files (x86)\Qualcomm\QPST\bin\fh_loader.exe" --port=\\.\COM8 --search_path=C:\my\extract\path --convertprogram2read --sendimage=gpt.bin --start_sector=0 --lun=0 --num_sectors=34 --noprompt --showpercentagecomplete --zlpawarehost=1 --memoryname=emmc
Replace COM8 with whatever COM port that Qualcomm HS-USB driver providers according to Windows Device Manager, and ensure that whatever you choose as C:\my\extract\path exists.
When the tool is done, you'll have a C:\my\extract\path\gpt.bin that you can examine to get the sector offsets and counts for each of your partitions. I used Linux' gdisk for that:
$ gdisk -l gpt.bin
...
Number Start (sector) End (sector) Size Code Name
1 131072 294911 80.0 MiB 0700 modem
2 294912 296959 1024.0 KiB FFFF bluetooth
3 296960 297215 128.0 KiB A01E pmic
4 297216 297471 128.0 KiB A01E pmicbak
5 297472 297473 1024 bytes A040 limits
6 297474 299521 1024.0 KiB A01A DDR
7 299522 299777 128.0 KiB A01D sec
8 393216 393727 256.0 KiB A022 apdp
9 393728 394239 256.0 KiB A023 msadp
10 394240 394241 1024 bytes A024 dpo
11 524288 527359 1.5 MiB A02A fsg
12 655360 655361 1024 bytes A029 fsc
13 655362 655377 8.0 KiB A02C ssd
14 655378 658449 1.5 MiB A027 modemst1
15 658450 661521 1.5 MiB A028 modemst2
16 661522 663569 1024.0 KiB A012 sbl1
17 663570 665617 1024.0 KiB A012 sbl1bak
18 665618 665809 96.0 KiB A019 sdi
19 665810 667857 1024.0 KiB A016 tz
20 667858 669905 1024.0 KiB A016 tzbak
21 669906 670905 500.0 KiB A018 rpm
22 670906 671905 500.0 KiB A018 rpmbak
23 671906 672929 512.0 KiB A017 hyp
24 672930 673953 512.0 KiB A017 hypbak
25 673954 740801 32.6 MiB FFFF splash
26 786432 796671 5.0 MiB A015 aboot
27 796672 806911 5.0 MiB A015 abootbak
28 806912 937983 64.0 MiB A036 boot
29 937984 1069055 64.0 MiB A025 recovery
30 1069056 7360511 3.0 GiB A038 system
31 7471104 10616831 1.5 GiB A039 cache
32 10616832 10682367 32.0 MiB A026 persist
33 10682368 10684415 1024.0 KiB A01F misc
34 10684416 10685439 512.0 KiB A02D keystore
35 10747904 10747905 1024 bytes A021 devinfo
36 10878976 10879999 512.0 KiB FFFF config
37 10880000 61071326 23.9 GiB A03A userdata
From there, you have enough information to back up each of your partitions, write a custom recovery, etcetera.
In my case, a Gigaset ME, both the system and userdata partitions were normal, unencrypted ext4 partitions with ample opportunities for forensics and data recovery.
Needless to say, there was no need to unlock bootloaders, install custom recovery, root the phone, or whatever.
There are some posts on how to root the Xiaomi Redmi 9 (Galahad/Lancelot) phone, but since they have lots of "don't know" phrases (or files of unknown origin), I've managed to do the whole process from scratch.
Lancelot or Galahad
Basically, the codename for Xiaomi Redmi 9 phone is Lancelot. But when you get shell via ADB, you will see Galahad. This can cause lots of confusion because you may think that Galahad and Lancelot are two different phones. In reality they're the same phone. Moreover, the specs of the Xiaomi Redmi 9 says that the phone has a MT6769T SoC (the info comes from the phone's /proc/cpuinfo). But it looks like the official ROM, TWRP, even CPU-Z treats the phone as if it had the MT6768 SoC. So keep that in mind when you look for some info concerning the phone.
The phone was bought in Europe/Poland last year (the black Friday, 2020) from the official source. Here's some more info:
Code:
galahad:/ # getprop | grep -i model
[ro.product.model]: [M2004J19C]
[ro.product.odm.model]: [M2004J19C]
[ro.product.product.model]: [M2004J19C]
[ro.product.system.model]: [M2004J19C]
[ro.product.vendor.model]: [M2004J19C]
galahad:/ # getprop | grep -i ro.build.version.
[ro.build.version.base_os]: [Redmi/galahad_eea/galahad:10/QP1A.190711.020/V12.0.0.1.QJCEUXM:user/release-keys]
[ro.build.version.incremental]: [V12.0.1.0.QJCEUXM]
[ro.build.version.security_patch]: [2021-01-05]
galahad:/ # getprop | grep -i baseband
[gsm.version.baseband]: [MOLY.LR12A.R3.MP.V98.P75,MOLY.LR12A.R3.MP.V98.P75]
[ro.baseband]: [unknown]
[vendor.gsm.project.baseband]: [HUAQIN_Q0MP1_MT6769_SP(LWCTG_CUSTOM)]
$ fastboot getvar all
...
(bootloader) product: lancelot
...
(bootloader) version-baseband: MOLY.LR12A.R3.MP.V98.P75
(bootloader) version-bootloader: lancelot-2b1e22f-20201123162228-2021011
(bootloader) version-preloader:
(bootloader) version: 0.5
...
The bootloader unlock
Before you even start thinking of flashing the TWRP image to the Xiaomi Redmi 9 (Galahad/Lancelot) phone, you have to unlock it's bootloader first. It's a straightforward operation, but you need some proper tools to achieve that. If you're using windows, use Mi Unlock, if you're on linux, use xiaomitool. I'm a linux user so I can't help with this process those of you who use windows. If you're going to use xiaomitool, there's a bug in the current version (20.7.28 beta), and you have to patch the source yourself to make it work again. It's not hard. There's an article step by step how to do it. It's in Polish, but all the necessary commands are included so you can just ctrl+c and ctrl+v.
When you unlock the bootloader, you can flash the TWRP image, so make sure you have the following in the Developer options:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
The TWRP image
There are some prebuilt TWRP images in the wild, but I wanted source of the files, and I couldn't get any. But I've managed to target this device tree. I attached the twrp-recovery.img (64MiB) file in this post. It looks like the TWRP image built from that source has everything that's needed, so you won't really have to build it yourself. If you want to build the TWRP image yourself from the provided source, you have to go through setting up the android build environment.
Flashing the TWRP image
When you have the TWRP image, you can flash it to the Xiaomi Redmi 9 (Galahad/Lancelot) phone using fastboot. On Debian, you just install the fastboot package. To flash the TWRP image, turn off you phone, turn it on using volumeDown+power, plug the phone via USB to your desktop/laptop and issue the following command:
Code:
$ fastboot flash recovery twrp-recovery.img
Remember one thing. This flashing has only a temporary effect. When you boot the device in a normal mode, the recovery partition will be automatically regenerated and flashed by your phone. So when you issue the command above, boot to recovery via:
Code:
$ fastboot reboot recovery
After you boot into TWRP recovery, it will ask for password. This is the password that you use to unlock your phone's lock screen.
Backup the phone's flash
The temporary TWRP recovery is needed to take the backup of the whole phone's flash. The only partition that has been changed is the recovery partition. Other partitions are intact. In this way, you can backup partitions that hold IMEI, WiFi/BT MACs, and other important stuff. If something goes wrong, you can restore the phone to it's default state (after unlocking) using fastboot and the partition images.
To make the backup of the whole phone's flash, use the following command:
Code:
$ adb pull /dev/block/mmcblk0 mmcblk0.img
This command is issued from your desktop/laptop computer, and not from the phone. Of course you could just use the dd command and backup the flash to the external SD card, but my external SD was only 32G, and the phone's flash is 64G. Besides it's better to store the phone's flash on your computer for future use.
The process of taking a backup is rather slow. It took around 2h (14M/s). After it finishes, you can check whether everything with the image is OK by looking into the image using the gdisk tool:
Code:
$ adb pull /dev/block/mmcblk0 mmcblk0.img
/dev/block/mmcblk0: 1 file pulled. 14.0 MB/s (62537072640 bytes in 4266.682s)
# gdisk -l /media/Zami/mmcblk0.img
GPT fdisk (gdisk) version 1.0.7
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /media/Zami/mmcblk0.img: 122142720 sectors, 58.2 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 00000000-0000-0000-0000-000000000000
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 122142686
Partitions will be aligned on 16-sector boundaries
Total free space is 61 sectors (30.5 KiB)
Number Start (sector) End (sector) Size Code Name
1 64 131135 64.0 MiB 0700 recovery
2 131136 132159 512.0 KiB 0700 misc
3 132160 133183 512.0 KiB 0700 para
4 133184 174143 20.0 MiB 0700 expdb
5 174144 176191 1024.0 KiB 0700 frp
6 176192 192575 8.0 MiB 0700 vbmeta
7 192576 208959 8.0 MiB 0700 vbmeta_system
8 208960 225343 8.0 MiB 0700 vbmeta_vendor
9 225344 271631 22.6 MiB 0700 md_udc
10 271632 337167 32.0 MiB 0700 metadata
11 337168 402703 32.0 MiB 0700 nvcfg
12 402704 533775 64.0 MiB 0700 nvdata
13 533776 632079 48.0 MiB 0700 persist
14 632080 730383 48.0 MiB 0700 persistbak
15 730384 746767 8.0 MiB 0700 protect1
16 746768 770047 11.4 MiB 0700 protect2
17 770048 786431 8.0 MiB 0700 seccfg
18 786432 790527 2.0 MiB 0700 sec1
19 790528 796671 3.0 MiB 0700 proinfo
20 796672 797695 512.0 KiB 0700 efuse
21 797696 850943 26.0 MiB 0700 boot_para
22 850944 982015 64.0 MiB 0700 nvram
23 982016 998399 8.0 MiB 0700 logo
24 998400 1260543 128.0 MiB 0700 md1img
25 1260544 1262591 1024.0 KiB 0700 spmfw
26 1262592 1274879 6.0 MiB 0700 scp1
27 1274880 1287167 6.0 MiB 0700 scp2
28 1287168 1289215 1024.0 KiB 0700 sspm_1
29 1289216 1291263 1024.0 KiB 0700 sspm_2
30 1291264 1324031 16.0 MiB 0700 gz1
31 1324032 1356799 16.0 MiB 0700 gz2
32 1356800 1360895 2.0 MiB 0700 lk
33 1360896 1364991 2.0 MiB 0700 lk2
34 1364992 1496063 64.0 MiB 0700 boot
35 1496064 1528831 16.0 MiB 0700 dtbo
36 1528832 1539071 5.0 MiB 0700 tee1
37 1539072 1549311 5.0 MiB 0700 tee2
38 1549312 1582079 16.0 MiB 0700 gsort
39 1582080 1844223 128.0 MiB 0700 minidump
40 1844224 2630655 384.0 MiB 0700 exaid
41 2630656 4727807 1024.0 MiB 0700 cust
42 4727808 4744191 8.0 MiB 0700 devinfo
43 4744192 4767743 11.5 MiB 0700 ffu
44 4767744 19447807 7.0 GiB 0700 super
45 19447808 20332543 432.0 MiB 0700 cache
46 20332544 122021823 48.5 GiB 0700 userdata
47 122021824 122109887 43.0 MiB 0700 otp
48 122109888 122142655 16.0 MiB 0700 flashinfo
As you can see, there's the whole flash layout with all the partitions in their stock state (except for the recovery partition, of course). If something goes wrong, you can extract the individual partition by mounting the image on a linux system in the following way:
Code:
# losetup /dev/loop5 /media/Zami/mmcblk0.img
# losetup -a
/dev/loop5: [64769]:12 (/media/Zami/mmcblk0.img)
The above command uses the /dev/loop5 device to mount the image. Since the image has many partitions, the corresponding devices will be created for each partition, which looks like this:
Code:
# ls -al /dev/loop5*
brw-rw---- 1 root disk 7, 320 2021-08-29 02:54:11 /dev/loop5
brw-rw---- 1 root disk 7, 321 2021-08-29 02:54:11 /dev/loop5p1
brw-rw---- 1 root disk 7, 330 2021-08-29 02:54:11 /dev/loop5p10
brw-rw---- 1 root disk 7, 331 2021-08-29 02:54:11 /dev/loop5p11
brw-rw---- 1 root disk 7, 332 2021-08-29 02:54:11 /dev/loop5p12
brw-rw---- 1 root disk 7, 333 2021-08-29 02:54:11 /dev/loop5p13
brw-rw---- 1 root disk 7, 334 2021-08-29 02:54:11 /dev/loop5p14
brw-rw---- 1 root disk 7, 335 2021-08-29 02:54:11 /dev/loop5p15
brw-rw---- 1 root disk 7, 336 2021-08-29 02:54:11 /dev/loop5p16
brw-rw---- 1 root disk 7, 337 2021-08-29 02:54:11 /dev/loop5p17
brw-rw---- 1 root disk 7, 338 2021-08-29 02:54:11 /dev/loop5p18
brw-rw---- 1 root disk 7, 339 2021-08-29 02:54:11 /dev/loop5p19
brw-rw---- 1 root disk 7, 322 2021-08-29 02:54:11 /dev/loop5p2
brw-rw---- 1 root disk 7, 340 2021-08-29 02:54:11 /dev/loop5p20
brw-rw---- 1 root disk 7, 341 2021-08-29 02:54:11 /dev/loop5p21
brw-rw---- 1 root disk 7, 342 2021-08-29 02:54:11 /dev/loop5p22
brw-rw---- 1 root disk 7, 343 2021-08-29 02:54:11 /dev/loop5p23
brw-rw---- 1 root disk 7, 344 2021-08-29 02:54:11 /dev/loop5p24
brw-rw---- 1 root disk 7, 345 2021-08-29 02:54:11 /dev/loop5p25
brw-rw---- 1 root disk 7, 346 2021-08-29 02:54:11 /dev/loop5p26
brw-rw---- 1 root disk 7, 347 2021-08-29 02:54:11 /dev/loop5p27
brw-rw---- 1 root disk 7, 348 2021-08-29 02:54:11 /dev/loop5p28
brw-rw---- 1 root disk 7, 349 2021-08-29 02:54:11 /dev/loop5p29
brw-rw---- 1 root disk 7, 323 2021-08-29 02:54:11 /dev/loop5p3
brw-rw---- 1 root disk 7, 350 2021-08-29 02:54:11 /dev/loop5p30
brw-rw---- 1 root disk 7, 351 2021-08-29 02:54:11 /dev/loop5p31
brw-rw---- 1 root disk 7, 352 2021-08-29 02:54:11 /dev/loop5p32
brw-rw---- 1 root disk 7, 353 2021-08-29 02:54:11 /dev/loop5p33
brw-rw---- 1 root disk 7, 354 2021-08-29 02:54:11 /dev/loop5p34
brw-rw---- 1 root disk 7, 355 2021-08-29 02:54:11 /dev/loop5p35
brw-rw---- 1 root disk 7, 356 2021-08-29 02:54:11 /dev/loop5p36
brw-rw---- 1 root disk 7, 357 2021-08-29 02:54:11 /dev/loop5p37
brw-rw---- 1 root disk 7, 358 2021-08-29 02:54:11 /dev/loop5p38
brw-rw---- 1 root disk 7, 359 2021-08-29 02:54:11 /dev/loop5p39
brw-rw---- 1 root disk 7, 324 2021-08-29 02:54:11 /dev/loop5p4
brw-rw---- 1 root disk 7, 360 2021-08-29 02:54:11 /dev/loop5p40
brw-rw---- 1 root disk 7, 361 2021-08-29 02:54:11 /dev/loop5p41
brw-rw---- 1 root disk 7, 362 2021-08-29 02:54:11 /dev/loop5p42
brw-rw---- 1 root disk 7, 363 2021-08-29 02:54:11 /dev/loop5p43
brw-rw---- 1 root disk 7, 364 2021-08-29 02:54:11 /dev/loop5p44
brw-rw---- 1 root disk 7, 365 2021-08-29 02:54:11 /dev/loop5p45
brw-rw---- 1 root disk 7, 366 2021-08-29 02:54:11 /dev/loop5p46
brw-rw---- 1 root disk 7, 367 2021-08-29 02:54:11 /dev/loop5p47
brw-rw---- 1 root disk 7, 368 2021-08-29 02:54:11 /dev/loop5p48
brw-rw---- 1 root disk 7, 325 2021-08-29 02:54:11 /dev/loop5p5
brw-rw---- 1 root disk 7, 326 2021-08-29 02:54:11 /dev/loop5p6
brw-rw---- 1 root disk 7, 327 2021-08-29 02:54:11 /dev/loop5p7
brw-rw---- 1 root disk 7, 328 2021-08-29 02:54:11 /dev/loop5p8
brw-rw---- 1 root disk 7, 329 2021-08-29 02:54:11 /dev/loop5p9
To extract some partition (for instance the stock boot), use the following command:
Code:
# dd if=/dev/loop5p34 of=./34-stock-boot.img
Extracting any of the partitions from the backup creates a file that can be flashed via fastboot or directly via dd from TWRP recovery. So as long as fastboot (or TWRP recovery) works and you are able to switch to that mode, you shouldn't brick the phone for good. All the bricks should be only temporary and they go away when you flash the stock partitions to the changed ones. So pay attention what changes you commit to the phone's flash.
The Magisk app and a bootloop
To sum up, we have a backup of the phone's flash on our computer, we have flashed a temp TWRP image to the recovery partition, and we are booted in the TWRP recovery mode. Now it's time to flash Magisk and get root on our Xiaomi Redmi 9 (Galahad/Lancelot) phone.
But not so fast. If you just flashed the Magisk apk file using TWRP, you will get a bootloop. This is because of the Android Verified Boot mechanism, which still works even after you unlock the phone. You can read about this AVB mechanism more here. Basically it's all about the boot partition hashes (and possibly other partition hashes as well) which are allowed by manufacturer of the phone to be valid. So only those boot images that have valid hashes can be used in the boot process of the device. Flashing Magisk changes the boot partition, and in this way the hash of the boot partition changes. So, when you try to boot the phone after you flashed Magisk from the TWRP recovery, it will bootloop. Also you will loose access to the recovery partition, so you won't be able to revert the change you did when you flashed the Magisk app. The only way to restore the phone in such state is to flash the stock boot partition. That's why you should make the phone's whole flash backup. I include the stock boot partition here for those who didn't have the backup, but pay attention that this boot image is for Android10/MIUI12 (see the specs above), and I don't know what will happen if you use the image with different software/firmware/ROM.
Install the Magisk app
To avoid the unpleasant bootloop situation after flashing the Magisk app, you have to deactivate the AVB mechanism. You do this by flashing the stock vbmeta partition using fastboot, i.e. the following command:
Code:
# dd if=/dev/loop5p6 of=./6-stock-vbmeta.img
$ fastboot --disable-verity --disable-verification flash vbmeta 6-stock-vbmeta.img
You can proceed with flashing the Magisk app only after you disable the AVB mechanism.
If your phone restored the stock recovery, flash once again the TWRP recovery, and boot into the recovery mode. Download the most recent Magisk app, currently Magisk-v23.0.apk. Yes, I know it's an APK file, and yes, you have to flash the APK file via TWRP recovery. You're going to see some messages about repacking the stock boot and flashing it.
This is the step when the phone stops rewriting the custom recovery partition. So, after installing the Magisk app, the TWRP recovery will be persistent, and you won't have to flash it again.
After flashing the APK file, you have to boot to the phone's OS in order to finish installing Magisk (the OS part/app). You'll be prompted to do this step, so follow what it says and ultimatelly you get the Magisk installed:
SafetyNet
The next thing is to open the Magisk App. After this, check the SafetyNet. It should fail. Go to the options and "Hide the Magisk app". You also have to activate MagiskHide. After this, check the SafetyNet again. It should pass now.
So now you have the root access on your Xiaomi Redmi 9 (Galahad/Lancelot) and also it passes the SafetyNet.
This HOWTO should work for the Xiaomi Redmi 9 (Galahad/Lancelot) phones, but I'm not sure whether I forgot to mention about something. Anyways, if you have any questions, or something doesn't work, ask.
Wow,realy great guide,good written and all infos are there,not bad!!!Cheers!!!
I fixed some spelling mistakes, now it should be easier to read.
Thanks a lot for this great guide.
Small problem here though ;-)
Entering
$ fastboot reboot recovery
leads to:
fastboot: usage: unknown reboot target recovery
Looking at fastboot --help there is no such parameter. Either bootloader or emergency (the latter doesn't work)
Thanks in advance - Chris
It works just fine with my phone:
Code:
$ fastboot reboot recovery
Rebooting into recovery OKAY [ 0.001s]
Finished. Total time: 0.252s
Maybe you need a newer version of the tool?
morfikov said:
It works just fine with my phone:
Code:
$ fastboot reboot recovery
Rebooting into recovery OKAY [ 0.001s]
Finished. Total time: 0.252s
Maybe you need a newer version of the tool?
Click to expand...
Click to collapse
Thank you, morfikov - that was it. Mine was nearly 12 years old :-D
Everyone else facing this issue: latest SDK Platform Tools always under https://developer.android.com/studio/releases/platform-tools
Thanks again for your fabulous guide!
Great guide! I even managed to compile latest TWRP from the devicetree you linked. The only thing that I would add is that I had to use losetup -fP <name>.img. The "P" flag forces the loop device to display partitions and "f" just takes the first available device. As for magisk, I had to use the Didgeridoohan's MagiskHide Props Config module in order to pass CTS check. I just had to "Force BASIC key attestation" using the default value "galahad". I suspect that has to do with the fact that i'm running latest EEA rom (Android 11), other than that I use the same phone - European version bought in Poland
morfikov said:
The process of taking a backup is rather slow. It took around 2h (14M/s)
Click to expand...
Click to collapse
You might have been using a USB 2.0 port.
It is advised that you use a USB 3.x Port. Throughput here was: 146.5 MB/s. It took around 10-15 Minutes.
Maybe you want to put that advise in your guide..
Another tipp which makes the the deavtivation of the AVB mechanism and flashing the stock vbmeta partition using fastbootmuch easier, fast - and also suitable to Windows machines. It takes all together only 2-3 minutes then:
When you're in TWRP after the first flash, instead of pulling the complete image of your Redmi 9 (which is not bad at all, but the image is not loadable under Win machines), you use the means of TWRP:
In TWRP you enter the section "Backup"
There you select the storage "Micro SD card"
In the list of partitions to be backed up ONLY select "vbmeta". It's only 8 MB. (This only takes a few seconds and requires not more than 9MB on your SD card ;-) )
Then "Swipe to Backup"
After that you stay in TWRP
Then you copy the tiny backup to your adb/fastboot folder on the PC (as you're in TWRP, you have full access):
Copy from your phone the files from Redmi's "External_SD/TWRP/BACKUPS/Redmi_9/<current date/time/ID>" to your adb/fastboot folder on the PC:
vbmeta.emmc.win
vbmeta.emmc.win.sha2
(recovery.log is not needed, it only contains the console output)
Within TWRP go back to the main menu and select "Reboot" and select "Fastboot"
The Smartphone reboots into TWRP / Fastboot mode
Now from the PC you turn the the AVB mechanism off by flashing:
$ fastboot --disable-verity --disable-verification flash vbmeta vbmeta.emmc.win
Now you continue with the guide above - reflashing TWRP & booting in Recovery:
$ fastboot flash recovery twrp-recovery.img
$ fastboot reboot recovery
In TWRP back again, now flash Magisk-vXY.Z.apk and reboot to System after that (to clean Cache & Dalvik is not a bad idea).
The flash of TWRP is now permanent (can be entered anytime from device off --> Press and hold Power and Volume up buttons)
It's weird that windows still can't mount such images.
Any tip for me?
I have J19AG (lancelot at first). The problem is that I can't fix broken Google Play Protect on other roms than EEA. This phone came with EEA rom which had GPP. Then I unlocked bootloader and flashed non EEA rom. I have tried TR, ID, IN, RU fastboot roms but none worked with GPP.
Im now on ID rom and trying to fix it using Magisk modules to change props. But neither galahad or lancelot worked for Force Basic Key attestation. After changing galahad to lancelot my base_os prop is empty. Magisk CTS check is still failed.
Code:
[ro.build.version.all_codenames]: [REL]
[ro.build.version.base_os]: []
[ro.build.version.codename]: [REL]
[ro.build.version.incremental]: [V12.0.3.0.QJCIDXM]
I would suggest you to restore the phone stock state with fastboot ROM. You can find some here:
Download: MIUI 12 stable update rolling out to several Xiaomi, Redmi and POCO devices
MIUI 12 stable builds have begun rolling out to several Xiaomi, Redmi, and POCO devices. Head on over for Recovery ROM and Fastboot ROM download links!
www.xda-developers.com
No I do not want this.
I asked some certain question.
I know exactly what I'm doing and have skills for that.
My goal was to have galahad with rom other than EEA with Google Play protect on.
Currently only EEA <-> Galahad is possible. ID, TW, TR rom have no Google Play protect when unlocked or locked bootloader on galahad (Redmi 9 with NFC).
The trick is to fix Google Play protect with Magisk and TWRP. But above methods didnt work for me.
I have no knowledge on this subject, so I can't help you with this.
Hello.
I'm having a problem using the losetup command. After using
sudo losetup /dev/loop3 mmcblk0.img
and checking out the partitions created with
[I]ls -al /dev/loop3*[/I]
I only get ...
brw-rw---- 1 root disk 7, 3 d’oct. 16 10:40 /dev/loop
When checking mmcblk0.img with command
[I]gdisk -l mmcblk0.img[/I]
I get the same as you.
I understand that losetup doesn't create the partitions other than one so I can't extract anyone in particular. Am I doing something wrong. I'm using an updated Ubuntu 20.04.
Thanks for your help.
Use:
Code:
# modprobe -r loop
# modprobe loop max_part=64
morfikov said:
Use:
Code:
# modprobe -r loop
# modprobe loop max_part=64
Click to expand...
Click to collapse
After using the first command I get
modprobe: FATAL: Module loop is builtin.
The second one doesn't display anything.
Then again when using ls -al /dev/loop3* I get
brw-rw---- 1 root disk 7, 3 d’oct. 16 10:40 /dev/loop3
Then edit the kernel cmd line in grub bootloader (or whatever ubuntu is using) and add to it loop.max_part=64 and restart the system.
morfikov said:
Then edit the kernel cmd line in grub bootloader (or whatever ubuntu is using) and add to it loop.max_part=64 and restart the system.
Click to expand...
Click to collapse
Thanks again. I'm still trying. In Ubuntu it's different and after doing it it didn't work (and somehow I broke the OS and had to reinstall it).
I think I will try to do it in a virtualised Debian system.
lotiopep said:
Thanks again. I'm still trying. In Ubuntu it's different and after doing it it didn't work (and somehow I broke the OS and had to reinstall it).
I think I will try to do it in a virtualised Debian system.
Click to expand...
Click to collapse
Finally it worked! Thanks!
I use crDrdoid v8.9 ROM (yes I know there's a newer version 8.11, but it didn't work for me for some reason). From time to time I visit xiaomifirmwareupdater.com/firmware/lancelot/ in order to check whether a newer firmware was released for my Xiaomi Redmi 9 (lancelot/galahad) phone. A couple days ago, I saw that there is V13.0.1.0.SJCEUXM for Android 12). I was using V12.5.4.0.RJCEUXM for Android 11, but this crDroid version offered Android 12.1. Everything was working well. Since there was a new version of the firmware, I downloaded it and flashed it via SHRP recovery. The flashing process went as usual, i.e. without any errors, but when I restarted the device, it didn't turn on. Only the fastboot mode was working.
Restoring the firmware
Fortunately, the firmware package consists only of a few images that are flashed to their corresponding partitions on the phone, for instance:
Code:
$ patool list fw_lancelot_miui_LANCELOTEEAGlobal_V12.5.4.0.RJCEUXM_67a1671939_11.0.zip'
patool: Listing fw_lancelot_miui_LANCELOTEEAGlobal_V12.5.4.0.RJCEUXM_67a1671939_11.0.zip ...
patool: running /usr/bin/7z l -- fw_lancelot_miui_LANCELOTEEAGlobal_V12.5.4.0.RJCEUXM_67a1671939_11.0.zip
7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,4 CPUs Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz (306A9),ASM,AES-NI)
Scanning the drive for archives:
1 file, 40808894 bytes (39 MiB)
Listing archive: fw_lancelot_miui_LANCELOTEEAGlobal_V12.5.4.0.RJCEUXM_67a1671939_11.0.zip
--
Path = fw_lancelot_miui_LANCELOTEEAGlobal_V12.5.4.0.RJCEUXM_67a1671939_11.0.zip
Type = zip
Physical Size = 40808894
Date Time Attr Size Compressed Name
------------------- ----- ------------ ------------ ------------------------
2022-02-28 13:40:44 D.... 0 0 META-INF
2022-02-28 13:40:40 ..... 280488 171992 preloader_raw.img
2022-02-28 13:40:40 ..... 282536 172052 preloader_ufs.img
2022-02-28 13:40:42 ..... 1 3 type.txt
2022-02-28 13:40:40 ..... 859 364 scatter.txt
2022-02-28 13:40:40 ..... 282536 172052 preloader_emmc.img
2022-02-28 13:40:40 ..... 59329408 35869684 md1img.img
2022-02-28 13:40:42 ..... 2505440 2166963 tee.img
2022-02-28 13:40:42 ..... 37984 7454 spmfw.img
2022-02-28 13:40:40 ..... 352816 144110 scp.img
2022-02-28 13:40:42 ..... 505616 483321 sspm.img
2022-02-28 13:40:24 ..... 1302976 522804 lk.img
2022-02-28 13:40:22 D.... 0 0 META-INF/com
2022-02-28 13:40:44 ..... 1634 1144 META-INF/CERT.RSA
2022-02-28 13:40:42 ..... 2217 999 META-INF/MANIFEST.MF
2022-02-28 13:40:42 ..... 2270 1091 META-INF/CERT.SF
2022-02-28 13:40:42 D.... 0 0 META-INF/com/android
2022-02-28 13:40:22 D.... 0 0 META-INF/com/google
2022-02-28 13:40:24 D.... 0 0 META-INF/com/google/android
2022-02-28 13:40:24 ..... 2340536 1090127 META-INF/com/google/android/update-binary
2022-02-28 13:40:44 ..... 3559 863 META-INF/com/google/android/updater-script
2022-02-28 13:40:22 ..... 316 220 META-INF/com/android/metadata
2022-02-28 13:40:42 ..... 1594 1077 META-INF/com/android/otacert
------------------- ----- ------------ ------------ ------------------------
2022-02-28 13:40:44 67232786 40806320 18 files, 5 folders
So if the fastboot mode works well, you can use the images and flash them in order to restore the device. Where to flash the images? Just check the flash layout of your phone:
Code:
# gdisk -l mmcblk0-stock-original.img
GPT fdisk (gdisk) version 1.0.9
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk mmcblk0-stock-original.img: 122142720 sectors, 58.2 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 00000000-0000-0000-0000-000000000000
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 122142686
Partitions will be aligned on 16-sector boundaries
Total free space is 61 sectors (30.5 KiB)
Number Start (sector) End (sector) Size Code Name
1 64 131135 64.0 MiB 0700 recovery
2 131136 132159 512.0 KiB 0700 misc
3 132160 133183 512.0 KiB 0700 para
4 133184 174143 20.0 MiB 0700 expdb
5 174144 176191 1024.0 KiB 0700 frp
6 176192 192575 8.0 MiB 0700 vbmeta
7 192576 208959 8.0 MiB 0700 vbmeta_system
8 208960 225343 8.0 MiB 0700 vbmeta_vendor
9 225344 271631 22.6 MiB 0700 md_udc
10 271632 337167 32.0 MiB 0700 metadata
11 337168 402703 32.0 MiB 0700 nvcfg
12 402704 533775 64.0 MiB 0700 nvdata
13 533776 632079 48.0 MiB 0700 persist
14 632080 730383 48.0 MiB 0700 persistbak
15 730384 746767 8.0 MiB 0700 protect1
16 746768 770047 11.4 MiB 0700 protect2
17 770048 786431 8.0 MiB 0700 seccfg
18 786432 790527 2.0 MiB 0700 sec1
19 790528 796671 3.0 MiB 0700 proinfo
20 796672 797695 512.0 KiB 0700 efuse
21 797696 850943 26.0 MiB 0700 boot_para
22 850944 982015 64.0 MiB 0700 nvram
23 982016 998399 8.0 MiB 0700 logo
24 998400 1260543 128.0 MiB 0700 md1img
25 1260544 1262591 1024.0 KiB 0700 spmfw
26 1262592 1274879 6.0 MiB 0700 scp1
27 1274880 1287167 6.0 MiB 0700 scp2
28 1287168 1289215 1024.0 KiB 0700 sspm_1
29 1289216 1291263 1024.0 KiB 0700 sspm_2
30 1291264 1324031 16.0 MiB 0700 gz1
31 1324032 1356799 16.0 MiB 0700 gz2
32 1356800 1360895 2.0 MiB 0700 lk
33 1360896 1364991 2.0 MiB 0700 lk2
34 1364992 1496063 64.0 MiB 0700 boot
35 1496064 1528831 16.0 MiB 0700 dtbo
36 1528832 1539071 5.0 MiB 0700 tee1
37 1539072 1549311 5.0 MiB 0700 tee2
38 1549312 1582079 16.0 MiB 0700 gsort
39 1582080 1844223 128.0 MiB 0700 minidump
40 1844224 2630655 384.0 MiB 0700 exaid
41 2630656 4727807 1024.0 MiB 0700 cust
42 4727808 4744191 8.0 MiB 0700 devinfo
43 4744192 4767743 11.5 MiB 0700 ffu
44 4767744 19447807 7.0 GiB 0700 super
45 19447808 20332543 432.0 MiB 0700 cache
46 20332544 122021823 48.5 GiB 0700 userdata
47 122021824 122109887 43.0 MiB 0700 otp
48 122109888 122142655 16.0 MiB 0700 flashinfo
So:
- `md1img.img` -- goes to `md1img` (24)
- `tee.img` -- goes to `tee1` i `tee2` (36 and 37)
- `spmfw.img` -- goes to `spmfw` (25)
- `scp.img` -- goes to `scp1` i `scp2` (26 and 27)
- `sspm.img` -- goes to `sspm_1` i `sspm_2` (28 and 29)
- `lk.img` -- goes to `lk` i `lk2` (32 and 33)
- `preloader_raw.img` -- no idea what to do with it
- `preloader_ufs.img` -- no idea what to do with it
- `preloader_emmc.img` -- no idea what to do with it
From what I've read, the images sspm_1 , tee1 , scp1 and lk are responsible for the main loader, and images sspm_2 , tee2 , scp2, lk2 for the alternative loader. I flashed only the main loader images and forgot to flash the alt loader. Moreover, since I didn't know what to do with the preloader images (there are 3), so I didn't flash any of them. :]
The phone is dead
When I rebooted my phone, there was no sign of life -- no vibration, no sound, no screen, no charging animation, nothing. When I connected the device to my laptop's USB port (with Debian Linux onboard), there was no log at all -- the phone seemed to be dead for good.
The phone is not dead
Playing with the phone's buttons a little bit (while the device is connected to my laptop's USB port), I found out that the Power + VolumeDown button combination generates the following messages in the system log on my Debian:
Code:
kernel: usb 3-1: new high-speed USB device number 10 using xhci_hcd
kernel: usb 3-1: New USB device found, idVendor=0e8d, idProduct=0003, bcdDevice= 1.00
kernel: usb 3-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
kernel: usb 3-1: Device is not authorized for usage
kernel: cdc_acm 3-1:1.0: ttyACM0: USB ACM device
kernel: usb 3-1: authorized to connect
kernel: usb 3-1: USB disconnect, device number 10
So the phone looks like to be partially dead, or not dead at all, or maybe even alive, but it only plays dead, just to force me to buy a new device. :]
SP Flash Tool and MTK Bypass Utility
Since Xiaomi Redmi 9 (lancelot/galahad) is a Mediatek device, there are some chances to restore its state using SP Flash Tool. So I downloaded SP_Flash_Tool_v5.2208_Linux and launched it. I also downloaded Redmi_9_Engineering_Rom.zip , but it looks like that the fastboot ROM is sufficient.
The is only one issue with SP Flash Tool -- it doesn't work without some authorized account. Without this account you won't be able to flash anything using SP Flash Tool. But there's the MTK Bypass Utility tool.
To make the tool work, you have to do the following steps:
Code:
$ git clone https://github.com/MTK-bypass/bypass_utility
$ cd bypass_utility/
$ git clone https://github.com/MTK-bypass/exploits_collection
$ cd exploits_collection/
$ cp ./default_config.json5 ../
$ cp -a ./payloads/ ../
$ cd ..
Then you launch the program:
Code:
$ python3 main.py
[2023-01-28 12:04:55.807367] Waiting for device
And now you plug the phone into the USB port and press the Power + VolDown buttons. The following messages should appear in the log:
Code:
[2023-01-28 12:05:06.892077] Found device = 0e8d:0003
[2023-01-28 12:05:07.012749] Device hw code: 0x707
[2023-01-28 12:05:07.012871] Device hw sub code: 0x8a00
[2023-01-28 12:05:07.012936] Device hw version: 0xca00
[2023-01-28 12:05:07.012994] Device sw version: 0x0
[2023-01-28 12:05:07.013076] Device secure boot: True
[2023-01-28 12:05:07.013140] Device serial link authorization: True
[2023-01-28 12:05:07.013232] Device download agent authorization: True
[2023-01-28 12:05:07.013301] Disabling watchdog timer
[2023-01-28 12:05:07.014062] Disabling protection
[2023-01-28 12:05:07.038921] Protection disabled
Now we can use SP Flash Tool to restore the bricked phone. To be sure, just check if the device /dev/ttyACM0 exists in your system:
Code:
# ls -al /dev/ttyACM0
crw-rw----+ 1 root dialout 166, 0 2023-01-28 11:38:45 /dev/ttyACM0
We have to configure SP Flash Tool to use this device:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
We need some DA file -- the one provided by SP Flash Tool, should be good, but I used the DA file provided by the Engineering ROM. We also need some scatter.txt file -- it can be found either in Engineering ROM, or in fastboot ROM. We have to provide paths to the two files in SP Flash Tool:
We can see that all the firmware partitions can be flashed, including preloader. So in this case, I used the firmware images from the fastboot ROM, with the exception for dtbo and boot, since they come from crDroid ROM. Now all we have to do is to press the Download button.
Chip mismatch!
I selected only one partition (just for testing purposes, to see whether it will work at all) and I pressed the Download button. I got the following error:
And it text version it says:
Code:
[error] Chip mismatch! scatter: platform[MT6768] type[]; device: hw_code[0xb8e8],
hw_subcode[0x9400], hw_ver[0x7fb2], sw_ver[0x0], chip_evolution[0] #(chip_mapping.cpp, line:259)
But when I pressed the Download button again, it worked:
and
So I checked all the firmware partitions and flashed them in one turn. But this didn't fix my phone. I had to flash the preloader image. I used preloader_lancelot.bin from the fastboot image. When I flashed it, the phone booted normally. None of the user data was lost.
Also, the article is written in Polish, so you can read it on my blog if you don't know English well.
Happy flashing. :]
Hey, this was great, thanks, but I have a problem, after doing this I get "NV data is corrupted" and cant get past recovery. Any idea why? thanks again
After doing what?
Hello! After I corrupted the boot partition and entered a bootloop, I tried to reflash the preloader partition from fastboot and ended up in this same situation. I've been following this post and everything seems to be going perfect, but at the end of the post you say that you flashed preloader_lancelot.bin, but in all the images I could find there were 3 versions of it (preloader_emmc.img, preloader_raw.img and preloader_ufs.img), which one did you use?
The only time I saw a preloader_lancelot.bin file was with a mtk command that extracted the current one (but mine is invalid I guess).
Sorry if the English is not perfect, it's not m native language.
The file is in the fastboot ROM.
morfikov said:
The file is in the fastboot ROM.
Click to expand...
Click to collapse
You are right, my bad, I just looked over the first file and didn't saw the second one.
Awesome post! I've just managed to boot, I'll see if I can update the system from some backups, idk in which moment I ended up falshing an old af android version that looks exactly like this (gotten from google):
@morfikov:
That A LOT for this detailed walkthrough!
FWIW, even though my phone appeared dead, I managed to start it by :
- plugging it in
- holding VolumeUP + Power for several seconds
That was enough to start it again and display the Mi logo. It didn't go much further but that was a great change to begin with!
I still haven't managed to flash it back to stock ROM, as the phone keeps rebooting before I can flash anything. :-/