[Android Q&A, Help & Troubleshooting] uengin:
Hi All,

I, too, am seeking to generate a scatter file for my device, while this post was helpful, I've got some questions, if some of the senior developers could answer, or anyone with the answers for that matter, I'd really appreciate it.

So, I have a mediatek device, with an MT6750 chip, namely a Maze Comet. It freezes at the product logo and does not proceed to the product logo animation. This happened because I issued the command "fastboot oem unlock". Issuing the command "fastboot oem lock" did not restore it, thereafter this is what I've done:

- Connect up the phone to computer

- insert SDCard to phone

- Launch phone in to fastboot

- issue the command

fastboot oem unlock

- issue the command

fastboot boot /path/to/TWRP/recovery/environment/image.img

- in TWRP, in the terminal I have used dd to write the boot, system and recovery partition to the SDCard as boot.img, system.img, and recovery.img, respectively. The extracted information from the TWRP terminal is as follows....:

major minor #blocks name

179 0 61071360 mmcblk0
179 1 16384 mmcblk0p1
179 2 512 mmcblk0p2
179 3 10240 mmcblk0p3
179 4 1024 mmcblk0p4
179 5 32768 mmcblk0p5
179 6 32768 mmcblk0p6
179 7 8192 mmcblk0p7
179 8 12768 mmcblk0p8
179 9 8192 mmcblk0p9
179 10 8192 mmcblk0p10
179 11 3072 mmcblk0p11
179 12 24576 mmcblk0p12
179 13 4096 mmcblk0p13
179 14 3072 mmcblk0p14
179 15 5120 mmcblk0p15
179 16 5120 mmcblk0p16
179 17 1024 mmcblk0p17
179 18 1024 mmcblk0p18
179 19 16384 mmcblk0p19
179 20 8192 mmcblk0p20
179 21 5120 mmcblk0p21
179 22 5120 mmcblk0p22
179 23 6144 mmcblk0p23
179 24 10240 mmcblk0p24
179 25 2621440 mmcblk0p25
179 26 442368 mmcblk0p26
179 27 57761775 mmcblk0p27
179 28 16384 mmcblk0p28
179 96 4096 mmcblk0rpmb
179 64 4096 mmcblk0boot1
179 32 4096 mmcblk0boot0
179 128 7761920 mmcblk1
179 129 7759872 mmcblk1p1

And...:

lrwxrwxrwx 1 root root 21 Dec 31 18:34 boot -> /dev/block/mmcblk0p19
lrwxrwxrwx 1 root root 21 Dec 31 18:34 cache -> /dev/block/mmcblk0p26
lrwxrwxrwx 1 root root 20 Dec 31 18:34 expdb -> /dev/block/mmcblk0p3
lrwxrwxrwx 1 root root 21 Dec 31 18:34 flashinfo -> /dev/block/mmcblk0p28
lrwxrwxrwx 1 root root 20 Dec 31 18:34 frp -> /dev/block/mmcblk0p4
lrwxrwxrwx 1 root root 21 Dec 31 18:34 keystore -> /dev/block/mmcblk0p24
lrwxrwxrwx 1 root root 21 Dec 31 18:34 lk -> /dev/block/mmcblk0p17
lrwxrwxrwx 1 root root 21 Dec 31 18:34 lk2 -> /dev/block/mmcblk0p18
lrwxrwxrwx 1 root root 21 Dec 31 18:34 logo -> /dev/block/mmcblk0p20
lrwxrwxrwx 1 root root 21 Dec 31 18:34 md1arm7 -> /dev/block/mmcblk0p14
lrwxrwxrwx 1 root root 21 Dec 31 18:34 md1dsp -> /dev/block/mmcblk0p13
lrwxrwxrwx 1 root root 21 Dec 31 18:34 md1img -> /dev/block/mmcblk0p12
lrwxrwxrwx 1 root root 21 Dec 31 18:34 md3img -> /dev/block/mmcblk0p15
lrwxrwxrwx 1 root root 20 Dec 31 18:34 metadata -> /dev/block/mmcblk0p6
lrwxrwxrwx 1 root root 20 Dec 31 18:34 nvdata -> /dev/block/mmcblk0p5
lrwxrwxrwx 1 root root 21 Dec 31 18:34 nvram -> /dev/block/mmcblk0p16
lrwxrwxrwx 1 root root 21 Dec 31 18:34 oemkeystore -> /dev/block/mmcblk0p10
lrwxrwxrwx 1 root root 20 Dec 31 18:34 para -> /dev/block/mmcblk0p2
lrwxrwxrwx 1 root root 21 Dec 31 18:34 proinfo -> /dev/block/mmcblk0p11
lrwxrwxrwx 1 root root 20 Dec 31 18:34 protect1 -> /dev/block/mmcblk0p7
lrwxrwxrwx 1 root root 20 Dec 31 18:34 protect2 -> /dev/block/mmcblk0p8
lrwxrwxrwx 1 root root 20 Dec 31 18:34 recovery -> /dev/block/mmcblk0p1
lrwxrwxrwx 1 root root 20 Dec 31 18:34 seccfg -> /dev/block/mmcblk0p9
lrwxrwxrwx 1 root root 21 Dec 31 18:34 secro -> /dev/block/mmcblk0p23
lrwxrwxrwx 1 root root 21 Dec 31 18:34 system -> /dev/block/mmcblk0p25
lrwxrwxrwx 1 root root 21 Dec 31 18:34 tee1 -> /dev/block/mmcblk0p21
lrwxrwxrwx 1 root root 21 Dec 31 18:34 tee2 -> /dev/block/mmcblk0p22
lrwxrwxrwx 1 root root 21 Dec 31 18:34 userdata -> /dev/block/mmcblk0p27

