Database Users

U8800 partition scheme.

In case this info is of use to someone...
Trying to understand what goes where,
Here is the partition table of a U8800:
#######################################
Disk /dev/sdb: 3959 MB, 3959422976 bytes
1 heads, 62 sectors/track, 124729 cylinders, total 7733248 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdb1 1 491520 245760 b W95 FAT32
/dev/sdb2 * 491521 492520 500 4d QNX4.x
/dev/sdb3 492521 498520 3000 46 Unknown
/dev/sdb4 498521 7733247 3617363+ 5 Extended
/dev/sdb5 524288 548863 12288 59 Unknown
/dev/sdb6 655360 921599 133120 4c Unknown
/dev/sdb7 1048576 1049575 500 5a Unknown
/dev/sdb8 1179648 1185791 3072 58 Unknown
/dev/sdb9 1310720 1324719 7000 50 OnTrack DM
/dev/sdb10 1441792 1447935 3072 4a Unknown
/dev/sdb11 1572864 1579007 3072 4b Unknown
/dev/sdb12 1703936 2154495 225280 83 Linux
/dev/sdb13 2228224 3457023 614400 83 Linux
/dev/sdb14 3538944 7733247 2097152 69 Unknown
#############################################
sdb1: This is the FAT32 partition that gets mounted when we boot into pink screen;
It holds, among other files, EMMCBOOT.MBN, which, if not present and as far as I've experimented, will get the phone straight into a blue screen and initiate a flash procedure if a 'dload' folder with a ROM is found in the sdcard. The contens of this partition are changed when a ROM is flashed.
sdb2: Is flagged as bootable, and holds an (so far) unknown filesystem (if any; could hold a raw binary image, for instance);
sdb3: Holds an unknown filesystem, if any. This partition is changed whenever you flash a ROM. dumping this partition back, from any 2.3BETA, to a 2.3 (B522) running phone, will get the USB pink screen mode working again, allowing acces to sdb1.
sdb5: holds an unknown filesystem if any; dumping this one back gets us the original "IDEOS" logo and, probably, whatever is needed to make previous CWM backups work again.
sdb6: ext3 filesystem with a directory called "recovery".
sdb7: Unknown filessytem, if any.
sdb8: Unknown filesystem, if any.
sdb9: Unknown filesystem, if any.
sdb10: Unknown filesystem, if any.
sdb11: Unknown filesystem, if any.
sdb12: ext3 filesystem; gets mounted at "/system".
sdb13: ext3 filesystem; gets mounted at "/data".
sdb14: vfat filesystem; represents the internal sdcard.
I'm trying to find out what needs to be restored in order to perform a clean, reliable downgrade. sdb5 is a must, but not the only one. I've flashed 2.2 and dumped it back right after. The result is an almost downgraded U8800. I say almost because charging the battery while the phone is off shows a different image (the one that comes with 2.3) and I can't power up the phone unless I take the cable out; this means there are still remnants of 2.3 somewhere...
UPDATE: Not being able to power up the phone was to due to the CWM recovery; restoring original recovery.img solved that one.

[Q] U8800 Pro bricked

