• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

[GUIDE][UTIL][MT65xx] Create Scatter File and Dump Full ROM

Search This thread

syserr

Senior Member
Aug 16, 2012
459
361
Idaho
[GUIDE][UTIL][MT65xx] Create Scatter File / Dump Full ROM
For any MT65xx device, no matter how obscure.


I will discuss a method for:
* making your own SPFT scatter file
* dumping your entire ROM (without root)
* dicing up your entire ROM into partition blocks


This is somewhat of a manual process. rua1's MTK Droid Root & Tools circumvents the need for doing most of this. I applaude his work, it's a big undertaking and he supports it well.

Here are a few reasons to use the method I discuss here:
* you want a ROM dump without rooting
* you want a ROM dump without your OS booted (clone cold system is safe)
* you want a guaranteed way to restore exactly current state (safety and return to store)
* you are just plain worried something will go wrong

-------------------------------------

I have two methods for creating a scatter file.

Method #1
Find your scatter information in SP Flash Tool's Logs

Well first, you have to make SP Flash Tool happy enough to give you some information about your device.

* Obtain a SPFT ROM that is known good for any phone/tablet, preferrably with the same chip as yours. Make sure that scatter file loads into SPFT without error, SPFT checks the PRELOADER and DSP_BL and if they aren't in the scatter directory, it will fail and maybe crash.

* Close SPFT, now modify the MT*scatter.txt file and introduce a few errors in the partition names, but don't change PRELOADER or DSP_BL. An example, instead of "ANDROID" replace it with "DEADBEEF". You ask why? Well you want to make SURE that the "Download" feature fails. You DON'T want the "Download" to actually work and write your random SPFT ROM to your new device. After loading the freshly broken scatter file, click "Download" and hook up your MTK device in preloader / META Mode. It will say your PMT block does not match the scatter file. ERROR:

* Go to SPFT's menu "Help / Open logs folder" and find the latest date. Open the BROM_DLL*.log in your text editor. Search for text that looks like this, I'd first search for "CMD_ReadPartitionInfo():

