XT1254 Free your Turbo! AIO information thread - Verizon Motorola Droid Turbo General

Lesson learned, head hanging down... Oh well. I tried guy. Either ways that only REINFORCES that we all need to get together and share what we know! Hence this thread:
Time for us to come together and put all of our knowledge together. Every known exploit for our bootloader, kernel, rom, ect needs to be logged in one area. All our partitions / sizes / locations / offsets need to be logged. Any and all information that can be gleamed from out fxz/sbf's need to be logged.
I have my own root exploit I want to work on for 5.0 and below... If that time comes, I'll release that. For now I'll keep this updated
Planned todo in order :
safestrap (Will boost Dev's, makes testing roms a breeze!)
kexec (Now Dev's can start juggling kernels) (maybe even forcefully reduce original kernels memory use) (reclaiming resources?, turning off unneeded original kernels modules ect... why not full hijacking of original kernel? Can you write to ANY memory region? (See graphics buffer vulnerability below.....hmmm 5.0 and under "AIO root / kexc / safestrap"? )
cm kernel (Hopefully a Dev beats me to it, as I have next planned....)
5.0 and below root (via graphics buffer vulnerability) https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-1474
How to backup critical files/partitions
**Just tried this, some partitions/files are assumed to be read protected...
So far, looks like we got data. I'm pretty sure its the kind you'd want if there was a brickfix in the future... sometimes each device has its own signature required for easy brickfix... Mines backed up in three different places already*
http://forum.xda-developers.com/dro...-aio-information-thread-t3138839/post61435029

XT1254 WRITE PROTECT :
if you bothered to read the init.rc files, you'd see that you can hijack the boot system early enough to disable qe if you're bothered by write protection, since this happens on fs stage:
# arrange access to the overlay
exec /system/bin/checknmount -d -s -m -t ext4 -r /overlay/sysupdate /cache/overlay/sysupdate.simg /cache/overlay/sysupdate.jar
# use the overlay, if it is compatible
exec /system/bin/stacker -d -c -r -t overlayfs /system /overlay/sysupdate[/HIDE]

How to copy your /firmware/image/*.* easily. *****Just tried this, some partitions/files are assumed to be read protected...
with efs explorer
copy /firmware/image/ folder to /sdcard/firmware/
with PC in MTP mode copy /image/ folder to PC
So far, looks like we got data. I'm pretty sure its the kind you'd want if there was a brickfix in the future... sometimes each device has its own signature required for easy brickfix... Mines backed up in three different places
List of partitions/files copied : (Remember, I havn't had time to even look further, the first one I opened wasn't blanked out.)
[email protected]:/ $ cd firmware
[email protected]:/firmware $ cd image
[email protected]:/firmware/image $ ls
acdb.mbn
adsp.b00
adsp.b01
adsp.b02
adsp.b03
adsp.b04
adsp.b05
adsp.b06
adsp.b07
adsp.b08
adsp.b10
adsp.b11
adsp.b12
adsp.mbn
adsp.mdt
apps.mbn
bdwlan11.bin
bdwlan20.bin
cmnlib.b00
cmnlib.b01
cmnlib.b02
cmnlib.b03
cmnlib.mdt
dsp2.mbn
efs1.bin
efs2.bin
efs3.bin
isdbtmm.b00
isdbtmm.b01
isdbtmm.b02
isdbtmm.b03
isdbtmm.mdt
keymaster.b00
keymaster.b01
keymaster.b02
keymaster.b03
keymaster.mdt
mba.mbn
otp11.bin
otp20.bin
playready.b00
playready.b01
playready.b02
playready.b03
playready.mdt
prov.b00
prov.b01
prov.b02
prov.b03
prov.mdt
qdsp6sw.mbn
qwlan11.bin
qwlan20.bin
rpm.mbn
sampleapp.b00
sampleapp.b01
sampleapp.b02
sampleapp.b03
sampleapp.mdt
sbl1.mbn
securemm.b00
securemm.b01
securemm.b02
securemm.b03
securemm.mdt
tqs.b00
tqs.b01
tqs.b02
tqs.b03
tqs.mdt
tz.mbn
utf11.bin
utf20.bin
widevine.b00
widevine.b01
widevine.b02
widevine.b03
widevine.mdt
[email protected]:/firmware/image $
Partition Table:
? ? ? Total size flash location partition name size notes:
179 0 30535680 "mmcblk0 " 32GB Flash Chip
179 1 131072 mmcblk0p1 " modem" 0x0000000008000000
179 2 384 "mmcblk0p2 " ? Sbl1 0x0000000000060000
179 3 56 "mmcblk0p3 " ? Sdi 0x000000000000e000
179 4 16 "mmcblk0p4 " sec: 0x0000000000004000
179 5 32 mmcblk0p5 " ddr" 0x0000000000008000
179 6 1024 mmcblk0p6 " aboot" 0x0000000000100000
179 7 256 mmcblk0p7 " rpm" 0x0000000000040000
179 8 512 mmcblk0p8 ? Utags 0x0000000000080000 contains imei, take note of backup partition
179 9 500 mmcblk0p9 ? Tz 0x000000000007d000
179 10 3072 mmcblk0p10 " factorytune1" 0x0000000000300000
179 11 1084 mmcblk0p11 " padA" 0x000000000010f000
179 12 384 mmcblk0p12 sbl1bak: 0x0000000000060000
179 13 1024 mmcblk0p13 " abootBackup" 0x0000000000100000
179 14 256 mmcblk0p14 ?rpmBackup 0x0000000000040000
179 15 512 mmcblk0p15 ? utagsBackup 0x0000000000080000 backup
79 16 500 mmcblk0p16 ? tzBackup 0x000000000007d000
179 17 1024 mmcblk0p17 " mdm1m9kefs1" 0x0000000000100000
179 18 1024 mmcblk0p18 " mdm1m9kefs2" 0x0000000000100000
179 19 2620 mmcblk0p19 " padB" 0x000000000028f000
179 20 2048 mmcblk0p20 " logs" 0x0000000000200000
179 21 32768 mmcblk0p21 " persist" 0x0000000002000000
179 22 256 mmcblk0p22 " mdm1hob" 0x0000000000040000
179 23 32 mmcblk0p23 " mdm1dhob" 0x0000000000008000
179 24 1024 mmcblk0p24 ? Sp 0x0000000000100000
179 25 128 mmcblk0p25 " cid" 0x0000000000020000
179 26 3072 mmcblk0p26 " pds" 0x0000000000300000
179 27 8192 mmcblk0p27 " logo" 0x0000000000800000
179 28 11264 mmcblk0p28 ? Clogo 0x0000000000b00000
179 29 1024 mmcblk0p29 " misc" 0x0000000000100000
179 30 1632 mmcblk0p30 " padC" 0x0000000000198000
179 31 780 mmcblk0p31 " mdm1m9kefs3" 0x00000000000c3000
259 0 1 mmcblk0p32 " mdm1m9kefsc" 0x0000000000000400
259 1 8 mmcblk0p33 ? Ssd 0x0000000000002000
259 2 8192 mmcblk0p34 " kpan" 0x0000000000800000
259 3 16384 mmcblk0p35 " boot" 0x0000000001000000
259 4 16400 mmcblk0p36 " recovery" 0x0000000001004000
259 5 16416 mmcblk0p37 " factorytune2" 0x0000000001008000
259 6 1469392 mmcblk0p38 " cache" 0x0000000059af4000
259 7 3457024 mmcblk0p39 ? System 0x00000000d3000000
259 8 25309056 mmcblk0p40 ? Userdata 0x0000000608be0000
179 32 4096 mmcblk0 rpmb (Replay Protected Memory Block) RPMB is not a regular partition and a different command sequence(CMD6-->CMD23-->CMD25-->CMD23-->CMD18) as mentioned in JEDEC Standard No. 84-A441, is required to access it, then why mmc initialisation code is using the wrong command sequence(CMD6-->CMD23-->CMD18) to access it?
Old Partition table:
(bootloader) sdi.git: git=MBM-NG-V70.47-0-gf291c61
(bootloader) sbl1.git: git=MBM-NG-V70.47-0-ga007c2c
(bootloader) rpm.git: git=MBM-NG-V70.47-0-g66204d2
(bootloader) tz.git: git=MBM-NG-V70.47-0-g4cdbfd4
(bootloader) aboot.git: git=MBM-NG-V70.47-0-gc723802
(bootloader) partition-size:modem: 0x0000000008000000
(bootloader) partition-size:sbl1: 0x0000000000060000
(bootloader) partition-size:sdi: 0x000000000000e000
(bootloader) partition-size:sec: 0x0000000000004000
(bootloader) partition-size:ddr: 0x0000000000008000
(bootloader) partition-size:aboot: 0x0000000000100000
(bootloader) partition-size:rpm: 0x0000000000040000
(bootloader) partition-size:utags: 0x0000000000080000
(bootloader) partition-size:tz: 0x000000000007d000
(bootloader) partition-size:factorytune1: 0x0000000000300000
(bootloader) partition-sizeadA: 0x000000000010f000
(bootloader) partition-size:sbl1bak: 0x0000000000060000
(bootloader) partition-size:abootBackup: 0x0000000000100000
(bootloader) partition-size:rpmBackup: 0x0000000000040000
(bootloader) partition-size:utagsBackup: 0x0000000000080000
(bootloader) partition-size:tzBackup: 0x000000000007d000
(bootloader) partition-size:mdm1m9kefs1: 0x0000000000100000
(bootloader) partition-size:mdm1m9kefs2: 0x0000000000100000
(bootloader) partition-sizeadB: 0x000000000028f000
(bootloader) partition-size:logs: 0x0000000000200000
(bootloader) partition-sizeersist: 0x0000000002000000
(bootloader) partition-size:mdm1hob: 0x0000000000040000
(bootloader) partition-size:mdm1dhob: 0x0000000000008000
(bootloader) partition-size:sp: 0x0000000000100000
(bootloader) partition-size:cid: 0x0000000000020000
(bootloader) partition-sizeds: 0x0000000000300000
(bootloader) partition-size:logo: 0x0000000000800000
(bootloader) partition-size:clogo: 0x0000000000b00000
(bootloader) partition-size:misc: 0x0000000000100000
(bootloader) partition-sizeadC: 0x0000000000198000
(bootloader) partition-size:mdm1m9kefs3: 0x00000000000c3000
(bootloader) partition-size:mdm1m9kefsc: 0x0000000000000400
(bootloader) partition-size:ssd: 0x0000000000002000
(bootloader) partition-size:kpan: 0x0000000000800000
(bootloader) partition-size:boot: 0x0000000001000000
(bootloader) partition-size:recovery: 0x0000000001004000
(bootloader) partition-size:factorytune2: 0x0000000001008000
(bootloader) partition-size:cache: 0x0000000059af4000
(bootloader) partition-size:system: 0x00000000d3000000
(bootloader) partition-size:userdata: 0x0000000608be0000
cat_/proc/partitions
Start_______End address_____major__minor__#blocks_____name____partition name
?0x?0?0?0?0__0x?0?0?0?0?___179_____0___30535680__mmcblk0
?0x?0?0?0?0__0x?0?0?0?0?___179_____1_____131072__mmcblk0p1 modem
?0x?0?0?0?0__0x?0?0?0?0?___179_____2_____384__mmcblk0p2 sbl1
?0x?0?0?0?0__0x?0?0?0?0?___179_____3______56__mmcblk0p3 sdi
?0x?0?0?0?0__0x?0?0?0?0?___179_____4______16__mmcblk0p4 sec
?0x?0?0?0?0__0x?0?0?0?0?___179_____5______32__mmcblk0p5 ddr
?0x?0?0?0?0__0x?0?0?0?0?___179_____6____1024__mmcblk0p6 aboot
?0x?0?0?0?0__0x?0?0?0?0?___179_____7_____256__mmcblk0p7 rpm
?0x?0?0?0?0__0x?0?0?0?0?___179_____8_____512__mmcblk0p8 utags
?0x?0?0?0?0__0x?0?0?0?0?___179_____9_____500__mmcblk0p9 tz
?0x?0?0?0?0__0x?0?0?0?0?___179____10____3072__mmcblk0p10 factorytune1
?0x?0?0?0?0__0x?0?0?0?0?___179____11____1084__mmcblk0p11 padA
?0x?0?0?0?0__0x?0?0?0?0?___179____12_____384__mmcblk0p12 sbl1bak
?0x?0?0?0?0__0x?0?0?0?0?___179____13____1024__mmcblk0p13 abootBackup
?0x?0?0?0?0__0x?0?0?0?0?___179____14_____256__mmcblk0p14 rpmBackup
?0x?0?0?0?0__0x?0?0?0?0?___179____15_____512__mmcblk0p15 utagsBackup
?0x?0?0?0?0__0x?0?0?0?0?___179____16_____500__mmcblk0p16 tzBackup
?0x?0?0?0?0__0x?0?0?0?0?___179____17____1024__mmcblk0p17 mdm1m9kefs1
?0x?0?0?0?0__0x?0?0?0?0?___179____18____1024__mmcblk0p18 mdm1m9kefs2
?0x?0?0?0?0__0x?0?0?0?0?___179____19____2620__mmcblk0p19 padB
?0x?0?0?0?0__0x?0?0?0?0?___179____20____2048__mmcblk0p20 logs
?0x?0?0?0?0__0x?0?0?0?0?___179____21___32768__mmcblk0p21 persist
?0x?0?0?0?0__0x?0?0?0?0?___179____22_____256__mmcblk0p22 mdm1hob
?0x?0?0?0?0__0x?0?0?0?0?___179____23______32__mmcblk0p23 mdm1dhob
?0x?0?0?0?0__0x?0?0?0?0?___179____24____1024__mmcblk0p24 sp
?0x?0?0?0?0__0x?0?0?0?0?___179____25_____128__mmcblk0p25 cid
?0x?0?0?0?0__0x?0?0?0?0?___179____26____3072__mmcblk0p26 pds
?0x?0?0?0?0__0x?0?0?0?0?___179____27____8192__mmcblk0p27 logo
?0x?0?0?0?0__0x?0?0?0?0?___179____28___11264__mmcblk0p28 clogo
?0x?0?0?0?0__0x?0?0?0?0?___179____29____1024__mmcblk0p29 misc
?0x?0?0?0?0__0x?0?0?0?0?___179____30____1632__mmcblk0p30 padC
?0x?0?0?0?0__0x?0?0?0?0?___179____31_____780__mmcblk0p31 mdm1m9kefs3
?0x?0?0?0?0__0x?0?0?0?0?___259_____0_______1__mmcblk0p32 mdm1m9kefsc
?0x?0?0?0?0__0x?0?0?0?0?___259_____1_______8__mmcblk0p33 ssd
?0x?0?0?0?0__0x?0?0?0?0?___259_____2____8192__mmcblk0p34 kpan
?0x?0?0?0?0__0x?0?0?0?0?___259_____3___16384__mmcblk0p35 boot
?0x?0?0?0?0__0x?0?0?0?0?___259_____4___16400__mmcblk0p36 recovery
?0x?0?0?0?0__0x?0?0?0?0?___259_____5___16416__mmcblk0p37 factorytune2
?0x?0?0?0?0__0x?0?0?0?0?___259____6__1469392__mmcblk0p38 cache
?0x?0?0?0?0__0x?0?0?0?0?___259____7__3457024__mmcblk0p39 system
?0x?0?0?0?0__0x?0?0?0?0?___259____8_25309056__mmcblk0p40 userdata
?0x?0?0?0?0__0x?0?0?0?0?___179____32____4096__mmcblk0rpmb *"protected data"
* The "RPMB partition is special and can not be accessed
by normal eMMC read / write CMDs". It will cause a kernel error, buffer I/O error"

BOOTLOADER:
Aboot:
Snaipersky said:
interesting stuff regarding ABOOT. newandroidbook.com/Articles/aboot.html?s. I have a Dev MX13, so I'm just here for ideological reasons.
As I understand it, the Turbo's WP is handled by ABOOT. Now, Moto has a bad habit of altering the bootloader so that downgrading is infeasible, and increments it. So it is possible to alter ABOOT.
According to NAB, most of the time (barring cases such as Samsung and Amazon, so we shouldn't have an issue- SHOULD being key) This is secured by a signature check rather than hashing, and the signature is of a fixed size.
One can retrieve the signed image, and if rooted, retrieve the image, sans-signature. Now, if we have the file with and without the signature, could one not create a WP-less, unsigned ABOOT, and then manually paste the signature (Forge it?) in front of it? It would be binary editing, Which I think would be the main challenge.
Could we daisychain this with MoFo to create an effective bootloader unlock? It would be a rootable, system flashable, and without WP, should be able to take a custom recovery.
I may be talking out my *** here, but just my understanding of things.
Click to expand...
Click to collapse
do some disassembly of tz.mbn and find a vulnerability to be able to blow the unlocking qfuse (assuming the device isn't permalocked by SBD_EN qfuse Moto uses)
a known bootloader exploit:
version: MBM-NG-V70.47-0-gcXXXXXX
https://www.codeaurora.org/projects...unds-checking-when-flashing-sparse-images-cve

KNOWN VULNERABILITIES :
bypass's intended restrictions on cryptographic operations, via a long key name:
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3100 -?? patched already?
https://www.exploit-db.com/docs/33864.pdf - ?? patched already?
Graphics buffer vulnerability :
https://packetstormsecurity.com/files/130778/Google-Android-Integer-Oveflow-Heap-Corruption.html
http://seclists.org/fulldisclosure/2015/Mar/63
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-1474

Safestrap :
safestrap/kexec. Safestrap can be changed to "reuse" certain existing partitions or emulate any of them.
/cache 2.3mb used......... 1.36GB FREE! can be used for /system
/firmware 77mb used ...... 45MB FREE! can be used for /cache
start by being able to load /system on to /cache
then look deeper into partitions for another one
or
go the create a Xgb file on the data partition and load it as a data partition

reserved for kexec

HARDWARE:
[/HIDE]Hardware-ish:
https://www.codeaurora.org/cgit/qui...r&id=82117399ba17ea60b7f771c641ff5b1c9283bdc9
https://www.codeaurora.org/cgit/qui...r&id=82117399ba17ea60b7f771c641ff5b1c9283bdc9
https://www.codeaurora.org/cgit/qui...r&id=82117399ba17ea60b7f771c641ff5b1c9283bdc9
https://www.codeaurora.org/cgit/qui...r&id=82117399ba17ea60b7f771c641ff5b1c9283bdc9
https://www.codeaurora.org/cgit/qui...=AU_LINUX_ANDROID_JB_3.2.1.3.04.03.00.176.156
http://forum.xda-developers.com/showthread.php?t=1914359
https://gitlab.com/k2wl/g2_kernel/commit/c3bbe60c733a17a2295241b558d8162b4c782154?view=parallel
http://forum.xda-developers.com/showthread.php?t=2136738
http://forum.xda-developers.com/showthread.php?t=1235219
https://github.com/dtsinc/DTS-Eagle...ob/master/arch/arm/boot/dts/qcom/apq8084.dtsi
http://pastebin.com/tX06Yp3q
http://forum.gsmhosting.com/vbb/f609/atf-drive-v12-30-update-19-may-2015-a-937102/index5.html
http://forum.xda-developers.com/showthread.php?t=1914359
http://faq.riffbox.org/content/10/5...emmc-efi_pit_mbr_ebr-partitioning-plugin.html
Qualcomm APQ8084 TLMM block
This binding describes the Top Level Mode Multiplexer block found in the
MSM8960 platform.
Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
a general description of GPIO and interrupt bindings.
Please refer to pinctrl-bindings.txt in this directory for details of the
common pinctrl bindings used by client devices, including the meaning of the
phrase "pin configuration node".
The pin configuration nodes act as a container for an arbitrary number of
subnodes. Each of these subnodes represents some desired configuration for a
pin, a group, or a list of pins or groups. This configuration can include the
mux function to select on those pin(s)/group(s), and various pin configuration
parameters, such as pull-up, drive strength, etc.
PIN CONFIGURATION NODES:
The name of each subnode is not important; all subnodes should be enumerated
and processed purely based on their content.
Each subnode only affects those parameters that are explicitly listed. In
other words, a subnode that lists a mux function but no pin configuration
parameters implies no information about any pin configuration parameters.
Similarly, a pin subnode that describes a pullup parameter implies no
information about e.g. the mux function.
The following generic properties as defined in pinctrl-bindings.txt are valid
to specify in a pin configuration subnode:
- pins:
Usage: required
Value type: <string-array>
Definition: List of gpio pins affected by the properties specified in
this subnode. Valid pins are:
gpio0-gpio146,
sdc1_clk,
sdc1_cmd,
sdc1_data
sdc2_clk,
sdc2_cmd,
sdc2_data
- function:
Usage: required
Value type: <string>
Definition: Specify the alternative function to be configured for the
specified pins. Functions are only valid for gpio pins.
Valid values are:
adsp_ext, audio_ref, blsp_i2c1, blsp_i2c2, blsp_i2c3,
blsp_i2c4, blsp_i2c5, blsp_i2c6, blsp_i2c7, blsp_i2c8,
blsp_i2c9, blsp_i2c10, blsp_i2c11, blsp_i2c12,
blsp_spi1, blsp_spi2, blsp_spi3, blsp_spi4, blsp_spi5,
blsp_spi6, blsp_spi7, blsp_spi8, blsp_spi9, blsp_spi10,
blsp_spi11, blsp_spi12, blsp_uart1, blsp_uart2, blsp_uart3,
blsp_uart4, blsp_uart5, blsp_uart6, blsp_uart7, blsp_uart8,
blsp_uart9, blsp_uart10, blsp_uart11, blsp_uart12,
blsp_uim1, blsp_uim2, blsp_uim3, blsp_uim4, blsp_uim5,
blsp_uim6, blsp_uim7, blsp_uim8, blsp_uim9, blsp_uim10,
blsp_uim11, blsp_uim12, cam_mclk0, cam_mclk1, cam_mclk2,
cam_mclk3, cci_async, cci_async_in0, cci_i2c0, cci_i2c1,
cci_timer0, cci_timer1, cci_timer2, cci_timer3, cci_timer4,
edp_hpd, gcc_gp1, gcc_gp2, gcc_gp3, gcc_obt, gcc_vtt,i
gp_mn, gp_pdm0, gp_pdm1, gp_pdm2, gp0_clk, gp1_clk, gpio,
hdmi_cec, hdmi_ddc, hdmi_dtest, hdmi_hpd, hdmi_rcv, hsic,
ldo_en, ldo_update, mdp_vsync, pci_e0, pci_e0_n, pci_e0_rst,
pci_e1, pci_e1_rst, pci_e1_rst_n, pci_e1_clkreq_n, pri_mi2s,
qua_mi2s, sata_act, sata_devsleep, sata_devsleep_n,
sd_write, sdc_emmc_mode, sdc3, sdc4, sec_mi2s, slimbus,
spdif_tx, spkr_i2s, spkr_i2s_ws, spss_geni, ter_mi2s, tsif1,
tsif2, uim, uim_batt_alarm
- bias-disable:
Usage: optional
Value type: <none>
Definition: The specified pins should be configued as no pull.
- bias-pull-down:
Usage: optional
Value type: <none>
Definition: The specified pins should be configued as pull down.
- bias-pull-up:
Usage: optional
Value type: <none>
Definition: The specified pins should be configued as pull up.
- output-high:
Usage: optional
Value type: <none>
Definition: The specified pins are configured in output mode, driven
high.
Not valid for sdc pins.
- output-low:
Usage: optional
Value type: <none>
Definition: The specified pins are configured in output mode, driven
low.
Not valid for sdc pins.
- drive-strength:
Usage: optional
Value type: <u32>
Definition: Selects the drive strength for the specified pins, in mA.
Valid values are: 2, 4, 6, 8, 10, 12, 14 and 16
Example:
tlmm: [email protected] {
compatible = "qcom,apq8084-pinctrl";
reg = <0xfd510000 0x4000>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
interrupts = <0 208 0>;
uart2: uart2-default {
mux {
pins = "gpio4", "gpio5";
function = "blsp_uart2";
};
tx {
pins = "gpio4";
drive-strength = <4>;
bias-disable;
};
rx {
pins = "gpio5";
drive-strength = <2>;
bias-pull-up;
};
};
};
APQ Memory... This may or may not match, as it was not pulled off a turbo.
soc: soc { };
memory {
#address-cells = <2>;
#size-cells = <2>;
qsecom_mem: [email protected] {
linux,reserve-contiguous-region;
reg = <0 0 0 0x1100000>;
label = "qseecom_mem";
};
secure_mem: [email protected] {
linux,reserve-contiguous-region;
reg = <0 0 0 0xfc00000>;
label = "secure_mem";
};
tz_apps_and_debug_mem: [email protected] {
linux,reserve-contiguous-region;
linux,reserve-region;
linux,remove-completely;
reg = <0x0 0xd400000 0x0 0x700000>;
label = "tz_apps_and_debug_mem";
};
peripheral_mem: [email protected] {
linux,reserve-contiguous-region;
linux,reserve-region;
linux,remove-completely;
reg = <0x0 0x0db00000 0x0 0x1d00000>;
label = "peripheral_mem";
};
external_image_mem: [email protected] {
linux,reserve-contiguous-region;
linux,reserve-region;
linux,remove-completely;
reg = <0x0 0x0f800000 0x0 0x800000>;
label = "external_image_mem";
};
};
};

reserved for qualcomm download mode and recovery / backdoor flashing info
www.github.com/jcsullins/qdloader
http://forum.xda-developers.com/showthread.php?t=2136738

RANDOM INFO :
USB:
ProductID's the XT1254 can present:
VendorID 22b8 (Motorola, this never changes)
ProductID
2ea4 - MTP mode, software install Off
2ea5 - MTP mode, USB debugging on
2ea6 - PTP mode
2ea7 - PTP mode, USB debugging on
2ea8 - MTP mode, software install On
2e24 - MTP mode, with USB tethering active
NOTE: It is not possible to enable software install in PTP mode, or with USB debugging turned on.
For Google to find them together: VIDID 22b8:2ea4 22b8:2ea5 22b8:2ea6 22b8:2ea7 22b8:2ea8
Credit : http://jamesmcrow.com/node/11

Just in case you need another post reserved - let me know and I can transfer this one to you.......

jerdog said:
Just in case you need another post reserved - let me know and I can transfer this one to you.......
Click to expand...
Click to collapse
Hey, I plan on making this a MONSTER thread of information... I WILL work on this phone like I did the ms910. I can only find faint hints on xda that I ever even owned the phone... I still have this though :
http://androidforums.com/threads/de...esteem-4g-lg-ms910.722075/page-3#post-5867057
and this :
https://github.com/saschaelble?tab=repositories
This will be my :
RANDOM INFO TO BE DIGESTED,
http://lwn.net/Articles/600110/ -hardware?
https://github.com/razrqcom-dev-team/android_device_motorola_quark -cm12 kernel github for xt1225!!
https://www.google.com/search?q=mmcblk0 rpmb&ie=utf-8&oe=utf-8
http://www.digitalinternals.com/mobile/android-mmc-mmcblk-partition-layout/259/
https://forums.oneplus.net/threads/solution-how-i-recovered-my-oneplus-one-from-hard-brick.184927/
http://forum.xda-developers.com/showthread.php?p=50336648#post50336648
https://github.com/gokulnatha/GT-I9...ation/devicetree/bindings/ocmem/msm-ocmem.txt
https://github.com/dtsinc/DTS-Eagle...ob/master/arch/arm/boot/dts/qcom/apq8084.dtsi
https://www.google.com/search?q=emmc_appsboot.mbn&ie=utf-8&oe=utf-8

I have finished unbrick for Motorola Droid Turbo, if I understand you correctly.
http://forum.xda-developers.com/droid-turbo/general/turbo-unbrick-t3139811

Continuing to peddle your warez and hacked up nonsense, even via PM, has earned you a nice vacation. Closing thread.

Related

Stock HBoot Partition Table

Here is the stock Partititon Table for HTC One (M7)
Code:
major minor #blocks name
179 0 30535680 mmcblk0
179 1 128 mmcblk0p1 sbl1
179 2 256 mmcblk0p2 sbl2
179 3 130671 mmcblk0p3 pg1fs
179 4 1 mmcblk0p4 ?
179 5 16 mmcblk0p5 board_info
179 6 256 mmcblk0p6 mfg
179 7 15577 mmcblk0p7 pg2fs
179 8 256 mmcblk0p8 sbl2_update
179 9 1024 mmcblk0p9 sbl3
179 10 256 mmcblk0p10 rpm
179 11 2048 mmcblk0p11 tz
179 12 2080 mmcblk0p12 hboot
179 13 5120 mmcblk0p13 sp1
179 14 1024 mmcblk0p14 wifi
179 15 1024 mmcblk0p15 dsps
179 16 61441 mmcblk0p16 adsp
179 17 8190 mmcblk0p17 radio_config
179 18 32768 mmcblk0p18 reserve_1
179 19 1022 mmcblk0p19 misc
179 20 4096 mmcblk0p20 modem_st1
179 21 4096 mmcblk0p21 modem_st2
179 22 20480 mmcblk0p22 devlog
179 23 4 mmcblk0p23 debug_config
179 24 256 mmcblk0p24 pdata
179 25 16 mmcblk0p25 control
179 26 1280 mmcblk0p26 local
179 27 64 mmcblk0p27 extra
179 28 1024 mmcblk0p28 cdma_record
179 29 98727 mmcblk0p29 reserve
179 30 54270 mmcblk0p30 reserve_2
179 31 76800 mmcblk0p31 radio
179 32 98303 mmcblk0p32 ?
179 33 16384 mmcblk0p33 boot
179 34 16383 mmcblk0p34 recovery
179 35 1900543 mmcblk0p35 system
179 36 655359 mmcblk0p36 cache
179 37 27262976 mmcblk0p37 userdata
Now interestingly enough I've found that the Engineering bootloader posted on the DNA forums that is questionably compatible with our device has this partition table:
Code:
major minor #blocks name
179 0 30535680 mmcblk0
179 1 128 mmcblk0p1 sbl1
179 2 256 mmcblk0p2 sbl2
179 3 130671 mmcblk0p3 pg1fs
179 4 1 mmcblk0p4 ?
179 5 16 mmcblk0p5 board_info
179 6 256 mmcblk0p6 mfg
179 7 15577 mmcblk0p7 pg2fs
179 8 256 mmcblk0p8 sbl2_update
179 9 1024 mmcblk0p9 sbl3
179 10 256 mmcblk0p10 rpm
179 11 2048 mmcblk0p11 tz
179 12 2080 mmcblk0p12 hboot
179 13 5120 mmcblk0p13 sp1
179 14 1024 mmcblk0p14 wifi
179 15 1024 mmcblk0p15 dsps
179 16 61441 mmcblk0p16 adsp
179 17 8190 mmcblk0p17 radio_config
179 18 32768 mmcblk0p18 reserve_1
179 19 1022 mmcblk0p19 misc
179 20 4096 mmcblk0p20 modem_st1
179 21 4096 mmcblk0p21 modem_st2
179 22 20480 mmcblk0p22 devlog
179 23 4 mmcblk0p23 debug_config
179 24 256 mmcblk0p24 pdata
179 25 16 mmcblk0p25 control
179 26 1280 mmcblk0p26 local
179 27 64 mmcblk0p27 extra
179 28 1024 mmcblk0p28 cdma_record
179 29 98727 mmcblk0p29 reserve
179 30 21502 mmcblk0p30 reserve_2
179 31 76800 mmcblk0p31 radio
179 32 16384 mmcblk0p32 boot
179 33 16383 mmcblk0p33 recovery
179 34 1900543 mmcblk0p34 system
179 35 655359 mmcblk0p35 cache
179 36 27394048 mmcblk0p36 userdata
As you can see this bootloader is missing our mmcblk0p32. And has slightly different #blocks in the userdata partition and even more different #blocks in the reserve_2 partition.
I was able to put piece together the names for the blacks by using
Code:
fastboot oem listpartition
while in the engineering bootloader. Doing this resulted in:
Code:
(bootloader) [merge_mfg]:(MERGEMFG, 10) block start=0, size=0 (0 KB)
(bootloader) [merge_emmc]:(RAW, 4) block start=0, size=4849663 (2424831 K
(bootloader) B)
(bootloader) [sbl1]:(RAW, 4) block start=1, size=256 (128 KB)
(bootloader) [sbl2]:(RAW, 4) block start=257, size=512 (256 KB)
(bootloader) [pg1fs]:(PGFS, 4) block start=769, size=261342 (130671 KB)
(bootloader) [board_info]:(RAW, 4) block start=262112, size=32 (16 KB)
(bootloader) [rfg_0]:(RAW, 4) block start=442370, size=2048 (1024 KB)
(bootloader) [rfg_1]:(RAW, 4) block start=444418, size=2048 (1024 KB)
(bootloader) [rfg_2]:(RAW, 4) block start=446466, size=2048 (1024 KB)
(bootloader) [rfg_3]:(RAW, 4) block start=448514, size=2048 (1024 KB)
(bootloader) [rfg_4]:(RAW, 4) block start=450562, size=2048 (1024 KB)
(bootloader) [rfg_5]:(RAW, 4) block start=452610, size=2048 (1024 KB)
(bootloader) [rfg_6]:(RAW, 4) block start=454658, size=2048 (1024 KB)
(bootloader) [mdmsmem]:(RAW, 4) block start=456706, size=2045 (1022 KB)
(bootloader) [dzsystem]:(DEZERO, 8) block start=1048577, size=3801086 (19
(bootloader) 00543 KB)
(bootloader) [dzdata]:(DEZERO, 8) block start=6160384, size=54788096 (273
(bootloader) 94048 KB)
(bootloader) [security_record]:(RAW, 1) block start=0, size=0 (0 KB)
(bootloader) [wcnss]:(RAW, 1) block start=0, size=0 (0 KB)
(bootloader) [wimax]:(RAW, 7E01) block start=0, size=0 (0 KB)
(bootloader) [felica]:(RAW, 1) block start=0, size=0 (0 KB)
(bootloader) [udata_wimax]:(RAW, 7E01) block start=0, size=0 (0 KB)
(bootloader) [spcustom]:(RAW, 1) block start=0, size=0 (0 KB)
(bootloader) [fat]:(RAW, C01) block start=0, size=0 (0 KB)
(bootloader) [imc]:(OTHER, 1) block start=0, size=0 (0 KB)
(bootloader) [nfc_record]:(EXT3, 8301) block start=0, size=0 (0 KB)
(bootloader) [microp]:(OTHER, 1) block start=0, size=0 (0 KB)
(bootloader) [cpld]:(OTHER, 1) block start=0, size=0 (0 KB)
(bootloader) [a1026]:(OTHER, 1) block start=0, size=0 (0 KB)
(bootloader) [nfc]:(OTHER, 1) block start=0, size=0 (0 KB)
(bootloader) [tp]:(OTHER, 1) block start=0, size=0 (0 KB)
(bootloader) [cs]:(OTHER, 1) block start=0, size=0 (0 KB)
(bootloader) [gauge]:(OTHER, 1) block start=0, size=0 (0 KB)
(bootloader) [cir]:(OTHER, 1) block start=0, size=0 (0 KB)
(bootloader) [rcdata]:(OTHER, 1) block start=0, size=0 (0 KB)
(bootloader) [mfg]:(RAW, 7301) block start=262145, size=512 (256 KB)
(bootloader) [pg2fs]:(PGFS, 21) block start=262658, size=31155 (15577 KB)
(bootloader) [sbl2_update]:(RAW, 1) block start=293814, size=512 (256 KB)
(bootloader) [sbl3]:(RAW, 4501) block start=294327, size=2048 (1024 KB)
(bootloader) [rpm]:(RAW, 4701) block start=296376, size=512 (256 KB)
(bootloader) [tz]:(RAW, 4601) block start=296889, size=4096 (2048 KB)
(bootloader) [hboot]:(RAW, 4C01) block start=300986, size=4161 (2080 KB)
(bootloader) [sp1]:(RAW, 3401) block start=305148, size=10240 (5120 KB)
(bootloader) [wifi]:(RAW, 3601) block start=315389, size=2048 (1024 KB)
(bootloader) [dsps]:(RAW, 1) block start=317438, size=2048 (1024 KB)
(bootloader) [adsp]:(RAW, 7A01) block start=319487, size=122882 (61441 KB
(bootloader) )
(bootloader) [radio_config]:(RAW, 7401) block start=442370, size=16381 (8
(bootloader) 190 KB)
(bootloader) [reserve_1]:(RAW, 1) block start=458752, size=65536 (32768 K
(bootloader) B)
(bootloader) [misc]:(RAW, 7601) block start=524289, size=2045 (1022 KB)
(bootloader) [modem_st1]:(EXT3, 4A01) block start=526335, size=8192 (4096
(bootloader) KB)
(bootloader) [modem_st2]:(EXT3, 4B01) block start=534528, size=8192 (4096
(bootloader) KB)
(bootloader) [devlog]:(EXT3, 1901) block start=542721, size=40960 (20480
(bootloader) KB)
(bootloader) [debug_config]:(RAW, 1) block start=583682, size=8 (4 KB)
(bootloader) [pdata]:(RAW, 2301) block start=583691, size=512 (256 KB)
(bootloader) [control]:(RAW, 1) block start=584204, size=32 (16 KB)
(bootloader) [local]:(RAW, 1) block start=584237, size=2561 (1280 KB)
(bootloader) [extra]:(RAW, 1) block start=586799, size=128 (64 KB)
(bootloader) [cdma_record]:(RAW, 1) block start=586928, size=2048 (1024 K
(bootloader) B)
(bootloader) [reserve]:(RAW, 1) block start=588977, size=197455 (98727 KB
(bootloader) )
(bootloader) [reserve_2]:(RAW, 1) block start=786433, size=43004 (21502 K
(bootloader) B)
(bootloader) [radio]:(RAW, 7701) block start=829438, size=153601 (76800 K
(bootloader) B)
(bootloader) [boot]:(RAW, 4801) block start=983040, size=32768 (16384 KB)
(bootloader) [recovery]:(RAW, 7101) block start=1015809, size=32767 (1638
(bootloader) 3 KB)
(bootloader) [system]:(EXT3, 8301) block start=1048577, size=3801086 (190
(bootloader) 0543 KB)
(bootloader) [cache]:(EXT3, 8301) block start=4849664, size=1310719 (6553
(bootloader) 59 KB)
(bootloader) [userdata]:(EXT3, 8301) block start=6160384, size=54788096 (
(bootloader) 27394048 KB)
While I was able to use this bootloader for testing. It will not boot an OS in its current form.
And here are two photos I took while in this engineering bootloader:
{
"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"
}
This engineering bootloader was found at http://forum.xda-developers.com/showthread.php?t=2155214
I do NOT recommend flashing it unless you know what you are doing. This is a true engineering bootloader and it WILL brick your device very easily if you make a mistake.
kozmikkick said:
Here is the stock Partititon Table for HTC One (M7)
Code:
major minor #blocks name
179 0 30535680 mmcblk0
179 1 128 mmcblk0p1 sbl1
179 2 256 mmcblk0p2 sbl2
179 3 130671 mmcblk0p3 pg1fs
179 4 1 mmcblk0p4 ?
179 5 16 mmcblk0p5 board_info
179 6 256 mmcblk0p6 mfg
179 7 15577 mmcblk0p7 pg2fs
179 8 256 mmcblk0p8 sbl2_update
179 9 1024 mmcblk0p9 sbl3
179 10 256 mmcblk0p10 rpm
179 11 2048 mmcblk0p11 tz
179 12 2080 mmcblk0p12 hboot
179 13 5120 mmcblk0p13 sp1
179 14 1024 mmcblk0p14 wifi
179 15 1024 mmcblk0p15 dsps
179 16 61441 mmcblk0p16 adsp
179 17 8190 mmcblk0p17 radio_config
179 18 32768 mmcblk0p18 reserve_1
179 19 1022 mmcblk0p19 misc
179 20 4096 mmcblk0p20 modem_st1
179 21 4096 mmcblk0p21 modem_st2
179 22 20480 mmcblk0p22 devlog
179 23 4 mmcblk0p23 debug_config
179 24 256 mmcblk0p24 pdata
179 25 16 mmcblk0p25 control
179 26 1280 mmcblk0p26 local
179 27 64 mmcblk0p27 extra
179 28 1024 mmcblk0p28 cdma_record
179 29 98727 mmcblk0p29 reserve
179 30 54270 mmcblk0p30 reserve_2
179 31 76800 mmcblk0p31 radio
179 32 98303 mmcblk0p32 ?
179 33 16384 mmcblk0p33 boot
179 34 16383 mmcblk0p34 recovery
179 35 1900543 mmcblk0p35 system
179 36 655359 mmcblk0p36 cache
179 37 27262976 mmcblk0p37 userdata
Click to expand...
Click to collapse
mmcblk0p4 or mmcblk0p32 can be for CIR.
mike1986. said:
mmcblk0p4 or mmcblk0p32 can be for CIR.
Click to expand...
Click to collapse
I could see that for mmcblk0p4 but would seem odd that 32 would be that with it being so large.
Though 32 does seem important as it's missing in the eng hboot and that's the only missing partition that could make it not boot.
Any thoughts on a workaround?
Sent from my HTC One using xda premium
kozmikkick said:
I could see that for mmcblk0p4 but would seem odd that 32 would be that with it being so large.
Though 32 does seem important as it's missing in the eng hboot and that's the only missing partition that could make it not boot.
Any thoughts on a workaround?
Sent from my HTC One using xda premium
Click to expand...
Click to collapse
True, mmcblk0p4 seems better candidate for CIR.
Maybe dzdata for 32?
BTW how comes DNA has EXT3 partitions by default?
mike1986. said:
True, mmcblk0p4 seems better candidate for CIR.
Maybe dzdata for 32?
BTW how comes DNA has EXT3 partitions by default?
Click to expand...
Click to collapse
No clue about DNA. I only have the m7.
The 3rd codeset that I posted is from the eng hboot. It's what I used to figure out the labels for the partitions. Combined with the adb partition list.
It'd be nice if our stock hboot had the fastboot oem listpartitions option.
Sent from my HTC One using xda premium
mike1986. said:
True, mmcblk0p4 seems better candidate for CIR.
Maybe dzdata for 32?
BTW how comes DNA has EXT3 partitions by default?
Click to expand...
Click to collapse
Had some free time. So I dumped 32. And its a completely empty partition. Not sure why they added it to our partition table in final release but it is completely unused.
I also dumped 30. Which I noted to be a bit different in block size between the eng and ship hboots.
This paritition was interesting. There is a lot of memory text as well as text regarding the modem/lte/wdma. I'm thinking this could be a cache partition for the radio? Though I could be easily wrong. May try and get a bump of this partition from butterfly and see what it does on m7.
Also did a hexdiff between the eng and stock hboot. It looks like the stock hboot has all of the commands that the eng hboot has, its just that they aren't unlocked for a SHIP hboot.
One other thing I just noticed on the ENG HBoot is that even though it picks up that my device is M7_UL it assigns it as PN07200 which is for M7_WLS. It should be PN07100.
I believe that this is the reason why it won't boot on OS on our device.
hboots won't work if it fails the assertion of partition tables. A single partition missing or at the very least an incorrect block size on a specific partition. I already worked on this when I ported the engineering hboot of HTC Sensation to Mytouch 4g slide and it took me weeks just reverse engineering the block sizes.
And yeah... The issue I had to solve was only an mismatched block size of the cache partition. Now I don't know how hard it is reverse engineeering it by snipping a single partition and mapping all the partitions above mmcblk0p33 and up. Plus I'm not even sure about the block sizes.
It would be easier if we could at least get the eng hboot of those htc one which was distributed before release.
And ohh messing with it without a jtag box is like walking in a rope crossing a 100meter building lol!
Riyal said:
hboots won't work if it fails the assertion of partition tables. A single partition missing or at the very least an incorrect block size on a specific partition. I already worked on this when I ported the engineering hboot of HTC Sensation to Mytouch 4g slide and it took me weeks just reverse engineering the block sizes.
And yeah... The issue I had to solve was only an mismatched block size of the cache partition. Now I don't know how hard it is reverse engineeering it by snipping a single partition and mapping all the partitions about mmcblk0p33 and up. Plus I'm not even sure about the block sizes.
It would be easier if we could at least get the eng hboot of those htc one which was distributed before release.
And ohh messing with it without a jtag box is like walking in a rope crossing a 100meter building lol!
Click to expand...
Click to collapse
Indeed. I've dug into it a bit. But theres no way I'll flash a modified hboot lol. Quick way to brick for sure!
It did boot once into the off. Not sure how but it did finish loading. Slow as help. I hard booted back into fastboot and reverted hboots.
Sent from my HTC One using xda premium
My thought initially was that it was going to change the partition table sizes automatically like it did on the g2 when flashing the eng desire z hboot on it.
Sent from my HTC One using xda premium
kozmikkick said:
My thought initially was that it was going to change the partition table sizes automatically like it did on the g2 when flashing the eng desire z hboot on it.
Sent from my HTC One using xda premium
Click to expand...
Click to collapse
it would be great if that's the case Maybe then we could implement a real external sdcard with mass usb storage
Riyal said:
it would be great if that's the case Maybe then we could implement a real external sdcard with mass usb storage
Click to expand...
Click to collapse
Doubtful but maybe.
Sent from my HTC One using xda premium
mike1986. said:
True, mmcblk0p4 seems better candidate for CIR.
Maybe dzdata for 32?
BTW how comes DNA has EXT3 partitions by default?
Click to expand...
Click to collapse
Good catch Mike! It would seem that HTC used ext3 during the development phase.
This might just boot if system cache and data are converted to ext3 since that are current ext4
Sent from my HTC One using xda premium
Mmcbk0p4[Extended]
Mmcbk0p4 is extended partition from 4 - mmcblk0p38. Gsm vs CDMA table differs also
Gsm-
System - mmcbl0p35
Boot - mmcblk0p33
On CDMA
Mmcblk0p35 - boot
Mmcblk0p33 - radio
That is why eng hboot on sprint variant won't boot or recognize radio also
mike1986. said:
mmcblk0p4 or mmcblk0p32 can be for CIR.
Click to expand...
Click to collapse
P4 is empty apart from CID and IMEI and one line encrypted bytes.
This partition was used on 2012 One Series phones to hack SCID into the phone as it wasn't protected there. It now seems to be. The CID offset is still the same as on the older phones.
dzdata files might be a filesystem layout for the the data partition, which is P37. Hence the wipe of the sdcard when flashing those images. There is always 3 flavors: 16, 32 and 64 which i assume correspond to available storage sizes. Well that is my explanation of those otherwise pretty odd images.
Cir.img is located in /system/etc after boot and seems to have no partition on its own. Opened with a hex editor it only reveals nicely ordered codes that look like remote control codes for various devices. I do not understand how RUUmode can inject an image file into an existing partition, not flashing a partition. I understand this must be possible as we have seen various OTA's with an upacked system being flashed, yet those use a meta-inf structure to accomplish that, the RUUmode.zips don't. So i am not too sure about cir.img myself.
Hope those thoughts can help you guys a little.
I picked up some vital info here myself and wish to say thanks.
[EDIT]
Here is my partition listing. I added data i found in Post #1, mainly pg2fs and some others that cannot be seen by cat /proc/emmc.
Hope i can help with this a little and thanks again!
https://docs.google.com/spreadsheet/ccc?key=0AjqWaJywIe10dExiQ0gtZmhBQ0F5NmY1V2pJVkMwdkE&usp=sharing
hi all!!, I have a questions
You know if any partition brings USB drivers?
I have a ONE with more than a month with a problem, not at all my PC detects a USB connection, but if I can connect it to the wall to charge it.
And also detects FASTBOOT mode "fastboot flash recovery recovery.img" for example, so I doubt it's any physical damage, since I detect FASTBOOT mode,
Can be damaged any partition with this libs or else?
I have flashed the official RUU and not fixed,
did ruus flashed all partitions?
bovoro said:
hi all!!, I have a questions
You know if any partition brings USB drivers?
I have a ONE with more than a month with a problem, not at all my PC detects a USB connection, but if I can connect it to the wall to charge it.
And also detects FASTBOOT mode "fastboot flash recovery recovery.img" for example, so I doubt it's any physical damage, since I detect FASTBOOT mode,
Can be damaged any partition with this libs or else?
I have flashed the official RUU and not fixed,
did ruus flashed all partitions?
Click to expand...
Click to collapse
There's probably nothing wrong with the phone. Did you try different USB cables and ports? What about downloading and reinstalling the USB drivers? I had a problem with USB and installing the drivers I found on here fixed it.
yes, I've tried usb cable motorola, nokia, samsung, other computers, installing, uninstalling drivers, to no avail, note that part of the problem is constantly entering Car Dock mode, I think I see this behavior with HTC one X and EVOs.
Or the fifth pin is damaged is the mode that detects CAR DOCK.
bovoro said:
yes, I've tried usb cable motorola, nokia, samsung, other computers, installing, uninstalling drivers, to no avail, note that part of the problem is constantly entering Car Dock mode, I think I see this behavior with HTC one X and EVOs.
Or the fifth pin is damaged is the mode that detects CAR DOCK.
Click to expand...
Click to collapse
Hmm... It sounds like your phone's USB port might be damaged... Normally it takes at least a year for that to happen, but I can't see any other reason why your phone have that problem with all computers and cables. The thing that confuses me is that every phone with a broken USB port that I've seen would not charge either, so I don't know why you can still charge and use fastboot with no problems...
It might be time to restore the stock ROM/firmware and send it in...

dual sim 802w research

H377 said:
Hi Scotty,
First of all really thank you for your kind contribution to the scene!
I have a HTC One DUAL SIM M7C_DUG 802w HTC__032 HBOOT 2.27.000 OS:2.41.402.3.
Recently I was playing around with temproot but couldn't reach my goal I wanted to try if I can permanently root the device somehow from the ADB session. Just playing....
Normally the temproot gives root privileges only within the ADB session you started it, nothing else - as far as I understood. I have to confess that I have mounted the system and root as RW and make some dirs but removed them. And even after a reboot everything was set back to normal: all the new files, dirs were removed. Due to the S-ON I guess...
And now the TAMPERED text is there. Even if the modifications are not on the flash anymore. Is this normal? I mean does the device check the modifications on the fly and if you change anything on the system partition or anywhere else it will flag the device as TAMPERED? I'm still S-ON, lock bootloader....
And I was wondering if I don't get the 4.4.2 OTA becasue of the tampered flag? Can this be?
If yes then I'm thinking of using the Firewater pack to achieve S-OFF and then remove the TAMPERED flag and maybe go back to S-ON to be able to receive the OTA someday.
Do I need anyway to go back to S-ON to receive the OTA? Or is it enough if the bootloader is locked?
Many thanks for your kind reply in advance!
Click to expand...
Click to collapse
starting a new thread for some info...
scotty1223 said:
starting a new thread for some info...
Click to expand...
Click to collapse
ok, @H377 lets start by figuring out where things are on your device.
if you could paste the results of:
adb shell
cat /proc/emmc
cat proc/partitions
scotty1223 said:
ok, @H377 lets start by figuring out where things are on your device.
Click to expand...
Click to collapse
Hey Scotty,
Thanks for helping me out!!!
Code:
cat /proc/emmc
dev: size erasesize name
mmcblk0p20: 000ffa00 00000200 "misc"
mmcblk0p37: 00fffe00 00000200 "recovery"
mmcblk0p36: 01000000 00000200 "boot"
mmcblk0p38: 93fffc00 00000200 "system"
mmcblk0p27: 00140200 00000200 "local"
mmcblk0p39: 17fffe00 00000200 "cache"
mmcblk0p40: 670000000 00000200 "userdata"
mmcblk0p23: 01400000 00000200 "devlog"
mmcblk0p25: 00040000 00000200 "pdata"
mmcblk0p28: 00010000 00000200 "extra"
mmcblk0p34: 04b00200 00000200 "radio"
mmcblk0p16: 03c00400 00000200 "adsp"
mmcblk0p15: 00100000 00000200 "dsps"
mmcblk0p18: 00500000 00000200 "wcnss"
mmcblk0p17: 007ffa00 00000200 "radio_config"
mmcblk0p21: 00400000 00000200 "modem_st1"
mmcblk0p22: 00400000 00000200 "modem_st2"
mmcblk0p30: 00040000 00000200 "skylink"
mmcblk0p31: 01900000 00000200 "carrier"
mmcblk0p29: 00100000 00000200 "cdma_record"
mmcblk0p19: 01affe00 00000200 "reserve_1"
mmcblk0p33: 034ffa00 00000200 "reserve_2"
mmcblk0p35: 05fffc00 00000200 "reserve_3"
mmcblk0p32: 04729a00 00000200 "reserve"
Code:
cat proc/partitions
major minor #blocks name
7 0 44730 loop0
179 0 30535680 mmcblk0
179 1 128 mmcblk0p1
179 2 256 mmcblk0p2
179 3 130671 mmcblk0p3
179 4 1 mmcblk0p4
179 5 16 mmcblk0p5
179 6 256 mmcblk0p6
179 7 15577 mmcblk0p7
179 8 256 mmcblk0p8
179 9 1024 mmcblk0p9
179 10 256 mmcblk0p10
179 11 2048 mmcblk0p11
179 12 2080 mmcblk0p12
179 13 5120 mmcblk0p13
179 14 1024 mmcblk0p14
179 15 1024 mmcblk0p15
179 16 61441 mmcblk0p16
179 17 8190 mmcblk0p17
179 18 5120 mmcblk0p18
179 19 27647 mmcblk0p19
179 20 1022 mmcblk0p20
179 21 4096 mmcblk0p21
179 22 4096 mmcblk0p22
179 23 20480 mmcblk0p23
179 24 4 mmcblk0p24
179 25 256 mmcblk0p25
179 26 16 mmcblk0p26
179 27 1280 mmcblk0p27
179 28 64 mmcblk0p28
179 29 1024 mmcblk0p29
179 30 256 mmcblk0p30
179 31 25600 mmcblk0p31
179 32 72870 mmcblk0p32
179 33 54270 mmcblk0p33
179 34 76800 mmcblk0p34
179 35 98303 mmcblk0p35
179 36 16384 mmcblk0p36
179 37 16383 mmcblk0p37
179 38 2424831 mmcblk0p38
179 39 393215 mmcblk0p39
179 40 27000832 mmcblk0p40
179 64 31341568 mmcblk1
179 65 31340544 mmcblk1p1
254 0 44730 dm-0
cool,thanks.
to back up your stock recovery,you will run your temp root and at a # prompt enter:
dd if=/dev/block/mmcblk0p37 of=/sdcard/mmcblk0p37
that will make a copy of your stock recovery on your sd card. youll want to copy it over to your PC where you can change the name to "stock-recovery.img" or something to that affect,and keep it safe.
let me take a quick look at the rest of the partitions,and see how they differ.
scotty1223 said:
cool,thanks.
to back up your stock recovery,you will run your temp root and at a # prompt enter:
dd if=/dev/block/mmcblk0p37 of=/sdcard/mmcblk0p37
that will make a copy of your stock recovery on your sd card. youll want to copy it over to your PC where you can change the name to "stock-recovery.img" or something to that affect,and keep it safe.
let me take a quick look at the rest of the partitions,and see how they differ.
Click to expand...
Click to collapse
Thank you sir!
Will give it a try
ok,so this is our best guess as to what the filled out partition table looks like,based on the locations/sizes of partitions compared to the m7 table i have:
Code:
cat proc/partitions
major minor #blocks name
7 0 44730 loop0
179 0 30535680 mmcblk0
179 1 128 mmcblk0p1 sbl1
179 2 256 mmcblk0p2 sbl2
179 3 130671 mmcblk0p3 pg1fs
179 4 1 mmcblk0p4 ?
179 5 16 mmcblk0p5 board_info
179 6 256 mmcblk0p6 mfg
179 7 15577 mmcblk0p7 pg2fs
179 8 256 mmcblk0p8 sbl2_update
179 9 1024 mmcblk0p9 sbl3
179 10 256 mmcblk0p10 rpm
179 11 2048 mmcblk0p11 tz
179 12 2080 mmcblk0p12 hboot
179 13 5120 mmcblk0p13 sp1
179 14 1024 mmcblk0p14 wifi
179 15 1024 mmcblk0p15 dsps
179 16 61441 mmcblk0p16 adsp
179 17 8190 mmcblk0p17 radio_config
179 18 5120 mmcblk0p18 wcnss
179 19 27647 mmcblk0p19 reserve_1
179 20 1022 mmcblk0p20 misc
179 21 4096 mmcblk0p21 modem_st1
179 22 4096 mmcblk0p22 modem_st2
179 23 20480 mmcblk0p23 devlog
179 24 4 mmcblk0p24 debug_config
179 25 256 mmcblk0p25 pdata
179 26 16 mmcblk0p26 control
179 27 1280 mmcblk0p27 local
179 28 64 mmcblk0p28 extra
179 29 1024 mmcblk0p29 cdma_record
179 30 256 mmcblk0p30 skylink
179 31 25600 mmcblk0p31 carrier
179 32 72870 mmcblk0p32 reserve
179 33 54270 mmcblk0p33 reserve_2
179 34 76800 mmcblk0p34 radio
179 35 98303 mmcblk0p35 reserve_3
179 36 16384 mmcblk0p36 boot
179 37 16383 mmcblk0p37 recovery
179 38 2424831 mmcblk0p38 system
179 39 393215 mmcblk0p39 cache
179 40 27000832 mmcblk0p40 userdata
179 64 31341568 mmcblk1
179 65 31340544 mmcblk1p1
254 0 44730 dm-0
you can back them all up,if you want to. just change the x to the number of each partition:
dd if=/dev/block/mmcblk0px of=/sdcard/mmcblk0px
aka,
dd if=/dev/block/mmcblk0p1 of=/sdcard/mmcblk0p1
dd if=/dev/block/mmcblk0p2 of=/sdcard/mmcblk0p2
and so on.
be aware that the bigger ones will take several minutes to copy,so its not hung if it seems to be taking forever. after youre done move them all to your PC and rename them according to the above table. if you need help here,let me know,but you seem to have a pretty good idea what youre doing.
you can make up your own unsinged ruu(i did this same thing before t mobile had released ruus).
in the home made ruu,youll want to include:
-an android info document(well work on that later)
-adsp
-boot
-hboot
-radio
-recovery
-rpm
-sbl1
-sbl2
-sbl3
-sp1
-system
-tz
i would like to look at mmcblk: 3,4,6,7,and 12 so if you upload those somewhere,and pm me a link(they have some personal info like esn,meid,etc so dont post a link publicly)
hopefully this will all help with the reservations you have about s off,and possibly be of use to some other folks as well. holler if you have questions
scotty1223 said:
ok,so this is our best guess as to what the filled out partition table looks like,based on the locations/sizes of partitions compared to the m7 table i have:
i would like to look at mmcblk: 3,4,6,7,and 12 so if you upload those somewhere,and pm me a link(they have some personal info like esn,meid,etc so dont post a link publicly)
hopefully this will all help with the reservations you have about s off,and possibly be of use to some other folks as well. holler if you have questions
Click to expand...
Click to collapse
Thank you so much really!
I will dump those partitions and will up load it somewhere but I guess it will be only tomorrow. Already started dumping the system and it really takes some time
Thank you so much for your kind help!!!!
H377 said:
Thank you so much really!
I will dump those partitions and will up load it somewhere but I guess it will be only tomorrow. Already started dumping the system and it really takes some time
Thank you so much for your kind help!!!!
Click to expand...
Click to collapse
youre quite welcome for the help. no hurry on the uploads,its more of a curiosity than anything,im pretty sure they will be the same as what ive allready seen.
also,just to make sure i havent accidentally given any false impressions,you will only be able to flash your home made ruu after you s off,as it will not have htcs official signiture and will fail the signiture check on an s on device
also,if you dont mind at some point(no hurry) can you paste for me the results of
fastboot getvar all
make sure to xxx out your esn,meid,imie
scotty1223 said:
youre quite welcome for the help. no hurry on the uploads,its more of a curiosity than anything,im pretty sure they will be the same as what ive allready seen.
also,just to make sure i havent accidentally given any false impressions,you will only be able to flash your home made ruu after you s off,as it will not have htcs official signiture and will fail the signiture check on an s on device
also,if you dont mind at some point(no hurry) can you paste for me the results of
fastboot getvar all
make sure to xxx out your esn,meid,imie
Click to expand...
Click to collapse
Hmm this is very strange: If I start the phone in fastboot mode Windows doesn't recognize the device.... Although the drivers are installed....
H377 said:
Hmm this is very strange: If I start the phone in fastboot mode Windows doesn't recognize the device.... Although the drivers are installed....
Click to expand...
Click to collapse
What windows are you running? 8 and 8.1 are prollematic,as is USB 3.0.
You can try unplug/replug and different ports and cables.
Make sure nothing is running on the pc that talk to the phone- HTC sync,pda net,easy tether,even I tunes
Other than that,make sure the phone is in fastboot and not hboot
Sent from my HTC PG09410 using Tapatalk 2
scotty1223 said:
What windows are you running? 8 and 8.1 are prollematic,as is USB 3.0.
You can try unplug/replug and different ports and cables.
Make sure nothing is running on the pc that talk to the phone- HTC sync,pda net,easy tether,even I tunes
Other than that,make sure the phone is in fastboot and not hboot
Sent from my HTC PG09410 using Tapatalk 2
Click to expand...
Click to collapse
Yeah unfortunately it's Windows 8 so I will try it with Windows 7. Everything else should be just fine.
Is there a guide on how to create the custom RUU?
Any luck?
Sent from my HTC6435LVW using Tapatalk
scotty1223 said:
Any luck?
Sent from my HTC6435LVW using Tapatalk
Click to expand...
Click to collapse
I am on 802w China Unicom
as the topic is 802w, this is my getvar all
(bootloader) version: 0.5
(bootloader) version-bootloader: 2.49.0000
(bootloader) version-baseband: U3.14.3509.14
(bootloader) version-cpld: None
(bootloader) version-microp: None
(bootloader) version-main: 4.21.1402.3
(bootloader) version-misc: PVT SHIP S-OFF
(bootloader) serialno:
(bootloader) imei:
(bootloader) meid:
(bootloader) product: m7cdug
(bootloader) platform: HBOOT-8064
(bootloader) modelid: PN0771000
(bootloader) cidnum: HTCCN703
(bootloader) battery-status: good
(bootloader) battery-voltage: 3691mV
(bootloader) partition-layout: Generic
(bootloader) security: off
(bootloader) build-mode: SHIP
(bootloader) boot-mode: FASTBOOT
(bootloader) commitno-bootloader: dirty-f6d46eca
(bootloader) hbootpreupdate: 11
(bootloader) gencheckpt: 0
Click to expand...
Click to collapse
currently I'm on KitKat OS 4.21.1402.3
If necessary I will downgrade to 2.43 (latest Android 4.2.2)
---------- Post added at 07:27 PM ---------- Previous post was at 06:53 PM ----------
H377 said:
Yeah unfortunately it's Windows 8 so I will try it with Windows 7. Everything else should be just fine.
Is there a guide on how to create the custom RUU?
Click to expand...
Click to collapse
to get adb working on Windows 8.1 you need to download and install Update for Windows 8.1 (KB2917929)
scotty1223 said:
Any luck?
Sent from my HTC6435LVW using Tapatalk
Click to expand...
Click to collapse
I am off from home at the moment. I will give it a try on the weekend.
H377 said:
Yeah unfortunately it's Windows 8 so I will try it with Windows 7. Everything else should be just fine.
Is there a guide on how to create the custom RUU?
Click to expand...
Click to collapse
i just realized i didnt answer this. in a nutshell,you will just rename your mmcblkopx files to the corresponding names based on the chard in post 6. ie,youll name mmcblk0p1 to sbl1.img(make sure you type in the .img extension so the files are converted to images) ,mmcblk0p2 to sbl2.img,and so on.
once youre done,youll just put the images,along with an android info text document together and zip them up. the text file well need to find in an OTApkg for your device,or make one up from scratch. it will contain info such as this:
Code:
modelid: PN0713000
cidnum: HTC__001
cidnum: HTC__E11
cidnum: HTC__102
cidnum: HTC__203
cidnum: HTC__405
cidnum: HTC__Y13
cidnum: HTC__304
cidnum: HTC__032
cidnum: HTC__A07
cidnum: HTC__J15
cidnum: HTC__016
mainver: 1.29.401.12
btype:1
aareport:1
hbootpreupdate:3
but it will have info thats relevant to your device. the images you use are up to you,but you can use the ones i suggested,also in post 6,for a fairly complete homemade ruu.
again,you cant flash it while s on,since it doesnt have htcs official siginture. hope that makes sense.
wewenk said:
I am on 802w China Unicom
as the topic is 802w, this is my getvar all
currently I'm on KitKat OS 4.21.1402.3
If necessary I will downgrade to 2.43 (latest Android 4.2.2)
Click to expand...
Click to collapse
no need to downgrade,i just need to look at a cuople partitions. if you guys want to lock/unlock,remove your tampered banner,and change your MID with adb,then i need to look at mmcblk0p3,mmcblk0p6,and mmcblk0p7
@scotty1223 okay so it mean we can build our own RUU?
Can we do it with s-on device? I want to build an Indonesian 802d ruu then
Sent from my HTC 802w using XDA Premium 4 mobile app
wewenk said:
@scotty1223 okay so it mean we can build our own RUU?
Can we do it with s-on device? I want to build an Indonesian 802d ruu then
Sent from my HTC 802w using XDA Premium 4 mobile app
Click to expand...
Click to collapse
No,you can't do it while s on,as everything but boot,system,and recovery is write protected. In order to make a complete ruu as described above,you'll need to be s off.
What you can do while s on is make a mini-ruu of sorts... Consisting of android info document,boot,system,and recovery. You can flash it while unlocked
Sent from my HTC PG09410 using Tapatalk 2
Okay, now what can I help to continue our research to get 802w unlocked without htcdev?
That will be the first goal for this research correct?
So if success, can we get our stock reset? I mean like htc1guru reset
With htcdev, unlock bl will reset to factory, erase internal phone storage, then we losing htcsoundrecorder, flashlight, calculator etc.
With your method, will it reset too?
Sent from my HTC 802w using XDA Premium 4 mobile app
wewenk said:
Okay, now what can I help to continue our research to get 802w unlocked without htcdev?
That will be the first goal for this research correct?
Click to expand...
Click to collapse
No, sorry if I have that impression. No way to unlock without HTC Dev due to s on write protections.
The purpose here is to be able to flip between locked and unlocked easily, without htcdev, after s off.
Also to be able to achieve locked at all... Without manually changing this flag, best you can do using fastboot command is relocked.
Sent from my HTC6435LVW using Tapatalk

[ROOT] Partitions backup & other partition info :

Before rooting, do backup your /boot and /system partitions via SPFT, as described here (whenever the post is filled in properly ) :
http://forum.xda-developers.com/r1-hd/how-to/backup-partitions-spft-rooting-t3426041
Since it's pretty tedious to run that for each and every partition, I propose to backup other ones after you get root. But note that copying the partitions back to the device is a lot quicker since all the necessary info can be preset in a scatter file !
I recommend that you follow other threads to get root, such as, for example, here :
http://forum.xda-developers.com/r1-hd/how-to/twrp-how-to-root-t3425677
Note, SuperSu will go for "systemless" root, and will patch boot.img. The original boot.img will be saved as /data/stock_boot_*.img.gz It's highly recommended that you backup this boot.img elsewhere (off the device if you did not manage to run SPFT beforehand), in order to be able to restore the device and accept the OTAs.
Some partitions will still be mounted, but I don't think it matters that much. Anyway, here is a list of what is usually mounted :
Code:
Filesystem Size Used Free Blksize
/dev 970.2M 84.0K 970.1M 4096
/sys/fs/cgroup 970.2M 12.0K 970.2M 4096
/mnt 970.2M 0.0K 970.2M 4096
/mnt/runtime/default/emulated 11.2G 522.4M 10.7G 4096
/mnt/runtime/read/emulated 11.2G 522.4M 10.7G 4096
/mnt/runtime/write/emulated 11.2G 522.4M 10.7G 4096
/system 2.5G 2.0G 516.5M 4096
/data 11.2G 522.4M 10.7G 4096
/cache 387.4M 988.0K 386.5M 4096
/protect_f 5.8M 60.0K 5.8M 4096
/protect_s 5.8M 56.0K 5.8M 4096
/nvdata 27.5M 2.2M 25.3M 4096
/storage 970.2M 0.0K 970.2M 4096
/storage/emulated 11.2G 522.4M 10.7G 4096
/su 90.5M 676.0K 89.8M 4096
To backup whatever partitions are out there, run these commands :
Code:
adb shell
su
mkdir /sdcard/images/
cd /sdcard/images
dd if=/dev/block/mmcblk0boot0 of=00_boot0.img
dd if=/dev/block/mmcblk0boot1 of=01_boot1.img
dd if=/dev/block/mmcblk0rpmb of=02_rpmb.img
dd if=/dev/block/mmcblk0 of=p0_pgpt.img bs=1024 count=512
dd if=/dev/block/mmcblk0p1 of=p1_proinfo.img
dd if=/dev/block/mmcblk0p2 of=p2_nvram.img
dd if=/dev/block/mmcblk0p3 of=p3_protect1.img
dd if=/dev/block/mmcblk0p4 of=p4_protect2.img
dd if=/dev/block/mmcblk0p5 of=p5_lk.img
dd if=/dev/block/mmcblk0p6 of=p6_para.img
dd if=/dev/block/mmcblk0p7 of=p7_boot.img
dd if=/dev/block/mmcblk0p8 of=p8_recovery.img
dd if=/dev/block/mmcblk0p9 of=p9_logo.img
dd if=/dev/block/mmcblk0p10 of=p10_expdb.img
dd if=/dev/block/mmcblk0p11 of=p11_seccfg.img
dd if=/dev/block/mmcblk0p12 of=p12_oemkeystore.img
dd if=/dev/block/mmcblk0p13 of=p13_secro.img
dd if=/dev/block/mmcblk0p14 of=p14_keystore.img
dd if=/dev/block/mmcblk0p15 of=p15_tee1.img
dd if=/dev/block/mmcblk0p16 of=p16_tee2.img
dd if=/dev/block/mmcblk0p17 of=p17_frp.img
dd if=/dev/block/mmcblk0p18 of=p18_nvdata.img
dd if=/dev/block/mmcblk0p19 of=p19_metadata.img
#dd if=/dev/block/mmcblk0p20 of=p20_system.img
#dd if=/dev/block/mmcblk0p21 of=p21_cache.img
#dd if=/dev/block/mmcblk0p22 of=p22_userdata.img
dd if=/dev/block/mmcblk0p23 of=p23_flashinfo.img
md5sum *.img
exit
exit
adb pull /sdcard/images
These are the files that you'll get
Code:
-rw-rw---- root sdcard_rw 4194304 2016-01-01 18:31 00_boot0.img
-rw-rw---- root sdcard_rw 4194304 2016-01-01 18:31 01_boot1.img
-rw-rw---- root sdcard_rw 0 2016-01-01 18:47 02_rpmb.img
-rw-rw---- root sdcard_rw 524288 2016-01-01 18:31 p0_pgpt.img
-rw-rw---- root sdcard_rw 3145728 2016-01-01 18:31 p1_proinfo.img
-rw-rw---- root sdcard_rw 5242880 2016-01-01 18:31 p2_nvram.img
-rw-rw---- root sdcard_rw 10485760 2016-01-01 18:31 p3_protect1.img
-rw-rw---- root sdcard_rw 10485760 2016-01-01 18:31 p4_protect2.img
-rw-rw---- root sdcard_rw 524288 2016-01-01 18:31 p5_lk.img
-rw-rw---- root sdcard_rw 524288 2016-01-01 18:31 p6_para.img
-rw-rw---- root sdcard_rw 16777216 2016-01-01 18:31 p7_boot.img
-rw-rw---- root sdcard_rw 16777216 2016-01-01 18:31 p8_recovery.img
-rw-rw---- root sdcard_rw 8388608 2016-01-01 18:31 p9_logo.img
-rw-rw---- root sdcard_rw 10485760 2016-01-01 18:31 p10_expdb.img
-rw-rw---- root sdcard_rw 524288 2016-01-01 18:31 p11_seccfg.img
-rw-rw---- root sdcard_rw 2097152 2016-01-01 18:31 p12_oemkeystore.img
-rw-rw---- root sdcard_rw 6291456 2016-01-01 18:31 p13_secro.img
-rw-rw---- root sdcard_rw 8388608 2016-01-01 18:31 p14_keystore.img
-rw-rw---- root sdcard_rw 5242880 2016-01-01 18:31 p15_tee1.img
-rw-rw---- root sdcard_rw 5242880 2016-01-01 18:31 p16_tee2.img
-rw-rw---- root sdcard_rw 1048576 2016-01-01 18:31 p17_frp.img
-rw-rw---- root sdcard_rw 33554432 2016-01-01 18:31 p18_nvdata.img
-rw-rw---- root sdcard_rw 38797312 2016-01-01 18:32 p19_metadata.img
-rw-rw---- root sdcard_rw 16777216 2016-01-01 18:32 p23_flashinfo.img
And this is another map of partitions to names :
Code:
lrwxrwxrwx root root 2016-01-01 17:30 boot -> /dev/block/mmcblk0p7
lrwxrwxrwx root root 2016-01-01 17:30 cache -> /dev/block/mmcblk0p21
lrwxrwxrwx root root 2016-01-01 17:30 expdb -> /dev/block/mmcblk0p10
lrwxrwxrwx root root 2016-01-01 17:30 flashinfo -> /dev/block/mmcblk0p23
lrwxrwxrwx root root 2016-01-01 17:30 frp -> /dev/block/mmcblk0p17
lrwxrwxrwx root root 2016-01-01 17:30 keystore -> /dev/block/mmcblk0p14
lrwxrwxrwx root root 2016-01-01 17:30 lk -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2016-01-01 17:30 logo -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2016-01-01 17:30 metadata -> /dev/block/mmcblk0p19
lrwxrwxrwx root root 2016-01-01 17:30 nvdata -> /dev/block/mmcblk0p18
lrwxrwxrwx root root 2016-01-01 17:30 nvram -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2016-01-01 17:30 oemkeystore -> /dev/block/mmcblk0p12
lrwxrwxrwx root root 2016-01-01 17:30 para -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2016-01-01 17:30 proinfo -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 2016-01-01 17:30 protect1 -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2016-01-01 17:30 protect2 -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2016-01-01 17:30 recovery -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2016-01-01 17:30 seccfg -> /dev/block/mmcblk0p11
lrwxrwxrwx root root 2016-01-01 17:30 secro -> /dev/block/mmcblk0p13
lrwxrwxrwx root root 2016-01-01 17:30 system -> /dev/block/mmcblk0p20
lrwxrwxrwx root root 2016-01-01 17:30 tee1 -> /dev/block/mmcblk0p15
lrwxrwxrwx root root 2016-01-01 17:30 tee2 -> /dev/block/mmcblk0p16
lrwxrwxrwx root root 2016-01-01 17:30 userdata -> /dev/block/mmcblk0p22
And mount output :
Code:
rootfs / rootfs ro,seclabel 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,seclabel,relatime,mode=600 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
adb /dev/usb-ffs/adb functionfs rw,relatime 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,seclabel,relatime 0 0
selinuxfs /sys/fs/selinux selinuxfs rw,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,seclabel,relatime 0 0
none /sys/fs/cgroup tmpfs rw,seclabel,relatime,mode=750,gid=1000 0 0
pstore /sys/fs/pstore pstore rw,seclabel,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt tmpfs rw,seclabel,relatime,mode=755,gid=1000 0 0
/dev/fuse /mnt/runtime/default/emulated fuse rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
/dev/fuse /mnt/runtime/read/emulated fuse rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
/dev/fuse /mnt/runtime/write/emulated fuse rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/system /system ext4 ro,seclabel,relatime,data=ordered 0 0
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/userdata /data ext4 rw,seclabel,nosuid,nodev,noatime,discard,noauto_da_alloc,resuid=10010,data=ordered 0 0
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/cache /cache ext4 rw,seclabel,nosuid,nodev,noatime,discard,noauto_da_alloc,data=ordered 0 0
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/protect1 /protect_f ext4 rw,seclabel,nosuid,nodev,noatime,nodelalloc,noauto_da_alloc,commit=1,data=ordered 0 0
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/protect2 /protect_s ext4 rw,seclabel,nosuid,nodev,noatime,nodelalloc,noauto_da_alloc,commit=1,data=ordered 0 0
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/nvdata /nvdata ext4 rw,seclabel,nosuid,nodev,noatime,discard,noauto_da_alloc,data=ordered 0 0
tmpfs /storage tmpfs rw,seclabel,relatime,mode=755,gid=1000 0 0
/dev/fuse /storage/emulated fuse rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
/dev/block/loop1 /su ext4 rw,seclabel,noatime,data=ordered 0 0
And partition sizes in blocks:
Code:
major minor #blocks name
7 0 1254 loop0
7 1 98304 loop1
179 0 15392768 mmcblk0
179 1 3072 mmcblk0p1
179 2 5120 mmcblk0p2
179 3 10240 mmcblk0p3
179 4 10240 mmcblk0p4
179 5 512 mmcblk0p5
179 6 512 mmcblk0p6
179 7 16384 mmcblk0p7
179 8 16384 mmcblk0p8
179 9 8192 mmcblk0p9
179 10 10240 mmcblk0p10
179 11 512 mmcblk0p11
179 12 2048 mmcblk0p12
179 13 6144 mmcblk0p13
179 14 8192 mmcblk0p14
179 15 5120 mmcblk0p15
179 16 5120 mmcblk0p16
179 17 1024 mmcblk0p17
179 18 32768 mmcblk0p18
179 19 37888 mmcblk0p19
179 20 2736128 mmcblk0p20
179 21 409600 mmcblk0p21
179 22 12049920 mmcblk0p22
179 23 16384 mmcblk0p23
179 96 4096 mmcblk0rpmb
179 64 4096 mmcblk0boot1
179 32 4096 mmcblk0boot0
And another great piece of info (borrowed from here, @ss2man44 ):
http://forum.xda-developers.com/showpost.php?p=67903154&postcount=619
(16 Gb Prime model)
Code:
> gdisk -l mmcblk0.img
GPT fdisk (gdisk) version 1.0.1
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk mmcblk0.img: 30785536 sectors, 14.7 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 00000000-0000-0000-0000-000000000000
Partition table holds up to 23 entries
First usable sector is 1024, last usable sector is 30784511
Partitions will be aligned on 1024-sector boundaries
Total free space is 0 sectors (0 bytes)
Number Start (sector) End (sector) Size Code Name
1 1024 7167 3.0 MiB 0700 proinfo
2 7168 17407 5.0 MiB 0700 nvram
3 17408 37887 10.0 MiB 0700 protect1
4 37888 58367 10.0 MiB 0700 protect2
5 58368 59391 512.0 KiB 0700 lk
6 59392 60415 512.0 KiB 0700 para
7 60416 93183 16.0 MiB 0700 boot
8 93184 125951 16.0 MiB 0700 recovery
9 125952 142335 8.0 MiB 0700 logo
10 142336 162815 10.0 MiB 0700 expdb
11 162816 163839 512.0 KiB 0700 seccfg
12 163840 167935 2.0 MiB 0700 oemkeystore
13 167936 180223 6.0 MiB 0700 secro
14 180224 196607 8.0 MiB 0700 keystore
15 196608 206847 5.0 MiB 0700 tee1
16 206848 217087 5.0 MiB 0700 tee2
17 217088 219135 1024.0 KiB 0700 frp
18 219136 284671 32.0 MiB 0700 nvdata
19 284672 360447 37.0 MiB 0700 metadata
20 360448 5832703 2.6 GiB 0700 system
21 5832704 6651903 400.0 MiB 0700 cache
22 6651904 30751743 11.5 GiB 0700 userdata
23 30751744 30784511 16.0 MiB 0700 flashinfo
And finally, partitions with their starting address/length in HEX for the 16 Gb version (stuff everybody was waiting for ) :
Code:
Name Block_device Start_adr Length
pgpt mmcblk0 0x0 0x80000
proinfo mmcblk0p1 0x80000 0x300000
nvram mmcblk0p2 0x380000 0x500000
protect1 mmcblk0p3 0x880000 0xa00000
protect2 mmcblk0p4 0x1280000 0xa00000
lk mmcblk0p5 0x1c80000 0x80000
para mmcblk0p6 0x1d00000 0x80000
boot mmcblk0p7 0x1d80000 0x1000000
recovery mmcblk0p8 0x2d80000 0x1000000
logo mmcblk0p9 0x3d80000 0x800000
expdb mmcblk0p10 0x4580000 0xa00000
seccfg mmcblk0p11 0x4f80000 0x80000
oemkeystore mmcblk0p12 0x5000000 0x200000
secro mmcblk0p13 0x5200000 0x600000
keystore mmcblk0p14 0x5800000 0x800000
tee1 mmcblk0p15 0x6000000 0x500000
tee2 mmcblk0p16 0x6500000 0x500000
frp mmcblk0p17 0x6a00000 0x100000
nvdata mmcblk0p18 0x6b00000 0x2000000
metadata mmcblk0p19 0x8b00000 0x2500000
system mmcblk0p20 0xb000000 0xa7000000
cache mmcblk0p21 0xb2000000 0x19000000
userdata mmcblk0p22 0xcb000000 0x2df780000
flashinfo mmcblk0p23 0x3aa780000 0x1000000
sgpt mmcblk0s 0x3ab780000 0x80000
[COLOR="Red"]end end 0x3ab800000 0x0[/COLOR]
Great guide with lots of detail. Those partition mounts can be useful for porting ROMs.
nice post. I have pulled all the firmware off of my stock v6.4 and was wondering if you have a fully working Scatter file i can test in sp flash tool
Tomsgt said:
nice post. I have pulled all the firmware off of my stock v6.4 and was wondering if you have a fully working Scatter file i can test in sp flash tool
Click to expand...
Click to collapse
Unfortunately, I do not.
It can be made manually out of 2 outputs :
Code:
cat /proc/partitions
ls -l /dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name
A bit of Python would go a long way to make sure all addresses are correct. I am surprised there is not a tool like this out there ...
bibikalka said:
Unfortunately, I do not.
It can be made manually out of 2 outputs :
A bit of Python would go a long way to make sure all addresses are correct. I am surprised there is not a tool like this out there ...
Click to expand...
Click to collapse
Thanks have on that someone else already made but I don't know how to check it to make sure it is correct or not. I have never made a scatter before.
Tomsgt said:
Thanks have on that someone else already made but I don't know how to check it to make sure it is correct or not. I have never made a scatter before.
Click to expand...
Click to collapse
I am trying to kludge through with the conversions now. never done one before so its taking some time. I am getting hung up on the relation between the output of cat /proc/partitions that gives size in blocks and output of parted that has size in kB MB and GB. assuming kB to B *1024 then DEC to HEX the values all come out off by about 0.2% and i dont know if it is supposed to be rounded off.
mrmazak said:
I am trying to kludge through with the conversions now. never done one before so its taking some time. I am getting hung up on the relation between the output of cat /proc/partitions that gives size in blocks and output of parted that has size in kB MB and GB. assuming kB to B *1024 then DEC to HEX the values all come out off by about 0.2% and i dont know if it is supposed to be rounded off.
Click to expand...
Click to collapse
check out the scatter file i have here http://rootjunkysdl.com/files/?dir=Blu R1 HD Amazon the twrp scatter will work
Tomsgt said:
check out the scatter file i have here http://rootjunkysdl.com/files/?dir=Blu R1 HD Amazon the twrp scatter will work
Click to expand...
Click to collapse
It that the same one from @bullet25. Or is it another one. Because it has the same error in the user data and last three partitions. At the least these. Are what I can see
mrmazak said:
It that the same one from @bullet25. Or is it another one. Because it has the same error in the user data and last three partitions. At the least these. Are what I can see
Click to expand...
Click to collapse
Let me put some Python together, and I'll generate a table of first address/length, so we'd be able to check what the scatter file has.
mrmazak said:
It that the same one from @bullet25. Or is it another one. Because it has the same error in the user data and last three partitions. At the least these. Are what I can see
Click to expand...
Click to collapse
Yeah it was that one I just renamed it. I figured it had errors but I need a fully working one.
---------- Post added at 05:12 PM ---------- Previous post was at 05:12 PM ----------
bibikalka said:
Let me put some Python together, and I'll generate a table of first address/length, so we'd be able to check what the scatter file has.
Click to expand...
Click to collapse
That would be awesome.
mrmazak said:
It that the same one from @bullet25. Or is it another one. Because it has the same error in the user data and last three partitions. At the least these. Are what I can see
Click to expand...
Click to collapse
Tomsgt said:
Yeah it was that one I just renamed it. I figured it had errors but I need a fully working one.
---------- Post added at 05:12 PM ---------- Previous post was at 05:12 PM ----------
That would be awesome.
Click to expand...
Click to collapse
With some Python I was able to generate the addresses/lengths, and indeed, the existing scatter MT6735...test7.txt is OK for the most part. See post #1 for the updated partitions list with this info for the 16 Gb version. The only things that need to be fixed in MT6735...test7.txt are at the end, see the segment below (I cannot guarantee that the various words in this are fully correct, but the names/addresses are!). Not sure if flashinfo needs to be restored during a full reimage. But its address will change depending on the 8/16 Gb version.
Code:
- partition_index: SYS22
partition_name: cache
file_name: cache.img
is_download: true
type: NORMAL_ROM
linear_start_addr: 0xb2000000
physical_start_addr: 0xb2000000
partition_size: 0x19000000
region: EMMC_USER
storage: HW_STORAGE_EMMC
boundary_check: true
is_reserved: false
operation_type: UPDATE
reserve: 0x00
- partition_index: SYS23
partition_name: userdata
file_name: userdata.img
is_download: true
type: NORMAL_ROM
linear_start_addr: 0xcb000000
physical_start_addr: 0xcb000000
partition_size: 0x2df780000
region: EMMC_USER
storage: HW_STORAGE_EMMC
boundary_check: true
is_reserved: false
operation_type: UPDATE
reserve: 0x00
- partition_index: SYS24
partition_name: flashinfo
file_name: flashinfo.img
is_download: true
type: NORMAL_ROM
linear_start_addr: 0x3aa780000
physical_start_addr: 0x3aa780000
partition_size: 0x1000000
region: EMMC_USER
storage: HW_STORAGE_EMMC
boundary_check: true
is_reserved: false
operation_type: UPDATE
reserve: 0x00
bibikalka said:
With some Python I was able to generate the addresses/lengths, and indeed, the existing scatter MT6735...test7.txt is OK for the most part. See post #1 for the updated partitions list with this info for the 16 Gb version. The only things that need to be fixed in MT6735...test7.txt are at the end, see the segment below (I cannot guarantee that the various words in this are fully correct, but the names/addresses are!). Not sure if flashinfo needs to be restored during a full reimage. But its address will change depending on the 8/16 Gb version.
Code:
- partition_index: SYS22
partition_name: cache
file_name: cache.img
is_download: true
type: NORMAL_ROM
linear_start_addr: 0xb2000000
physical_start_addr: 0xb2000000
partition_size: 0x19000000
region: EMMC_USER
storage: HW_STORAGE_EMMC
boundary_check: true
is_reserved: false
operation_type: UPDATE
reserve: 0x00
- partition_index: SYS23
partition_name: userdata
file_name: userdata.img
is_download: true
type: NORMAL_ROM
linear_start_addr: 0xcb000000
physical_start_addr: 0xcb000000
partition_size: 0x2df780000
region: EMMC_USER
storage: HW_STORAGE_EMMC
boundary_check: true
is_reserved: false
operation_type: UPDATE
reserve: 0x00
- partition_index: SYS24
partition_name: flashinfo
file_name: flashinfo.img
is_download: true
type: NORMAL_ROM
linear_start_addr: 0x3aa780000
physical_start_addr: 0x3aa780000
partition_size: 0x1000000
region: EMMC_USER
storage: HW_STORAGE_EMMC
boundary_check: true
is_reserved: false
operation_type: UPDATE
reserve: 0x00
Click to expand...
Click to collapse
thanks i just updated my scatter
thats good. So are you gonna continue with the python script and maybe make some type of app with it?
I am not familiar with scatter files and spft that much so excuse me if this is completely wrong. But your numbers for the start and length do add up which seems correct. except that the flashinfo offset in the official update does not add up. So i looked at a couple other files I had found. (both from my other blu phone Life-one-X) and they also do not add up. (as in when I use a programmers calculator to add the hex). So as your numbers are correct I dont understand if the flashinfo is supposed to be mathematically in line or if it should be something else. Then that also leaves the sgpt partition in limbo after the flashinfo.
of course none of this should matter at the moment , i think, because both of these partitions are flagged in the scatter as not to be downloaded(flashed)
mrmazak said:
thats good. So are you gonna continue with the python script and maybe make some type of app with it?
I am not familiar with scatter files and spft that much so excuse me if this is completely wrong. But your numbers for the start and length do add up which seems correct. except that the flashinfo offset in the official update does not add up. So i looked at a couple other files I had found. (both from my other blu phone Life-one-X) and they also do not add up. (as in when I use a programmers calculator to add the hex). So as your numbers are correct I dont understand if the flashinfo is supposed to be mathematically in line or if it should be something else. Then that also leaves the sgpt partition in limbo after the flashinfo.
of course none of this should matter at the moment , i think, because both of these partitions are flagged in the scatter as not to be downloaded(flashed)
Click to expand...
Click to collapse
OK, good catch ! The thing is, my script is basically an automatic calculator, I use the output of the 2 commands, sort them semi-manually, and then run awk to extract names, addresses to be used with Python :
Code:
cat /proc/partitions
ls -l /dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name
...a bit of work, and in Python end up as:
pname=["proinfo","nvram","protect1","protect2","lk","para","boot","recovery","logo","expdb","seccfg","oemkeystore","secro","keystore","tee1","tee2","frp","nvdata","metadata","system","cache","userdata","flashinfo"]
pdev=["mmcblk0p1","mmcblk0p2","mmcblk0p3","mmcblk0p4","mmcblk0p5","mmcblk0p6","mmcblk0p7","mmcblk0p8","mmcblk0p9","mmcblk0p10","mmcblk0p11","mmcblk0p12","mmcblk0p13","mmcblk0p14","mmcblk0p15","mmcblk0p16","mmcblk0p17","mmcblk0p18","mmcblk0p19","mmcblk0p20","mmcblk0p21","mmcblk0p22","mmcblk0p23"]
psize=[3072,5120,10240,10240,512,512,16384,16384,8192,10240,512,2048,6144,8192,5120,5120,1024,32768,37888,2736128,409600,12049920,16384]
Then I add everything sequentially, and print it out (I realized I am missing pgpt chunk, need to read it directly from mmcblk0!).
I don't see "sgpt" partition anywhere in any of the Android outputs.
And, there is an easy way to find out if flashinfo address is correct, first dd the partition in Android, 2nd read it using the addresses/lengths in SPFT. If it matches, the addresses are correct by definition !
@mrmazak, @Tomsgt
I added pgpt and sgpt partitions to the list of addresses. I also read flashinfo via the SPFT, and compared to the one from dd, and it matched exactly. If I try to read past the last address I've counted, it gives me a read error, meaning the math is correct! Please see the section below for sgpt (16 Gb version of BLU R1 !!!)
Code:
- partition_index: SYS25
partition_name: sgpt
file_name: sgpt.img
is_download: true
type: NORMAL_ROM
linear_start_addr: 0x3ab780000
physical_start_addr: 0x3ab780000
partition_size: 0x80000
region: EMMC_USER
storage: HW_STORAGE_EMMC
boundary_check: true
is_reserved: false
operation_type: UPDATE
reserve: 0x00
bibikalka said:
@mrmazak, @Tomsgt
I added pgpt and sgpt partitions to the list of addresses. I also read flashinfo via the SPFT, and compared to the one from dd, and it matched exactly. If I try to read past the last address I've counted, it gives me a read error, meaning the math is correct! Please see the section below for sgpt (16 Gb version of BLU R1 !!!)
Code:
- partition_index: SYS25
partition_name: sgpt
file_name: sgpt.img
is_download: true
type: NORMAL_ROM
linear_start_addr: 0x3ab780000
physical_start_addr: 0x3ab780000
partition_size: 0x80000
region: EMMC_USER
storage: HW_STORAGE_EMMC
boundary_check: true
is_reserved: false
operation_type: UPDATE
reserve: 0x00
Click to expand...
Click to collapse
thanks for all the help
Brilliant
And finally, partitions with their starting address/length in HEX for the 16 Gb version (stuff everybody was waiting for ) :
Code:
Name Block_device Start_adr Length
pgpt mmcblk0 0x0 0x80000
proinfo mmcblk0p1 0x80000 0x300000
nvram mmcblk0p2 0x380000 0x500000
protect1 mmcblk0p3 0x880000 0xa00000
protect2 mmcblk0p4 0x1280000 0xa00000
lk mmcblk0p5 0x1c80000 0x80000
para mmcblk0p6 0x1d00000 0x80000
boot mmcblk0p7 0x1d80000 0x1000000
recovery mmcblk0p8 0x2d80000 0x1000000
logo mmcblk0p9 0x3d80000 0x800000
expdb mmcblk0p10 0x4580000 0xa00000
seccfg mmcblk0p11 0x4f80000 0x80000
oemkeystore mmcblk0p12 0x5000000 0x200000
secro mmcblk0p13 0x5200000 0x600000
keystore mmcblk0p14 0x5800000 0x800000
tee1 mmcblk0p15 0x6000000 0x500000
tee2 mmcblk0p16 0x6500000 0x500000
frp mmcblk0p17 0x6a00000 0x100000
nvdata mmcblk0p18 0x6b00000 0x2000000
metadata mmcblk0p19 0x8b00000 0x2500000
system mmcblk0p20 0xb000000 0xa7000000
cache mmcblk0p21 0xb2000000 0x19000000
userdata mmcblk0p22 0xcb000000 0x2df780000
flashinfo mmcblk0p23 0x3aa780000 0x1000000
sgpt mmcblk0s 0x3ab780000 0x80000
[COLOR="Red"]end end 0x3ab800000 0x0[/COLOR]
Click to expand...
Click to collapse
OK sir you are brilliant, if you ever have spare time on your hands to let me drill you with questions I'd love the chance. Secondly, before I go making things worse, and I apologize if this has been answered:
According to your partitions here the scatter I was trying to unbrick my phone with is just all wrong. Or am I misunderstanding how it translates into scatter, for example my first partition was preloader at 0x0 with a 40000 length. Assuming pgpt is the preloader, and the length is 80k, this could very possibly be why I'm getting brom 4032? So if I edited the scatter to use proper partitions, files, and dug through my working 16/2 and got proper backups to use this would be where to start with any unbrick? Or do I have no clue what I'm talking about here.
Persuasion89 said:
OK sir you are brilliant, if you ever have spare time on your hands to let me drill you with questions I'd love the chance. Secondly, before I go making things worse, and I apologize if this has been answered:
According to your partitions here the scatter I was trying to unbrick my phone with is just all wrong. Or am I misunderstanding how it translates into scatter, for example my first partition was preloader at 0x0 with a 40000 length. Assuming pgpt is the preloader, and the length is 80k, this could very possibly be why I'm getting brom 4032? So if I edited the scatter to use proper partitions, files, and dug through my working 16/2 and got proper backups to use this would be where to start with any unbrick? Or do I have no clue what I'm talking about here.
Click to expand...
Click to collapse
What's wrong with the existing scatter files out there ? Just use those ! The addresses do match what's posted here, so should not be any issue at all.
@bibikalka or @Tomsgt , quick question. Do either of you two happen to know if the device requires/uses a uboot image?
bullet25 said:
@bibikalka or @Tomsgt , quick question. Do either of you two happen to know if the device requires/uses a uboot image?
Click to expand...
Click to collapse
Of course ! It's in every OTA update, uboot.img, and sometimes, as lk.bin

Meizu Pro5 32gb/64gb partition tables/partition information

Hi,
The past week i've been busy in flashing flyme/twrp/ubuntu and all went very well, but i find the experience a little limited until now. Especially when reading about all the ppl who bricked their device or are stuck one way or another with locked bootloaders, missing recovery's etc.
I found that the bootloader unlock status is kept in the /private partition, wether manipulating this partition in order to unlock the device is possible, i dont know.
So in order to up the experience for all i need your help
I've been mapping out the partition layout on my Chinese Meizu Pro5 64gb (converted to global/intl now), but one device only gets you so far. There are differences between the Flyme/Ubuntu devices, the Flyme devices U/A/I and the TWRP recovery (lets all thank faust93) does not work for everyone (it does for me).
For anyone that has access to 'sgdisk' (you successfully installed TWRP or have an Ubuntu edition) i need a layout of your partitions: (your personal info/guid is excluded (-v GUID) from this)
# sgdisk --print /dev/block/sda | grep -v GUID >/sdcard/partition_layout.txt
We have the following devices:
1. G [M576_intl_official] Global 32gb
2. G [M576_intl_official] Global 64gb
3. U: [M576_unicom_custom] Unicom 32gb
4. U: [M576_unicom_custom] Unicom 64gb
5. A: [M576_mobile_public] Mobile Public 32gb
6. A: [M576_mobile_public] Mobile Public 64gb
7. I: [M576_intl_official] Ubuntu Meizu 32gb
8. I: [M576_intl_official] Ubuntu Meizu 64gb
TWRP 3: fstab table (work in progress)
Code:
/private emmc /dev/block/sda1 flags=display="Private";backup=1 # meizu imei/esn/wifi/bluetooth/serial/lock/unlock
/proinfo emmc /dev/block/sda2 # meizu firmware/machine_type/region_id unicom(U)/chicom(A)/intl(G)
#/misc emmc /dev/block/sda3 # empty 0x00
/param emmc /dev/block/sda21 # u-boot active stats
/efs ext4 /dev/block/sda22 flags=display="EFS";backup=1
#/pnv emmc /dev/block/sda23 # empty 0x00
/ldfw emmc /dev/block/sda24 flags=display="Firmware";backup=1
/dtb emmc /dev/block/sda25 flags=display="Device Tree";backup=1
/bootimg emmc /dev/block/sda26 flags=display="Boot"
/recovery ext4 /dev/block/sda27 flags=display="Recovery";backup=1
/bootlogo emmc /dev/block/sda28 flags=display="Bootlogo";backup=1
#/rstinfo emmc /dev/block/sda29 # kernel log
#/mnv ext4 /dev/block/sda30 # nv_protected
#/reserved1 emmc /dev/block/sda31 # empty 0x00
#/reserved2 emmc /dev/block/sda32 # empty 0x00
#/reserved3 emmc /dev/block/sda33 # empty 0x00
/system ext4 /dev/block/sda41 flags=display="System"
#/custom ext4 /dev/block/sda42 # preload: adds applications to system on first install/factory reset
/cache ext4 /dev/block/sda43 flags=display="Cache";backup=1
/sdcard ext4 /dev/block/sda44 flags=display="Internal Storage";storage;settingsstorage
#/u-boot emmc /dev/block/sdb # u-boot bootloader
#- emmc /dev/block/sdc # empty 0x00 ( ?? could be used as backup bootloader for Android 7.0 nougat ??)
/external_sd vfat /dev/block/mmcblk0p1 flags=display="Micro SDcard";storage;wipeingui;removable
/usb-otg vfat ?? flags=display="USB-OTG";storage;wipeingui;removable
*** BRICK WARNING: the bootloader expects >> ldfw << and >>dtb<< ***
*** Make sure ldfw and dtb are flashed, i did not dare to try without ***
*** Also make sure that bootloader and ldfw are from the flyme_5.6.1.19_daily ***
Code:
bootloader: u-boot bootloader
ldfw : u-boot load firmware (TrustZone driver?, can someone verify)
dtb : u-boot device tree blob/binary, to pass to linux kernel
.
Switching from android-to-ubuntu or ubuntu-to-android
requires the following partitions to be flashed:
Code:
/ldfw emmc /dev/block/sda24 flags=display="Firmware";backup=1
/dtb emmc /dev/block/sda25 flags=display="Device Tree";backup=1
/bootimg emmc /dev/block/sda26 flags=display="Boot"
/bootlogo emmc /dev/block/sda28 flags=display="Bootlogo";backup=1
/system ext4 /dev/block/sda41 flags=display="System"
.
My partition table
Code:
Meizu Pro 5 64gb Unicom Edition
Disk /dev/block/sda: 15267840 sectors, 58.2 GiB
Logical sector size: 4096 bytes
Disk identifier (GUID):
Partition table holds up to 128 entries
First usable sector is 6, last usable sector is 15267834
Partitions will be aligned on 64-sector boundaries
Total free space is 11386 sectors (44.5 MiB)
Number Start (sector) End (sector) Size Code Name
1 1024 1279 1024.0 KiB 0700 private
2 1280 1343 256.0 KiB 0700 proinfo
3 1344 1407 256.0 KiB 0700 misc
21 2048 3071 4.0 MiB 0700 param
22 3072 5119 8.0 MiB 0700 efs
23 5120 5631 2.0 MiB 0700 pnv
24 5632 6655 4.0 MiB 0700 ldfw
25 6656 7679 4.0 MiB 0700 dtb
26 7680 13823 24.0 MiB 0700 bootimg
27 13824 22015 32.0 MiB 0700 recovery
28 22016 30207 32.0 MiB 0700 bootlogo
29 30208 35327 20.0 MiB 0700 rstinfo
30 35328 40447 20.0 MiB 0700 mnv
31 40448 45567 20.0 MiB 0700 reserved1
32 45568 50687 20.0 MiB 0700 reserved2
33 50688 55807 20.0 MiB 0700 reserved3
41 65536 720895 2.5 GiB 0700 system
42 720896 851967 512.0 MiB 0700 custom
43 851968 983039 512.0 MiB 0700 cache
44 983040 15267834 54.5 GiB 0700 userdata
If you find any errors or have contributions, post in the thread or pm me.
Awesome
Wow, what a wasteland ... anyone still here .... here .... here .... ..... .... **dustball** ..... **crickets**
Anyways, i found the partition tables lurking in the bootloader,
they are pretty much the same for all the devices:
The 32gb and 64gb editions are the same, partition 44 userdata is just a leftover partition.
The only difference between Android and Ubuntu is partition 43,
maybe Wimpy can shed some light on this
Code:
< index=43,name=cache,size=[B]512MiB[/B],uuid=${uuid_cache};
---
> index=43,name=cache,size=[B]700MiB[/B],uuid=${uuid_cache};
Android partition table
Code:
index=1,name=private,size=1MiB,start=0x400000,uuid=${uuid_private};
index=2,name=proinfo,size=256KiB,uuid=${uuid_proinfo};
index=3,name=misc,size=256KiB,uuid=${uuid_misc};
index=21,name=param,size=4MiB,start=0x800000,uuid=${uuid_param};
index=22,name=efs,size=8MiB,uuid=${uuid_efs};
index=23,name=pnv,size=2MiB,uuid=${uuid_pnv};
index=24,name=ldfw,size=4MiB,uuid=${uuid_ldfw};
index=25,name=dtb,size=4MiB,uuid=${uuid_dtb};
index=26,name=bootimg,size=24MiB,uuid=${uuid_bootimg};
index=27,name=recovery,size=32MiB,uuid=${uuid_recovery};
index=28,name=bootlogo,size=32MiB,uuid=${uuid_bootlogo};
index=29,name=rstinfo,size=20MiB,uuid=${uuid_rstinfo};
index=30,name=mnv,size=20MiB,uuid=${uuid_mnv};
index=31,name=reserved1,size=20MiB,uuid=${uuid_reserved1};
index=32,name=reserved2,size=20MiB,uuid=${uuid_reserved2};
index=33,name=reserved3,size=20MiB,uuid=${uuid_reserved3};
index=41,name=system,size=2560MiB,start=0x10000000,uuid=${uuid_system};
index=42,name=custom,size=512MiB,uuid=${uuid_custom};
[B]index=43,name=cache,size=512MiB,uuid=${uuid_cache};[/B]
index=44,name=userdata,size=0,uuid=${uuid_userdata};
Ubuntu partition table
Code:
index=1,name=private,size=1MiB,start=0x400000,uuid=${uuid_private};
index=2,name=proinfo,size=256KiB,uuid=${uuid_proinfo};
index=3,name=misc,size=256KiB,uuid=${uuid_misc};
index=21,name=param,size=4MiB,start=0x800000,uuid=${uuid_param};
index=22,name=efs,size=8MiB,uuid=${uuid_efs};
index=23,name=pnv,size=2MiB,uuid=${uuid_pnv};
index=24,name=ldfw,size=4MiB,uuid=${uuid_ldfw};
index=25,name=dtb,size=4MiB,uuid=${uuid_dtb};
index=26,name=bootimg,size=24MiB,uuid=${uuid_bootimg};
index=27,name=recovery,size=32MiB,uuid=${uuid_recovery};
index=28,name=bootlogo,size=32MiB,uuid=${uuid_bootlogo};
index=29,name=rstinfo,size=20MiB,uuid=${uuid_rstinfo};
index=30,name=mnv,size=20MiB,uuid=${uuid_mnv};
index=31,name=reserved1,size=20MiB,uuid=${uuid_reserved1};
index=32,name=reserved2,size=20MiB,uuid=${uuid_reserved2};
index=33,name=reserved3,size=20MiB,uuid=${uuid_reserved3};
index=41,name=system,size=2560MiB,start=0x10000000,uuid=${uuid_system};
index=42,name=custom,size=512MiB,uuid=${uuid_custom};
[B]index=43,name=cache,size=700MiB,uuid=${uuid_cache};[/B]
index=44,name=userdata,size=0,uuid=${uuid_userdata};
I installed ubuntu on a android Meizu Pro 5 and now, when I try to change channels to rc-proposed using system-image-cli I find that the 512MB cache partition is not enough. So I guess that is the reason the Ubuntu version has a 700MB cache partition. That (/dev/sda43) is the place where the files for an upgrade are downloaded and then installed from the recovery mode.
st0rm77 said:
Hi,
The past week i've been busy in flashing flyme/twrp/ubuntu and all went very well, but i find the experience a little limited until now. Especially when reading about all the ppl who bricked their device or are stuck one way or another with locked bootloaders, missing recovery's etc.
I found that the bootloader unlock status is kept in the /private partition, wether manipulating this partition in order to unlock the device is possible, i dont know.
So in order to up the experience for all i need your help
I've been mapping out the partition layout on my Chinese Meizu Pro5 64gb (converted to global/intl now), but one device only gets you so far. There are differences between the Flyme/Ubuntu devices, the Flyme devices U/A/I and the TWRP recovery (lets all thank faust93) does not work for everyone (it does for me).
For anyone that has access to 'sgdisk' (you successfully installed TWRP or have an Ubuntu edition) i need a layout of your partitions: (your personal info/guid is excluded (-v GUID) from this)
# sgdisk --print /dev/block/sda | grep -v GUID >/sdcard/partition_layout.txt
We have the following devices:
1. G [M576_intl_official] Global 32gb
2. G [M576_intl_official] Global 64gb
3. U: [M576_unicom_custom] Unicom 32gb
4. U: [M576_unicom_custom] Unicom 64gb
5. A: [M576_mobile_public] Mobile Public 32gb
6. A: [M576_mobile_public] Mobile Public 64gb
7. I: [M576_intl_official] Ubuntu Meizu 32gb
8. I: [M576_intl_official] Ubuntu Meizu 64gb
TWRP 3: fstab table (work in progress)
Code:
/private emmc /dev/block/sda1 flags=display="Private";backup=1 # meizu imei/esn/wifi/bluetooth/serial/lock/unlock
/proinfo emmc /dev/block/sda2 # meizu firmware/machine_type/region_id unicom(U)/chicom(A)/intl(G)
#/misc emmc /dev/block/sda3 # empty 0x00
/param emmc /dev/block/sda21 # u-boot active stats
/efs ext4 /dev/block/sda22 flags=display="EFS";backup=1
#/pnv emmc /dev/block/sda23 # empty 0x00
/ldfw emmc /dev/block/sda24 flags=display="Firmware";backup=1
/dtb emmc /dev/block/sda25 flags=display="Device Tree";backup=1
/bootimg emmc /dev/block/sda26 flags=display="Boot"
/recovery ext4 /dev/block/sda27 flags=display="Recovery";backup=1
/bootlogo emmc /dev/block/sda28 flags=display="Bootlogo";backup=1
#/rstinfo emmc /dev/block/sda29 # kernel log
#/mnv ext4 /dev/block/sda30 # nv_protected
#/reserved1 emmc /dev/block/sda31 # empty 0x00
#/reserved2 emmc /dev/block/sda32 # empty 0x00
#/reserved3 emmc /dev/block/sda33 # empty 0x00
/system ext4 /dev/block/sda41 flags=display="System"
#/custom ext4 /dev/block/sda42 # preload: adds applications to system on first install/factory reset
/cache ext4 /dev/block/sda43 flags=display="Cache";backup=1
/sdcard ext4 /dev/block/sda44 flags=display="Internal Storage";storage;settingsstorage
#/u-boot emmc /dev/block/sdb # u-boot bootloader
#- emmc /dev/block/sdc # empty 0x00 ( ?? could be used as backup bootloader for Android 7.0 nougat ??)
/external_sd vfat /dev/block/mmcblk0p1 flags=display="Micro SDcard";storage;wipeingui;removable
/usb-otg vfat ?? flags=display="USB-OTG";storage;wipeingui;removable
*** BRICK WARNING: the bootloader expects >> ldfw << and >>dtb<< ***
*** Make sure ldfw and dtb are flashed, i did not dare to try without ***
*** Also make sure that bootloader and ldfw are from the flyme_5.6.1.19_daily ***
Code:
bootloader: u-boot bootloader
ldfw : u-boot load firmware (TrustZone driver?, can someone verify)
dtb : u-boot device tree blob/binary, to pass to linux kernel
.
Switching from android-to-ubuntu or ubuntu-to-android
requires the following partitions to be flashed:
Code:
/ldfw emmc /dev/block/sda24 flags=display="Firmware";backup=1
/dtb emmc /dev/block/sda25 flags=display="Device Tree";backup=1
/bootimg emmc /dev/block/sda26 flags=display="Boot"
/bootlogo emmc /dev/block/sda28 flags=display="Bootlogo";backup=1
/system ext4 /dev/block/sda41 flags=display="System"
.
My partition table
Code:
Meizu Pro 5 64gb Unicom Edition
Disk /dev/block/sda: 15267840 sectors, 58.2 GiB
Logical sector size: 4096 bytes
Disk identifier (GUID):
Partition table holds up to 128 entries
First usable sector is 6, last usable sector is 15267834
Partitions will be aligned on 64-sector boundaries
Total free space is 11386 sectors (44.5 MiB)
Number Start (sector) End (sector) Size Code Name
1 1024 1279 1024.0 KiB 0700 private
2 1280 1343 256.0 KiB 0700 proinfo
3 1344 1407 256.0 KiB 0700 misc
21 2048 3071 4.0 MiB 0700 param
22 3072 5119 8.0 MiB 0700 efs
23 5120 5631 2.0 MiB 0700 pnv
24 5632 6655 4.0 MiB 0700 ldfw
25 6656 7679 4.0 MiB 0700 dtb
26 7680 13823 24.0 MiB 0700 bootimg
27 13824 22015 32.0 MiB 0700 recovery
28 22016 30207 32.0 MiB 0700 bootlogo
29 30208 35327 20.0 MiB 0700 rstinfo
30 35328 40447 20.0 MiB 0700 mnv
31 40448 45567 20.0 MiB 0700 reserved1
32 45568 50687 20.0 MiB 0700 reserved2
33 50688 55807 20.0 MiB 0700 reserved3
41 65536 720895 2.5 GiB 0700 system
42 720896 851967 512.0 MiB 0700 custom
43 851968 983039 512.0 MiB 0700 cache
44 983040 15267834 54.5 GiB 0700 userdata
If you find any errors or have contributions, post in the thread or pm me.
Awesome
Click to expand...
Click to collapse
Hi, I have lost my partitions due to the latest update of Magisk.
PYCON told me that I could redefine my partitions yet I haven't got a clue about how to do this.
I have a chinese version 32 Gb Pro 5 by the way.
This guy here has the same problem : https://forum.xda-developers.com/meizu-pro-5/help/provide-images-partitions-t3639336
Could somebody help us please ?

Seeking sonimxp5800 firehose_8920 file

Seeking sonimxp5800 firehose_8920 file
essential-phone :The thread is closed, this is the tested version of the firmware, the key cannot be verified
Code:
C:\Users\x\Desktop\fastboot getvar all
(bootloader) version:0.5
(bootloader) battery-soc-ok:yes
(bootloader) battery-voltage:4157000
(bootloader) variant:QRD eMMC
(bootloader) secure:yes
(bootloader) version-baseband:
(bootloader) version-bootloader:
(bootloader) display-panel:
(bootloader) off-mode-charge:0
(bootloader) charger-screen-enabled:0
(bootloader) max-download-size: 0x1ff00000
(bootloader) partition-type:cache:ext4
(bootloader) partition-size:cache: 0x40000000
(bootloader) partition-type:userdata:ext4
(bootloader) partition-size:userdata: 0x2858d0e00
(bootloader) partition-type:system:ext4
(bootloader) partition-size:system: 0xa0000000
(bootloader) serialno:c3cacaf3
(bootloader) kernel:lk
(bootloader) product:QC_REFERENCE_PHONE
all:
finished. total time: 0.111s
XP5812:/ $ cat /proc/partitions
major minor #blocks name
254 0 524288 zram0
179 0 15388672 mmcblk0
179 1 106496 mmcblk0p1
179 2 1 mmcblk0p2
179 3 8 mmcblk0p3
179 4 512 mmcblk0p4
179 5 512 mmcblk0p5
179 6 512 mmcblk0p6
179 7 512 mmcblk0p7
179 8 2048 mmcblk0p8
179 9 2048 mmcblk0p9
179 10 256 mmcblk0p10
179 11 256 mmcblk0p11
179 12 16384 mmcblk0p12
179 13 1536 mmcblk0p13
179 14 1536 mmcblk0p14
179 15 32 mmcblk0p15
179 16 1536 mmcblk0p16
179 17 16 mmcblk0p17
179 18 11264 mmcblk0p18
179 19 1024 mmcblk0p19
179 20 1024 mmcblk0p20
179 21 65536 mmcblk0p21
179 22 65536 mmcblk0p22
179 23 1024 mmcblk0p23
179 24 2621440 mmcblk0p24
179 25 1048576 mmcblk0p25
179 26 32768 mmcblk0p26
179 27 1024 mmcblk0p27
179 28 512 mmcblk0p28
179 29 32 mmcblk0p29
179 30 262144 mmcblk0p30
179 31 32 mmcblk0p31
259 0 512 mmcblk0p32
259 1 1024 mmcblk0p33
259 2 32768 mmcblk0p34
259 3 512 mmcblk0p35
259 4 4096 mmcblk0p36
259 5 256 mmcblk0p37
259 6 256 mmcblk0p38
259 7 256 mmcblk0p39
259 8 256 mmcblk0p40
259 9 256 mmcblk0p41
259 10 256 mmcblk0p42
259 11 256 mmcblk0p43
259 12 256 mmcblk0p44
259 13 8 mmcblk0p45
259 14 9020 mmcblk0p46
259 15 7636 mmcblk0p47
259 16 5824 mmcblk0p48
259 17 4820 mmcblk0p49
259 18 10576707 mmcblk0p50
179 32 4096 mmcblk0rpmb
253 0 2580508 dm-0
253 1 10576691 dm-1
XP5812:/ $
XP5812:/ $cat /proc/cpuinfo
Processor : AArch64 Processor rev 4 (aarch64)
processor : 0
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 1
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 2
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 3
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
Hardware : Qualcomm Technologies, Inc MSM8920
XP5812:/ $
what is a firehose file? and what is the zip file attached?
nijohnson said:
what is a firehose file? and what is the zip file attached?
Click to expand...
Click to collapse
This looks very interesting! I have a dead essential I can use this on if you can confirm it works!!!
I have a dead one as well. But I have no idea what to do with the file.
nijohnson said:
what is a firehose file? and what is the zip file attached?
Click to expand...
Click to collapse
https://forum.xda-developers.com/showpost.php?p=80465045&postcount=6
nijohnson said:
I have a dead one as well. But I have no idea what to do with the file.
Click to expand...
Click to collapse
Initial Steps
EDL mode refresh firmware
eleotk said:
Initial Steps
EDL mode refresh firmware
Click to expand...
Click to collapse
Initial step #1 - get pasword ((
Does anybody found it?
I can't find password out. Can you just post it directly? Thanks a lot.
One idea.. Has anyone asked Sonim?
They gave me debug images along with flash tools for the XP8 when I asked about a year ago.. Although not as useful as the early (unlockable) debug images provided by eleotk.. Sonim had to verify I was local in the US and it took a few days but was not an issue. We are seeing now that many variations of the debug image exist for the XP8 so I'm sure it's the same case on this XP5812.
They do seem to keep a tighter grip on the XP5s since custom apps require Sonim direct validation/signing but it may be worth a shot since any debug images they provide would have the required mbn file for flashing.
Obviously you need to give them a developer style excuse as they will likely not help if they know your trying to modify the device.
I would ask them myself however the only XP5s I have is a Sprint XP5800 that's working with the ZTE 8920 mbn file. This issue appears unique to the variant I believe? Aside from the XP5823 label - it looks simular on my end.
Code:
XP5823:/ $ su
XP5823:/ # cat /proc/partitions
major minor #blocks name
254 0 524288 zram0
179 0 15388672 mmcblk0
179 1 106496 mmcblk0p1
179 2 1 mmcblk0p2
179 3 8 mmcblk0p3
179 4 512 mmcblk0p4
179 5 512 mmcblk0p5
179 6 512 mmcblk0p6
179 7 512 mmcblk0p7
179 8 2048 mmcblk0p8
179 9 2048 mmcblk0p9
179 10 256 mmcblk0p10
179 11 256 mmcblk0p11
179 12 16384 mmcblk0p12
179 13 1536 mmcblk0p13
179 14 1536 mmcblk0p14
179 15 32 mmcblk0p15
179 16 1536 mmcblk0p16
179 17 16 mmcblk0p17
179 18 11264 mmcblk0p18
179 19 1024 mmcblk0p19
179 20 1024 mmcblk0p20
179 21 65536 mmcblk0p21
179 22 65536 mmcblk0p22
179 23 1024 mmcblk0p23
179 24 2621440 mmcblk0p24
179 25 1048576 mmcblk0p25
179 26 32768 mmcblk0p26
179 27 1024 mmcblk0p27
179 28 512 mmcblk0p28
179 29 32 mmcblk0p29
179 30 262144 mmcblk0p30
179 31 32 mmcblk0p31
259 0 512 mmcblk0p32
259 1 1024 mmcblk0p33
259 2 32768 mmcblk0p34
259 3 512 mmcblk0p35
259 4 4096 mmcblk0p36
259 5 256 mmcblk0p37
259 6 256 mmcblk0p38
259 7 256 mmcblk0p39
259 8 256 mmcblk0p40
259 9 256 mmcblk0p41
259 10 256 mmcblk0p42
259 11 256 mmcblk0p43
259 12 256 mmcblk0p44
259 13 8 mmcblk0p45
259 14 9020 mmcblk0p46
259 15 7636 mmcblk0p47
259 16 5824 mmcblk0p48
259 17 4820 mmcblk0p49
259 18 10576707 mmcblk0p50
179 32 4096 mmcblk0rpmb
253 0 10576691 dm-0
XP5823:/ # cat /proc/cpuinfo
Processor : AArch64 Processor rev 4 (aarch64)
processor : 0
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 1
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 2
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 3
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
Hardware : Qualcomm Technologies, Inc MSM8920
XP5823:/ #
Edit.. Missed the bootloader options. The Sprint variant at least seems to be shipped in an unlocked state with secure boot also disabled. This is likely why it trusts the ZTE mbn file.
Code:
(bootloader) version:0.5
(bootloader) battery-soc-ok:yes
(bootloader) battery-voltage:3745000
(bootloader) variant:QRD eMMC
(bootloader) secure:no
(bootloader) version-baseband:
(bootloader) version-bootloader:
(bootloader) display-panel:
(bootloader) off-mode-charge:0
(bootloader) charger-screen-enabled:0
(bootloader) max-download-size: 0x1ff00000
(bootloader) partition-type:cache:ext4
(bootloader) partition-size:cache: 0x40000000
(bootloader) partition-type:userdata:ext4
(bootloader) partition-size:userdata: 0x2858d0e00
(bootloader) partition-type:system:ext4
(bootloader) partition-size:system: 0xa0000000
(bootloader) model:XP5800
(bootloader) build:5SA.0.2-03-7.1.2-29.03.00
(bootloader) imei:XXXXXXXXXXXXXXX
(bootloader) serialno:XXXXXXXX
(bootloader) kernel:lk
(bootloader) product:QC_REFERENCE_PHONE
all:
finished. total time: 0.030s
Maybe my English is not well written, password: sonimxp5800
smokeyou said:
One idea.. Has anyone asked Sonim?
They gave me debug images along with flash tools for the XP8 when I asked about a year ago.. Although not as useful as the early (unlockable) debug images provided by eleotk.. Sonim had to verify I was local in the US and it took a few days but was not an issue. We are seeing now that many variations of the debug image exist for the XP8 so I'm sure it's the same case on this XP5812.
They do seem to keep a tighter grip on the XP5s since custom apps require Sonim direct validation/signing but it may be worth a shot since any debug images they provide would have the required mbn file for flashing.
Obviously you need to give them a developer style excuse as they will likely not help if they know your trying to modify the device.
I would ask them myself however the only XP5s I have is a Sprint XP5800 that's working with the ZTE 8920 mbn file. This issue appears unique to the variant I believe? Aside from the XP5823 label - it looks simular on my end.
Code:
XP5823:/ $ su
XP5823:/ # cat /proc/partitions
major minor #blocks name
254 0 524288 zram0
179 0 15388672 mmcblk0
179 1 106496 mmcblk0p1
179 2 1 mmcblk0p2
179 3 8 mmcblk0p3
179 4 512 mmcblk0p4
179 5 512 mmcblk0p5
179 6 512 mmcblk0p6
179 7 512 mmcblk0p7
179 8 2048 mmcblk0p8
179 9 2048 mmcblk0p9
179 10 256 mmcblk0p10
179 11 256 mmcblk0p11
179 12 16384 mmcblk0p12
179 13 1536 mmcblk0p13
179 14 1536 mmcblk0p14
179 15 32 mmcblk0p15
179 16 1536 mmcblk0p16
179 17 16 mmcblk0p17
179 18 11264 mmcblk0p18
179 19 1024 mmcblk0p19
179 20 1024 mmcblk0p20
179 21 65536 mmcblk0p21
179 22 65536 mmcblk0p22
179 23 1024 mmcblk0p23
179 24 2621440 mmcblk0p24
179 25 1048576 mmcblk0p25
179 26 32768 mmcblk0p26
179 27 1024 mmcblk0p27
179 28 512 mmcblk0p28
179 29 32 mmcblk0p29
179 30 262144 mmcblk0p30
179 31 32 mmcblk0p31
259 0 512 mmcblk0p32
259 1 1024 mmcblk0p33
259 2 32768 mmcblk0p34
259 3 512 mmcblk0p35
259 4 4096 mmcblk0p36
259 5 256 mmcblk0p37
259 6 256 mmcblk0p38
259 7 256 mmcblk0p39
259 8 256 mmcblk0p40
259 9 256 mmcblk0p41
259 10 256 mmcblk0p42
259 11 256 mmcblk0p43
259 12 256 mmcblk0p44
259 13 8 mmcblk0p45
259 14 9020 mmcblk0p46
259 15 7636 mmcblk0p47
259 16 5824 mmcblk0p48
259 17 4820 mmcblk0p49
259 18 10576707 mmcblk0p50
179 32 4096 mmcblk0rpmb
253 0 10576691 dm-0
XP5823:/ # cat /proc/cpuinfo
Processor : AArch64 Processor rev 4 (aarch64)
processor : 0
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 1
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 2
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 3
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
Hardware : Qualcomm Technologies, Inc MSM8920
XP5823:/ #
Edit.. Missed the bootloader options. The Sprint variant at least seems to be shipped in an unlocked state with secure boot also disabled. This is likely why it trusts the ZTE mbn file.
Code:
(bootloader) version:0.5
(bootloader) battery-soc-ok:yes
(bootloader) battery-voltage:3745000
(bootloader) variant:QRD eMMC
(bootloader) secure:no
(bootloader) version-baseband:
(bootloader) version-bootloader:
(bootloader) display-panel:
(bootloader) off-mode-charge:0
(bootloader) charger-screen-enabled:0
(bootloader) max-download-size: 0x1ff00000
(bootloader) partition-type:cache:ext4
(bootloader) partition-size:cache: 0x40000000
(bootloader) partition-type:userdata:ext4
(bootloader) partition-size:userdata: 0x2858d0e00
(bootloader) partition-type:system:ext4
(bootloader) partition-size:system: 0xa0000000
(bootloader) model:XP5800
(bootloader) build:5SA.0.2-03-7.1.2-29.03.00
(bootloader) imei:XXXXXXXXXXXXXXX
(bootloader) serialno:XXXXXXXX
(bootloader) kernel:lk
(bootloader) product:QC_REFERENCE_PHONE
all:
finished. total time: 0.030s
Click to expand...
Click to collapse
It seems that I should find the Sprint version XP5800 easier, XP5800 is too little information.
Please forgive my lack of knowledge. This file/process is not something that could fix a bricked phone, correct?
nijohnson said:
Please forgive my lack of knowledge. This file/process is not something that could fix a bricked phone, correct?
Click to expand...
Click to collapse
Yes, refill the wrong partition
Essential_Phone 9008 download
1. First you need to install QPST, and then confirm the following files in the QPST installation directory.
D:\Program Files (x86)\Qualcomm\QPST\bin
QFIL.exe
Fhloader.exe
QSaharaServer.exe
1
2
2. The device needs to switch to port 9008.
3 Download official file extract
https://storage.googleapis.com/essential-static/PH1-Images-QP1A.191005.014.zip
4 I will release 4 files and extract them into the official file.
5 Running QFIL
Set to see pictures
@eleotk something ent wrong... (
st.noigel said:
@eleotk something ent wrong... (
Click to expand...
Click to collapse
devicetype:ufs
eleotk said:
Essential_Phone 9008 download
1. First you need to install QPST, and then confirm the following files in the QPST installation directory.
D:\Program Files (x86)\Qualcomm\QPST\bin
QFIL.exe
Fhloader.exe
QSaharaServer.exe
1
2
2. The device needs to switch to port 9008.
3 Download official file extract
https://storage.googleapis.com/essential-static/PH1-Images-QP1A.191005.014.zip
4 I will release 4 files and extract them into the official file.
5 Running QFIL
Set to see pictures
Click to expand...
Click to collapse
I guess I don't understand? I can't get Qsahara to work? I have everything downloaded and my screen is the same as yours?
tha_mechanic said:
I guess I don't understand? I can't get Qsahara to work? I have everything downloaded and my screen is the same as yours?
Click to expand...
Click to collapse
https://forum.xda-developers.com/z5.../restore-stock-image-lock-bootloader-t3888785
https://mirrors.lolinet.com/software/windows/Qualcomm/QPST/
eleotk said:
https://forum.xda-developers.com/z5.../restore-stock-image-lock-bootloader-t3888785
https://mirrors.lolinet.com/software/windows/Qualcomm/QPST/
Click to expand...
Click to collapse
It looks like my PH-1 is completele dead (
P.S. I`ll try ahain with another PC )
St.Noigel said:
It looks like my PH-1 is completele dead (
P.S. I`ll try ahain with another PC )
Click to expand...
Click to collapse
Replace the file, still can't pass my verification, end

Categories

Resources