Author Topic: gdisk2scatter.py - A python program to generate a scatter file from gdisk -l  (Read 98 times)

TauPan

  • Newbie
  • *
  • Posts: 38
    • View Profile
    • http://
Hi!

The attached file  [ You are not allowed to view attachments ]  will convert the output of gdisk -l (which you can get in termux via `tsu; gdisk -l /dev/block/mmcblk0` into a scatter file which can be used in SP Flashtool for MTK based chipsets (Planet Computers devices).

It comes with absolutely no warranty of any kind.

There are some partitions which are not listed in gdisk -l which I copied verbatim from my Cosmo Communicator.

I'd be interested how this compares with a known good scatter file, e.g. as generated by the scatter file generator for the Gemini PDA.

My intended usage is to use this to take a complete dump of my Cosmo and restore it on a spare device,  however you'd be mad to attempt this with a different device without thoroughly checking the file and actually knowing what you're doing. (If you're lucky, SP flashtool might refuse to flash the data.)

It's not my fault if you brick your device.

All partitions are marked as "is_download: true" so you can dump them, but that doesn't mean that they should be flashed ("Download tab").

I'd be interested in your feedback.

P.S.: I forgot: It works like your regular unix command... If you don't give any arguments, it reads from stdin and writes to stdout, otherwise the first argument is the file to be read and the second will be the file to write (which will be truncated).

Edit: I got the terminology wrong, read back pulls the data from the device and "Download" means to flash. More in my reply.
« Last Edit: July 17, 2021, 04:59:24 am by TauPan »

TauPan

  • Newbie
  • *
  • Posts: 38
    • View Profile
    • http://
Ok, now I've tried to read back the data from my beat up Cosmo and trying to flash it to the spare device turned up a couple of bugs:

 - The preloader length is too short. I took that from the wrong example scatter file. It must be doubled. After flashing that, I got a recoverable brick. Recoverable by reading back the preloader with the correct length and flashing that.
 - The order of partitions is wrong. SP Flash tool orders them by start address, and the tool uses the order of partitions in the GPT partition table. This is relevant because after read back, you will end up with a bunch of files called ROM_0, ROM_1... the numbers will not match the partition index in the scatter file but the order of start addresses.
- the  preloader file name suggests a certain version number, but there are clearly some very different preloader versions around and I don't know how to figure out the version. Maybe with a hexdump...
- The otp and flashinfo can't be flashed the way they are dumped, SP Flashtool complains they are incorrect. Maybe the length is too short here as well. I also don't know what purpose they serve and if they should be flashed at all.
- sgpt will not be read back from the scatter file, SP Flashtool ignores it.

In order to use the scatter file for reading back, a value in options.ini needs to be changed, read back from scatter true or something. (Need to recheck once my laptop is available again, as it's currently busy trying to flash the spare device.)

And of course flashing is only possible with an unlocked bootloader.

I'll possibly continue with a post in the Cosmo forum about how to do a complete backup for restoring on a different device, if I am successful (currently flashing my userdata, which takes quite a while with a 128G dumpfile)...