Here is the long version.
My phone a U8800 Pro was running the official B928 version downloaded from Huawei
I wanted to install the latest version Cyanogen 11. That needed me to install the latest version of TWRP which led me to the mistake that I needed to update the bootloader as well.
And then I did another mistake where I installed what is obviously the wrong bootloader from here (http://forum.xda-developers.com/showthread.php?t=1800045) using
Code:
dd if=/tmp/bootloader.bin of=/dev/block/mmcblk0p3
The phone since then just boot cycles continously and cannot even login to recovery mode.
I attempted to re-install B928 from the SD card but always fails at about 1/4 of the way through with a
Code:
dload_sd_ram_data_proc->(retry >= DLOAD_RETRY) failed!
msg.
Now interestingly if I remove the battery and just use the USB I get an empty pink screen and I can see at least the partitions of the internal drive
Code:
Disk /dev/sdg: 3.7 GiB, 3959422976 bytes, 7733248 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdg1 1 524287 262143+ c W95 FAT32 (LBA)
/dev/sdg2 * 524288 525287 500 4d QNX4.x
/dev/sdg3 525288 531287 3000 46 Unknown
/dev/sdg4 531288 7733247 3600980 5 Extended
/dev/sdg5 655360 679935 12288 59 Unknown
/dev/sdg6 786432 1052671 133120 4c Unknown
/dev/sdg7 1179648 1183743 2048 5a Unknown
/dev/sdg8 1310720 1316863 3072 58 Unknown
/dev/sdg9 1441792 1455791 7000 50 OnTrack DM
/dev/sdg10 1572864 1579007 3072 4a Unknown
/dev/sdg11 1703936 1710079 3072 4b Unknown
/dev/sdg12 1835008 2621439 393216 83 Linux
/dev/sdg13 2621440 4456447 917504 83 Linux
/dev/sdg14 4456448 7733247 1638400 69 Unknown
and can mount some of them.
Now where can I find an appropriate bootloader and which partition should I attempt to copy it on .
And secondly if that works out, how do I install TWRP 2.8.0.0 . Using TWRP manager fails which led to this whole mess really.
On /dev/sdg1 I can see a dir called image and it contains
Code:
amss.mbn boot.img cust.img EMMCBOOT.MBN recovery.img
but don't want to touch anything before I know more since I can do more dmg.
Thanks for all the help in advance
Edit: I managed to copy the bootloader from a friend and copy it back on my phone so that problem was solved. It needed to go to the /dev/sdg3 partition if anyone is wandering. Now pink screen seems locked and can't access the internal storage through USB so back to square 1.

Glad you got the problem solved out. When you unlock your bootloader (like I said in here), boot your phone to pink screen and plug it to your computer. You're using linux? If so, there probably is going to be four difference device's to be shown, the one which you're interested is the device containing "image" folder, in there replace the recovery.img with appropriate one.

[Q&A] [GUIDE][K920] Unlock bootloader on Lenovo VIBE Z2 Pro

Q&A for [GUIDE][K920] Unlock bootloader on Lenovo VIBE Z2 Pro
Some developers prefer that questions remain separate from their main development thread to help keep things organized. Placing your question within this thread will increase its chances of being answered by a member of the community or by the developer.
Before posting, please use the forum search and read through the discussion thread for [GUIDE][K920] Unlock bootloader on Lenovo VIBE Z2 Pro. If you can't find an answer, post it here, being sure to give as much information as possible (firmware version, steps to reproduce, logcat if available) so that you can get help.
Thanks for understanding and for helping to keep XDA neat and tidy!

Great guide, Electry.
I just used the QFil to unbrick my phone.
My phone hung at the bootup logo after the latest update. I think it was because I didn't unroot before update.
Nice to see some development on this great phone.

Tried to unlock bootloader but its not success
Hi supporter!
I tried to unlock bootloader my K920 China mobile version (OTA to 5.0.2, vibeUI2.5)
but i can't dial *#*#8899#*#* because it not appear pop-up dialog
I was setup driver, but Device Manager is not have the "Modem" to show "Lenovo HS-USB modem phone", the "Port" is not show "Lenovo HS-USB Diagnostics" and "Lenovo HS-USB NMEA" too.
pls help!
Thanks!
ps. sorry about my English

buidinhhai said:
Hi supporter!
I tried to unlock bootloader my K920 China mobile version (OTA to 5.0.2, vibeUI2.5)
but i can't dial *#*#8899#*#* because it not appear pop-up dialog
I was setup driver, but Device Manager is not have the "Modem" to show "Lenovo HS-USB modem phone", the "Port" is not show "Lenovo HS-USB Diagnostics" and "Lenovo HS-USB NMEA" too.
pls help!
Thanks!
ps. sorry about my English
Click to expand...
Click to collapse
You could try skipping step 8. and 9. in "Preparation" section, as I'm not sure if enabling diagnostic mode is really needed. Simply continue with the guide and let me know how it worked

I don't know unlocked BL or not
Electry said:
You could try skipping step 8. and 9. in "Preparation" section, as I'm not sure if enabling diagnostic mode is really needed. Simply continue with the guide and let me know how it worked
Click to expand...
Click to collapse
I press volume- and plug in the cable, the Device Manager show all port such as the upon post. But when i tried to flash , the QFil show this :
Start Download
COM Port number:6
Switch To EDL
Download Fail:Switch To EDL FailSystem.Exception: Fail to find QDLoader port after switch
в QFIL.Tech.DownloadTech.GetPortAfterReset(String description, Int32 timeoutInSec)
в QFIL.Tech.DownloadTech.SwitchToEDL()
Finish Download
Then i've tried to unlock
(press volume + and plug in the cable to see Qualcomm HS-USB QDloader 9008)
the QFil show this :
Process Index:0
Programmer Path:C:\VibeZ2Pro_UnLock_BootLoader_L\prog_emmc_firehose_8974.mbn
Image Search Path:C:\VibeZ2Pro_UnLock_BootLoader_L
Please select the XML file
Start Download
Program Path:C:\VibeZ2Pro_UnLock_BootLoader_L\prog_emmc_firehose_8974.mbn
COM Port number:3
Sahara Connecting ...
Sahara Version:2
Start Sending Programmer
Sending Programmer Finished
Switch To FireHose
Max Payload Size to Target:49152 Bytes
Device Type:eMMC
Platform:8x26
Disable Ack Raw Data Every N Packets
Ack Raw Data:False
Skip Write:False
Always Validate:False
Use Verbose:False
COM Port number:3
Sending NOP
FireHose NOP sent successfully
Sending Configuration
Device Type:eMMC
Platform:8x26
Request payload size 0xc000 is not the same as support payload size, change to 0x20000
Set TxBuffer 0x20000, RxBuffer 0x4000
Firehose configure packet sent successfully!
Total Bytes To Program 0xB1EA0
Download Image
PROGRAM: Partition 0, Sector: 0, Length: 33 Sectors, Sector Size: 512 Bytes
File: C:\VibeZ2Pro_UnLock_BootLoader_L\gpt_backup0.bin
PROGRAM: Written Bytes 0x4200 (64)
Program Size: 0.02 MB
PROGRAM: Partition 0, Sector: 0, Length: 34 Sectors, Sector Size: 512 Bytes
File: C:\VibeZ2Pro_UnLock_BootLoader_L\gpt_main0.bin
PROGRAM: Written Bytes 0x4400 (64)
Program Size: 0.02 MB
PROGRAM: Replace the partition sectors number 0x1000 to file size in sector 0x54c
PROGRAM: Partition 0, Sector: 264232, Length: 1356 Sectors, Sector Size: 512 Bytes
File: C:\VibeZ2Pro_UnLock_BootLoader_L\emmc_appsboot.mbn
PROGRAM: Written Bytes 0xa9800 (64)
Program Size: 0.66 MB
Total Size: 0.69 MB
Total Size: 0 Seconds
PATCH: Partition 0, Sector: 7, Offset 168 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-34.
PATCH: Partition 0, Sector: 0, Offset 168 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-34.
PATCH: Partition 0, Sector: 1, Offset 48 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-34.
PATCH: Partition 0, Sector: 0, Offset 48 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-34.
PATCH: Partition 0, Sector: 1, Offset 32 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-1.
PATCH: Partition 0, Sector: 0, Offset 24 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-1.
PATCH: Partition 0, Sector: 0, Offset 72 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-33.
PATCH: Partition 0, Sector: 1, Offset 88 Bytes, Size: 4 Bytes, Value: CRC32(2,3072)
PATCH: Partition 0, Sector: 0, Offset 88 Bytes, Size: 4 Bytes, Value: CRC32(NUM_DISK_SECTORS-33.,3072)
PATCH: Partition 0, Sector: 1, Offset 16 Bytes, Size: 4 Bytes, Value: 0
PATCH: Partition 0, Sector: 1, Offset 16 Bytes, Size: 4 Bytes, Value: CRC32(1,92)
PATCH: Partition 0, Sector: 0, Offset 16 Bytes, Size: 4 Bytes, Value: 0
PATCH: Partition 0, Sector: 0, Offset 16 Bytes, Size: 4 Bytes, Value: CRC32(NUM_DISK_SECTORS-1.,92)
Total download file size: 0,6948242MB
Throughput: 0M/s
Reset Phone
Waiting for reset done...
Let me know was i unlocked bootloader ?
is there the code or other method to test the Lenovo-phone's status of the bootloader?

buidinhhai said:
Let me know was i unlocked bootloader ?
is there the code or other method to test the Lenovo-phone's status of the bootloader?
Click to expand...
Click to collapse
It looks like you did it
If you have Lollipop, you can check it by doing "One-Time boot" into TWRP recovery. It should boot without an error.
Guide here: http://forum.xda-developers.com/android/development/recovery-twrp-2-8-6-1-sevenmaxs-t3086999

thanks to Electry
Electry said:
It looks like you did it
If you have Lollipop, you can check it by doing "One-Time boot" into TWRP recovery. It should boot without an error.
Guide here: http://forum.xda-developers.com/android/development/recovery-twrp-2-8-6-1-sevenmaxs-t3086999
Click to expand...
Click to collapse
Finally, i unlocked bootloader and up rom 4.4.2. Now, my phone has google service and my language - Vietnamese.
Thanks for your help, @Electry.

I have the same message, but my problem is that, That I have problem with OS. They not loaded. Telephone booting until logo, vibration and rebooting.
Was lolipop 5.0.2 untill it. Errors the same
PATCH: Partition 0, Sector: 7, Offset 296 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-34.
PATCH: Partition 0, Sector: 0, Offset 296 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-34.
PATCH: Partition 0, Sector: 1, Offset 48 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-34.
PATCH: Partition 0, Sector: 0, Offset 48 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-34.
PATCH: Partition 0, Sector: 1, Offset 32 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-1.
PATCH: Partition 0, Sector: 0, Offset 24 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-1.
PATCH: Partition 0, Sector: 0, Offset 72 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-33.
PATCH: Partition 0, Sector: 1, Offset 88 Bytes, Size: 4 Bytes, Value: CRC32(2,3072)
PATCH: Partition 0, Sector: 0, Offset 88 Bytes, Size: 4 Bytes, Value: CRC32(NUM_DISK_SECTORS-33.,3072)
PATCH: Partition 0, Sector: 1, Offset 16 Bytes, Size: 4 Bytes, Value: 0
PATCH: Partition 0, Sector: 1, Offset 16 Bytes, Size: 4 Bytes, Value: CRC32(1,92)
PATCH: Partition 0, Sector: 0, Offset 16 Bytes, Size: 4 Bytes, Value: 0
PATCH: Partition 0, Sector: 0, Offset 16 Bytes, Size: 4 Bytes, Value: CRC32(NUM_DISK_SECTORS-1.,92)
Total download file size: 2051,244MB
Throughput: 15,

Great giude friend

Hello to everybody !!
Also my Lenovo S856 is bricked. This happened because the recovery did not allow to make mods (backup, restore ..) but only wipes, and I thought it depended on the locked bootloader. At that point, I used the app EzUnlock and yet the phone is bricked, it does not turn on, no recovery, no sign of life, and it is seen as Qualcomm HS-USB Dignostics 9006 (COM3).
My seller sent me a rom to make the flash with MiFlash but the process crashes after 4 seconds. I also tried the QFIL tools and even then the process crashes with the message "Download Fail: Switch To FailFireHose Fail.
Any suggestions ?
Thanks for help

Electry said:
You could try skipping step 8. and 9. in "Preparation" section, as I'm not sure if enabling diagnostic mode is really needed. Simply continue with the guide and let me know how it worked
Click to expand...
Click to collapse
Am stuck in an error
Reset Phone
Waiting for reset done...
Download Fail:FireHose Fail Fail to find QDLoader port after switch
Finish Download
then phone boots in normal mode. Please help.
Supersu needs binary update and i also cant update it. Plz Help

Hello,
Everytime I try this method I am getting the below error
Process Index:0
Programmer Path:C:\Users\user\Downloads\UnlockBootloader_LP_ROW\UnlockBootloader_LP_ROW\prog_emmc_firehose_8974.mbn
Image Search Path:C:\Users\user\Downloads\UnlockBootloader_LP_ROW\UnlockBootloader_LP_ROW
Please select the XML file
Start Download
COM Port number:7
Switch To EDL
Download Fail:System.Exception: Failed to Switch to Emergency Download mode
at QC.QMSLPhone.Phone.QPHONEMS_SwitchToEDL()
at QC.SwDownloadDLL.SwDownload.SwitchToEDL()
Download Fail:Switch To EDL FailSystem.Exception: FireHose Fail
at QC.SwDownloadDLL.SwDownload.SwitchToEDL()
at QFIL.Tech.DownloadTech.SwitchToEDL()
Finish Download
Please let me know what can be done.
Note : I am on Lenovo Vibe z2 Pro Stock rom build S288[rooted]

Issue resolved.. Thank you

Any idea how to unlock bootloader of lenovo vibe P1 with mm6.0.1
Sent from my Lenovo P1a42 using XDA-Developers mobile app

buidinhhai said:
I press volume- and plug in the cable, the Device Manager show all port such as the upon post. But when i tried to flash , the QFil show this :
Start Download
COM Port number:6
Switch To EDL
Download Fail:Switch To EDL FailSystem.Exception: Fail to find QDLoader port after switch
в QFIL.Tech.DownloadTech.GetPortAfterReset(String description, Int32 timeoutInSec)
в QFIL.Tech.DownloadTech.SwitchToEDL()
Finish Download
Then i've tried to unlock
(press volume + and plug in the cable to see Qualcomm HS-USB QDloader 9008)
the QFil show this :
Process Index:0
Programmer Path:C:\VibeZ2Pro_UnLock_BootLoader_L\prog_emmc_firehose_8974.mbn
Image Search Path:C:\VibeZ2Pro_UnLock_BootLoader_L
Please select the XML file
Start Download
Program Path:C:\VibeZ2Pro_UnLock_BootLoader_L\prog_emmc_firehose_8974.mbn
COM Port number:3
Sahara Connecting ...
Sahara Version:2
Start Sending Programmer
Sending Programmer Finished
Switch To FireHose
Max Payload Size to Target:49152 Bytes
Device Type:eMMC
Platform:8x26
Disable Ack Raw Data Every N Packets
Ack Raw Data:False
Skip Write:False
Always Validate:False
Use Verbose:False
COM Port number:3
Sending NOP
FireHose NOP sent successfully
Sending Configuration
Device Type:eMMC
Platform:8x26
Request payload size 0xc000 is not the same as support payload size, change to 0x20000
Set TxBuffer 0x20000, RxBuffer 0x4000
Firehose configure packet sent successfully!
Total Bytes To Program 0xB1EA0
Download Image
PROGRAM: Partition 0, Sector: 0, Length: 33 Sectors, Sector Size: 512 Bytes
File: C:\VibeZ2Pro_UnLock_BootLoader_L\gpt_backup0.bin
PROGRAM: Written Bytes 0x4200 (64)
Program Size: 0.02 MB
PROGRAM: Partition 0, Sector: 0, Length: 34 Sectors, Sector Size: 512 Bytes
File: C:\VibeZ2Pro_UnLock_BootLoader_L\gpt_main0.bin
PROGRAM: Written Bytes 0x4400 (64)
Program Size: 0.02 MB
PROGRAM: Replace the partition sectors number 0x1000 to file size in sector 0x54c
PROGRAM: Partition 0, Sector: 264232, Length: 1356 Sectors, Sector Size: 512 Bytes
File: C:\VibeZ2Pro_UnLock_BootLoader_L\emmc_appsboot.mbn
PROGRAM: Written Bytes 0xa9800 (64)
Program Size: 0.66 MB
Total Size: 0.69 MB
Total Size: 0 Seconds
PATCH: Partition 0, Sector: 7, Offset 168 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-34.
PATCH: Partition 0, Sector: 0, Offset 168 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-34.
PATCH: Partition 0, Sector: 1, Offset 48 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-34.
PATCH: Partition 0, Sector: 0, Offset 48 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-34.
PATCH: Partition 0, Sector: 1, Offset 32 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-1.
PATCH: Partition 0, Sector: 0, Offset 24 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-1.
PATCH: Partition 0, Sector: 0, Offset 72 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-33.
PATCH: Partition 0, Sector: 1, Offset 88 Bytes, Size: 4 Bytes, Value: CRC32(2,3072)
PATCH: Partition 0, Sector: 0, Offset 88 Bytes, Size: 4 Bytes, Value: CRC32(NUM_DISK_SECTORS-33.,3072)
PATCH: Partition 0, Sector: 1, Offset 16 Bytes, Size: 4 Bytes, Value: 0
PATCH: Partition 0, Sector: 1, Offset 16 Bytes, Size: 4 Bytes, Value: CRC32(1,92)
PATCH: Partition 0, Sector: 0, Offset 16 Bytes, Size: 4 Bytes, Value: 0
PATCH: Partition 0, Sector: 0, Offset 16 Bytes, Size: 4 Bytes, Value: CRC32(NUM_DISK_SECTORS-1.,92)
Total download file size: 0,6948242MB
Throughput: 0M/s
Reset Phone
Waiting for reset done...
Let me know was i unlocked bootloader ?
is there the code or other method to test the Lenovo-phone's status of the bootloader?
Click to expand...
Click to collapse
Dear after that remove the cable & also remove the battery of phone . put any ota zip "Hungary2Default.ota" OR better "HongKong2Default.ota" in Sd Card & apply update from sd card option
this worked for me

adithebratt said:
Issue resolved.. Thank you
Click to expand...
Click to collapse
able to share how you resolved that?
i sort of unlocked bootloader (based on the comment from the earlier posts) but I failed to flash TWRP to the phone, always "waiting for device"

Issued resolved with another USB cable (my 3rd USB cable that I hardly use)

[GUIDE] UnBrick your OnePlus X on a Linux machine

DISCLAIMER: This guide describes procedures with tools that are designed to write directly to the storage of your device. This has the potential to lead to data loss or bricking your device. If you follow this guide carefully, none of these things should happen. That being said, you are still responsible for your own actions and how you handle the tools mentioned in this guide. Caution is advised.
When do i need this?​The following procedure can be used to get your device back into a booting state if all else fails. Usually you'd want to use this tool to get a working recovery running on your device and then go from there. If your bootloader is locked you can use this tool to flash the stock recovery again and unlock the bootloader as ususal.
If that is not sufficient, you can also reflash all of firmware, bootloader and stock recovery.
This guide is not needed if:​- The device still boots into stock recovery or TWRP
Flashing the official OxygenOS can fix many issues and you can unlock your bootloader as needed.
- The bootloader is unlocked. Use fastboot flash recovery <twrp image>
Check it with fastboot oem device-info
Use TWRP v3.0.2-0 with the OxygenOS 2 bootloader and the latest TWRP with the OxygenOS 3 bootloader.
- The ROM still boots and is rooted. Flash a stock recovery in a root shell:
adb root && adb shell
dd of=/dev/block/platform/msm_sdcc.1/by-name/recovery if=/sdcard/OxygenOS_recovery.img
OxygenOS 2 Lollipop recovery - OxygenOS 3 Marshmallow recovery
On custom ROMs, you can usually enable root access for ADB in developer settings, even if you didn't root them youself.
If any link is dead, search for it on https://web.archive.org
Spoiler: Verify downloaded files
The OxygenOS recovery links download from OnePlus's official amazon cloud storage. To verify, compare with the OxygenOS download link from the official page. OnePlus no longer links to these files and provides no checksums, you can use these to verify your download:
Code:
de38f20e72da38d48899f14d022cc1b1cd6bff0f4a506adb7bcf0153e73b1934 OPX_recovery.img
2810feb0d87686ea0529d8718600fdf3181cf0c93f0b9e29e5f13004af0e2d84 OPX_MM_recovery.img
e2fb0f0fef7d644cf3e6c1c0699381074fd4a83f64be319b75b9942443a95c90 OnePlusXOxygen_14_OTA_019_all_201611071506_03f73e21449d4d31.zip
fd58d703cf677dc5148ab5dd0f4af6c3df13faeb51166719e17aa192a86a6c0a OPX_UnBrick_Mini_By_Naman_Bhalla.zip
Don't continue unless you actually checked if your bootloader is still unlocked. Sometime it is re-locked on accident if some things go wrong.
Recovery and ROM only boot with a compatible bootloader. If you're not sure, try one then the other.
There are two major versions of the OnePlus X bootloader, one from OxygenOS 2 (Lollipop) and one from OxygenOS 3 (Marshmallow), released ca. September 2016, all newer ROMs should be compatible.
Trying to boot into a ROM or recovery that is incompatible with the installed bootloader will get you stuck on the bootlogo screen. On the OxygenOS 2 bootloader the "Powered by Android" part will disappear.
A locked OxygenOS 2 bootloader will boot any compatible software.
A locked OxygenOS 3 bootloader will only boot software signed by OnePlus. When trying to boot an unsigned ROM or recovery the device will vibrate, splash the bootlogo for a second and reboot, resulting in an endless loop.
If all else fails: Flashing through EDL​
You may know the legendary Mega Unbrick Guide for A Hard Bricked OnePlus X by Naman Bhalla but it only works on Windows.
It uses EDL, a hidden Qualcomm interface that allows direct read/write access to the devices flash storage to restore firmware, bootloader and stock recovery.
EDL is a powerful tool. A device in EDL mode will follow all instructions given to it without checking whether it would be a good idea to do so. If the instructions tell your device to overwrite userdata, IMEI or MAC address it will do so. Only flash files that are meant for your device. Don't edit any file unless you know what it does.
Preparation:​You need to be at least somewhat familiar with the command line to do this.
- Install git from your distribution
- Download and compile the open source flashing tool QDL. Follow the section "Get the Linux flashing tool" from these instructions.
- Temporarily add QDL to your $PATH with export PATH="$(pwd):$PATH"
QDL must be able to communicate with your device. You can install the appropriate udev rules right now or try it without them first.
- Open a text editor sudo nano /etc/udev/rules.d/51-edl.rules
- Copy these rules and paste them. Ctrl+S to save, Ctrl+X to exit
- The rules should apply the next time you connect your device
- If flashing does not work check the file contents: cat /etc/udev/rules.d/51-edl.rules
- If you can't read the file: sudo chmod a+r /etc/udev/rules.d/51-edl.rules
- If the new rules still don't load for some reason: sudo udevadm control --reload
- Download the "UnBrick tool mini" as uploaded by Naman Bhalla. (direct link)
- Create a clean working directory and extract the zip file.
Customize what to flash:​By default, the UnBrick tool mini will flash OxygenOS 2 bootloader, firmware and stock recovery. From there you can flash the latest OxygenOS and unlock your bootloader again for a clean start.
Flashing OxygenOS will always install a compatible bootloader and firmware and OxygenOS will automatically upgrade the recovery during the boot process.
If this is what you want just skip to the next step.
The UnBrick tool will flash config.bin and persist.img and reset these partitions.
Resetting config will re-lock the bootloader.
Resetting persist will require it to be repopulated again. OxygenOS can do this but most Custom ROMs will have broken sensors.
If you don't want to flash certain files, rename them or move them to another directory.
If you only want to flash certain partitions like the recovery, create a new directory, e.g. flash_recovery-only. Download the recovery version you need:
OxygenOS 2 Lollipop recovery - OxygenOS 3 Marshmallow recovery
Copy it to the new directory and rename it to recovery.img to match the filename the UnBrick tool uses.
Additionaly, copy these files from the UnBrick tool:
gpt_main0.bin
gpt_backup0.bin
patch0.xml
prog_emmc_firehose_8974.mbn
rawprogram0.xml
Main procedure:​
cd to the directory with the files from the UnBrick tool. Go to your custom directory if you created one in the previous step.
Run qdl prog_emmc_firehose_8974.mbn rawprogram0.xml patch0.xml
QDL will wait for your device to connect.
If QDL asks for permissions go back to "Preparation" and install the udev rules.
With the OnePlus X powered off hold VolUp and connect it to the PC. Otherwise, connect it to the PC first and hold Power+VolUp until it connects in EDL mode.
To verify the connection you can check lsusb or sudo dmesg -w
Devices in EDL mode show up with idVendor=05c6 and idProduct=9008, usually as Product: QHSUSB__BULK
lsusb example: ID 05c6:9008 Qualcomm, Inc. Gobi Wireless Modem (QDL mode)
To filter the output: lsusb -d 05c6:9008
QDL should print several lines of output, reporting what is flashed etc.
Once it's done, QDL will kick your device out of EDL mode. If everything is alright your phone should vibrate and boot to the charging screen. You should be able to boot to recovery now.
Congratulations on unbricking your device on a Linux machine, enjoy.
Changelog:
2019-12-12 - Original post
??? - undocumented edits
2020-05-24 - Fix possible execution of QDL without patch0.xml which would break the partition table
2022-09-05 - Fix unnessesarily confusing instructions

Thanks

I have a new TWRP on my OPX, but I don't really know what to change in the rawprogram0.xml file.

emilianoheyns said:
I have a new TWRP on my OPX, but I don't really know what to change in the rawprogram0.xml file.
Click to expand...
Click to collapse
I'm not sure if i correctly understood your situation so i am going to assume the folloing:
- You are running a Linux based operating system on your desktop computer
- You have downloaded all necessary files as mentioned in the guide and successfully compiled qdl
- You want to use modern (newer than 2016) ROMs and the current OnePlus firmware and bootloader, i.e. from OxygenOS 3.1.4
- On your OnePlus X, you have "the old bootloader" installed, that is firmware prior to OxygenOS 3 (based on Marshmallow), i.e. firmware from OxygenOS 2.2.1 or similar
- Additionally, you accidentaly flashed TWRP version 3.0.2-1 or newer to your OnePlus X and rebooted into a soft-bricked state
If these assumptions are correct, i suggest as the easiest solution to reflash a compatible TWRP and update your firmware using that version of TWRP. If you can use your recovery, it is almost always the easiest method to make any remaining modifications in the recovery.
The procedure is as follows:
- From https://dl.twrp.me/onyx/, download TWRP version 3.0.2-0 and 3.3.1-0
- Reflash an old version of TWRP that is compatible, i.e. anything version 3.0.2-0 and below.
Once you flashed TWRP in one way or another, continue with the following steps to update your bootloader:
- Reboot to that version of TWRP to see if you succeeded
- In TWRP, install either one of the following to update your firmware:
- The official OxygenOS 3.1.4 zip downloaded from OnePlus via https://www.oneplus.com/support/softwareupgrade​- Only the firmware by following this guide: https://forum.xda-developers.com/oneplus-x/general/guide-update-bootloader-firmware-to-t347891766​- Copy to your device: twrp-3.3.1-0-onyx.img and the installation zip you chose in the previous step
- Flash the zip in TWRP. Once TWRP is done flashing, immediately flash a version of TWRP 3.0.2-1 or later to recovery
- In TWRP, choose Reboot > Recovery. If your OnePlus X reboots to TWRP, everything went good and you can go on to flash roms and anything else like you're used to. Just note that very old ROMs (like from 2016 and before) will no longer boot on your device, but you can revert your Firmware by flashing the follwing zip: https://forum.xda-developers.com/oneplus-x/general/zip-recovery-flashable-firmware-radio-t3381420
Just remember that immediately after flashing this zip in TWRP, you have to flash TWRP version 3.0.2-0 or older again.
Now, there are some differnt cases that affect how TWRP initially needs to be flashed:
1. Your OnePlus X bootloader is not locked
(tested by running "fastboot oem device-info" on your desktop while your phone is connected in fastboot mode)
If your bootloader is still unlocked you can avoid the hassle of using qdl and simply resort to "fastboot flash recovery <recovery image file>" to fix your device.
2. Your ROM still boots and that ROM is rooted.
In this situation you can still avoid going through the hassle of using qdl.
All you need to do is to get a root shell running. There are several ways to achieve this:
- In a Terminal Emulator on the device run the command "su"
- On a desktop with your phone connected with adb enabled:
- Run either "adb root" and then "adb shell"
- Or run "adb shell" and within that shell, run "su"
Once you got the shell running you can flash your recovery with
"dd of=/dev/block/bootdevice/by-name/recovery if=/sdcard/twrp-3.0.2-0-onyx.img"
To get the image to your device if downloaded on your desktop you can use "adb push twrp-3.0.2-0-onyx.img /sdcard/"
3. Your ROM does not boot or is not rooted.
This is the case where you absolutely need qdl and the situation i assume you are in.
Once you downloaded and unpacked the package from Naman Bhalla, you should see a directory containing the rawprogram0.xml and prog_emmc_firehose_8974.mbn files and a lot of others. You can take just the rawprogram0.xml and the prog_emmc_firehose_8974.mbn file and copy them to your working directory for the next steps.
Now, open rawprogram0.xml in a text editor. Search for the string "recovery". You will see a line starting with "<program" and ending in "/>". In your case, only the line containing " label="recovery" " and " filename="recovery.img" " is relevant. Remove all other lines starting with "<program" and save. Optionally, rename the file to "program-onyx-recovery.xml" or something you will recognize. This might be useful if you plan to keep the file and use it again in the future.
Now, optionally change filename="recovery.img" to the file name of your TWRP file or just rename your downloaded TWRP file to "recovery.img".
To flash, make sure that the following files are in your working directory:
- prog_emmc_firehose_8974.mbn
- rawprogram0.xml (but your customized version)
- recovery.img (whatever recovery you want to flash)
If that is settled, run qdl as explained in my initial guide in the original post to flash the recovery file.
Edit 2022-09-04: This whole paragraph only applies to the OxygenOS 2 bootloader. A locked OxygenOS 3 bootloader will only boot a signed ROM or a signed recovery. However, the device storage can always be dumped through EDL and the final point about encryption always applies.
Some final remarks on locked bootloader on the OnePlus X:
For the future, remember to just keep your bootloader unlocked. It can save you a lot of hassle.
And if you feel uncomfortable about walking around with an unlocked bootloader:
Re-locking the bootloader while TWRP is installed doesn't give any security benefit at all (for obvious reasons). Even if your Recevery would not be open to any local attacker, a locked bootloader doesn't give you much of a benefit on the OnePlus X.
Yes, the generic attac surface of simply using "fastboot flash" is gone, but remember how easy it is to find the UnBrick tool for the OnePlus X we used in this guide. Any attacker can use it as well to flash a malicious recovery onto your device, even if your bootloader is locked - and your OnePlus will boot it.
This is because the OnePlus X does not support Android Verified Boot. This is a security feature on newer Android devices that prevents booting unsigned software if the bootloader is locked. This can prevent flashing malicious firmware, OS or revovery onto a device. But since it also prevents booting TWRP you'd likely be walking around with an unlocked bootloader anyway even if your device were to support this security feature.
Funnily enough, this leads to the conclusion that running your OnePlus X with stock OxygenOS, Recovery and locked bootloader is about as insecure as running TWRP and having an unlocked bootloader if we are talking about an attacker with physical access to the device who also knows about this tool. And since such a tool exists for pretty much every android device as it is originally used to flash these devices in their factories and can be publicly found for most devices, it can be assumed that any attacker has access to this tool.
So remember, the only protection you can have on a OnePlus X is encrypting your data with a strong passcode and hoping that your data stays private even if you might lose your device.

I have no problems with having an unlocked bootloader -- I thought this device had one already. Yesterday it was running TWRP3.0.2-1 and LOS Marshmellow, I just screwed it up trying to upgrade it to an unofficial LOS16. It would first bootloop constantly, then I tried QDL, and now it doesn't even seem to turn on; I can hold the power button for a full minute but the screen remains black, and there's no vibration as I'm used to. It does show up in QDL mode; I tried the procedure as per point 3, using twrp-3.0.2-1 as the recovery image. QDL says:
Code:
HELLO version: 0x2 compatible: 0x1 max_len: 1024 mode: 0
READ image: 13 offset: 0x0 length: 0x50
READ image: 13 offset: 0x50 length: 0x1000
READ image: 13 offset: 0x1050 length: 0x1000
READ image: 13 offset: 0x2050 length: 0x1000
READ image: 13 offset: 0x3050 length: 0x1000
READ image: 13 offset: 0x4050 length: 0x1000
READ image: 13 offset: 0x5050 length: 0x1000
READ image: 13 offset: 0x6050 length: 0x1000
READ image: 13 offset: 0x7050 length: 0x1000
READ image: 13 offset: 0x8050 length: 0x1000
READ image: 13 offset: 0x9050 length: 0x1000
READ image: 13 offset: 0xa050 length: 0x1000
READ image: 13 offset: 0xb050 length: 0x1000
READ image: 13 offset: 0xc050 length: 0x1000
READ image: 13 offset: 0xd050 length: 0x1000
READ image: 13 offset: 0xe050 length: 0x1000
READ image: 13 offset: 0xf050 length: 0x1000
READ image: 13 offset: 0x10050 length: 0x1000
READ image: 13 offset: 0x11050 length: 0x1000
READ image: 13 offset: 0x12050 length: 0x1000
READ image: 13 offset: 0x13050 length: 0x1000
READ image: 13 offset: 0x14050 length: 0x890
END OF IMAGE image: 13 status: 0
DONE status: 0
qdl: failed to read: Connection timed out
LOG: Host's payload to target size is too large
LOG: [email protected] [email protected]
LOG: [email protected] [email protected]
LOG: [email protected] [email protected]
LOG: start 1409024, num 31680
LOG: Finished sector address 1440704
[PROGRAM] flashed "recovery" successfully at 3960kB/s
no boot partition found
but the OPX still won't boot.

Is your bootloader actually unlocked?
The OnePlus X ships with a locked bootloader that prevents flashing files to the device using fastboot.
The usual steps to modify the OnePlus X and installing custom ROMs are:
- Unlock the bootloader by running "fastboot oem unlock" on a desktop PC while the phone is connected in fastboot mode.
- Flash TWRP by running "fastboot flash recovery TWRP.img" on a desktop PC while the phone is connected in fastboot mode.
Pressing the volume up button while turning on the device normally puts it into fastboot mode and "Fasboot Mode" will be displayed in the middle of the screen along with the oneplus logo.
Unlocking only works with the original OnePlus recovery and if the option "Allow OEM unlocking" is checked in the developer settings. Unlocking requires wiping all userdata.
Did you never do this yourself with your OnePlus X? Did you get this device as a used phone from someone else who already unlocked the bootloader?
What do you mean by "bootloop constantly"? Could you not boot the recovery?
Are you saying you already ran QDL with the unmodified files from the UnBrick tool?
If you really had TWRP 3.0.2-1 running before all your problems started, then doing so initially soft-bricked your device to begin with, as i outlined in footnote [1] of my original post.
I am not sure of the precise timeline and order of your descriptions. I currently assume that you're saying:
1. Had a working device with ROM: "LineageOS 13.0" Recovery: "TWRP version 3.0.2-1" Firmware: Unknown
2. Flashed some "lineage-16.0-unofficial.zip" in TWRP
3. When rebooting, "bootloops" appeared [How did that look? What was affected - just ROM or recovery as well?]
4. Run QDL with the unmodified files from the UnBrick tool that is linked in my original post
5. Phone does not react to button presses except when putting into EDL mode
6. Run QDL with recovery only as described in Point 3 of my follow up post, with the image file of TWRP version 3.0.2-1, QDL repoted success
7. Still not booting [What exactly does this mean? Still no reaction to button presses? Dees the phone vibrate and bring up the OnePlus logo?]

I've followed the mentioned steps and Im still stuck on linux logo..
I desesperately need help, bought a bricked second hand Oneplus X which I know nothing of in terms of past actions but previous owner

BolitaBolita said:
I've followed the mentioned steps and Im still stuck on linux logo..
I desesperately need help, bought a bricked second hand Oneplus X which I know nothing of in terms of past actions but previous owner
Click to expand...
Click to collapse
If you did not modify any files from the unbrick tool by Naman Bhalla and qdl ran through sucessfully, it should have flashed a compatible combination of bootloader and stock recovery so you should be able to reboot to that one.
If this is not the case, you can also go with flashing just a TWRP image. Since there are really just two possible versions of the bootloader (at least in regards to booting compatibility) this should succeed after the second try at most. If not, it means that some other stuff might be broken as well.
As i wrote in my OP, for the OnePlus X any TWRP v3.0.2-0 or older is compatible with the "old bootloader" (Lollipop) and any TWRP v3.0.2-1 or newer is compatible with the "new bootloader" (Marshmallow).
What you basically want to achieve is to just get any recovery booting (be it Stock, TWRP, orangefox or any other useful recovery). From that point, it is fairly easy to get anywhere else on the OnePlus X.
As for other things that can break:
Most of the partitions in your device can be restored to an intact state by flashing an official OxygenOS zip (https://www.oneplus.com/support/softwareupgrade). There are some other ways but this is the safe and easy method.
Only a few partitions cannot be restored once tampered, since they are unique to the specific device. If this happens to be the case, then it can be fairly hard to fix. If the previous owner had unlocked the devices bootloader and flashed some stuff on it, you should ask them whether they might have some TWRP backups around, namely of the partitions "Persist" and "EFS".

SebiderSushi said:
If you did not modify any files from the unbrick tool by Naman Bhalla and qdl ran through sucessfully, it should have flashed a compatible combination of bootloader and stock recovery so you should be able to reboot to that one.
If this is not the case, you can also go with flashing just a TWRP image. Since there are really just two possible versions of the bootloader (at least in regards to booting compatibility) this should succeed after the second try at most. If not, it means that some other stuff might be broken as well.
As i wrote in my OP, for the OnePlus X any TWRP v3.0.2-0 or older is compatible with the "old bootloader" (Lollipop) and any TWRP v3.0.2-1 or newer is compatible with the "new bootloader" (Marshmallow).
What you basically want to achieve is to just get any recovery booting (be it Stock, TWRP, orangefox or any other useful recovery). From that point, it is fairly easy to get anywhere else on the OnePlus X.
As for other things that can break:
Most of the partitions in your device can be restored to an intact state by flashing an official OxygenOS zip (https://www.oneplus.com/support/softwareupgrade). There are some other ways but this is the safe and easy method.
Only a few partitions cannot be restored once tampered, since they are unique to the specific device. If this happens to be the case, then it can be fairly hard to fix. If the previous owner had unlocked the devices bootloader and flashed some stuff on it, you should ask them whether they might have some TWRP backups around, namely of the partitions "Persist" and "EFS".
Click to expand...
Click to collapse
Thank you for your reply SebiderSushi.
The only option I have in terms of recovery booting is the Oneplus original one since I bought the phone bricked (can't access dev options and can't connect through ADB for oem unlock).
I've managed to unlock the bootloader and tried to flash the official OsOxygen zip. The update stopped halfway and the phone bricked once again.
I've tried the Naman Bhalla unbrick tool with the MSMdownloadtool 2.1 (previously attempted 2.0). The process runs successfully, until its marked in green 'download complete'. Phone still bricked.
I'm currently attempting with QFIL through this thread https://www.droidsavvy.com/unbrick-qualcomm-mobiles/
Drivers correctly installed, port 9008 is detected and QFIL is currently. I'm using the files from the unbrick tool by Naman Bhalla for this. The output is the following:
Process Index:0
Programmer Path:C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\prog_emmc_firehose_8974.mbn
Image Search Path:C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla
Please select the XML file
Start Download
Program Path:C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\prog_emmc_firehose_8974.mbn
COM Port number:3
Sahara Connecting ...
Sahara Version:0
Start Sending Programmer
Download Fail:System.Exception: Unable to download Flash Programmer using Sahara Protocol
at QC.QMSLPhone.Phone.QPHONEMS_SaharaArmPrgDownload(String sFileName)
at QC.SwDownloadDLL.SwDownload.QPHONEMSSaharaDownloadArmPrg(UInt64& version, String armPrgPath)
Download Fail:Sahara FailSahara Fail
Finish Download
Start Download
Program Path:C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\prog_emmc_firehose_8974.mbn
COM Port number:3
Sahara Connecting ...
Sahara Version:0
Start Sending Programmer
Download Fail:System.Exception: Unable to download Flash Programmer using Sahara Protocol
at QC.QMSLPhone.Phone.QPHONEMS_SaharaArmPrgDownload(String sFileName)
at QC.SwDownloadDLL.SwDownload.QPHONEMSSaharaDownloadArmPrg(UInt64& version, String armPrgPath)
Download Fail:Sahara FailSahara Fail
Finish Download
Start Download
Program Path:C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\prog_emmc_firehose_8974.mbn
COM Port number:3
Sahara Connecting ...
Sahara Version:0
Start Sending Programmer
Download Fail:System.Exception: Unable to download Flash Programmer using Sahara Protocol
at QC.QMSLPhone.Phone.QPHONEMS_SaharaArmPrgDownload(String sFileName)
at QC.SwDownloadDLL.SwDownload.QPHONEMSSaharaDownloadArmPrg(UInt64& version, String armPrgPath)
Download Fail:Sahara FailSahara Fail
Finish Download
Start Download
Program Path:C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\prog_emmc_firehose_8974.mbn
COM Port number:3
Sahara Connecting ...
Sahara Version:0
Start Sending Programmer
Download Fail:System.Exception: Unable to download Flash Programmer using Sahara Protocol
at QC.QMSLPhone.Phone.QPHONEMS_SaharaArmPrgDownload(String sFileName)
at QC.SwDownloadDLL.SwDownload.QPHONEMSSaharaDownloadArmPrg(UInt64& version, String armPrgPath)
Download Fail:Sahara FailSahara Fail
Finish Download
Start Download
Program Path:C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\prog_emmc_firehose_8974.mbn
COM Port number:3
Sahara Connecting ...
Sahara Version:2
Start Sending Programmer
Sending Programmer Finished
Switch To FireHose
Max Payload Size to Target:49152 Bytes
Device Type:eMMC
Platform:8x26
Disable Ack Raw Data Every N Packets
Ack Raw Data:False
Skip Write:False
Always Validate:False
Use Verbose:False
COM Port number:3
Sending NOP
FireHose NOP sent successfully
Sending Configuration
Device Type:eMMC
Platform:8x26
Request payload size 0xc000 is not the same as support payload size, change to 0x20000
Set TxBuffer 0x20000, RxBuffer 0x4000
Firehose configure packet sent successfully!
Total Bytes To Program 0x62AE4A0
Download Image
PROGRAM: Partition 0, Sector: 0, Length: 33 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\gpt_backup0.bin
PROGRAM: Written Bytes 0x4200 (64)
Program Size: 0.02 MB
PROGRAM: Partition 0, Sector: 0, Length: 34 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\gpt_main0.bin
PROGRAM: Written Bytes 0x4400 (64)
Program Size: 0.02 MB
PROGRAM: Partition 0, Sector: 1609554, Length: 1024 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\config.bin
PROGRAM: Written Bytes 0x80000 (64)
Program Size: 0.50 MB
PROGRAM: Replace the partition sectors number 0x8000 to file size in sector 0x254
PROGRAM: Partition 0, Sector: 1460242, Length: 596 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\logo.bin
PROGRAM: Written Bytes 0x4a800 (64)
Program Size: 0.29 MB
PROGRAM: Replace the partition sectors number 0x8000 to file size in sector 0x74f0
PROGRAM: Partition 0, Sector: 1409024, Length: 29936 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\recovery.img
PROGRAM: Written Bytes 0xe9e000 (64)
Program Size: 14.62 MB
PROGRAM: Replace the partition sectors number 0x10000 to file size in sector 0x26a3
PROGRAM: Partition 0, Sector: 294912, Length: 9891 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\persist.img
PROGRAM: Written Bytes 0x4d4600 (64)
Program Size: 4.83 MB
PROGRAM: Partition 0, Sector: 259048, Length: 20480 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\static_nvbk.bin
PROGRAM: Written Bytes 0xa00000 (64)
Program Size: 10.00 MB
PROGRAM: Partition 0, Sector: 238568, Length: 20480 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\dynamic_nvbk.bin
PROGRAM: Written Bytes 0xa00000 (64)
Program Size: 10.00 MB
PROGRAM: Replace the partition sectors number 0x3e8 to file size in sector 0x28d
PROGRAM: Partition 0, Sector: 229376, Length: 653 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\tz.mbn
PROGRAM: Written Bytes 0x51a00 (64)
Program Size: 0.32 MB
PROGRAM: Replace the partition sectors number 0x3e8 to file size in sector 0x174
PROGRAM: Partition 0, Sector: 182272, Length: 372 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\rpm.mbn
PROGRAM: Written Bytes 0x2e800 (64)
Program Size: 0.18 MB
PROGRAM: Replace the partition sectors number 0x800 to file size in sector 0x380
PROGRAM: Partition 0, Sector: 180224, Length: 896 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\emmc_appsboot.mbn
PROGRAM: Written Bytes 0x70000 (64)
Program Size: 0.44 MB
PROGRAM: Replace the partition sectors number 0x40 to file size in sector 0x17
PROGRAM: Partition 0, Sector: 148480, Length: 23 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\sdi.mbn
PROGRAM: Written Bytes 0x2e00 (64)
Program Size: 0.01 MB
PROGRAM: Replace the partition sectors number 0x400 to file size in sector 0x22d
PROGRAM: Partition 0, Sector: 147456, Length: 557 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\sbl1.mbn
PROGRAM: Written Bytes 0x45a00 (64)
Program Size: 0.27 MB
PROGRAM: Replace the partition sectors number 0x20000 to file size in sector 0x1c983
PROGRAM: Partition 0, Sector: 16384, Length: 117123 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\NON-HLOS.bin
PROGRAM: Written Bytes 0x3930600 (64)
Program Size: 57.19 MB
Total Size: 98.68 MB
Total Size: 28 Seconds
Throughput: 3.52 MB/Seconds
PATCH: Partition 0, Sector: 9, Offset 40 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-34.
PATCH: Partition 0, Sector: 0, Offset 40 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-34.
PATCH: Partition 0, Sector: 1, Offset 48 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-34.
PATCH: Partition 0, Sector: 0, Offset 48 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-34.
PATCH: Partition 0, Sector: 1, Offset 32 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-1.
PATCH: Partition 0, Sector: 0, Offset 24 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-1.
PATCH: Partition 0, Sector: 0, Offset 72 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-33.
PATCH: Partition 0, Sector: 1, Offset 88 Bytes, Size: 4 Bytes, Value: CRC32(2,4096)
PATCH: Partition 0, Sector: 0, Offset 88 Bytes, Size: 4 Bytes, Value: CRC32(NUM_DISK_SECTORS-33.,4096)
PATCH: Partition 0, Sector: 1, Offset 16 Bytes, Size: 4 Bytes, Value: 0
PATCH: Partition 0, Sector: 1, Offset 16 Bytes, Size: 4 Bytes, Value: CRC32(1,92)
PATCH: Partition 0, Sector: 0, Offset 16 Bytes, Size: 4 Bytes, Value: 0
PATCH: Partition 0, Sector: 0, Offset 16 Bytes, Size: 4 Bytes, Value: CRC32(NUM_DISK_SECTORS-1.,92)
Total download file size: 98.68066MB
Throughput: 3.524309M/s
Reset Phone
Waiting for reset done...
Download Fail:FireHose Fail Fail to find QDLoader port after switch
Finish Download

BolitaBolita said:
The only option I have in terms of recovery booting is the Oneplus original one since I bought the phone bricked (can't access dev options and can't connect through ADB for oem unlock).
Click to expand...
Click to collapse
Now what exactly do you even mean when you say "Bricked"?
If you can boot into recovery, then your device is usually not bricked, but even if, it is usually not in a state where using a flashing tool and risking to **** up the device for good has any real advantage over solving whatever problem in the recovery.
As long as your device doesn't have any hardware errors (broken storage) then the official OnePlus Recovery should almost always be able to install the official OxygenOS.
Under what terms did you even buy this device? How did the previous owner describe the state of the device and its defects if they mentioned them?
BolitaBolita said:
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\config.bin
Click to expand...
Click to collapse
You are using windows, so how did you even end up in this thread?

Sorry for the delay -- I thought I had set up notifications and didn't want to push on the point until you had time, but I did not receive a notification for this.
SebiderSushi said:
Is your bootloader actually unlocked?
The OnePlus X ships with a locked bootloader that prevents flashing files to the device using fastboot.
The usual steps to modify the OnePlus X and installing custom ROMs are:
- Unlock the bootloader by running "fastboot oem unlock" on a desktop PC while the phone is connected in fastboot mode.
- Flash TWRP by running "fastboot flash recovery TWRP.img" on a desktop PC while the phone is connected in fastboot mode.
Click to expand...
Click to collapse
I had a LineageOS running on the OPX before I screwed up an upgrade of LOS. I had TWRP on the phone. The bootloader must be unlocked then yes?
SebiderSushi said:
Pressing the volume up button while turning on the device normally puts it into fastboot mode and "Fasboot Mode" will be displayed in the middle of the screen along with the oneplus logo.
Click to expand...
Click to collapse
broadly, that is what I had done before, but right now I don't even get the fastboot logo.
SebiderSushi said:
Unlocking only works with the original OnePlus recovery and if the option "Allow OEM unlocking" is checked in the developer settings. Unlocking requires wiping all userdata.
Click to expand...
Click to collapse
Right, but I had passed that station before, as it was running LOS.
SebiderSushi said:
Did you never do this yourself with your OnePlus X? Did you get this device as a used phone from someone else who already unlocked the bootloader?
Click to expand...
Click to collapse
No, I did all this myself, but screwed up the update to a non-official LOS.
SebiderSushi said:
What do you mean by "bootloop constantly"? Could you not boot the recovery?
Click to expand...
Click to collapse
I could not, no, but now I'm not even getting the fastboot logo
SebiderSushi said:
Are you saying you already ran QDL with the unmodified files from the UnBrick tool?
Click to expand...
Click to collapse
Correct, yes.
SebiderSushi said:
I am not sure of the precise timeline and order of your descriptions. I currently assume that you're saying:
1. Had a working device with ROM: "LineageOS 13.0" Recovery: "TWRP version 3.0.2-1" Firmware: Unknown
2. Flashed some "lineage-16.0-unofficial.zip" in TWRP
3. When rebooting, "bootloops" appeared [How did that look? What was affected - just ROM or recovery as well?]
Click to expand...
Click to collapse
Initially I could get to recovery, I tried to upgrade to the latest TWRP for the OPX, when I tried to restart that to recovery, it would just vibrate and reboot continuously
SebiderSushi said:
7. Still not booting [What exactly does this mean? Still no reaction to button presses? Dees the phone vibrate and bring up the OnePlus logo?]
Click to expand...
Click to collapse
Currently, the screen stays black, and I can hold volume up or power for 20 seconds with no reaction (no vibrate, no logo)

First off, i'm extremely sorry for my delay! I also happened to notice your message just today.
Right now i got around and tried reproducing your scenario on my own OnePlus X.
As you said that you ran the unmodified setup from the unbrick tool according to my guide, i did as well - and ran into the same issue you were describing.
After some fiddling around, i realized that you must supply the patch0.xml file as well for a complete flash on the OnePlus X when you also modify the GPT (partition table), which the unmodified rawprogram0.xml does. This is not the case if you only install a recovery or other individual partitions so it slipped my mind. I deeply apologize for not testing the command line for the unmodified UnBrick tool package well enough while writing my Guide.
If nothing else is wrong, running
"/path/to/qdl_source_code/qdl prog_emmc_firehose_8974.mbn rawprogram0.xml patch0.xml"
with the unmodified UnBrick tool will fix the device back to a booting state with the stock recovery and Lollipop Bootloader installed on the device., it did so in my case.
Alternatively, if you don't want to reflash all partitions from the package, you can also just try running
"/path/to/qdl_source_code/qdl prog_emmc_firehose_8974.mbn patch0.xml"
Short of any good documentation, i guessed that the problem appeared because the unmodified rawprogram0.xml also writes the GPT table in its last two program elements. If you look in patch0.xml, you can see that it takes care of the GPT in some way. Once i removed the two program items regarding the GPT, rawprogram0.xml could be applied without needing to flash patch0.xml together with it.
So i assume that it is safe to individually flash any partition listed it rawprogram0.xml apart from the GPT. If your GPT is not in a valid state, there's not much booting going on, since your device won't be able to even read your bootloader from the disk without a partition table.
emilianoheyns said:
I had a LineageOS running on the OPX before I screwed up an upgrade of LOS. I had TWRP on the phone. The bootloader must be unlocked then yes?
Click to expand...
Click to collapse
While this implies that you very likely once had an unlocked bootloader to allow installation of TWRP to your device, it is not necessarily the case. For one, it is possible to re-lock the bootloader on the OnePlus X and still boot and use custom recoveries and software. Only flashing images via fastboot becomes impossible again if you relock the bootloader. This is because the OnePlus X is a fairly old device (remember it came out with android 5.1). Such old devices don't support features like Android Verified Boot yet. This is the standard on modern android devices and it implies that a locked bootloader should only load and boot untampered system partitions as signed by the device vendor.
Edit 2022-09-04: I was wrong about this. This only applies to the OxygenOS 2 bootloader. Trying to boot an unsigned ROM or recovery with an unlocked OxygenOS 3 bootloader causes the exact symptoms that were described; The bootloader repeatedly tries booting in an infinite loop. Probably the LOS fash that went wrong caused the bootloader to re-lock, which is why rebooting to recovery didn't work afterwards as well as booting the ROM.
Also, qdl (or any othe software using the Qualcomm Emergency Download Mode) can also install custom Recoveries or ROMs to the devices without unlocking the bootloader and flashing stuff through fastboot.

After that, you can also boot back into fastboot mode and the run
fastboot oem device-info
from your computer to check if your devices bootloader is currently unlocked or not. If it is not, this is a perfect chance to unlock it, since you already got the official recovery installed and probably no user data to take care of anyway.

Hi, thanks for getting back to me. The problem I'm facing currently is that the OPX currently seems unresponsive -- the screen stays black, and no vibration, seemingly regardless of what button combination I use or how long I keep it on the charger. Any idea what key combo is most likely to bring it up in a state that QDL would see it?
I have fetched a fresh copy of OPX_UnBrick_Mini_By_Naman_Bhalla; I'm sorry to have to ask again, but I should then copy over prog_emmc_firehose_8974.mbn, rawprogram0.xml and patch0.xml unchanged, and run `/path/to/qdl_source_code/qdl prog_emmc_firehose_8974.mbn rawprogram0.xml patch0.xml`? I think I'd prefer to get it back to a booting state to then figure out what I can safely flash on it.
---------- Post added at 04:35 PM ---------- Previous post was at 04:30 PM ----------
I should note, if I connect the charger, the red charging light comes on for a second, maybe two, end then goes out again. It does not come back on unless I plug in again, even if I let it charge overnight.

In my case the usual route to enter EDL mode worked fine - that is, disconnect your OnePlus X from any power source for a few seconds, then press and hold the Volume Up button and after a few seconds reconnect it to your PC where you run qdl, then release the button and execute qdl.
If you want to flash the default confuguration of the unbrick tool you must open your terminal window in the folder you extracted from the download (or cd to it). This is because the files that are flashed to the device are in this folder as you caj see and they are being referenced with relative paths / their filenames from within "rawprogram0.xml".

SebiderSushi said:
In my case the usual route to enter EDL mode worked fine - that is, disconnect your OnePlus X from any power source for a few seconds, then press and hold the Volume Up button and after a few seconds reconnect it to your PC where you run qdl, then release the button and execute qdl.
Click to expand...
Click to collapse
Ah well, it must have died somewhere along the way then. When I do that, even after having it on the charger, nothing shows up in dmesg. Thanks in any case!

I wouldn't give up just yet. The actual rule for entering EDL mode on the OnePlus X is:
- The device must be powered off at the beginning
- The Volume Up button must be in pressed state when connecting it to the computer
Edit 2022-09-04: I was wrong about this. It is also possible to hold Power+Vol Up while connected to the PC until the device shows up in dmesg -w
Everything else, like waiting few seconds here and there is mostly safeties to ensure each state is entered or recognized cleanly.
I mostly had my phone running fresh from the last flashing process, which means that qdl had turned it off cleanly for me. So i definitely had good conditions to enter EDL mode.
I don't know what's going on with your notification LED since i didn't notice this on my device or payed any attention to it - but it might indicate that your phone could be in a not cleanly powered off state.
You can still try pressing the power button for a longer time (maybe about 10 to 30 seconds) to see if that switches off your device the right way before you retry entering EDL mode.
Or do any other experiments pressing buttons or try with different cables.
When was the last time you could successfully connect your device in any mode and which mode was it?

The symptoms you described about black screen, no vibrations or any reaction to button presses were also present on my device as well so this is i'd guess it's just normal for the state.

If you get it back to a booting state you should be able to install the official OxygenOS right from the stock recovery, or flash a compatible TWRP image using qdl or fastboot and copy any remaining data that you want to keep.

@SebiderSushi, could you please take a look at >this post< and hint if anything else can be done using edl on linux?

Attempted Unlock of Fire HD 8 (2016/ 6th generat). Is this tablet terminally bricked?

I had assembled a Fire HD 8 (2016) using parts from three different tablets, and I thought I'd have a play and see it if I could unlock it using a modified version of amonet for karnak (Fire HD 8, 2018).
I started with a rooted Fire HD 8 (2016) running Fire OS 5.6.3.4 (build 626536720). Amonet-karnak-v3.01 was downloaded from here: https://forum.xda-developers.com/showpost.php?p=80166353&postcount=1. Image files from Fire OS 5.6.3.4, update-kindle-49.6.2.6_user_626536720.bin: lk.bin, tz.img, preloader.bin, preloader.hdr0 and preloader.hdr1 were copied to amonet/bin, replacing the originals. The script 'fireos-step.sh'' was edited to allow 'max_pl=6' (preloader version 6), to change the model to 'full_giza' and to change the path (PART_PREFIX=) to /dev/block/platform/mtk-msdc.0.
The output from running the modified 'fireos-step.sh' script was as follows:
Code:
[email protected]:~/Downloads/amonet-giza-t/amonet$ sudo ./fireos-step.sh
Testing root access...
uid=0(root) gid=0(root) context=u:r:init:s0
PL version: 6 (6)
LK version: 1 (1)
TZ version: 258 (258)
Flashing PL
1602 KB/s (138924 bytes in 0.084s)
271+1 records in
271+1 records out
138924 bytes transferred in 0.063 secs (2205142 bytes/sec)
271+1 records in
271+1 records out
138924 bytes transferred in 0.016 secs (8682750 bytes/sec)
Flashing LK-payload
62 KB/s (2872 bytes in 0.044s)
5+1 records in
5+1 records out
2872 bytes transferred in 0.005 secs (574400 bytes/sec)
Flashing LK
4234 KB/s (487392 bytes in 0.112s)
951+1 records in
951+1 records out
487392 bytes transferred in 0.045 secs (10830933 bytes/sec)
Flashing TZ
4218 KB/s (3307008 bytes in 0.765s)
6459+0 records in
6459+0 records out
3307008 bytes transferred in 0.287 secs (11522675 bytes/sec)
6459+0 records in
6459+0 records out
3307008 bytes transferred in 0.297 secs (11134707 bytes/sec)
Flashing TWRP
4285 KB/s (13930496 bytes in 3.174s)
27208+0 records in
27208+0 records out
13930496 bytes transferred in 1.046 secs (13317873 bytes/sec)
Patching boot
2+0 records in
2+0 records out
1024 bytes transferred in 0.001 secs (1024000 bytes/sec)
2+0 records in
2+0 records out
1024 bytes transferred in 0.004 secs (256000 bytes/sec)
- Inject microloader
2+0 records in
2+0 records out
1024 bytes transferred in 0.004 secs (256000 bytes/sec)
Flashing PL header
44 KB/s (2048 bytes in 0.044s)
44 KB/s (2048 bytes in 0.044s)
4+0 records in
4+0 records out
2048 bytes transferred in 0.040 secs (51200 bytes/sec)
4+0 records in
4+0 records out
2048 bytes transferred in 0.052 secs (39384 bytes/sec)
Rebooting to TWRP
[email protected]:~/Downloads/amonet-giza-t/amonet$
This seemed OK but after rebooting, the tablet got stuck on the white Amazon logo, with no recovery mode available.
Amonet_giza_v1.3 was downloaded from here: https://forum.xda-developers.com/showpost.php?p=80232977&postcount=1. I ran the script 'bootrom-step.sh' (shorting method) and this was apparently sucessful:
Code:
[email protected]:~/Downloads/amonet-giza-v1.3$ sudo ./bootrom-step.sh
[2020-06-17 14:49:13.017742] Waiting for bootrom
[2020-06-17 14:49:44.205417] Found port = /dev/ttyACM0
[2020-06-17 14:49:44.215424] Handshake
[2020-06-17 14:49:44.263501] Disable watchdog
* * * Remove the short and press Enter * * *
[2020-06-17 14:49:48.644612] Init crypto engine
[2020-06-17 14:49:48.790589] Disable caches
[2020-06-17 14:49:48.798307] Disable bootrom range checks
[2020-06-17 14:49:48.898946] Load payload from ../brom-payload/build/payload.bin = 0x48D8 bytes
[2020-06-17 14:49:48.965959] Send payload
[2020-06-17 14:49:53.690455] Let's rock
[2020-06-17 14:49:53.699383] Wait for the payload to come online...
[2020-06-17 14:49:54.420378] all good
[2020-06-17 14:49:54.429345] Check GPT
[2020-06-17 14:49:54.802163] gpt_parsed = {'nvram': (7168, 10240), 'recovery': (92416, 32768), 'expdb': (154880, 20480), 'para': (137472, 1024), 'lk': (58880, 1000), 'secro': (125184, 12288), 'frp': (175360, 2048), 'protect2': (37888, 20480), 'metadata': (197888, 80640), 'logo': (138496, 16384), 'tee1': (177408, 10240), 'protect1': (17408, 20480), 'tee2': (187648, 10240), 'seccfg': (58368, 512), 'boot': (59880, 32536), 'proinfo': (1024, 6144)}
[2020-06-17 14:49:54.806253] Check boot0
[2020-06-17 14:49:55.053280] Check rpmb
[2020-06-17 14:49:55.269372] Downgrade rpmb
[2020-06-17 14:49:55.277150] Recheck rpmb
[2020-06-17 14:49:56.174262] rpmb downgrade ok
[2020-06-17 14:49:56.180584] Clear preloader header
[8 / 8]
[2020-06-17 14:49:56.897490] Flashing TZ
[6459 / 6459]
[2020-06-17 14:52:29.248010] Flash LK
[952 / 952]
[2020-06-17 14:52:52.133657] Flash PL
[280 / 280]
[2020-06-17 14:53:10.364218] Reboot
[email protected]:~/Downloads/amonet-giza-v1.3
However, it is still getting stuck at the white Amazon logo. Is there any way of resurrecting this tablet?

MontysEvilTwin said:
I had assembled a Fire HD 8 (2016) using parts from three different tablets, and I thought I'd have a play and see it if I could unlock it using a modified version of amonet for karnak (Fire HD 8, 2018).
I started with a rooted Fire HD 8 (2016) running Fire OS 5.6.3.4 (build 626536720). Amonet-karnak-v3.01 was downloaded from here: https://forum.xda-developers.com/showpost.php?p=80166353&postcount=1. Image files from Fire OS 5.6.3.4, update-kindle-49.6.2.6_user_626536720.bin: lk.bin, tz.img, preloader.bin, preloader.hdr0 and preloader.hdr1 were copied to amonet/bin, replacing the originals. The script 'fireos-step.sh'' was edited to allow 'max_pl=6' (preloader version 6), to change the model to 'full_giza' and to change the path (PART_PREFIX=) to /dev/block/platform/mtk-msdc.0.
The output from running the modified 'fireos-step.sh' script was as follows:
Code:
[email protected]:~/Downloads/amonet-giza-t/amonet$ sudo ./fireos-step.sh
Testing root access...
uid=0(root) gid=0(root) context=u:r:init:s0
PL version: 6 (6)
LK version: 1 (1)
TZ version: 258 (258)
Flashing PL
1602 KB/s (138924 bytes in 0.084s)
271+1 records in
271+1 records out
138924 bytes transferred in 0.063 secs (2205142 bytes/sec)
271+1 records in
271+1 records out
138924 bytes transferred in 0.016 secs (8682750 bytes/sec)
Flashing LK-payload
62 KB/s (2872 bytes in 0.044s)
5+1 records in
5+1 records out
2872 bytes transferred in 0.005 secs (574400 bytes/sec)
Flashing LK
4234 KB/s (487392 bytes in 0.112s)
951+1 records in
951+1 records out
487392 bytes transferred in 0.045 secs (10830933 bytes/sec)
Flashing TZ
4218 KB/s (3307008 bytes in 0.765s)
6459+0 records in
6459+0 records out
3307008 bytes transferred in 0.287 secs (11522675 bytes/sec)
6459+0 records in
6459+0 records out
3307008 bytes transferred in 0.297 secs (11134707 bytes/sec)
Flashing TWRP
4285 KB/s (13930496 bytes in 3.174s)
27208+0 records in
27208+0 records out
13930496 bytes transferred in 1.046 secs (13317873 bytes/sec)
Patching boot
2+0 records in
2+0 records out
1024 bytes transferred in 0.001 secs (1024000 bytes/sec)
2+0 records in
2+0 records out
1024 bytes transferred in 0.004 secs (256000 bytes/sec)
- Inject microloader
2+0 records in
2+0 records out
1024 bytes transferred in 0.004 secs (256000 bytes/sec)
Flashing PL header
44 KB/s (2048 bytes in 0.044s)
44 KB/s (2048 bytes in 0.044s)
4+0 records in
4+0 records out
2048 bytes transferred in 0.040 secs (51200 bytes/sec)
4+0 records in
4+0 records out
2048 bytes transferred in 0.052 secs (39384 bytes/sec)
Rebooting to TWRP
[email protected]:~/Downloads/amonet-giza-t/amonet$
This seemed OK but after rebooting, the tablet got stuck on the white Amazon logo, with no recovery mode available.
Amonet_giza_v1.3 was downloaded from here: https://forum.xda-developers.com/showpost.php?p=80232977&postcount=1. I ran the script 'bootrom-step.sh' (shorting method) and this was apparently sucessful:
Code:
[email protected]:~/Downloads/amonet-giza-v1.3$ sudo ./bootrom-step.sh
[2020-06-17 14:49:13.017742] Waiting for bootrom
[2020-06-17 14:49:44.205417] Found port = /dev/ttyACM0
[2020-06-17 14:49:44.215424] Handshake
[2020-06-17 14:49:44.263501] Disable watchdog
* * * Remove the short and press Enter * * *
[2020-06-17 14:49:48.644612] Init crypto engine
[2020-06-17 14:49:48.790589] Disable caches
[2020-06-17 14:49:48.798307] Disable bootrom range checks
[2020-06-17 14:49:48.898946] Load payload from ../brom-payload/build/payload.bin = 0x48D8 bytes
[2020-06-17 14:49:48.965959] Send payload
[2020-06-17 14:49:53.690455] Let's rock
[2020-06-17 14:49:53.699383] Wait for the payload to come online...
[2020-06-17 14:49:54.420378] all good
[2020-06-17 14:49:54.429345] Check GPT
[2020-06-17 14:49:54.802163] gpt_parsed = {'nvram': (7168, 10240), 'recovery': (92416, 32768), 'expdb': (154880, 20480), 'para': (137472, 1024), 'lk': (58880, 1000), 'secro': (125184, 12288), 'frp': (175360, 2048), 'protect2': (37888, 20480), 'metadata': (197888, 80640), 'logo': (138496, 16384), 'tee1': (177408, 10240), 'protect1': (17408, 20480), 'tee2': (187648, 10240), 'seccfg': (58368, 512), 'boot': (59880, 32536), 'proinfo': (1024, 6144)}
[2020-06-17 14:49:54.806253] Check boot0
[2020-06-17 14:49:55.053280] Check rpmb
[2020-06-17 14:49:55.269372] Downgrade rpmb
[2020-06-17 14:49:55.277150] Recheck rpmb
[2020-06-17 14:49:56.174262] rpmb downgrade ok
[2020-06-17 14:49:56.180584] Clear preloader header
[8 / 8]
[2020-06-17 14:49:56.897490] Flashing TZ
[6459 / 6459]
[2020-06-17 14:52:29.248010] Flash LK
[952 / 952]
[2020-06-17 14:52:52.133657] Flash PL
[280 / 280]
[2020-06-17 14:53:10.364218] Reboot
[email protected]:~/Downloads/amonet-giza-v1.3
However, it is still getting stuck at the white Amazon logo. Is there any way of resurrecting this tablet?
Click to expand...
Click to collapse
Have you tried flashing the full image from amazon?

Michajin said:
Have you tried flashing the full image from amazon?
Click to expand...
Click to collapse
I can't get into recovery. I think that the standard recovery was overwritten by TWRP, but it won't boot into TWRP.

MontysEvilTwin said:
I can't get into recovery. I think that the standard recovery was overwritten by TWRP, but it won't boot into TWRP.
Click to expand...
Click to collapse
I never seen Giza get that far to make the full unlock/TWRP install. Can you show me the thread that unlocks it? The thread you listed was a unbrick thread. Did you try anything that might have wiped the recovery partition? Vol (+or-) and power don't try and force recovery? (i dont have a giza, just trying to help).

Michajin said:
I never seen Giza get that far to make the full unlock/TWRP install. Can you show me the thread that unlocks it? The thread you listed was a unbrick thread. Did you try anything that might have wiped the recovery partition? Vol (+or-) and power don't try and force recovery? (i dont have a giza, just trying to help).
Click to expand...
Click to collapse
There is no official unlock, I was playing around with a spare tablet and I used the latest version of amonet for karnak (v 3.0.1) but with giza bootloader files and a modified fireos-step script. According to the output (post #1) TWRP did flash correctly and as this is based on amonet for karnak it will have overwritten the recovery partition. It was a risk, as while the giza, douglas and karnak tablets all have a common processor, the douglas requires the device to be repartitioned and TWRP to be installed on a second recovery partition, karnak does not.
There is an old thread (see here: https://forum.xda-developers.com/hd8-hd10/orig-development/fire-hd8-2017-amonet-debrick-root-t3897841) which enabled the douglas to be rooted before mtk-su was released. This installed karnak bootloader files using amonet and then flashed a rooted software image (hacked fastboot) before flashing the devices own bootloaders. This also works for giza using giza bootloaders. I will probably try this method. I am not sure if it is sufficient to flash a system and boot image or if I need to reflash a separate recovery image too?

MontysEvilTwin said:
There is no official unlock, I was playing around with a spare tablet and I used the latest version of amonet for karnak (v 3.0.1) but with giza bootloader files and a modified fireos-step script. According to the output (post #1) TWRP did flash correctly and as this is based on amonet for karnak it will have overwritten the recovery partition. It was a risk, as while the giza, douglas and karnak tablets all have a common processor, the douglas requires the device to be repartitioned and TWRP to be installed on a second recovery partition, karnak does not.
There is an old thread (see here: https://forum.xda-developers.com/hd8-hd10/orig-development/fire-hd8-2017-amonet-debrick-root-t3897841) which enabled the douglas to be rooted before mtk-su was released. This installed karnak bootloader files using amonet and then flashed a rooted software image (hacked fastboot) before flashing the devices own bootloaders. This also works for giza using giza bootloaders. I will probably try this method. I am not sure if it is sufficient to flash a system and boot image or if I need to reflash a separate recovery image too?
Click to expand...
Click to collapse
I fixed it using the last method described in my previous post; the original HD 8 (2017) debrick thread. This used shorting with the bootrom method to install karnak preloader, TZ and LK files, plus hacked fastboot. I then flashed boot.img (taken from the '.bin' of the OS 5.3.6.4 software - first build), system.img (created from the same software using a python script, as described in the link) and, to be safe, I also flashed recovery.img (copied from another 2016 HD 8 running the same version of software). Then I used bootrom again (amonet-res from the link, with 2016 HD 8 files) to restore 2016 HD 8 preloader plus LK and TZ files. The device then booted normally into Fire OS.

MontysEvilTwin said:
I fixed it using the last method described in my previous post; the original HD 8 (2017) debrick thread. This used shorting with the bootrom method to install karnak preloader, TZ and LK files, plus hacked fastboot. I then flashed boot.img (taken from the '.bin' of the OS 5.3.6.4 software - first build), system.img (created from the same software using a python script, as described in the link) and, to be safe, I also flashed recovery.img (copied from another 2016 HD 8 running the same version of software). Then I used bootrom again (amonet-res from the link, with 2016 HD 8 files) to restore 2016 HD 8 preloader plus LK and TZ files. The device then booted normally into Fire OS.
Click to expand...
Click to collapse
Awesome!
Sounds like you had it unlocked, and you could have installed TWRP (douglas?) over stock recovery from the hacked fastboot.

Michajin said:
Awesome!
Sounds like you had it unlocked, and you could have installed TWRP (douglas?) over stock recovery from the hacked fastboot.
Click to expand...
Click to collapse
I think someone who knows what they are doing could get it working. I know it flashed TWRP for karnak when I first tried to unlock but something I did temporarily bricked the tablet. The method I used to recover installs karnak files on the device. The screen stays black but hacked fastboot still runs.
It may be that the exploit for douglas is worth trying. This is a bit different to karnak in that it repartitions the device and installs TWRP on a secondary partition.

MontysEvilTwin said:
I think someone who knows what they are doing could get it working. I know it flashed TWRP for karnak when I first tried to unlock but something I did temporarily bricked the tablet. The method I used to recover installs karnak files on the device. The screen stays black but hacked fastboot still runs.
It may be that the exploit for douglas is worth trying. This is a bit different to karnak in that it repartitions the device and installs TWRP on a secondary position.
Click to expand...
Click to collapse
Promising move. Thanks! :good:
Wish @k4y0z or @xyz could spare some time to look into your hints described here to unlock this 8hd 6th gen bad boy.
Fingers crossed!

drdtyc said:
Promising move. Thanks! :good:
Wish @k4y0z or @xyz could spare some time to look into your hints described here to unlock this 8hd 6th gen bad boy.
Fingers crossed!
Click to expand...
Click to collapse
I have done nothing original really. I am sure those guys you mentioned could make this work (assuming the LK file has the necessary vulnerability) but they may not have the tablet in question, the time and/ or the inclination.

You did a great job. I expect that you only need some operations. To try, I can help you try because I own 3 from Amazon hd8 6th giza

I was thinking of modifying amonet for douglas (HD 8, 2017) and trying it on the 2016 model. This would involve replacing some of the files in amonet/bin with their equivalents from the latest HD 8, 2016 software 'bin' and minor tweaking of the 'step-1' and 'step-2' scripts. This method re-partitions the device to create new 'boot_x' and 'recovery_x' partitions. The partitioning schemes for these two devices are different: they have the same 'by-name' paths, but the 2016 model has some extra partitions, and has a different partition numbering scheme. I am not sure if the amonet (HD 8, 2017) scripts would partition the 2016 device correctly or if they would create an unrecoverable brick. I may try it anyway at some point out of curiosity.

MontysEvilTwin said:
I was thinking of modifying amonet for douglas (HD 8, 2017) and trying it on the 2016 model. This would involve replacing some of the files in amonet/bin with their equivalents from the latest HD 8, 2016 software 'bin' and minor tweaking of the 'step-1' and 'step-2' scripts. This method re-partitions the device to create new 'boot_x' and 'recovery_x' partitions. The partitioning schemes for these two devices are different: they have the same 'by-name' paths, but the 2016 model has some extra partitions, and has a different partition numbering scheme. I am not sure if the amonet (HD 8, 2017) scripts would partition the 2016 device correctly or if they would create an unrecoverable brick. I may try it anyway at some point out of curiosity.
Click to expand...
Click to collapse
Great, as amonet for giza is taking shape!
Would pm @k4y0z get a useful answer of partition schemes ? It is like straight from the horse's mouth, so to speak, as he is the author of those 'step-1' and 'step-2' scripts.
My apologies in advance if this post breaks any etiquette of the XDA forum.

drdtyc said:
Great, as amonet for giza is taking shape!
Would pm @k4y0z get a useful answer of partition schemes ? It is like straight from the horse's mouth, so to speak, as he is the author of those 'step-1' and 'step-2' scripts.
My apologies in advance if this post breaks any etiquette of the XDA forum.
Click to expand...
Click to collapse
Please don't get your hopes up. I am having a look out of interest and to learn a bit, but what needs changing may be beyond me.

MontysEvilTwin said:
Please don't get your hopes up. I am having a look out of interest and to learn a bit, but what needs changing may be beyond me.
Click to expand...
Click to collapse
Good that you are looking into this!
Keep up the good work.
Not all hope is lost yet to unlock this bad boy.
---------- Post added at 05:42 PM ---------- Previous post was at 05:35 PM ----------
https://forum.xda-developers.com/hd8-hd10/general/custom-recovery-rooted-6th-gen-fire-hd-t3540050
This thread discusses the partition structure of several Fire tablets including the 8hd 6th gen. All these are beyond me.
It may be of use to @MontysEvilTwin.
---------- Post added at 05:43 PM ---------- Previous post was at 05:42 PM ----------
https://forum.xda-developers.com/amazon-fire/development/partitions-list-t3236213
This thread lists the partition structure of Fire Android devices.
It may be of use to @MontysEvilTwin.

anyone need help i am ready i have three rooted device from GIZA
regards

Ever since I got the tablet in 2017, I was looking for a way to get TWRP working on this device. Thanks for giving me hope for a a full unlock experience!
I have a rooted device, so feel free to ask me run some commands (that doesn't brick it hopefully, it's my daily driver for stuff)
(I guess it's almost time to start porting LineageOS?)

Unfortunately my attempt has ended in failure. I downloaded amonet-douglas-v1.2 (see here: https://forum.xda-developers.com/showpost.php?p=80154797&postcount=1) and replaced the LK, TZ, and preloader images in the 'bin' folder with those from the latest version of FIre OS for giza (5.3.6.4). I also edited the 'Step-1' and 'Step-2' scripts to allow them to run on the giza (HD 8, 2016). I ran Step-1. Output here:
Code:
[email protected]:~/Downloads/amonet-giza-t2/amonet$ sudo ./step-1.sh
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
Testing root access...
uid=0(root) gid=0(root) context=u:r:init:s0
PL version: 6 (6)
LK version: 1 (2)
TZ version: 258 (259)
Your device will be reset to factory defaults...
Press Enter to Continue...
Dumping GPT
34+0 records in
34+0 records out
17408 bytes transferred in 0.001 secs (17408000 bytes/sec)
97 KB/s (17408 bytes in 0.174s)
Modifying GPT
[2020-06-23 12:47:56.140090] Input GPT:
[2020-06-23 12:47:56.155798]
[2020-06-23 12:47:56.165320] Sector size (logical): 512 bytes
[2020-06-23 12:47:56.181377] Disk identifier (GUID): 0977B6B6-2B39-4075-8CCF-F0F9A3D117CD
[2020-06-23 12:47:56.187570] Partition table holds up to 128 entries
[2020-06-23 12:47:56.192110] This partition table begins at sector 2 and ends at sector 33
[2020-06-23 12:47:56.196498] First usable sector is 34, last usable sector is 30777310
[2020-06-23 12:47:56.201418] Other partition table is at sector 30777343
[2020-06-23 12:47:56.207044]
[2020-06-23 12:47:56.212063] Number Start (sector) End (sector) Size Name
[2020-06-23 12:47:56.270255] 1 1024 7167 3.00 MiB proinfo
[2020-06-23 12:47:56.280114] 2 7168 17407 5.00 MiB nvram
[2020-06-23 12:47:56.294441] 3 17408 37887 10.00 MiB protect1
[2020-06-23 12:47:56.315751] 4 37888 58367 10.00 MiB protect2
[2020-06-23 12:47:56.327317] 5 58368 58879 256.00 KiB seccfg
[2020-06-23 12:47:56.338008] 6 58880 59879 500.00 KiB lk
[2020-06-23 12:47:56.348155] 7 59880 92415 15.89 MiB boot
[2020-06-23 12:47:56.364741] 8 92416 125183 16.00 MiB recovery
[2020-06-23 12:47:56.375237] 9 125184 137471 6.00 MiB secro
[2020-06-23 12:47:56.385676] 10 137472 138495 512.00 KiB para
[2020-06-23 12:47:56.403211] 11 138496 154879 8.00 MiB logo
[2020-06-23 12:47:56.414057] 12 154880 175359 10.00 MiB expdb
[2020-06-23 12:47:56.423967] 13 175360 177407 1024.00 KiB frp
[2020-06-23 12:47:56.446425] 14 177408 187647 5.00 MiB tee1
[2020-06-23 12:47:56.457419] 15 187648 197887 5.00 MiB tee2
[2020-06-23 12:47:56.466734] 16 197888 278527 39.38 MiB metadata
[2020-06-23 12:47:56.486107] 17 278528 280575 1024.00 KiB kb
[2020-06-23 12:47:56.501732] 18 280576 282623 1024.00 KiB dkb
[2020-06-23 12:47:56.511501] 19 282624 3588671 1.58 GiB system
[2020-06-23 12:47:56.534411] 20 3588672 4457023 424.00 MiB cache
[2020-06-23 12:47:56.545231] 21 4457024 4458047 512.00 KiB MISC
[2020-06-23 12:47:56.554629] 22 4458048 4490815 16.00 MiB persisbackup
[2020-06-23 12:47:56.572927] 23 4490816 4499455 4.22 MiB PMT
[2020-06-23 12:47:56.583723] 24 4499456 30777310 12.53 GiB userdata
[2020-06-23 12:47:57.130509]
[2020-06-23 12:47:57.135884] Regenerate primary and backup GPT from input
[2020-06-23 12:47:57.140959] Writing regenerated GPT to gpt-G000KW0463310950/gpt.bin.gpt
[2020-06-23 12:47:57.272546] Writing regenerated backup GPT to gpt-G000KW0463310950/gpt.bin.bak
[2020-06-23 12:47:57.296137] Writing backup GPT offset to gpt-G000KW0463310950/gpt.bin.offset
[2020-06-23 12:47:57.325285]
[2020-06-23 12:47:57.330897] Modified GPT Step 1:
[2020-06-23 12:47:57.351999]
[2020-06-23 12:47:57.358603] Sector size (logical): 512 bytes
[2020-06-23 12:47:57.364570] Disk identifier (GUID): 0977B6B6-2B39-4075-8CCF-F0F9A3D117CD
[2020-06-23 12:47:57.369705] Partition table holds up to 128 entries
[2020-06-23 12:47:57.374261] This partition table begins at sector 2 and ends at sector 33
[2020-06-23 12:47:57.378757] First usable sector is 34, last usable sector is 30777310
[2020-06-23 12:47:57.383981] Other partition table is at sector 30777343
[2020-06-23 12:47:57.389786]
[2020-06-23 12:47:57.396300] Number Start (sector) End (sector) Size Name
[2020-06-23 12:47:57.413002] 1 1024 7167 3.00 MiB proinfo
[2020-06-23 12:47:57.429682] 2 7168 17407 5.00 MiB nvram
[2020-06-23 12:47:57.462799] 3 17408 37887 10.00 MiB protect1
[2020-06-23 12:47:57.479811] 4 37888 58367 10.00 MiB protect2
[2020-06-23 12:47:57.500102] 5 58368 58879 256.00 KiB seccfg
[2020-06-23 12:47:57.513027] 6 58880 59879 500.00 KiB lk
[2020-06-23 12:47:57.521735] 7 59880 92415 15.89 MiB boot
[2020-06-23 12:47:57.530851] 8 92416 125183 16.00 MiB recovery
[2020-06-23 12:47:57.546480] 9 125184 137471 6.00 MiB secro
[2020-06-23 12:47:57.558800] 10 137472 138495 512.00 KiB para
[2020-06-23 12:47:57.567431] 11 138496 154879 8.00 MiB logo
[2020-06-23 12:47:57.583867] 12 154880 175359 10.00 MiB expdb
[2020-06-23 12:47:57.601516] 13 175360 177407 1024.00 KiB frp
[2020-06-23 12:47:57.612980] 14 177408 187647 5.00 MiB tee1
[2020-06-23 12:47:57.622936] 15 187648 197887 5.00 MiB tee2
[2020-06-23 12:47:57.633490] 16 197888 278527 39.38 MiB metadata
[2020-06-23 12:47:57.647775] 17 278528 280575 1024.00 KiB kb
[2020-06-23 12:47:57.659414] 18 280576 282623 1024.00 KiB dkb
[2020-06-23 12:47:57.679812] 19 282624 3588671 1.58 GiB system
[2020-06-23 12:47:57.690797] 20 3588672 4457023 424.00 MiB cache
[2020-06-23 12:47:57.700665] 21 4457024 4458047 512.00 KiB MISC
[2020-06-23 12:47:57.714175] 22 4458048 4490815 16.00 MiB persisbackup
[2020-06-23 12:47:57.730194] 23 4490816 4499455 4.22 MiB PMT
[2020-06-23 12:47:57.739627] 24 4499456 30325759 12.31 GiB userdata
[2020-06-23 12:47:57.749898] 25 30325760 30551039 110.00 MiB boot_tmp
[2020-06-23 12:47:57.759279] 26 30551040 30776319 110.00 MiB recovery_tmp
[2020-06-23 12:47:58.281302]
[2020-06-23 12:47:58.286574] Writing primary GPT (part 1) to gpt-G000KW0463310950/gpt.bin.step1.gpt
[2020-06-23 12:47:58.428890] Writing backup GPT (part 1) to gpt-G000KW0463310950/gpt.bin.step1.bak
[2020-06-23 12:47:58.455505]
[2020-06-23 12:47:58.466746] Modified GPT Step 2:
[2020-06-23 12:47:58.481602]
[2020-06-23 12:47:58.487415] Sector size (logical): 512 bytes
[2020-06-23 12:47:58.492206] Disk identifier (GUID): 0977B6B6-2B39-4075-8CCF-F0F9A3D117CD
[2020-06-23 12:47:58.511517] Partition table holds up to 128 entries
[2020-06-23 12:47:58.518431] This partition table begins at sector 2 and ends at sector 33
[2020-06-23 12:47:58.523640] First usable sector is 34, last usable sector is 30777310
[2020-06-23 12:47:58.529462] Other partition table is at sector 30777343
[2020-06-23 12:47:58.543548]
[2020-06-23 12:47:58.566847] Number Start (sector) End (sector) Size Name
[2020-06-23 12:47:58.578207] 1 1024 7167 3.00 MiB proinfo
[2020-06-23 12:47:58.600018] 2 7168 17407 5.00 MiB nvram
[2020-06-23 12:47:58.621133] 3 17408 37887 10.00 MiB protect1
[2020-06-23 12:47:58.629613] 4 37888 58367 10.00 MiB protect2
[2020-06-23 12:47:58.642478] 5 58368 58879 256.00 KiB seccfg
[2020-06-23 12:47:58.656863] 6 58880 59879 500.00 KiB lk
[2020-06-23 12:47:58.665863] 7 59880 92415 15.89 MiB boot_x
[2020-06-23 12:47:58.674533] 8 92416 125183 16.00 MiB recovery_x
[2020-06-23 12:47:58.686749] 9 125184 137471 6.00 MiB secro
[2020-06-23 12:47:58.713124] 10 137472 138495 512.00 KiB para
[2020-06-23 12:47:58.726349] 11 138496 154879 8.00 MiB logo
[2020-06-23 12:47:58.738046] 12 154880 175359 10.00 MiB expdb
[2020-06-23 12:47:58.764317] 13 175360 177407 1024.00 KiB frp
[2020-06-23 12:47:58.777031] 14 177408 187647 5.00 MiB tee1
[2020-06-23 12:47:58.793473] 15 187648 197887 5.00 MiB tee2
[2020-06-23 12:47:58.805405] 16 197888 278527 39.38 MiB metadata
[2020-06-23 12:47:58.813721] 17 278528 280575 1024.00 KiB kb
[2020-06-23 12:47:58.823369] 18 280576 282623 1024.00 KiB dkb
[2020-06-23 12:47:58.836732] 19 282624 3588671 1.58 GiB system
[2020-06-23 12:47:58.855238] 20 3588672 4457023 424.00 MiB cache
[2020-06-23 12:47:58.868765] 21 4457024 4458047 512.00 KiB MISC
[2020-06-23 12:47:58.895499] 22 4458048 4490815 16.00 MiB persisbackup
[2020-06-23 12:47:58.905577] 23 4490816 4499455 4.22 MiB PMT
[2020-06-23 12:47:58.913732] 24 4499456 30325759 12.31 GiB userdata
[2020-06-23 12:47:58.925229] 25 30325760 30551039 110.00 MiB boot
[2020-06-23 12:47:58.944759] 26 30551040 30776319 110.00 MiB recovery
[2020-06-23 12:47:59.460926]
[2020-06-23 12:47:59.466811] Writing primary GPT (part 2) to gpt-G000KW0463310950/gpt.bin.step2.gpt
[2020-06-23 12:47:59.594491] Writing backup GPT (part 2) to gpt-G000KW0463310950/gpt.bin.step2.bak
Flashing temp GPT
239 KB/s (17408 bytes in 0.070s)
34+0 records in
34+0 records out
17408 bytes transferred in 0.001 secs (17408000 bytes/sec)
Preparing for Factory Reset
Rebooting into Recovery
[email protected]:~/Downloads/amonet-giza-t2/amonet$
This seemed to run OK; the device rebooted and did a factory reset. I then ran Step-2. The output is below:
Code:
[email protected]:~/Downloads/amonet-giza-t2/amonet$ sudo ./step-2.sh
Testing root access...
uid=0(root) gid=0(root) context=u:r:init:s0
Looking for partition-suffix
lrwxrwxrwx root root 2020-06-23 11:48 recovery_tmp -> /dev/block/mmcblk0p26
Flashing exploit
57 KB/s (4096 bytes in 0.069s)
3563 KB/s (492132 bytes in 0.134s)
8+0 records in
8+0 records out
4096 bytes transferred in 0.001 secs (4096000 bytes/sec)
961+1 records in
961+1 records out
492132 bytes transferred in 0.035 secs (14060914 bytes/sec)
8+0 records in
8+0 records out
4096 bytes transferred in 0.002 secs (2048000 bytes/sec)
961+1 records in
961+1 records out
492132 bytes transferred in 0.034 secs (14474470 bytes/sec)
Flashing LK
3589 KB/s (487392 bytes in 0.132s)
951+1 records in
951+1 records out
487392 bytes transferred in 0.040 secs (12184800 bytes/sec)
Flashing TZ
3689 KB/s (3307008 bytes in 0.875s)
6459+0 records in
6459+0 records out
3307008 bytes transferred in 0.270 secs (12248177 bytes/sec)
6459+0 records in
6459+0 records out
3307008 bytes transferred in 0.325 secs (10175409 bytes/sec)
Flashing Preloader
44 KB/s (2048 bytes in 0.044s)
44 KB/s (2048 bytes in 0.044s)
1706 KB/s (138924 bytes in 0.079s)
4+0 records in
4+0 records out
2048 bytes transferred in 0.056 secs (36571 bytes/sec)
4+0 records in
4+0 records out
2048 bytes transferred in 0.059 secs (34711 bytes/sec)
271+1 records in
271+1 records out
138924 bytes transferred in 0.067 secs (2073492 bytes/sec)
271+1 records in
271+1 records out
138924 bytes transferred in 0.018 secs (7718000 bytes/sec)
Flashing final GPT
350 KB/s (17408 bytes in 0.048s)
34+0 records in
34+0 records out
17408 bytes transferred in 0.002 secs (8704000 bytes/sec)
Flashing final GPT (backup)
335 KB/s (16896 bytes in 0.049s)
33+0 records in
33+0 records out
16896 bytes transferred in 0.002 secs (8448000 bytes/sec)
Flashing TWRP
3565 KB/s (13512704 bytes in 3.701s)
26392+0 records in
26392+0 records out
13512704 bytes transferred in 1.596 secs (8466606 bytes/sec)
Rebooting into TWRP
[email protected]:~/Downloads/amonet-giza-t2/amonet$
Unfortunately, after rebooting the device got stuck on the white Amazon logo. I attempted to recover using the original debrick method for douglas (a reworking of the original karnak unlock method) modified for giza: see here (https://forum.xda-developers.com/showpost.php?p=78853205&postcount=1) However the bottom write method fell over; the device failed a gpt check:
Code:
[email protected]:/media/x/SD Card/Giza-Restore/amonet$ sudo ./bootrom-step.sh
[2020-06-23 15:30:19.049767] Waiting for bootrom
[2020-06-23 15:30:33.527575] Found port = /dev/ttyACM0
[2020-06-23 15:30:33.542589] Handshake
[2020-06-23 15:30:33.581694] Disable watchdog
* * * Remove the short and press Enter * * *
[2020-06-23 15:30:35.884990] Init crypto engine
[2020-06-23 15:30:36.034842] Disable caches
[2020-06-23 15:30:36.044648] Disable bootrom range checks
[2020-06-23 15:30:36.161904] Load payload from ../brom-payload/build/payload.bin = 0x4690 bytes
[2020-06-23 15:30:36.205440] Send payload
[2020-06-23 15:30:40.773015] Let's rock
[2020-06-23 15:30:40.788256] Wait for the payload to come online...
[2020-06-23 15:30:41.517972] all good
[2020-06-23 15:30:41.527461] Check GPT
[2020-06-23 15:30:41.888837] gpt_parsed = {'tee1': (177408, 10240), 'boot_x': (59880, 32536), 'nvram': (7168, 10240), 'frp': (175360, 2048), 'metadata': (197888, 80640), 'protect1': (17408, 20480), 'protect2': (37888, 20480), 'logo': (138496, 16384), 'tee2': (187648, 10240), 'secro': (125184, 12288), 'expdb': (154880, 20480), 'seccfg': (58368, 512), 'proinfo': (1024, 6144), 'lk': (58880, 1000), 'recovery_x': (92416, 32768), 'para': (137472, 1024)}
Traceback (most recent call last):
File "main.py", line 123, in <module>
main()
File "main.py", line 69, in main
raise RuntimeError("bad gpt")
RuntimeError: bad gpt
[email protected]:/media/x/SD Card/Giza-Restore/amonet$
Is there anything I can do to restore this tablet?

Looks like the device now has 'boot_x' and 'recovery_x' partitions but no boot or recovery. I can get bootrom working (by modifying 'main.py') but can't get into fastboot. Is it possible to rename the '_x' partitions directly through bootrom? Or is there another clever way?