Code:
11/14/13 09:01:27.382 BROM_DLL[3836][2208]: DA_cmd::CMD_ReadPartitionInfo(): command is allowed. (FlashToolLib/sv5/common/generic/src/da_c
md.cpp:5242)
11/14/13 09:01:27.382 BROM_DLL[3836][2208]: DA_cmd::CMD_ReadPartitionInfo(): getting 20 partitions .. (FlashToolLib/sv5/common/generic/src
/da_cmd.cpp:5269)
11/14/13 09:01:27.397 BROM_DLL[3836][2208]: DA_cmd::CMD_ReadPartitionInfo(): dump 20 partitions (FlashToolLib/sv5/common/generic/src/da_cm
d.cpp:5279)
11/14/13 09:01:27.397 BROM_DLL[3836][2208]: PART[0 ](PRELOADER     ) - offset (0x0000000000000000) - size (0x0000000000040000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.397 BROM_DLL[3836][2208]: PART[1 ](DSP_BL        ) - offset (0x0000000000040000) - size (0x00000000005C0000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.397 BROM_DLL[3836][2208]: PART[2 ](MBR           ) - offset (0x0000000000600000) - size (0x0000000000004000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[3 ](EBR1          ) - offset (0x0000000000604000) - size (0x000000000005C000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[4 ](__NODL_PMT    ) - offset (0x0000000000660000) - size (0x0000000000400000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[5 ](__NODL_NVRAM  ) - offset (0x0000000000A60000) - size (0x0000000000300000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[6 ](__NODL_SECCFG ) - offset (0x0000000000D60000) - size (0x0000000000020000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[7 ](UBOOT         ) - offset (0x0000000000D80000) - size (0x0000000000060000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[8 ](BOOTIMG       ) - offset (0x0000000000DE0000) - size (0x0000000000600000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[9 ](RECOVERY      ) - offset (0x00000000013E0000) - size (0x0000000000600000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[10](SEC_RO        ) - offset (0x00000000019E0000) - size (0x0000000000600000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[11](__NODL_MISC   ) - offset (0x0000000001FE0000) - size (0x0000000000060000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[12](LOGO          ) - offset (0x0000000002040000) - size (0x0000000000300000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[13](__NODL_EXPDB  ) - offset (0x0000000002340000) - size (0x00000000000A0000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[14](EBR2          ) - offset (0x00000000023E0000) - size (0x0000000000004000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[15](FAC           ) - offset (0x00000000023E4000) - size (0x0000000010000000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[16](ANDROID       ) - offset (0x00000000123E4000) - size (0x0000000020100000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[17](CACHE         ) - offset (0x00000000324E4000) - size (0x0000000020100000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[18](USRDATA       ) - offset (0x00000000525E4000) - size (0x0000000020100000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[19](FAT           ) - offset (0x00000000726E4000) - size (0x0000000000000000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
Make sure you aren't looking at a dump of your scatter, but looking at the partition dump from your device. (If it contains DEADBEEF flag from above, you are looking at the wrong part of the log.) You can manually create a scatter file from that, or you can paste the lines with partition info into a text file and run this shell script:

Code:
cat pastedlog.txt | sed -n 's/.*](\([^ ]*\)[^(]*(\([^)]*\).*)/\1 \2\n{\n}/p' | sed 's/x00000000/x/g' > mynewscatter.txt

This will get you really close, but the last entry you see in a typical scatter file is BMTPOOL. I don't know much about BMTPOOL or __NODL_BMPPOOL other than it's not a real partition. It might not even be required? (You might be able to fake that entry if you look at similar scatter files. If not, read on)

Method #2
An alternate and supplemental way of getting scatter info is to use ADB on a running device. I'm sure this is similar to MTK Droid Root & Tools method.

Code:
adb pull /proc/dumchar_info

Now that you have that file local on your PC, you can run this python script:

Code:
import sys
import string
import re

ins = open( "dumchar.txt", "rb" )
outs = open( "scatter.txt", "wb" )
for line in ins:
    linesp = re.split('\W+', line)
    name = linesp[0].upper()
    start = int(linesp[2],16)
    block = linesp[5]
    if block != 'misc':
        start = start + 0x600000
    outs.write(name + " " + string.replace(hex(start), "L", "") + "\n{\n}\n")
ins.close()
outs.close()

This method gives you the BMTPOOL entry that the other method does not, but it lacks the __NODL_ designator for all partitions. If you aren't familiar with that prefix, SPFT uses that to know if it should typically allow you to DownLoad over the top of the paritition.

With both scatter files, throw them side-by-side in a text editor (or diff tool) and with a brain, it's easy enough to merge one with the __NODL_ prefix and the one with the BMTPOOL entry.

Scatter file complete!

PS - Possibly another way, is to use SPFT to do a "Read back" (read memory) at 0x660000 of size 0x400000. Save this as the PMT block and analyse it with a hex editor. I believe the PMT block is always at address 0x66000 judging from a dozen different scatter files.

Dump Full ROM
Perfect Total Backup of your Firmware

The safe way to do this with or without a proper scatter file is the "Read back" feature of SP Flash Tool. There are MANY reasons to dislike MediaTek, but this feature is so nice that I can forgive them for most of their wrong doing.

Most of this section I will generalize from my Lenovo A2107A Guide.

Here is a cookbook for doing a total backup of your MTK device with MediaTek's SP Flash Tool. No rooting, you might even do this before you ever boot! I have basically done this with both of my devices before I fiddled too much. I recommend doing it before you do anything really.

1. Install VCOM Drivers.
2. Install SP Flash Tool.
3. Grab an SPFT ROM, really anything should work, you just have to make SP Flash Tool happy. SPFT validates the scatter file against some of the image files, so you have to calm SPFT down by giving it something it can make sense of. We won't use the scatter file or image files while we do the "Read back" operation.
4. Run SP Flash Tool, Open Scatter File
5. Don't play with anything, go into the "Read back" tab (This will read your flash to a file on your PC)
6. Click on any items in the list, then click the "Remove" button
7. Now click the "Add" button
8. Double click on the "N/A" under Read Flag
9. Type a file name to write to, like "WHOLE_ROM"
10. Now it will popup a window "Readback block start address"
11. Leave "Hex" selected, Start Address" 0x0000, Length: 0x40000000, Click OK (NOTE: this will get the first GIG of flash)
12. Click the "Read back" button
13. SPFT now waits for you to connect your device and put it in Meta Mode
14. Without plugging your phone/tablet in, tap the Reset Button or make sure it's fully off
15. Hold VolUp, plug in USB, Release VolUp (putting it in Meta Mode) <--- Important
16. You will see the progress bar moving. Total backup takes forever, because in this mode SPFT seems to not do USB HIGHSPEED
That's IT! It'll take a few hours, so go to bed.

If you ever restore, just go into Recovery and Wipe Data and Cache. (as these are large and we probably didn't back them up above)

Note: "Length" in Step 11 is probably long enough for most devices. You can reference the scatter file you made above to make sure get everything, but you don't need USRDATA or CACHE, as those get wiped anyway.


Dicing up Full ROM image into partition images


I've made a little bash shell script to dice up a whole ROM according to a scatter file. This creates files exactly the size of the partitions. Some post processing needs done below the script:

dice.sh
Code:
#!/bin/bash

scatterfile=$1
rom=$2
pdir=raw.partitions

rm -rf $pdir
mkdir $pdir

cat $scatterfile | grep "x" | while read line; do
    name=$(echo $line | sed 's/ .*//g')
    name=$(echo $name | sed 's/^__NODL_//g')
    start=$(echo $line | sed 's/.* //g')
#    echo $name

    if [[ -n $last_name ]]; then
	echo "Processing: $last_name"
	echo "     start: $last_start"
	size=$(( $start - $last_start ))
	if [[ $size -lt 0 ]]; then
	    size=0xFFFFF000
	else
	    size=0x$(echo "obase=16; $size" | bc)
	fi
	echo "      size: $size"
	short_start=$(echo $last_start | sed 's/000$//g')
	short_size=$(echo $size | sed 's/000$//g')
	echo dd if=$rom of=$pdir/$last_name bs=$(( 0x1000 )) \
	    skip=$(( $short_start )) count=$(( $short_size ))
	dd if=$rom of=$pdir/$last_name bs=$(( 0x1000 )) \
	    skip=$(( $short_start )) count=$(( $short_size ))
    fi

    last_name=$name
    last_start=$start
done

Now there is some post processing done. Truncate MBR, EBR1, EBR2 to 512 bytes. And remove trailing bytes of 0000 or FFFF on the end of PRELOADER and DSP_BL.

Here is a one off script for example use:

clean.sh
Code:
#!/bin/bash

pdir=raw.partitions
odir=out

rm -rf $odir
mkdir $odir

dd if=$pdir/PRELOADER of=$odir/preloader.bin bs=$(( 0x800 )) skip=1
./trim.sh $odir/preloader.bin
./trimFF.sh $odir/preloader.bin

dd if=$pdir/DSP_BL of=$odir/DSP_BL bs=$(( 0x8000 )) count=1
./trimFF.sh $odir/DSP_BL

dd if=$pdir/MBR of=$odir/MBR bs=512 count=1
dd if=$pdir/EBR1 of=$odir/EBR1 bs=512 count=1
dd if=$pdir/EBR2 of=$odir/EBR2 bs=512 count=1

cp $pdir/UBOOT $odir/uboot.bin

cp $pdir/LOGO $odir/logo.bin
./trim.sh $odir/logo.bin

cp $pdir/SEC_RO $odir/secro.img

cp $pdir/RECOVERY $odir/recovery.img

cp $pdir/BOOTIMG $odir/boot.img

cp $pdir/FAC $odir/fac.img

cp $pdir/ANDROID $odir/system.img

cp MT*.txt $odir/

And quickly, Here is my hack to remove 0000 and FFFF from the end of files:

trim.sh
Code:
#!/bin/bash
truncate -s $(( 4 + $(cat $1 | hexdump -v -e '/4 "%_ad: " ' -e '4/1 "%02X" "\n"' \
 | grep -v ": 00000000" | tail -n 1 | sed 's/:.*//') )) $1
trimFF.sh
Code:
#!/bin/bash
truncate -s $(( 4 + $(cat $1 | hexdump -v -e '/4 "%_ad: " ' -e '4/1 "%02X" "\n"' \
 | grep -v ": FFFFFFFF" | tail -n 1 | sed 's/:.*//') )) $1

You should be able to read the clean.sh script and figure out only in just those few cases, is special post processing needed. If you don't post process, SPFT will give errors.

I hope this helps. If you have any questions, ask... I'll try to clarify this first post.
 
Last edited:

fragargon

Senior Member
Feb 14, 2011
1,091
283
[GUIDE][UTIL][MT65xx] Create Scatter File / Dump Full ROM
For any MT65xx device, no matter how obscure.




Dicing up Full ROM image into partition images


I've made a little bash shell script to dice up a whole ROM according to a scatter file. This creates files exactly the size of the partitions. Some post processing needs done below the script:

dice.sh
Code:
#!/bin/bash

scatterfile=$1
rom=$2
pdir=raw.partitions

rm -rf $pdir
mkdir $pdir

cat $scatterfile | grep "x" | while read line; do
    name=$(echo $line | sed 's/ .*//g')
    name=$(echo $name | sed 's/^__NODL_//g')
    start=$(echo $line | sed 's/.* //g')
#    echo $name

    if [[ -n $last_name ]]; then
	echo "Processing: $last_name"
	echo "     start: $last_start"
	size=$(( $start - $last_start ))
	if [[ $size -lt 0 ]]; then
	    size=0xFFFFF000
	else
	    size=0x$(echo "obase=16; $size" | bc)
	fi
	echo "      size: $size"
	short_start=$(echo $last_start | sed 's/000$//g')
	short_size=$(echo $size | sed 's/000$//g')
	echo dd if=$rom of=$pdir/$last_name bs=$(( 0x1000 )) \
	    skip=$(( $short_start )) count=$(( $short_size ))
	dd if=$rom of=$pdir/$last_name bs=$(( 0x1000 )) \
	    skip=$(( $short_start )) count=$(( $short_size ))
    fi

    last_name=$name
    last_start=$start
done



hi syserr,

i m tryin to run the script dice.sh and this is the trace i get

Code:
[email protected] ~/TESTbcup $ sh -x ./dice.sh
+ 
: not found2: ./dice.sh: 
+ scatterfile=
+ rom=
+ pdir=raw.partitions
+ 
: not found6: ./dice.sh: 
+ rm -rf raw.partitions
+ mkdir raw.partitions
+ 
: not found9: ./dice.sh: 
./dice.sh: 37: ./dice.sh: Syntax error: end of file unexpected (expecting "then")
[email protected] ~/TESTbcup $

any advice would be welcome. I dumb a complete rom and try to dice it.

thank you syserr
 
Last edited:

syserr

Senior Member
Aug 16, 2012
459
361
Idaho
hi syserr,

i m tryin to run the script dice.sh and this is the trace i get

Code:
[email protected] ~/TESTbcup $ sh -x ./dice.sh
+ 
: not found2: ./dice.sh: 
+ scatterfile=
+ rom=
+ pdir=raw.partitions
+ 
: not found6: ./dice.sh: 
+ rm -rf raw.partitions
+ mkdir raw.partitions
+ 
: not found9: ./dice.sh: 
./dice.sh: 37: ./dice.sh: Syntax error: end of file unexpected (expecting "then")
[email protected] ~/TESTbcup $

any advice would be welcome. I dumb a complete rom and try to dice it.

thank you syserr

Sorry Sorry Sorry. It takes 2 arguments, I should do some error checking and make sure the user supplies them.

Code:
./dice.sh scatterfile.txt FULLROM.img
It might have some syntax that is specific to bash, so "sh" might throw errors too.
 

Alex1948

Senior Member
Jan 13, 2012
117
19
Sibiu
Dumchar.txt

I did dumchar_info, I've renamed it dumchar.txt.

Run script , and it gives me error(He created and an scatter.txt), but empty - see image
 

syserr

Senior Member
Aug 16, 2012
459
361
Idaho
I did dumchar_info, I've renamed it dumchar.txt.

Run script , and it gives me error(He created and an scatter.txt), but empty - see image

I'm sorry, I didn't see this message before, I'm following about 10 threads and this got lost.

I also copied this over from the rua1 thread. I don't think he appreciates our conversation over there, mainly because it's somewhat off topic.
For @syserr
I do not know what all you write here, Python, etc.start adress + lenght , I think we know how to add two numbers in base 16 , no other ....MTKdroid is a software that solves everything,In Python a script of yours, gives me error.
I posted a picture of treadh and you did not answer why(Or you can not quite explain , and we do not understand) - see image

Answers:
I've never run it without putting it in a file. Put that python text in dumchar2scatter.py, or something like that. I'm 99% sure that will get rid of the error and give you stuff in your scatter file. You are using Python2, that is good!

You are free to PM me why you feel I didn't see a post. Again, sorry.

Because I think you are genuinely interested in learning, I will describe what my little script is doing. (btw, this is about my third program/script in Python ever)


Code:
import sys
import string
import re

ins = open( "dumchar.txt", "rb" )           [COLOR=Blue]# creates a file handle (ins) to read in dumchar.txt[/COLOR]
outs = open( "scatter.txt", "wb" )          [COLOR=Blue]# creates a file handle (outs) to write to scatter.txt[/COLOR]
for line in ins:                                     [COLOR=Blue]# loops through each line of the input file and puts each line in variable "line"[/COLOR]
    linesp = re.split('\W+', line)              [COLOR=Blue]# this splits the line varable based on whitespace/spaces, results go into linesp array[/COLOR]
    name = linesp[0].upper()                 [COLOR=Blue]# grabs the first thing in the line, uppercases it, puts it in a varable called name[/COLOR]
    start = int(linesp[2],16)                   [COLOR=Blue]# start variable gets the value of the 3rd thing in the line, but also converts it to an int from text[/COLOR]
    block = linesp[5]                            [COLOR=Blue]# block variable gets 6th thing in line - usually misc or blk[/COLOR]
    if block != 'misc':                            [COLOR=Blue]# if the block variable is NOT 'misc' (only preloader and dsp_bl are these) then ...[/COLOR]
        start = start + 0x600000              [COLOR=Blue]# add the offset to the start variable[/COLOR]
    outs.write(name + " " + string.replace(hex(start), "L", "") + "\n{\n}\n")    [COLOR=Blue]# write out name with start address followed by { } on newlines[/COLOR]
ins.close()                                       [COLOR="Blue"]# just close the file handles here, to clean up, outs might need last writes to be flushed to file.[/COLOR]
outs.close()

I've previewed the code block above on this forum. :( Why is it so narrow, sorry you will need to use the scrollbar a lot.

UPDATE: Also it's important to have SPACES in a python file, not tabs. And the spaces are critical for python to know code blocks, it acts like {} in Java/C. So, when you make your python file, use spaces to make sure lines line up just right.
 
Last edited:
  • Like
Reactions: DerTeufel1980

Alex1948

Senior Member
Jan 13, 2012
117
19
Sibiu
I'm sorry, I didn't see this message before, I'm following about 10 threads and this got lost.

I also copied this over from the rua1 thread. I don't think he appreciates our conversation over there, mainly because it's somewhat off topic.


Answers:
I've never run it without putting it in a file. Put that python text in dumchar2scatter.py, or something like that. I'm 99% sure that will get rid of the error and give you stuff in your scatter file. You are using Python2, that is good!

You are free to PM me why you feel I didn't see a post. Again, sorry.

Because I think you are genuinely interested in learning, I will describe what my little script is doing. (btw, this is about my third program/script in Python ever)


Code:
import sys
import string
import re

ins = open( "dumchar.txt", "rb" )           [COLOR=Blue]# creates a file handle (ins) to read in dumchar.txt[/COLOR]
outs = open( "scatter.txt", "wb" )          [COLOR=Blue]# creates a file handle (outs) to write to scatter.txt[/COLOR]
for line in ins:                                     [COLOR=Blue]# loops through each line of the input file and puts each line in variable "line"[/COLOR]
    linesp = re.split('\W+', line)              [COLOR=Blue]# this splits the line varable based on whitespace/spaces, results go into linesp array[/COLOR]
    name = linesp[0].upper()                 [COLOR=Blue]# grabs the first thing in the line, uppercases it, puts it in a varable called name[/COLOR]
    start = int(linesp[2],16)                   [COLOR=Blue]# start variable gets the value of the 3rd thing in the line, but also converts it to an int from text[/COLOR]
    block = linesp[5]                            [COLOR=Blue]# block variable gets 6th thing in line - usually misc or blk[/COLOR]
    if block != 'misc':                            [COLOR=Blue]# if the block variable is NOT 'misc' (only preloader and dsp_bl are these) then ...[/COLOR]
        start = start + 0x600000              [COLOR=Blue]# add the offset to the start variable[/COLOR]
    outs.write(name + " " + string.replace(hex(start), "L", "") + "\n{\n}\n")    [COLOR=Blue]# write out name with start address followed by { } on newlines[/COLOR]
ins.close()                                       [COLOR="Blue"]# just close the file handles here, to clean up, outs might need last writes to be flushed to file.[/COLOR]
outs.close()

I've previewed the code block above on this forum. :( Why is it so narrow, sorry you will need to use the scrollbar a lot.

UPDATE: Also it's important to have SPACES in a python file, not tabs. And the spaces are critical for python to know code blocks, it acts like {} in Java/C. So, when you make your python file, use spaces to make sure lines line up just right.

OK, I get it("" I don't think he appreciates our conversation over there, mainly because it's somewhat off topic.""
, and why I posted here.
I do not know python, but try to understand more about these phones and their software.
A carefully read what I've written for other questions, as I have, and across from method 1, and there I have some questions.
Especially that last for hours at a READ BACK ,Dump Full ROM , with start adress and lenght by you.

I understand your explanation, written in the program right lines.I did not need them, I know what each instruction written there.
I do not know python but I want to understand .Look - I send you dumchar_info and firmware.info , with partitions start adress and lenght and see what you get.
And finally you get scatter file , my SCATTER FILE , block info - start adress , size , etc.
It's OK. ?As we do not just theory.
I liked your idea, what you wrote but I want to see it completed
 
Last edited:

Alex1948

Senior Member
Jan 13, 2012
117
19
Sibiu
Crashes

I did as you said. Look :

Send and dumchar.txt and dumchar2scatter.py

It's ok, I'm sorry you do not answer.I also sent a file and I wanted to enlighten and method 1.
I feel that all that script and dump rom are stupid
I think you should post here on this thred, not on MTKDroid Tool.

Sorry, if you prove me wrong

I'm sorry special excuse but if the script does not work , I posted the file dumchar.txt ,the idea that a fix you

It again sorry, did not mean to upset
 

Attachments

  • dumchar2scatter.JPG
    dumchar2scatter.JPG
    96 KB · Views: 2,708
  • dumchar.txt
    1.9 KB · Views: 2,130
Last edited:
  • Like
Reactions: captaintokesalot420

Alex1948

Senior Member
Jan 13, 2012
117
19
Sibiu
Scatter.txt

Successful scatter.txt.As shown in the picture has the same start adress with MTKDroid scatter file , without __NODL_ to 10 partitions.
SP Flash Tool , scatter - loading , load all - see image 2.
For Read Back why use it or one obtained with MTKDroid(see image 3)

Tks.
 

Attachments

  • Scatter-txt.JPG
    Scatter-txt.JPG
    232.6 KB · Views: 2,209
Last edited:

syserr

Senior Member
Aug 16, 2012
459
361
Idaho
It's ok, I'm sorry you do not answer.

Hi Alex, I figured out why I wasn't catching your posts here. I'm normally looking at my Subscribed threads, and I hadn't subscribed to this thread. I should subscribe and look at my notifications too.

I will look at your messages today. My script is "dumb" as it's looking for a certain path for the block device in the output of dumchar. If that output changes, my script will probably fail.
 
  • Like
Reactions: coolbeans2016

syserr

Senior Member
Aug 16, 2012
459
361
Idaho
Successful scatter.txt.As shown in the picture has the same start adress with MTKDroid scatter file , without __NODL_ to 10 partitions.
SP Flash Tool , scatter - loading , load all - see image 2.
For Read Back why use it or one obtained with MTKDroid(see image 3)

Tks.

I see it's working for you now. Great. We could make great tools, but MediaTek is changing things that cause problems for even rua1's MTKDRT. Personally, I think it's good to understand things. I'm glad you want to understand too.
 
  • Like
Reactions: Alex1948

Alex1948

Senior Member
Jan 13, 2012
117
19
Sibiu
WHOLE_ROM

4. Run SP Flash Tool, Open Scatter File :
- What scatter file upload ? images 1(that obtained with MTKDroid) or scatter.txt (renamed) and otained with dumchar , script pyton....see images 2. ???
- Start adress is 0x00000000 , but Lenght can pass 0xE7F20000 (start adress FAT=0xC81C0000+FAT lenght=0x1FD60000) END adress FAT ???

With this file, probably higher, than 1GB ,WHOLE_ROM - without extension , What do I do next ?
- to get all the MTKDroid A5_Duo_130806_ForFlashtoolFromReadBack_131007-212823 - see image 3(for this we used start adress 0x00000000 and Lenght 0x3c9c0000 - my CACHE start adress) and My ROM_0 has - 969 MB

And another CWM recovery, more personalized for this phone with can be done?Android-Kitchen-0.224 ? Need 2 files(system.img and boot.img)
I installed and cygwin but does not work, crashes
 

Attachments

  • ForFlashToolFromReadBack.JPG
    ForFlashToolFromReadBack.JPG
    82.1 KB · Views: 1,314
Last edited:

syserr

Senior Member
Aug 16, 2012
459
361
Idaho
4. Run SP Flash Tool, Open Scatter File :
- What scatter file upload ? images 1(that obtained with MTKDroid) or scatter.txt (renamed) and otained with dumchar , script pyton....see images 2. ???
- Start adress is 0x00000000 , but Lenght can pass 0xE7F20000 (start adress FAT=0xC81C0000+FAT lenght=0x1FD60000) END adress FAT ???

With this file, probably higher, than 1GB ,WHOLE_ROM - without extension , What do I do next ?
- to get all the MTKDroid A5_Duo_130806_ForFlashtoolFromReadBack_131007-212823 - see image 3(for this we used start adress 0x00000000 and Lenght 0x3c9c0000 - my CACHE start adress) and My ROM_0 has - 969 MB

And another CWM recovery, more personalized for this phone with can be done?Android-Kitchen-0.224 ? Need 2 files(system.img and boot.img)
I installed and cygwin but does not work, crashes

#3 and #4 go hand in hand. You just need to make SPFT happy. In all my testing, the scatter and img files can be WRONG... *IF* all you are doing is using "Read back" and "Write memory". It makes sense that to do raw reads and writes, you wouldn't need to know the structure. But this tool forces you to have a scatter and images so it will perform the read/write tasks.

On your second issue, the "FAT" block is not very important and at least on ICS 4.0.4 on my device, if it is all zeros, then on first boot Android will ask to format it. On 4.0.3, I think I had to create a FAT image, which is pretty easy on Linux.
 

gls9

Senior Member
Nov 13, 2011
233
47
I used this "tool".
But with clean.sh I get a error about DSP_BL. In my scatterfile (MT6589) it is not there. I attached scatterfile.

Is there another "replacement" which i need to clean ?
 

Attachments

  • MT6589_Android_scatter_emmc.txt
    516 bytes · Views: 1,332

JoeSip

Member
Mar 13, 2014
23
3
Lost calibration data - Unresponsive screen

Hey guys, I have Star N9800 phone. During the last week I've been trying hard to fix my touchscreen driver since I flashed a stock ROM. The problems I was facing were checking and comparing lk.bin (lcm driver) with other people who also have same phone, downloading different ROMs and boot images, tried almost everything. I even opened my phone and disconnected the digitizer to check if it's the problem. When it's connected it says: touchscreen: ili2113a when I check version in factory mode (VOL- + HOME + POWER). When it's disconnected it says: touchscreen: (null), so obviously digitizer is working fine.

Today I think i've found the problem. While using SP Flash Tool I've used manual format from 0x00000000 to whatever it said. It deleted calibration data. And apparently calibration data is stored in nvram.bin which can be backed up using MTK Droid Tools while running a working ROM.
I have flashed original stock ROM now, I'm rooted and I can control my phone from the PC but can't use the screen. It's fully unresponsive. I've checked some answers here on XDA and some guy said I should make a nvram backup of stock ROM and then flash userdata_nvram_only.tar as USERDATA in SP Flash Tool. When I tried unzipping that .tar it clearly has /data/nvram/ folder which also contains some calibration and other files. But when I flashed that .tar as USERDATA my phone isn't booting anymore. I've tried flashing different boot.img but the problem is still here.

Does anybody know how to fix my touchscreen?
I contacted few people on www.NeedRom.com to upload userdata_nvram_only.tar for me, but I don't know whether they are going to do it or not.
I appreciate all help I can get, and I'd seriously hate if I had to send the phone back to china. I wouldn't really do it.
 
  • Like
Reactions: westy06

syserr

Senior Member
Aug 16, 2012
459
361
Idaho
Posted my reply to his PM:


JoeSip said:
Wow you cleared some things for me now. I have Star N9800 smartphone. I've flashed 15 ROMs and tried disconnecting and connecting back the digitizer but screen is still unresponsive. It doesn't react at all. It could be because I used Format option and manual format option in SP Flash tool. Do you have any clue how to get my screen working again? Apparently when doing manual format from adress 0x00000000 calibration data gets removed. Please help me, i'm really desperate.


I can ask people from www.NeedRom.com to help me. They already tried because some of us have the same problems...
You could be the saviour of us all.

I think you are totally on track. The NVRAM block/partition is special and it really bugs me that I didn't know this up front when I killed my first MTK device, and people I trusted (ahead of me) didn't talk about it. (FYI, I bought an identical device to repair my device's NVRAM block)

The trick here is... most MTK SP Flash ROMs available don't have the NVRAM block. This is because, they are unique to the device (IMEI and MAC) and if you don't Format with SP Flash, then you don't need them.

What you need... someone with an identical device that is willing to run SP Flash and do a "Read Memory" on the address range of NVRAM block. You would get the address range from the scatter file.
 
  • Like
Reactions: JoeSip

syserr

Senior Member
Aug 16, 2012
459
361
Idaho
Hey guys, I have Star N9800 phone. During the last week I've been trying hard to fix my touchscreen driver since I flashed a stock ROM. The problems I was facing were checking and comparing lk.bin (lcm driver) with other people who also have same phone, downloading different ROMs and boot images, tried almost everything. I even opened my phone and disconnected the digitizer to check if it's the problem. When it's connected it says: touchscreen: ili2113a when I check version in factory mode (VOL- + HOME + POWER). When it's disconnected it says: touchscreen: (null), so obviously digitizer is working fine.

Today I think i've found the problem. While using SP Flash Tool I've used manual format from 0x00000000 to whatever it said. It deleted calibration data. And apparently calibration data is stored in nvram.bin which can be backed up using MTK Droid Tools while running a working ROM.
I have flashed original stock ROM now, I'm rooted and I can control my phone from the PC but can't use the screen. It's fully unresponsive. I've checked some answers here on XDA and some guy said I should make a nvram backup of stock ROM and then flash userdata_nvram_only.tar as USERDATA in SP Flash Tool. When I tried unzipping that .tar it clearly has /data/nvram/ folder which also contains some calibration and other files. But when I flashed that .tar as USERDATA my phone isn't booting anymore. I've tried flashing different boot.img but the problem is still here.

Does anybody know how to fix my touchscreen?
I contacted few people on www.NeedRom.com to upload userdata_nvram_only.tar for me, but I don't know whether they are going to do it or not.
I appreciate all help I can get, and I'd seriously hate if I had to send the phone back to china. I wouldn't really do it.

I'll say a couple more things:

Yes, right now your NVRAM block is probably all zeros. And yes, you can use MTK Droid Tools to back up a good NVRAM... I like using SP Flash Tool to read the memory range of the NVRAM block, then I know it's in a shutdown state etc. All MKDRT is doing is running an adb command and doing something like "dd if=/dev/mc***** of=nvram.bin bs=1M count=1"... You could do that too with adb.

You don't need the USERDATA block at all. I would correct your request, to just ask for NVRAM. As USERDATA/USRDATA/DATA (all aliases of the same thing) is a block for your installed apps and data. It is what gets wiped when you do a Factory Reset with typical ROMs or with CWM etc.
 
  • Like
Reactions: westy06 and JoeSip

JoeSip

Member
Mar 13, 2014
23
3
Thank you very much man!
So now I'm supposed to just get backup of NVRAM that someone has done in MTK Droid Tools and not the whole ROM?
What if I flash full backup of someone's whole ROM? Will that save me too?
 
  • Like
Reactions: westy06

Top Liked Posts

  • There are no posts matching your filters.
  • 32
    [GUIDE][UTIL][MT65xx] Create Scatter File / Dump Full ROM
    For any MT65xx device, no matter how obscure.


    I will discuss a method for:
    * making your own SPFT scatter file
    * dumping your entire ROM (without root)
    * dicing up your entire ROM into partition blocks


    This is somewhat of a manual process. rua1's MTK Droid Root & Tools circumvents the need for doing most of this. I applaude his work, it's a big undertaking and he supports it well.

    Here are a few reasons to use the method I discuss here:
    * you want a ROM dump without rooting
    * you want a ROM dump without your OS booted (clone cold system is safe)
    * you want a guaranteed way to restore exactly current state (safety and return to store)
    * you are just plain worried something will go wrong

    -------------------------------------

    I have two methods for creating a scatter file.

    Method #1
    Find your scatter information in SP Flash Tool's Logs

    Well first, you have to make SP Flash Tool happy enough to give you some information about your device.

    * Obtain a SPFT ROM that is known good for any phone/tablet, preferrably with the same chip as yours. Make sure that scatter file loads into SPFT without error, SPFT checks the PRELOADER and DSP_BL and if they aren't in the scatter directory, it will fail and maybe crash.

    * Close SPFT, now modify the MT*scatter.txt file and introduce a few errors in the partition names, but don't change PRELOADER or DSP_BL. An example, instead of "ANDROID" replace it with "DEADBEEF". You ask why? Well you want to make SURE that the "Download" feature fails. You DON'T want the "Download" to actually work and write your random SPFT ROM to your new device. After loading the freshly broken scatter file, click "Download" and hook up your MTK device in preloader / META Mode. It will say your PMT block does not match the scatter file. ERROR:

    * Go to SPFT's menu "Help / Open logs folder" and find the latest date. Open the BROM_DLL*.log in your text editor. Search for text that looks like this, I'd first search for "CMD_ReadPartitionInfo():

    Code:
    11/14/13 09:01:27.382 BROM_DLL[3836][2208]: DA_cmd::CMD_ReadPartitionInfo(): command is allowed. (FlashToolLib/sv5/common/generic/src/da_c
    md.cpp:5242)
    11/14/13 09:01:27.382 BROM_DLL[3836][2208]: DA_cmd::CMD_ReadPartitionInfo(): getting 20 partitions .. (FlashToolLib/sv5/common/generic/src
    /da_cmd.cpp:5269)
    11/14/13 09:01:27.397 BROM_DLL[3836][2208]: DA_cmd::CMD_ReadPartitionInfo(): dump 20 partitions (FlashToolLib/sv5/common/generic/src/da_cm
    d.cpp:5279)
    11/14/13 09:01:27.397 BROM_DLL[3836][2208]: PART[0 ](PRELOADER     ) - offset (0x0000000000000000) - size (0x0000000000040000) - mask (0x0
    000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
    11/14/13 09:01:27.397 BROM_DLL[3836][2208]: PART[1 ](DSP_BL        ) - offset (0x0000000000040000) - size (0x00000000005C0000) - mask (0x0
    000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
    11/14/13 09:01:27.397 BROM_DLL[3836][2208]: PART[2 ](MBR           ) - offset (0x0000000000600000) - size (0x0000000000004000) - mask (0x0
    000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
    11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[3 ](EBR1          ) - offset (0x0000000000604000) - size (0x000000000005C000) - mask (0x0
    000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
    11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[4 ](__NODL_PMT    ) - offset (0x0000000000660000) - size (0x0000000000400000) - mask (0x0
    000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
    11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[5 ](__NODL_NVRAM  ) - offset (0x0000000000A60000) - size (0x0000000000300000) - mask (0x0
    000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
    11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[6 ](__NODL_SECCFG ) - offset (0x0000000000D60000) - size (0x0000000000020000) - mask (0x0
    000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
    11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[7 ](UBOOT         ) - offset (0x0000000000D80000) - size (0x0000000000060000) - mask (0x0
    000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
    11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[8 ](BOOTIMG       ) - offset (0x0000000000DE0000) - size (0x0000000000600000) - mask (0x0
    000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
    11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[9 ](RECOVERY      ) - offset (0x00000000013E0000) - size (0x0000000000600000) - mask (0x0
    000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
    11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[10](SEC_RO        ) - offset (0x00000000019E0000) - size (0x0000000000600000) - mask (0x0
    000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
    11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[11](__NODL_MISC   ) - offset (0x0000000001FE0000) - size (0x0000000000060000) - mask (0x0
    000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
    11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[12](LOGO          ) - offset (0x0000000002040000) - size (0x0000000000300000) - mask (0x0
    000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
    11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[13](__NODL_EXPDB  ) - offset (0x0000000002340000) - size (0x00000000000A0000) - mask (0x0
    000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
    11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[14](EBR2          ) - offset (0x00000000023E0000) - size (0x0000000000004000) - mask (0x0
    000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
    11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[15](FAC           ) - offset (0x00000000023E4000) - size (0x0000000010000000) - mask (0x0
    000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
    11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[16](ANDROID       ) - offset (0x00000000123E4000) - size (0x0000000020100000) - mask (0x0
    000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
    11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[17](CACHE         ) - offset (0x00000000324E4000) - size (0x0000000020100000) - mask (0x0
    000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
    11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[18](USRDATA       ) - offset (0x00000000525E4000) - size (0x0000000020100000) - mask (0x0
    000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
    11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[19](FAT           ) - offset (0x00000000726E4000) - size (0x0000000000000000) - mask (0x0
    000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
    Make sure you aren't looking at a dump of your scatter, but looking at the partition dump from your device. (If it contains DEADBEEF flag from above, you are looking at the wrong part of the log.) You can manually create a scatter file from that, or you can paste the lines with partition info into a text file and run this shell script:

    Code:
    cat pastedlog.txt | sed -n 's/.*](\([^ ]*\)[^(]*(\([^)]*\).*)/\1 \2\n{\n}/p' | sed 's/x00000000/x/g' > mynewscatter.txt

    This will get you really close, but the last entry you see in a typical scatter file is BMTPOOL. I don't know much about BMTPOOL or __NODL_BMPPOOL other than it's not a real partition. It might not even be required? (You might be able to fake that entry if you look at similar scatter files. If not, read on)

    Method #2
    An alternate and supplemental way of getting scatter info is to use ADB on a running device. I'm sure this is similar to MTK Droid Root & Tools method.

    Code:
    adb pull /proc/dumchar_info

    Now that you have that file local on your PC, you can run this python script:

    Code:
    import sys
    import string
    import re
    
    ins = open( "dumchar.txt", "rb" )
    outs = open( "scatter.txt", "wb" )
    for line in ins:
        linesp = re.split('\W+', line)
        name = linesp[0].upper()
        start = int(linesp[2],16)
        block = linesp[5]
        if block != 'misc':
            start = start + 0x600000
        outs.write(name + " " + string.replace(hex(start), "L", "") + "\n{\n}\n")
    ins.close()
    outs.close()

    This method gives you the BMTPOOL entry that the other method does not, but it lacks the __NODL_ designator for all partitions. If you aren't familiar with that prefix, SPFT uses that to know if it should typically allow you to DownLoad over the top of the paritition.

    With both scatter files, throw them side-by-side in a text editor (or diff tool) and with a brain, it's easy enough to merge one with the __NODL_ prefix and the one with the BMTPOOL entry.

    Scatter file complete!

    PS - Possibly another way, is to use SPFT to do a "Read back" (read memory) at 0x660000 of size 0x400000. Save this as the PMT block and analyse it with a hex editor. I believe the PMT block is always at address 0x66000 judging from a dozen different scatter files.

    Dump Full ROM
    Perfect Total Backup of your Firmware

    The safe way to do this with or without a proper scatter file is the "Read back" feature of SP Flash Tool. There are MANY reasons to dislike MediaTek, but this feature is so nice that I can forgive them for most of their wrong doing.

    Most of this section I will generalize from my Lenovo A2107A Guide.

    Here is a cookbook for doing a total backup of your MTK device with MediaTek's SP Flash Tool. No rooting, you might even do this before you ever boot! I have basically done this with both of my devices before I fiddled too much. I recommend doing it before you do anything really.

    1. Install VCOM Drivers.
    2. Install SP Flash Tool.
    3. Grab an SPFT ROM, really anything should work, you just have to make SP Flash Tool happy. SPFT validates the scatter file against some of the image files, so you have to calm SPFT down by giving it something it can make sense of. We won't use the scatter file or image files while we do the "Read back" operation.
    4. Run SP Flash Tool, Open Scatter File
    5. Don't play with anything, go into the "Read back" tab (This will read your flash to a file on your PC)
    6. Click on any items in the list, then click the "Remove" button
    7. Now click the "Add" button
    8. Double click on the "N/A" under Read Flag
    9. Type a file name to write to, like "WHOLE_ROM"
    10. Now it will popup a window "Readback block start address"
    11. Leave "Hex" selected, Start Address" 0x0000, Length: 0x40000000, Click OK (NOTE: this will get the first GIG of flash)
    12. Click the "Read back" button
    13. SPFT now waits for you to connect your device and put it in Meta Mode
    14. Without plugging your phone/tablet in, tap the Reset Button or make sure it's fully off
    15. Hold VolUp, plug in USB, Release VolUp (putting it in Meta Mode) <--- Important
    16. You will see the progress bar moving. Total backup takes forever, because in this mode SPFT seems to not do USB HIGHSPEED
    That's IT! It'll take a few hours, so go to bed.

    If you ever restore, just go into Recovery and Wipe Data and Cache. (as these are large and we probably didn't back them up above)

    Note: "Length" in Step 11 is probably long enough for most devices. You can reference the scatter file you made above to make sure get everything, but you don't need USRDATA or CACHE, as those get wiped anyway.


    Dicing up Full ROM image into partition images


    I've made a little bash shell script to dice up a whole ROM according to a scatter file. This creates files exactly the size of the partitions. Some post processing needs done below the script:

    dice.sh
    Code:
    #!/bin/bash
    
    scatterfile=$1
    rom=$2
    pdir=raw.partitions
    
    rm -rf $pdir
    mkdir $pdir
    
    cat $scatterfile | grep "x" | while read line; do
        name=$(echo $line | sed 's/ .*//g')
        name=$(echo $name | sed 's/^__NODL_//g')
        start=$(echo $line | sed 's/.* //g')
    #    echo $name
    
        if [[ -n $last_name ]]; then
    	echo "Processing: $last_name"
    	echo "     start: $last_start"
    	size=$(( $start - $last_start ))
    	if [[ $size -lt 0 ]]; then
    	    size=0xFFFFF000
    	else
    	    size=0x$(echo "obase=16; $size" | bc)
    	fi
    	echo "      size: $size"
    	short_start=$(echo $last_start | sed 's/000$//g')
    	short_size=$(echo $size | sed 's/000$//g')
    	echo dd if=$rom of=$pdir/$last_name bs=$(( 0x1000 )) \
    	    skip=$(( $short_start )) count=$(( $short_size ))
    	dd if=$rom of=$pdir/$last_name bs=$(( 0x1000 )) \
    	    skip=$(( $short_start )) count=$(( $short_size ))
        fi
    
        last_name=$name
        last_start=$start
    done

    Now there is some post processing done. Truncate MBR, EBR1, EBR2 to 512 bytes. And remove trailing bytes of 0000 or FFFF on the end of PRELOADER and DSP_BL.

    Here is a one off script for example use:

    clean.sh
    Code:
    #!/bin/bash
    
    pdir=raw.partitions
    odir=out
    
    rm -rf $odir
    mkdir $odir
    
    dd if=$pdir/PRELOADER of=$odir/preloader.bin bs=$(( 0x800 )) skip=1
    ./trim.sh $odir/preloader.bin
    ./trimFF.sh $odir/preloader.bin
    
    dd if=$pdir/DSP_BL of=$odir/DSP_BL bs=$(( 0x8000 )) count=1
    ./trimFF.sh $odir/DSP_BL
    
    dd if=$pdir/MBR of=$odir/MBR bs=512 count=1
    dd if=$pdir/EBR1 of=$odir/EBR1 bs=512 count=1
    dd if=$pdir/EBR2 of=$odir/EBR2 bs=512 count=1
    
    cp $pdir/UBOOT $odir/uboot.bin
    
    cp $pdir/LOGO $odir/logo.bin
    ./trim.sh $odir/logo.bin
    
    cp $pdir/SEC_RO $odir/secro.img
    
    cp $pdir/RECOVERY $odir/recovery.img
    
    cp $pdir/BOOTIMG $odir/boot.img
    
    cp $pdir/FAC $odir/fac.img
    
    cp $pdir/ANDROID $odir/system.img
    
    cp MT*.txt $odir/

    And quickly, Here is my hack to remove 0000 and FFFF from the end of files:

    trim.sh
    Code:
    #!/bin/bash
    truncate -s $(( 4 + $(cat $1 | hexdump -v -e '/4 "%_ad: " ' -e '4/1 "%02X" "\n"' \
     | grep -v ": 00000000" | tail -n 1 | sed 's/:.*//') )) $1
    trimFF.sh
    Code:
    #!/bin/bash
    truncate -s $(( 4 + $(cat $1 | hexdump -v -e '/4 "%_ad: " ' -e '4/1 "%02X" "\n"' \
     | grep -v ": FFFFFFFF" | tail -n 1 | sed 's/:.*//') )) $1

    You should be able to read the clean.sh script and figure out only in just those few cases, is special post processing needed. If you don't post process, SPFT will give errors.

    I hope this helps. If you have any questions, ask... I'll try to clarify this first post.
    6
    Hey, Syserr,
    this thread is great and it has given me great inspiration. as you may or may not know, the new mediatek SoC's do not have an easy way of extracting a scatter file. there is no dumchar_info file. i am sure your other methods would work to do it (via sp flash tool), but this is a pain if you want to do a simple backup. so i took your dice.sh script and re-wrote it work with a different file: /proc/partinfo. all phones should have this, as it is really a base part of linux. i cant see anyone disabling this in a kernel build. i think too much relies on it. anyway, if you want to check it out, it is attached. this is my method:

    pull the partinfo file:
    Code:
    adb shell cat /proc/partinfo>partinfo.txt
    dump the rom (without sp flash tool)
    Code:
    adb forward tcp:5555 tcp:5555
    adb shell su -c "nc -l -p $netcat_port -e dd if=/dev/block/mmcblk0" &
    nc 5555 127.0.0.1 |pv -i 0.5 >rom.img
    run the script
    Code:
    dice.sh partinfo.txt rom.img

    should run on both old and new mtk SoC's. more work to be done because it is dumping everything. and there is no scatter file... but i am working on all of that. just thought you might find it interesting.
    5
    New versions of the SP Flash (from 5.1548) also allow to dice the ROM directly during the Readback. You need to modify the line "ShowByScatter=false" in file option.ini to "ShowByScatter=true".
    The files will be dumped as ROM_0, ROM_1, ROM_2 etc.
    Also it might occur that "userdata" is not listed, in case you want to save an image you need to add it manually.
    4
    Script for newer MTK chipsets

    With the newer MTK chipsets the format of the scatter file is very different and I've made a shell script to work with those. Find it in the Alcatel Pixi thread.
    :)

    Edit: Be very careful with flashing back the extracted preloader...people have reported bricked phones by flashing the wrong preloader. The extracted preloader must be edited first. There are 0x800 bytes at the start that must be removed, and extra bytes at the end (either 0x00 or 0xFF) that should also be removed. See post#1 for ideas and scripts (clean, trim, and trimFF) on how to do this.
    2
    hi syserr,

    i m tryin to run the script dice.sh and this is the trace i get

    Code:
    [email protected] ~/TESTbcup $ sh -x ./dice.sh
    + 
    : not found2: ./dice.sh: 
    + scatterfile=
    + rom=
    + pdir=raw.partitions
    + 
    : not found6: ./dice.sh: 
    + rm -rf raw.partitions
    + mkdir raw.partitions
    + 
    : not found9: ./dice.sh: 
    ./dice.sh: 37: ./dice.sh: Syntax error: end of file unexpected (expecting "then")
    [email protected] ~/TESTbcup $

    any advice would be welcome. I dumb a complete rom and try to dice it.

    thank you syserr

    Sorry Sorry Sorry. It takes 2 arguments, I should do some error checking and make sure the user supplies them.

    Code:
    ./dice.sh scatterfile.txt FULLROM.img
    It might have some syntax that is specific to bash, so "sh" might throw errors too.