search

do1fmd / BV9900Pro-optimization

The Blackview BV9900 Pro is a very good phone regarding hardware specifications. Unfortunately the software has a lot of bugs. Here are instructions how to root your phone, get rid of Google Services and fix most bugs.
9 stars 3 forks source link

Restore of a sp flash backup does not work #3

Closed blobb999 closed 3 years ago

blobb999 commented 3 years ago

I did a custom backup with the "[ReadBack] ShowByScatter=true" option Because there was no scatter file created, i edited the delivered firmware scatter_file pointing to each ROM_x partition.

Unfortunately, a test restore (download) resulted in a loop with the option to try it again or do a factory reset. Any idea how to progress this correct?

Solved: The size of the /data Partition is 114036MB which equals to HEX = 0x1BD7400000 So change in the scatter file twice the SYS42 partition_size from 0xc0000000 (3GB) to 0x1BD7400000 (111GB) Example:

partition_index: SYS42
partition_name: userdata
file_name: ROM_42
is_download: true
type: EXT4_IMG
linear_start_addr: 0x160800000
physical_start_addr: 0x160800000
partition_size: 0x1BD7400000
region: EMMC_USER
storage: HW_STORAGE_EMMC
boundary_check: true
is_reserved: false
operation_type: UPDATE
is_upgradable: false
empty_boot_needed: false
reserve: 0x00
do1fmd commented 3 years ago

Hello,

usually you do not have to edit the scatter_file and SP Flash Tool does not create one for you. Just use the scatter_file for your ROM (included in the firmware) and open that one with SP Flash Tool.

blobb999 commented 3 years ago

I did this for doing the Backup itself. I have successful backed up 44 Partition from Rom_0 tilll Rom_42. To restore this Backup, the original scatter File is pointing to the original Firmware Files and would not restore the created backup with Rom_0 till Rom_44. How to progress a proper restore?

do1fmd commented 3 years ago

I put the scatter file in the same directory with the backed up partitions and renamed the backup-files themself. So I did not touch the scatter file.

Maybe your scatter file is wrong? The scatter file I used for my BV9900 Pro has an md5sum of 5c48e4b3ccadfe29c92d23e789175a55

blobb999 commented 3 years ago

Yes the scatter file is pointing correctly to each ROM. Checksums for the scatter files matter? this would be new for me. Without the checksum.ini, checksums for the partition files are ignored. The backup creates 42 Partition files, the restore List is restoring only 24 of them. In the readback you see, which partition points to which file, preloader to ROM_0, recovery to ROM_2, misc to ROM_3 and so on... Its much easier imo to change one time the scatter file for any new backup instead of changing the 24 files names for every new backup. It is restoring the backup, but the device hangs like i explained in the inital issue post.

blobb999 commented 3 years ago

############################################################################################################ #

General Setting

# ############################################################################################################

############################################################################################################ #

UFS Layout Setting

# ############################################################################################################

do1fmd commented 3 years ago

Yes the scatter file is pointing correctly to each ROM. Checksums for the scatter files matter? this would be new for me. Without the checksum.ini, checksums for the partition files are ignored. The backup creates 42 Partition files, the restore List is restoring only 24 of them. In the readback you see, which partition points to which file, preloader to ROM_0, recovery to ROM_2, misc to ROM_3 and so on... Its much easier imo to change one time the scatter file for any new backup instead of changing the 24 files names for every new backup. It is restoring the backup, but the device hangs like i explained in the inital issue post.

No, checksum does not matter. I just gave you the checksum to compare, if we both use the same scatter file. For me it was working without any issue. Is the device in bootloop or does the restore process hang? Did you chose "Download only" while restoring in SP flash tool?

blobb999 commented 3 years ago

No, the restore process worked just fine with "download only". I did even a Test restoring for every backed up partitions, except the "nvram" by enabling the "is_download: false" flag to true. Its not a classical bootloop, its a system restore option menu caused by the unreadable /data partition. i had done previous two backups. One configured as standard, second complete debloadet. Both backups showing after restoring the same results.

do1fmd commented 3 years ago

So the problem is the encrypted data partition, I guess. Sorry, never had this issue. I never had the need to recover my data partition, yet. Maybe you should open a thread at xda-developers.com. Sorry.

blobb999 commented 3 years ago

Done - https://forum.xda-developers.com/t/sp_flash-rom-backup-a-mt6779v-ce-device-tricks-errors.4355531/