And...:

Found valid GPT with protective MBR; using GPT

Disk /dev/block/mmcblk0: 122142720 sectors, 2296M
Logical sector size: 512
Disk identifier (GUID): 00000000-0000-0000-0000-000000000000
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 122142686

Number Start (sector) End (sector) Size Code Name
1 64 32831 16.0M 0700 recovery
2 32832 33855 512K 0700 para
3 33856 54335 10.0M 0700 expdb
4 54336 56383 1024K 0700 frp
5 56384 121919 32.0M 0700 nvdata
6 121920 187455 32.0M 0700 metadata
7 187456 203839 8192K 0700 protect1
8 203840 229375 12.4M 0700 protect2
9 229376 245759 8192K 0700 seccfg
10 245760 262143 8192K 0700 oemkeystore
11 262144 268287 3072K 0700 proinfo
12 268288 317439 24.0M 0700 md1img
13 317440 325631 4096K 0700 md1dsp
14 325632 331775 3072K 0700 md1arm7
15 331776 342015 5120K 0700 md3img
16 342016 352255 5120K 0700 nvram
17 352256 354303 1024K 0700 lk
18 354304 356351 1024K 0700 lk2
19 356352 389119 16.0M 0700 boot
20 389120 405503 8192K 0700 logo
21 405504 415743 5120K 0700 tee1
22 415744 425983 5120K 0700 tee2
23 425984 438271 6144K 0700 secro
24 438272 458751 10.0M 0700 keystore
25 458752 5701631 2560M 0700 system
26 5701632 6586367 432M 0700 cache
27 6586368 122109918 55.0G 0700 userdata
28 122109919 122142686 16.0M 0700 flashinfo

I believe the latter most set of data being the most useful, below are the objectives:

1. Create a set of partition images from a working phone before any modifications are made.

2. Build a scatter file so that these "original" images can be flashed back with tools like SP Flash tool or similar.

3. Now that the phone refuses to boot because of the "fastboot oem unlock" command, use the recovered images with an MTK flash tool in hope that the flash tool restores the register that was disturbed by they "unlock" command.

Questions:

- With the above said, can anyone provide a scatter file for any MTK device, MT6750 would be highly appreciated, to get an idea of the formatting and data content of the scatter file?

- Also, the scatter file I'm sure, has hex storage addresses from a very low level hardware interface addressing scheme, so none of this logical addressing business. Therefore, the sector based addresses above from the linux terminal, is this any good if it were to be converted to hex addresses based on the number of bytes a sector may be, would this somehow end up with some sort of offsets that may brick the device? Another way of asking this might be, is there a conversion method we could utilise to convert sector addresses in to hex memory addresses?

Short of the above, I am tempted to buy a flash programmer, desolder the flash off the phone, dump the contents and start analysing it in the hex editor to find the start addresses of these partitions... However, money hates me, money does not come anywhere near me, so, tempted as I am, I'm unable to do this.

Look forward to your guidance. Thank you.