Develop Bugs

[REF] bml* partition layout

LAYOUT MAPPING COMPLETE! THANKS EVERYONE!​
based on XXJF5 stock 2.1#1
256 KB -- bml1, contain boot.bin (262144 bytes), Primary Boot Loader (low-level hardware initialization)
256 KB -- bml2, contains PIT file first 512 bytes
10240 KB -- bml3 /dev/block/stl3 /efs
1280 KB -- bml4 contain Sbl.bin (1310720 bytes) Secondary Boot Loader (loads the Linux kernel and passes the necessary arguments)
1280KB -- bml5 contains Secondary Boot Loader (for recovery, ect)
5120KB -- bml6 param.lfs /mnt/.lfs j4fs
7680KB -- bml7 contain zImage and initramfs
7680KB -- bml8 empty
293376KB -- bml9 factoryfs.rfs ( /system RFS Partition) /dev/block/stl9
137216KB -- bml10 dbdata.rfs ( /dbdata RFS Partition) /dev/block/stl10
35840KB -- bml11 cache.rfs ( /cache RFS Partition) /dev/block/stl11
12800KB -- bml12 modem.bin

Hello husq510
Thanks for this infos, i'll follow this thread closely because i'm looking for the place where ServiceMode settings are stored.

anyone tried writing to the bml directly?

husq510 said:
bash-3.2# ls -al /dev/block/bml*
1280 KB -- bml4 kernel (zImage)
293376KB -- bml9 factoryfs.rfs ( /system RFS Partition)
Click to expand...
Click to collapse
interesting. so ive dd the bml4 and bml9 of optus australia stock 19000DTJF3. now anyone want to point me in the direction of creating an odin package out of it.

i whoner .... how can bml4 be the zImage? bml4=1.2MB, zImage=5.8MB ?? also if it should just contain the kernel without initram, it's still about 2.6MB? any idea?

jodue said:
i whoner .... how can bml4 be the zImage? bml4=1.2MB, zImage=5.8MB ?? also if it should just contain the kernel without initram, it's still about 2.6MB? any idea?
Click to expand...
Click to collapse
you are right, cant be. then kernel must be in some other bml place, seems bml7.
gandalf:~/Desktop/android/bml ackie$ grep "booting the kernel" *
Binary file bml7.dump matches
gandalf:~/Desktop/android/bml ackie$ hexdump -n 128 bml7.dump | grep "e1a0 0000 e1a0"
0000000 0000 e1a0 0000 e1a0 0000 e1a0 0000 e1a0
0000020 0002 ea00 [2818 016f] [0000 0000] [a510 005b] <- zimage magic number 0x016F2818, start at 0x0, end at 0x005b10a5
0000030 7001 e1a0 8002 e1a0 2000 e10f 0003 e312
0000040 0001 1a00 0017 e3a0 3456 ef12 2000 e10f
0000050 20c0 e382 f002 e121 0000 0000 0000 0000
0000060 00d0 e28f 307e e890 0001 e050 000a 0a00
0000070 5000 e085 6000 e086 c000 e08c 2000 e082
0000080
Offset into zImage Value Description
0x24 0x016F2818 Magic number used to identify this is an ARM Linux zImage
0x28 start address The address the zImage starts at
0x2C end address The address the zImage ends at
so if you start at 0x0 of bml7 and read untill offset inside 0x2c for XXJF5 is 0x005b10a5 you have your zImage.

husq510 said:
so if you start at 0x0 of bml7 and read untill offset inside 0x2c for XXJF5 is 0x005b10a5 you have your zImage.
Click to expand...
Click to collapse
so is it safe to assume after 0x005b10a5 is the ram disk?