blobb999 commented 3 years ago

I am still working on this issue.

As alternative way doing backups, i tried TWRP Somehow i got one time a working TWRP for the BV9900Pro ported and i can not repeat it. No idea how i did it. Unfortunately, i have not ported it with the mt6779 fstab, so it has no sd_card. see https://forum.hovatek.com/thread-40750-post-221082.html#pid221082 https://forum.hovatek.com/thread-21839-post-221060.html#pid221060 - with a working TWRP - link

blobb999 commented 3 years ago

i am still on it, I believe, i found the Problem..... see scatter file:

partition_index: SYS42 partition_name: userdata file_name: ROM_42 is_download: true type: EXT4_IMG linear_start_addr: 0x160800000 physical_start_addr: 0x160800000 partition_size: 0x1BD7400000 region: EMMC_USER storage: HW_STORAGE_EMMC boundary_check: true is_reserved: false operation_type: UPDATE is_upgradable: false empty_boot_needed: false reserve: 0x00

The "partition_size: 0xc0000000" are 3 Gigabytes, The partition /user has 111 Gigabytes which is in HEX "0x1BC0000000" Of course, a read back of 111 Gigabytes takes some time and space, with wwr MTK for example it can be trimmed.

The possible max size of a full dump from 0x0 - 0x1DC0000000 are 119 Gigabytes. According to a TWRP Backup-Log, the size of the /data Partition is 114036MB which equals to HEX = 0x1BD7400000 For the scatter File, it needs exactly this HEX to dump or restore the whole /data partition. A Dumb of this size takes about 50 Minutes with the Blackviewpro. Gona test, if its working.

Meanwhile first test shows, the restore works!

do1fmd commented 3 years ago

Thanks a lot for your work and sharing your progress. Please keep me/us up to date, if you could successfully backup and restore the data partition.

blobb999 commented 3 years ago

A second test shows, its working this way. It would be nice, if you update this in your Guide Taking the default scatter values does not make a proper and working backup from the userdata.

"Now connect the switched-off phone to PC while holding the Vol-Up button." Pressing the Volume Up is not necessary. Just Plug in the turned off phone after Readback or Download is activated.

Pressing VolumeUp & Power, release Power Key while keep pressing VolumeUp brings you in the selection Menu Recovery Fastboot Restart

do1fmd commented 3 years ago

Hi @f1cscari, I updated my Guide and added this section: https://github.com/do1fmd/BV9900Pro-optimization/#preparations-for-backing-up-the-data-partition

Please have a look, if everything is correct now.

Thanks a lot for your participation and tests.

blobb999 commented 3 years ago

Looking good, thx :) "This should be at line number 745 & 1523" and "only a few bytes will be saved and the recovered partition won't be readable." It does a normal factory reset, re-formating the /data partition.

Mention also the size it takes (111GB) & plus time ~50 Minutes.

Plus It does no matter this way, if the partition is encrypted or not

Minus If its encrypted, you can not trim this large file,

do1fmd commented 3 years ago

Changed the guide accordingly: https://github.com/do1fmd/BV9900Pro-optimization/#preparations-for-backing-up-the-data-partition

blobb999 commented 3 years ago

Perfect! Another very important hint is missed in your Bugfixes Guide https://forum.xda-developers.com/t/req-blackview-bv9900-pro-root-recovery.4097681/post-85357409

If you don't want to use the Magisk feature mentioned there, you can try to edit build.prop directly.
ro.freeme_freemanager and ro.hct_autostart_manager must be set to 0.

This was the only working solution which got my default apps autostarting. i had several other auto start apps tested, nothing worked except your advice in the XDA Forum :) Thank you for this....

do1fmd commented 3 years ago

Perfect! Another very important hint is missed in your Bugfixes Guide https://forum.xda-developers.com/t/req-blackview-bv9900-pro-root-recovery.4097681/post-85357409

If you don't want to use the Magisk feature mentioned there, you can try to edit build.prop directly.
ro.freeme_freemanager and ro.hct_autostart_manager must be set to 0.

This was the only working solution which got my default apps autostarting. i had several other auto start apps tested, nothing worked except your advice in the XDA Forum :) Thank you for this....

That one is already described here: https://github.com/do1fmd/BV9900Pro-optimization/blob/main/bugfixes.md#apps-and-widgets-do-not-start-after-boot-magisk-or-at-least-root-needed