Is there any way to re-partition ROM eMMC ? since /cache has 500 MB ,it can be re - partitioned to merge into /data partition . so any body here know how to re-partition ROM ? is it possible ?
Parted dump:
Code:
31 106824kB 117268kB 10445kB boot
32 117268kB 127795kB 10527kB recovery
33 127795kB 603980kB 476185kB ext4 cache
34 603980kB 1543504kB 939524kB ext4 system
35 1543504kB 1551892kB 8389kB kpan
36 1551892kB 3958768kB 2406875kB ext4 userdata
Since the "important" partitions are towards the end, something can well be done (as long as you have full OS installation media in zip or nandroid format, plus some tools which may not even be needed on this phone)... If you can wait a week I'll try to write a guide
After some testing, it appears to be impossible, like there is some S-ON on the partition table area...
full partition table needed please..
Ryccardo said:
Parted dump:
Code:
31 106824kB 117268kB 10445kB boot
32 117268kB 127795kB 10527kB recovery
33 127795kB 603980kB 476185kB ext4 cache
34 603980kB 1543504kB 939524kB ext4 system
35 1543504kB 1551892kB 8389kB kpan
36 1551892kB 3958768kB 2406875kB ext4 userdata
Since the "important" partitions are towards the end, something can well be done (as long as you have full OS installation media in zip or nandroid format, plus some tools which may not even be needed on this phone)... If you can wait a week I'll try to write a guide
Click to expand...
Click to collapse
Hey bro, could you please provide me a full partition table in that same format?
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
This page is trying to find out which partition is for what ?
Code:
Model: MMC P1J95K (sd/mmc)
Disk /dev/block/mmcblk0: 15302656s
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 131072s 262143s 131072s fat16 modem
2 262144s 265215s 3072s tunning
3 265216s 267263s 2048s traceability
4 267264s 267265s 2s fsc
5 267266s 267281s 16s ssd
6 267282s 268305s 1024s sbl1
7 268306s 269329s 1024s sbl1bak
8 269330s 270353s 1024s rpm
9 270354s 271377s 1024s rpmbak
10 271378s 272401s 1024s tz
11 272402s 273425s 1024s tzbak
12 273426s 275473s 2048s pad
13 275474s 276497s 1024s hyp
14 276498s 277521s 1024s hypbak
15 277522s 280593s 3072s modemst1
16 280594s 283665s 3072s modemst2
17 283666s 285713s 2048s simlock
18 285714s 288785s 3072s efsdata
19 393216s 393279s 64s DDR
20 393280s 396351s 3072s fsg
21 396352s 396383s 32s sec
22 396384s 398431s 2048s aboot
23 398432s 400479s 2048s abootbak
24 400480s 466015s 65536s boot
25 466016s 531551s 65536s recovery
26 531552s 5898239s 5366688s ext2 system
27 5898240s 5963775s 65536s ext4 persist
28 5963776s 6004735s 40960s reserved
29 6004736s 6021119s 16384s splash
30 6021120s 6062079s 40960s ext4 tctpersist
31 6062080s 6082559s 20480s ext4 hdcp
32 6082560s 6082575s 16s fota
33 6082576s 6606863s 524288s ext4 cache
34 6606864s 6608911s 2048s misc
35 6608912s 6613007s 4096s persistent
36 6684672s 6686719s 2048s devinfo
37 6815744s 6816767s 1024s keystore
38 6816768s 6816831s 64s config
39 6816832s 6816959s 128s oem
40 6816960s 6823151s 6192s redbend
41 6823152s 6825199s 2048s ciqbp
42 6825200s 6827247s 2048s ciqap
43 6827248s 15302622s 8475375s ext4 userdata
25. recovery - partition to be used for recovery boots this is allinone image to let you boot when all door closed.
26. system - this is android which is booted once linux bootup and mounted at /system
33. cache - for temporary work usually lost after reboot but not always
43. userdata - this partition hold userdata, internal sd (/storage/sdcard0 or /sdcard), internal app installed mainly mounted at /data
10. tz
11. tzbak - Trusted Zone and back up are trusted zone providers to android
5. ssd - secure software download; "Secure Software Download" is a memory based file system (RAMFS) for secure storage, used to download and store "who knows what" on the eMMC. It is a referenced part in the Remote Storage RPC Client of the MSM kernel.
6. sbl1 - secondary bootloader
7. sbl1bak - secondary bootloader backup
8. rpm - resource and power manager @MotoJunkie01 /rpm is also known as primary bootloader, and flashing this partition should always be avoided if at all possible. /rpm, /sbl1, /tz, and /aboot are all considered bootloaders.
9. rpmbak - resource and power manager backup
24. boot - this partition holds kernel and initrd.gz
15. modemst1 - Modem1 (NV data)
16. modemst2 - Modem2 (NV data)
22. aboot - AP Bootloader {AP has some thing to do with APN configuration}
23. abootbak - AP Bootloader backup
20. fsg - Probably stands for File System (FS) "Golden". According to Samsung documentation, this partition is a "Golden Copy". This is partially confirmed by RE of the PARAM partition, which indicate that this partition should contain a copy of MODEMST1. As such it is a backup of the current EFS2 filesystem. The creation of a FSG is not supported on flash devices and the internal (QMI) DIAG request "EFS2_DIAG_MAKE_GOLDEN_COPY", can only be used to create a backup one time over the life of the device. [80-V1294-11] ref
rest of the partition you write
Good research. /rpm is also known as primary bootloader, and flashing this partition should always be avoided if at all possible. /rpm, /sbl1, /tz, and /aboot are all considered bootloaders (and/or bootloader dependent partitions). Tampering with any of these is the quickest way to hard brick a device beyond repairability. /fsg, in Motorola devices anyway, is considered a radio firmware partition and contains the fsg-id configuration for carrier dependent parameters. I included /fsg in my modem thread (my baseband installer flashes /modem, /fsg, and formats modemst1 & modemst2). The /simlock partition does exactly what it implies. When a network unlock code is entered into the device, the requisite changes are applied to /simlock in order to enable GSM network unlocking. In theory, if an unlocked device's /simlock partition is flashed to a locked device, the locked device also becomes network unlocked. This works on most brands which use a similar partition index for network locking/unlocking. I'll research the partitions you didn't reference and add some additional info.
The /splash partition is the boot logo.
The /splash partition is the boot logo.
If you remove or tamper it you will get beautiful tux icon
Recovery and boot are actually in the same format -- an "ANDROID!" archive containing a kernel, an initrd, and a kernel command line. The recovery is just another kernel and an initrd containing all the files you see in your recovery.
Cache is used for the system communicating with the recovery. The system places a command in a file there telling the recovery to perform a function like factory reset or apply a FOTA. The recovery reads that, does the command, and writes its state and logs back to cache. I don't know what else cache is used for, but FOTA temp files certainly don't download there (they're in /data/data/com.tcl.dmclient/files/last_dlpkgfile on this phone), and the Play Store doesn't download stuff to there when installing apps.
tz/tzbak are something for the ARM Trust Zone, which is a bit like TPM on PCs. It's a function built into the processor that can be used to store keys securely. These partitions contain an ELF file, so I suspect this is a binary that interfaces with or runs inside the Trust Zone, and not the data store for it.
I haven't seen any real info about ssd, but given "Secure Software Download" and that it's only 8 KB, I'm guessing it's used by the baseband for things like updates and SIM apps pushed through the cell network.
The boot sequence as I understand it is rpm -> sbl1 -> aboot -> boot (Linux kernel).
Rpm, sbl1 and tz are updated with each firmware update for this device that I've seen. It looks like the updater changes rpm, sbl1 and tz; and then rpmbak, sbl1bak and tzbak are updated after a successful boot. The updater seems to update both aboot and abootbak though. I determined this by looking at a backup taken after an update and reboot, and one taken after an update and no reboot.
Do you have a link where I can read more about fsg, modemst1/2, EFS2 and EFS2_DIAG_MAKE_GOLDEN_COPY?
Chupi383 said:
Recovery and boot are actually in the same format -- an "ANDROID!" archive containing a kernel, an initrd, and a kernel command line. The recovery is just another kernel and an initrd containing all the files you see in your recovery.
Cache is used for the system communicating with the recovery. The system places a command in a file there telling the recovery to perform a function like factory reset or apply a FOTA. The recovery reads that, does the command, and writes its state and logs back to cache. I don't know what else cache is used for, but FOTA temp files certainly don't download there (they're in /data/data/com.tcl.dmclient/files/last_dlpkgfile on this phone), and the Play Store doesn't download stuff to there when installing apps.
tz/tzbak are something for the ARM Trust Zone, which is a bit like TPM on PCs. It's a function built into the processor that can be used to store keys securely. These partitions contain an ELF file, so I suspect this is a binary that interfaces with or runs inside the Trust Zone, and not the data store for it.
I haven't seen any real info about ssd, but given "Secure Software Download" and that it's only 8 KB, I'm guessing it's used by the baseband for things like updates and SIM apps pushed through the cell network.
The boot sequence as I understand it is rpm -> sbl1 -> aboot -> boot (Linux kernel).
Rpm, sbl1 and tz are updated with each firmware update for this device that I've seen. It looks like the updater changes rpm, sbl1 and tz; and then rpmbak, sbl1bak and tzbak are updated after a successful boot. The updater seems to update both aboot and abootbak though. I determined this by looking at a backup taken after an update and reboot, and one taken after an update and no reboot.
Do you have a link where I can read more about fsg, modemst1/2, EFS2 and EFS2_DIAG_MAKE_GOLDEN_COPY?
Click to expand...
Click to collapse
I can confirm that modemst1 and modemst2 are nv data partitions. The /fsg partition (a configuration which has been used by Samsung and Motorola for many years) is a baseband firmware partition that contains carrier ID and carrier regional information.
---------- Post added at 03:35 AM ---------- Previous post was at 03:33 AM ----------
MotoJunkie01 said:
I can confirm that modemst1 and modemst2 are nv data partitions. The /fsg partition (a configuration which has been used by Samsung and Motorola for many years) is a baseband firmware partition that contains carrier ID and carrier regional information.
Click to expand...
Click to collapse
@Chupi383, Question: have you been able to successfully capture an OTA for this device? If so, where is the OTA stored once downloaded? Thanks for your help on this.
@MotoJunkie01 The downloaded OTA is stored as /data/data/com.tcl.dmclient/files/last_dlpkgfile.
You can also get the download URL for an XML file named "desc" from logcat. You can download desc by using a user agent string spoofer with the user agent "Red Bend Software vDirect Mobile(TM) RedBend-vdm-5.6.0.65". Then that will contain the download URL for the zip itself, which you can download with the same user agent. The fun thing about these zips is once you have the URL for one, you can guess the URLs for other to/from firmware version pairs.
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.