Hello Folks.
I found some interesting bits in bml12.
"Service Mode" datas strings are in it, like show these example :
Code:
strings ./bml12 | grep Diamond
[SND] TurnON UtaAudioModifyHf(prev_Diamond_mode:0x%x)
`[SND]DiamondVoice_GetMode : path = 0x%x, Diamond_mode = 0x%x
`[SND]DiamondVoice_GetMode : Diamond_mode = 0x%x
[SND]DiamondVoiceTXcfgMSG
`[SND] DiamondVoice_RxInit : DiamondVoice_Mode_v = 0x%x
Diamond Solution
[9] Diamond Solution
[SND]DiamondVoice_Config : DiamondVoice_Mode_v = 0x%x, Diamond_mode= 0x%x
strings ./bml12 | grep DEBUG
MN_GPS_DEBUG_INFO_CNF
GPS_DEBUG_INFO_CNF
[1] DEBUG SCREEN
[2] DEBUG INFO
DEBUG INFO
DEBUG MSG 115200
DEBUG MSG SETTING FAIL
DEBUG MSG 921600
DEBUG MSG ON
DEBUG MSG OFF
AUDIO_LIB_DSP_DEBUG_GRP1
AUDIO_LIB_DSP_DEBUG_GRP2
AUDIO_LIB_DSP_DEBUG_GRP3
AUDIO_LIB_DSP_DEBUG_GRP4
AUDIO_LIB_DSP_DEBUG_GRP5
AUD_LIB_DSP_DEBUG
IPC_MISC_PHONE_DEBUG
IPC_MISC_DEBUG_LEVEL
IPC_SVC_DEBUG_DUMP
IPC_SVC_DEBUG_STRING

And I found my IMEI number in bml3
edit :
+ some MAC hardware address too (but not the Wifi one)
+ the HW Version : MP 0.800
I guess that bml3 is device-specific.
But I don't know if it's the source of specific values or just contains copy of hardware-related data.
In the first case, modifying bml3 would allow to change IMEI or other sensitive values ^^

nonato said:
so is it safe to assume after 0x005b10a5 is the ram disk?
Click to expand...
Click to collapse
nope, to extract the ram disk, u hv to find the magic number of gz and extract the gzip image out... i was able to get the directory listing of the ramdisk but not the content..
the other problem is after u get the ramdisk and do any modifications, u hv to reverse the process.. not an easy job but if anyone found a solution, please share.
anyone try writing to the bml directly? dd doesnt seem to work
anyway, its possible to extract the image and use odin to flash after tar but if can write to bml directly, clockworkmod can effectively backup/restore the kernel.. (just a thought)

raspdeep said:
nope, to extract the ram disk, u hv to find the magic number of gz and extract the gzip image out... i was able to get the directory listing of the ramdisk but not the content..
the other problem is after u get the ramdisk and do any modifications, u hv to reverse the process.. not an easy job but if anyone found a solution, please share.
anyone try writing to the bml directly? dd doesnt seem to work
anyway, its possible to extract the image and use odin to flash after tar but if can write to bml directly, clockworkmod can effectively backup/restore the kernel.. (just a thought)
Click to expand...
Click to collapse
No, you cant write directly to bml.
Data write to a sector involves following sequence of low-level flash operations:
1. Block copy for back-up
2. Block erase
3. Copy back for non-modified pages
4. Writing the sector data to the modified page
These sequences of operations are not atomic, so a write request to this block device driver is prone to data corruption. For this reason, read-only file systems such as CRAMFS are adequate to run on top of this block device driver.

use this small script to extract your current zImage:
offset=`dd if=/dev/block/bml7 bs=1 skip=44 count=4 2>/dev/null| hexdump -e '1/4 "%d"' -e '"\n"'`
echo $offset
dd if=/dev/block/bml7 bs=1 count=$offset of=/sdcard/zImage_backup

husq510 said:
use this small script to extract your current zImage:
Click to expand...
Click to collapse
nice, thanks for sharing that!

i just extracted initramfs from bml7, file attached, unzip and cpio -i
some file differs from leshak:
modules/dpram.ko
modules/multipdp.ko
modules/dhd.ko
modules/stgloc
initramfs/init.rc
.info/rootfs.info
default.prop
init.smdkc110.sh
sbin/recovery
sbin/init

how do u extract this?
gunzip -c initrd-cpio.zip | cpio -i does not work.. gave errors

how did you dump and make the zip file you have attached?
thanks,
husq510 said:
i just extracted initramfs from bml7, file attached, unzip and cpio -i
some file differs from leshak:
modules/dpram.ko
modules/multipdp.ko
modules/dhd.ko
modules/stgloc
initramfs/init.rc
.info/rootfs.info
default.prop
init.smdkc110.sh
sbin/recovery
sbin/init
Click to expand...
Click to collapse

raspdeep said:
how do u extract this?
gunzip -c initrd-cpio.zip | cpio -i does not work.. gave errors
Click to expand...
Click to collapse
[email protected] you have to use unzip instead gzip, cuz forum dislike .gz format, so I had to use standard zip.
mkdir initramfs
mv initrd-cpio.zip initramfs
cd initramfs
unzip initrd-cpio.zio
cat initrd.cpio | cpio -i --no-absolute-filenames

Hey, did somebody already tried to dump one or some bml partitions and restore them later ?
I guess this could be the ultimate backup tool.

I took a look into this and found that
bml2 : PIT file is here
bml5 : Sbl.bin is here
I opened it with a Hexeditor and compared with things from the firmware.
My device is running on JP3, froyo, at the moment.

thanks i will update first post. layout mapping is complete now!

[Q] How to restore only stock recovery after cf-autoot

SM-T705, CF-Autoroot:
cf-autoroot changes recovery. So after rooting I want to restore the correct recovery.img from my stock firmware package.
- Can this be done with dd (no sure because it is a sparsed image) or by flashify ?
ODIN:
Recovery must be converted to .tar first, http://forum.xda-developers.com/showthread.php?t=2281287&page=5, http://forum.xda-developers.com/showpost.php?p=45629177&postcount=1) what Variant will work for W7,8.1.
One suggest file format for tar = ustar and the other one gnu ... waht is right for Odin ?
and how to under Linux ?
- I tried Odin with the help of the attached files ... seems to work ? How can the .img>tar conversion be done under Linux ?
- what about dd (must the stock.img be processed before in any ways (beacause ist sparsed) ?
- also flashify seems to work

- what about dd - must the stock.img be processed before in any ways (because ist sparsed) ? In any case it's smaller than a backup from Flashify or dd ...
In my case (Tab S, SM-T705) the partition has 10240 blocks. I did a dd from the partition and this file contains $1000000 Bytes. File size is 10MB = 10485760 Bytes.
Is the only way to fill every Byte from the end of the stock recovery with 00 by a hex editor ?
Would be super nice to get commands for Windows and Linux.

[Q] T-Mobile Samsung Galaxy S4 (SGH-M919) How do I fix a vibrate loop / soft bricked?

My T-Mobile S4 was having WIFI / LTE connectivity issues on Rogers so having successfully flashed ROM's before I started going through different jfltetmo ROM's but at some point flashed the wrong ROM. The last working ROM on my phone was CyanogenMod cm-11-20140217-NIGHTLY-jfltetmo.zip coupled with openrecovery-twrp-2.8.1.0-jfltetmo.tar but now my phone can only enter download mode and that too only when connected to a USB cable. If I turn my phone ON or try to enter Recovery mode it goes into a vibrate loop (no logo displayed) - does this make my phone soft bricked? Here is the screen output for my phone when in Download mode:
ODIN MODE
PRODUCT NAME: SGH-M919
CUSTOM BINARY DOWNLOAD: Yes (80 counts)
CURRENT BINARY: Custom
SYSTEM STATUS: Custom
QUALCOMM SECUREBOOT: ENABLE
Things I have tried so far:
-followed AndroidRootz Unroot / Unbrick Galaxy S4 tutorial step by step
-connect using Kies 3 with Samsung USB drivers v1.5.45.0 but Kies won't detect my phone
-flashed M919 stock Kitkat 4.4.2 (M919UVUFNB4_M919TMBFNB4_TMB.zip) using ODIN v3.10, v3.09, v3.07, and v1.85 which fails with ODIN showing:
<ID:0/006> aboot.mbn
<ID:0/006> NAND Write Start!!
<ID:0/006> FAIL! (Auth)
<ID:0/006>
<ID:0/006> Complete(Write) operation failed.
<OSM> All threads completed. (succeed 0 / failed 1)
and phone screen showing:
START [224, 1448]
SECURE CHECK FAIL: aboot
-flashed TWRP v2.8.1.0 ODIN tar which resulted in ODIN showing a PASS but there still was no Recovery Mode
-flashed TWRP v2.8.1.0 recovery img and CWM v6.0.4.3 recovery img to RECOVERY partition using Heimdall v1.4.0 which were both successful but there was still no Recovery Mode
I also extracted my device's PIT file using Heimdall (my-PIT.zip) then compared it with a stock PIT (JFLTE_USA_TMO_16G_PIT.zip) I had found somewhere online. It seems I have slightly corrupted my partition so I tried the following fixes:
-ODIN flash just the stock PIT (JFLTE_USA_TMO_16G.pit inside JFLTE_USA_TMO_16G_PIT.zip) which fails with ODIN showing:
<ID:0/006> Initialzation..
<ID:0/006> Set PIT file..
<ID:0/006> DO NOT TURN OFF TARGET!!
<ID:0/006> FAIL!
<ID:0/006>
<ID:0/006> Re-Partition operation failed.
<OSM> All threads completed. (succeed 0 / failed 1)
and phone screen showing:
START [224, 1448]
SECURE CHECK FAIL: PIT
Do I need to explicitly fix my PIT partition first?
-If yes, is there a way to use ODIN, Heimdall, or some other tool to fix my PIT?
-if no, am I missing some step or using wrong firmware/tools?
Is there anything else I can do to get my phone back up and running? I am guessing I just need to be able to get into Recovery and the rest should be straight forward.
Any help to fix this issue would be greatly appreciated, thanks in advance

You said the last working rom, but you failed to mention the last thing you flashed before the issue....And that was?.....

ShinySide said:
You said the last working rom, but you failed to mention the last thing you flashed before the issue....And that was?.....
Click to expand...
Click to collapse
I can't remember now which ROM caused the issues - it was either a Samsung S3 or S4 ROM.

shaqto said:
I can't remember now which ROM caused the issues - it was either a Samsung S3 or S4 ROM.
Click to expand...
Click to collapse
If you flashed an s3 rom or firmware, you're most likely screwed.
Best bet find a pit file for m919 that isn't your pit file.

ShinySide said:
If you flashed an s3 rom or firmware, you're most likely screwed.
Best bet find a pit file for m919 that isn't your pit file.
Click to expand...
Click to collapse
I did find and flash a S4 ROM which I attached in my original thread

shaqto said:
I did find and flash a S4 ROM which I attached in my original thread
Click to expand...
Click to collapse
Yeah just noticed it.
Quick look thru it, you fcuked your boot Partition. At least if not more stuff. Didn't really compare side by side. Just what stood out to me.
Here's what it should be.
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 20
Attributes: 5 (Read/Write)
Update Attributes: 1 (FOTA)
Partition Block Size/Offset: 10146376
Partition Block Count: 20480
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: BOOT
Flash Filename: boot.img
FOTA Filename:
here's yours
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 8
Attributes: 5 (Read/Write)
Update Attributes: 1 (FOTA)
Partition Block Size/Offset: 146176
Partition Block Count: 20480
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: BOOT
Flash Filename: boot.img
FOTA Filename:
notice the Identifier on the correct one is 20. dev/block/mmcblk0p20 is the boot.img Partition for us. You flashed a boot.img to the tz Partition.
Your most likely only hope is jtag.
But there's one more thing.... we're obviously not getting the full story. This wasn't a s3 or s4 rom you flashed. Because your identifier 8 aka /dev/block/mmcblk0p8 isn't even the boot Partition for the s3. mmcblk0p8 on the s3 is the cache.img.ext4 Partition.

ShinySide said:
Yeah just noticed it.
Quick look thru it, you fcuked your boot Partition. At least if not more stuff. Didn't really compare side by side. Just what stood out to me.
Here's what it should be.
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 20
Attributes: 5 (Read/Write)
Update Attributes: 1 (FOTA)
Partition Block Size/Offset: 10146376
Partition Block Count: 20480
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: BOOT
Flash Filename: boot.img
FOTA Filename:
here's yours
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 8
Attributes: 5 (Read/Write)
Update Attributes: 1 (FOTA)
Partition Block Size/Offset: 146176
Partition Block Count: 20480
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: BOOT
Flash Filename: boot.img
FOTA Filename:
notice the Identifier on the correct one is 20. dev/block/mmcblk0p20 is the boot.img Partition for us. You flashed a boot.img to the tz Partition.
Your most likely only hope is jtag.
But there's one more thing.... we're obviously not getting the full story. This wasn't a s3 or s4 rom you flashed. Because your identifier 8 aka /dev/block/mmcblk0p8 isn't even the boot Partition for the s3. mmcblk0p8 on the s3 is the cache.img.ext4 Partition.
Click to expand...
Click to collapse
Correct, the BOOT partition is messed up now which is why I was trying to fix the PIT (or at least I thought I was) by flashing the stock PIT file in ODIN with re-partition checked.. Is "partition block size/offset" the memory address for the start of a given partition? I guess the better question is, is there any way to replace the partition mappings using a modified PIT or any other method? Also I was curious, what is the "Partition Block Count"?
What if we approach this problem a different way - rather than changing the partition mapping to have BOOT entry point to the correct BOOT partition location, can we not just update the incorrect BOOT partition location with the actual BOOT img? ie. flash boot.img onto the device using my existing PIT file via Heimdall
You are also correct the S3 PIT file also does not match my PIT file - actually I did a search on Google for PIT file and I don't think any device has a PIT file identical to the PIT structure currently on my phone. I know it's stupid of me not being able to remember which ROM caused my phone to be in this state but it's also because I downloaded several M919 ROM's and immediately deleted the bad ROM after thinking I will never need it again. Anyways thanks again for helping out.

[How to] Determine dd Parameters For All LG G4 Models

[How to] determine dd parameters for all LG G4 models
IMPORTANT:
Only for advanced users!
You are an advanced user if you know exactly what you are doing.
You are an advanced user if you know what to do if something went wrong.
You are NOT an advanced user if you know how to do copy+paste.
You can bring your smartphone into a state, so it no longer works.
I am not responsible for anything. The following instructions are only suggestions.
Hello,
everyone knows how to root the LG G4 with the "low effort root" method.
They copied the system partition to an ".img" file, rooted it and copied it back to the "system" partition.
Many users wonder how to get the right parameters for the "dd" commands.
Please read the complete guide and be sure that you understand it until you execute a command!
Information:
Code:
dd if=/inputfile bs=8192 count=12345 of=/outputfile
if = Input File
of = Output File
bs = Blocksize in bytes (default is 512 - to increase copy speed use multiple of 512 e.g. 8192)
count = how many blocks
skip = skip blocks before start reading
seek = skip blocks before start writing
more info: http://man7.org/linux/man-pages/man1/dd.1.html
There are different models of the LG G4 on the market.
We know that the system partition is different depending on the model of the G4.
As an example I will show you how to calculate the parameters for the LG G4 H815 (International Model).
What you need:
Windows with Send_Command.exe
Instructions:
At first we need to know where the "system" partition starts (first sector) and how big it is (partition size).
I used the first method to find these values. But I recommend the second method because it's easier.
First method (difficult method, extracting the GPT and using "gdisk" in linux to read the partition info)
What you need:
Linux with "gdisk" installed
Instructions:
Put your smartphone to "Download Mode" and connect it to the Send_Command.exe command prompt.
We need to copy the partition table to the internal storage.
The partition table of GPT (GUID Partition Table) has a size of 16384 bytes and starts at LBA2.
Each LBA has a size of 512 bytes. Because we start at LBA0 we need to add 1024 bytes.
In summary 16384 + 1024 = 17408 (bytes).
Execute the following command:
Code:
dd if=/dev/block/mmcblk0 bs=1 count=17408 of=/data/media/0/gpt_backup.img
Enter "LEAVE" to restart your phone.
You will find the (very small) file "gpt_backup.img" on your internal storage.
Switch to Linux:
Copy the file to your Linux and open the terminal. Then type this:
Code:
gdisk /yourpath/gpt_backup.img
Some warnings will occur. Ignore them.
You will see:
Code:
Command (? for help):
Enter "p" and hit "enter".
You will get a list of the partitions.
Scroll up a bit and check that you see:
"Logical sector size: 512 bytes"
Scroll down and look for the "system" partition.
You will find a line similar to this:
Code:
47 884736 9363455 4.0GiB FFFF system
Now you know the number of the "system" partition is "47".
You will see:
Code:
Command (? for help):
Type "i" and hit "enter".
You will be asked the partition number.
Enter it and hit "enter".
You will see something conatining lines similar to this:
Code:
First sector: 884736
Last sector: 9363455
Partition size: 8478720
Partition name: 'system'
We need the values from "First sector" and "Partition size".
Second method (easier method, just using "adb shell" to read the partition info)
What you need:
adb shell
usb debugging enabled
To get the "logical sector size" use:
cat /sys/block/mmcblk0/queue/logical_block_size
It should be 512
smason said:
To find in any smartphone the offset and the size of /system:
$ adb shell
[email protected]:/ $ ls -la /dev/block/bootdevice/by-name/system
ls -la /dev/block/bootdevice/by-name/system
lrwxrwxrwx root root 2015-01-02 10:50 system -> /dev/block/mmcblk0p47
[email protected]:/ $ cd /sys/block/mmcblk0/mmcblk0p47
cd /sys/block/mmcblk0/mmcblk0p47
[email protected]:/sys/block/mmcblk0/mmcblk0p47 $ cat start
cat start
884736
[email protected]:/sys/block/mmcblk0/mmcblk0p47 $ cat size
cat size
8478720
[email protected]:/sys/block/mmcblk0/mmcblk0p47 $
so:
offset = 512 * 884736 = 452984832
partition size = 512 * 8478720 = 4341104640
Cheers!
Click to expand...
Click to collapse
So "first sector" is the value from "cat start" (884736).
The "partiton size" is the value from "cat size" (8478720).
Now the mathematics (using the values from above):
Logical sector size = 512 (I never saw something different on LG G4 smartphones)
Assuming bs=8192
skip and seek: "First sector" * "Logical sector size" / bs
884736 * 512 / 8192 = 55296
count: "Partition size" * "Logical sector size" / bs
8478720 * 512 / 8192 = 529920
That was an example for the H815 (International Model).
Use your own values to calulate the "dd" parameters!
Back to Windows:
Put your smartphone to "Download Mode" and connect it to the Send_Command.exe command prompt.
Now you can copy your "system" partition to "system.img" with the following command:
Code:
dd if=/dev/block/mmcblk0 bs=8192 skip=55296 count=529920 of=/data/media/0/system.img
Replace the values with the ones you calculated for your model!
Now you could copy the "system.img" to your Linux and root it or do everything else you want.
Important: Do NOT delete the original "system.img" from your internal storage as long as you are not 100% sure your G4 is stable.
If your modifications don't work, you can copy back the original "system" partition (with "dd").
To copy the modified "system_changed.img" back to the "system" partition use the following command:
Code:
dd if=/data/media/0/system_changed.img bs=8192 seek=55296 count=529920 of=/dev/block/mmcblk0
Replace the values with the ones you calculated for your model!
Important: Be sure to use "skip" when reading and "seek" when writing.
The "dd" command should take about a minute.
Did the instructions help you?
Please give a "Thanks!"
Thank you

Hi,
thanks for this great post.
I just have one question. With your formulas and using 8K block size, I get a floating point number as result. So I used a block size of 4K instead, and I get an even number. This seems better to me so I went with it, as I believe smaller block sizes are always ok?
I'm just wondering one thing which seems not right to me. My system partition is reported to be 2.5GB:
Partition number (1-42): 39
Partition GUID code: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (Microsoft basic data)
Partition unique GUID: A8725BAA-9E45-B2F8-8FA3-8C972F60F0CF
First sector: 836608 (at 408.5 MiB)
Last sector: 6074573 (at 2.9 GiB)
Partition size: 5237966 sectors (2.5 GiB)
Attribute flags: 1000000000000000
Partition name: 'system'
So with the formulas:
FACTOR 512 / 4096 = 0.125
skip and seek: "First sector" * "Logical sector size" / bs
836608 *FACTOR = 104576
count: "Partition size" * "Logical sector size" / bs
8478720 * FACTOR = 1059840
If I now run the dd command:
dd if=/dev/block/mmcblk0 bs=4096 skip=104576 count=1059840 of=/storage/external_SD/system.img
I get a file system.img which is 4096 MB. Should it not be 2.5GB as my original system partition?
If I use bs=512 (the default) and type
dd if=/dev/block/mmcblk0 bs=512 skip=836608 count=8478720 of=/storage/external_SD/system.img
I get a system.img of the right size (bit over 2.5GB).
I think the block size to use for "skip" is to be specified with the option ibs=XXX, not bs=XXX which only applies to "count" (according to man dd). I tried the ibs option, but the command then just doesn't work on Send_Command.exe. It doesn't even print an error but simply returns immediately.
Cheers
Jen

Hi,
which phone do you have?
Your calculation seems wrong. It's ok to use BS with 4k. I could be a bit slower then 8k, but that doesn't matter.
BUT: Look at your "count" value. Your partition size is 5237966. You used 8478720 (the value from my G4(H815EU) example). Thats wrong!!!
How to calculate with 1k and your values:
bs=1024
skip=836608*512/1024=418304
count=5237966*512/1024=2618983
Please check my calulation!!!
It's interesting, that the Send_Command shell has access to your external sd card...
I think the block size to use for "skip" is to be specified with the option ibs=XXX, not bs=XXX which only applies to "count" (according to man dd).
Click to expand...
Click to collapse
No. "bs" is the right parameter.
If you use "bs" it sets "ibs" and "obs" to the value of "bs".
Just do "dd --help" on a linux system for more details.

Hi Dominik,
oh my, how embarrassing I actually did take the wrong value from the example you posted. I used my value (the 5237966) for calculating the parameters with bs=8K, and got a floating value, so tried 4K instead... and the wrong value must have snug in. Oups.
I also get floating value on 4K now that you've pointed my mistake out:
5237966 * 512/4096= 654745.75
If I rounded this up, would this not mean that I copy a tiny bit of the next partition on the image? And if I then use the image to restore, would I not run the risk to damage something in the following partition?
Anyway, it's not a huge drama as I can just use bs=512 and it works.
Yes I have access to the SD card, the image also has copied there successfully. I was also surprised because I read in the forums that it's not possible.
I found it out with the "df" command, as the SD was listed there. I needed to use it because there's no room on my internal storage (it's a ridiculous 8GB on the LG H735) to store the image there.
My system partition is only 2.5GB so I don't think I have to reformat, but you are right it would be better to use ext4.

Ok
I removed my information about formatting the sd card.
You dont't have to format it. FAT32 is ok.
So you can use your sd card on systems which don't support ext4 too.

I have the LG G4S (H735). It's unusable without rooting as it only has 8GB internal memory. That's why I'm trying to root it now.

jen.magnolis said:
I have the LG G4S (H735). It's unusable without rooting as it only has 8GB internal memory. That's why I'm trying to root it now.
Click to expand...
Click to collapse
Ok, good luck.
Please open a new thread if you have questions about rooting your phone.
Or is there already one? Maybe these?
http://forum.xda-developers.com/g4/help/rooting-lg-h735-g4-beat-t3192491
http://forum.xda-developers.com/g4/general/lg-g4s-world-root-lg-devices-t3231759/page7
Oh. Just saw that you are already there

dominik-p said:
Ok, good luck.
Please open a new thread if you have questions about rooting your phone.
Or is there already one? Maybe these?
http://forum.xda-developers.com/g4/help/rooting-lg-h735-g4-beat-t3192491
http://forum.xda-developers.com/g4/general/lg-g4s-world-root-lg-devices-t3231759/page7
Oh. Just saw that you are already there
Click to expand...
Click to collapse
I just created a new thread too to focus on the particular problem I have:
http://forum.xda-developers.com/g4/general/rooting-lg-g4s-h735-t3243549

this guide helped in dumping boot and recovery partitions.
thank you very much sir! i successfully dumped my boot and recovery partition using dd in my mediatek device by following your guide.

sparksthedev said:
thank you very much sir! i successfully dumped my boot and recovery partition using dd in my mediatek device by following your guide.
Click to expand...
Click to collapse
Congratulations
Did you use the first (more komplex) oder the second method for your device?
I saw that you had problems in this thread:
http://forum.xda-developers.com/showthread.php?p=65907557#post65907557
And you wrote a guide for MTK devices here:
http://forum.xda-developers.com/general/general/guide-dumping-boot-img-recovery-img-t3339530
This doesn't work with the LG G4, but I think it will help many others.
Thank you

My sister asked me to root her phone. It seems more complicated than anything I did in the past (HTC Wildfire, Galaxy Core Plus, Xperia M4A).
I tried this tutorial and it kinda worked, but I can't mount image I got, so it's useless (image, not tutorial!).
Phone is LG-H736 (Beat). I got this result in gdisk:
Code:
Partition number (1-42): 39
Partition GUID code: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (Microsoft basic data)
Partition unique GUID: A9520AE6-ABC6-F107-E8FE-B37C4C30CB77
First sector: 836608 (at 408.5 MiB)
Last sector: 6074573 (at 2.9 GiB)
Partition size: 5237966 sectors (2.5 GiB)
Attribute flags: 1000000000000000
Partition name: 'system'
The 8K bs gave me floating point result, so I used 0,5K.
So the dd command were:
Code:
dd if=/dev/block/mmcblk0 bs=512 skip=836608 count=5237966 of=/storage/external_SD/system.img
BTW, I had access to SDCard and I didn't need to open ports...
EDIT: I got the system.img. The problem was I haven't got enough space on SD card.
But now I bricked it...
https://forum.xda-developers.com/g4/help/softbricked-g4-beat-lg-h735-t3959237

Error flashing bootloader with heimdall

I need to update the bootloader on a T705 in order to run the Marshmallow ROM. Got the correct sboot.bin file but attempting to flash with heimdall gives the error "Failed to confirm end of file transfer sequence!":
Code:
# heimdall flash --BOOTLOADER sboot.bin
Heimdall v1.4.1
Copyright (c) 2010-2014 Benjamin Dobell, Glass Echidna
http://www.glassechidna.com.au/
This software is provided free of charge. Copying and redistribution is
encouraged.
If you appreciate this software and you would like to support future
development please consider donating:
http://www.glassechidna.com.au/donate/
Initialising connection...
Detecting device...
Claiming interface...
Setting up interface...
Initialising protocol...
Protocol initialisation successful.
Beginning session...
Some devices may take up to 2 minutes to respond.
Please be patient!
Session begun.
Downloading device's PIT file...
PIT file download successful.
Uploading BOOTLOADER
100%
ERROR: Failed to confirm end of file transfer sequence!
ERROR: BOOTLOADER upload failed!
Ending session...
ERROR: Failed to send end session packet!
Releasing device interface...
Can't use odin as I don't have a windows machine.
My pit shows the bootloader as read-only and zero bytes:
Code:
--- Entry #0 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 80
Attributes: 2 (STL Read-Only)
Update Attributes: 1 (FOTA)
Partition Block Size/Offset: 0
Partition Block Count: 2046
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: BOOTLOADER
Flash Filename: sboot.bin
FOTA Filename:
Is that normal or does it mean the bootloader is locked? Sorry for my ignorance, don't have any experience flashing the bootloader.

Sorry I can't answer your questions but I'm also a non-windows user (Linux). To use the safer Odin I created a Windows VirtualBox VM with a Windows install iso I downloaded over the net. Subsequently it has been suggested by others that it would have been easier for my to have created a bootable usb. In any event you never have to activate the window license to use Odin just answer that pop-up by clicking later. I download the latest firmware (there is a firmware download tool thread in the general section), quickly and use Odin all in that VM.
I posted a how-to create such a VM in the general section but if doing it again I'd likely go the USB route but either way is likely safe than your current method.
Sent from my SM-T800 using XDA Premium HD app

You're lucky you even got Heimdall to connect on the tab s.
I've had zero success with it on either windows or Linux.
Stick with a VM as suggested. It takes literally a few minutes to set up.
https://dev.windows.com/en-us/microsoft-edge/tools/vms/linux/

Thanks for the advice. Heimdall on Linux previously worked well for me when I flashed TWRP on the same T705 a few months ago. This time though I'll try odin in a VM as you both suggest.

Got odin working. The VM was slightly problematic:
Couldn't get Virtualbox on Mac to work. VM couldn't see the tablet.
Under Linux, had to "modprobe -r cdc_acm" to get it to work, as described here
Even then, Odin was failing with a big red FAIL! message at the completion of the flash. Resorted to pirating Windows 7 and installing on a spare harddrive. Still got the Odin FAIL! So I think it was the files I was using. Would the slightly wrong version cause a flashing error? My tablet is an Australian T705Y and the images may have been for a different region.
Anyway, downloaded the complete official ROM from sammobile and that flashed fine using Odin. Then installed TWRP and now the Marshmallow ROM.

cr1key said:
Got odin working. The VM was slightly problematic:
Couldn't get Virtualbox on Mac to work. VM couldn't see the tablet.
Under Linux, had to "modprobe -r cdc_acm" to get it to work, as described here
Even then, Odin was failing with a big red FAIL! message at the completion of the flash. Resorted to pirating Windows 7 and installing on a spare harddrive. Still got the Odin FAIL! So I think it was the files I was using. Would the slightly wrong version cause a flashing error? My tablet is an Australian T705Y and the images may have been for a different region.
Anyway, downloaded the complete official ROM from sammobile and that flashed fine using Odin. Then installed TWRP and now the Marshmallow ROM.
Click to expand...
Click to collapse
yes I am curious how to flash only sboot.bin through odin (or any other means)

The heimdall command is at the top of the thread.
I never actually attempted the bootloader in odin. I tried flashing the modem (which I also had to update), but as that was failing I never progressed to the bootloader. For the modem I just used a tar file that contained modem.bin. Odin reads the PIT and figures out where which partition it should go in (in this case, RADIO). I expect it'd work for the bootloader too. The official ROM distributions are tar files containing *.bin files:
Code:
-rw-rw-r-- dpi/dpi 1148160 2015-10-23 00:29 sboot.bin
-rw-rw-r-- dpi/dpi 7592208 2015-10-23 00:29 boot.img
-rw-rw-r-- dpi/dpi 7803152 2015-10-23 00:29 recovery.img
-rw------- dpi/dpi 2313405472 2015-10-23 00:30 system.img
-rw-r--r-- dpi/dpi 40231200 2015-10-23 00:31 cache.img
-rw-r--r-- dpi/dpi 217281008 2015-10-23 00:31 hidden.img
-rw-rw-r-- dpi/dpi 28600832 2015-10-23 00:24 modem.bin
odin flashes each one in turn to the appropriate partition. Just use PDA to flash the tar file. Possibly you could use the BOOTLOADER (sometimes called just "BL") button, but I don't think it matters.