[Android General] limited_imagination:
Hi PW, just like [MENTION=9720847]AeonFlux1603[/MENTION], I was down with a raging flu & fever, and all my work and correspondence backed up.

Unfortunately, since my last post, I have to report that my device still freezes at the Lenovo boot logo.

You recall that I previously tried fix my issue by using SP Flash Tool ver. 5.1824.00 to reflash only the stock boot partition, from the ROM available at the Russian Lenovo forum (TB3-850F_S100030_161209_ROW).

But that first attempt did not fix the problem. The device would not get past the Lenovo logo screen, either in a regular boot or in TWRP recovery, no matter what button-pushing tapdance I tried with the volume and power buttons. And unlike the adb tool, the SP Flash Tool does not seem to have a command with the ability to reboot the device into recovery or fastboot, so it's all down to the physical buttons. That's notoriously hard to do even with a working TB3-850F, as others have commented in this thread, and with mine it proved impossible. I can't get any PC communication with the device in adb or fastboot, nothing shows up with "adb devices" or "fastboot devices". So SPFT is the only potentially useful tool for PC communication.

For my second attempt, I used SP Flash Tool to flash over all the other partitions except for the recovery, in order to preserve TWRP on the device, on the off chance that I could get TWRP to start. So from the stock ROM available at the Russian Lenovo forum, that meant the following partitions were flashed on my device: preloader, lk, boot, logo, secro, and cache.

That still was not enough to get the thing to boot normally, or start TWRP, no matter what button-pushing tapdance I tried. So I then went ahead and tried a third step, using the SP Flash Tool to flash the stock Chinese recovery partition too, just on the off chance it needed every single partition in agreement from the same ROM. So that means that I now have all these partitions successfully flashed via SPFT, from the stock ROM: preloader, lk, boot, recovery, logo, secro, and cache. SPFT reports the hex addresses of four other partitions, but strangely, SPFT does not does not give me an option to flash any data from the ROM file to them (ie. tee1, tee2, system and userdata).

Actually, on review of the contents of the actual ROM file folders, I see a "userdata-sign.img" file of 42.8 MB, and a "system-sign.img" file of 2.8 GB, which for some reason don't show up in SPFT under the "download" tab ... maybe this is the problem??? Hmm. Worth further investigation before I dismantle this thing.

Anyway, no dice after those 2 attempts with SPFT. It still just hangs on the Lenovo logo screen, even with all partitions flashed from the stock ROM via SPFT. I can't get the stock Chinese recovery to start, either.

So I think I'm at the stage of pulling the screen off this device, to reanimate the TB3-850F that I have with a smashed screen. Hard to get enthusiastic about that job, but I will do it as time permits.

Notwithstanding this result, I put the whole thing down to a learning experience, and well worth the (cheap) price of a TB3-850F. I regret nothing... https://youtu.be/JKPvx38D4GM

The most surprising thing to me was that flashing the boot image was a 1-way trip. I thought if my custom boot image was bad, then I would get away with just flashing a stock backup over it. This proves not to be the case, and that's worth knowing in terms of risk assessment for any future efforts.

So, let's do an autopsy. Where could it have gone wrong?

First stage, obviously, I could have screwed up right from the kernel compile process. Several warnings were issued during the compile process, as you can see in the log that I attached to post #523 in this thread. I had removed the "-Werror" flags from the original source code, which was forcing all warnings to be treated as errors and so it stopped the compile. Additionally, as you see in my post #519, I executed the "make" command with the "-i" option (ie. "--ignore-errors") and also CONFIG_NO_ERROR_ON_MISMATCH=y (ie. ignore the 59 section mismatches). So you can't say I wasn't warned, as I intentionally pulled out all the safety stops for the compile to work. But even so, I thought the kernel so built had a fighting chance to work on the device, and it was worth trying. Unfortunately, I don't think we can say one way or the other at this point.

The second stage I could have failed, would be creating the boot.img with Android Image Kitchen. I had very limited experience with this previously, and you can check my steps in post #530 of this thread. My gut feeling is that this is where it went so badly wrong as to make it impossible to recover even by reflashing the stock ROM. Using Android Image Kitchen, I unpacked and modified the boot partition file that I had backed up from my device with TWRP, but maybe I should have worked with the stock ROM boot partition file instead. They are not identical. TWRP created a backup file called boot.emmc.win of 16.8 MB in size, but the stock ROM contains boot-sign.img file of only about 9 MB in size. The AIK unpackimg script works on the boot.emmc.win file, but it does not work on the boot-sign.img file, and it just returns an unrecognized format error. Furthermore, the AIK repack command did generate an odd error when it tried to sign the new boot image file with AVB boot, as I mentioned in post #530, and I don't know what the implications of that are. Obviously the stock boot-sign.img file was signed in some way at the factory, which my modified boot image was not. Any comment here, especially by [MENTION=8548258]wezroot2k[/MENTION] who obviously has more experience repacking with AIK than I do, is welcome.

The third stage I could have failed, would be the actual flashing of the boot partition with TWRP. As mentioned in post #530 in this thread, I told TWRP to restore a backup of the boot partition, but the "restoration" file was actually my own modified boot.emmc.win, repacked with the new kernel by Android Image Kitchen. I notice that TWRP created an .md5 checksum file when it backed up each partition, and obviously that checksum for my modified boot.emmc.win would not match the original TWRP boot.emmc.win file. Maybe "restore" was not the correct method of using TWRP to flash the boot partition?

Anyway, those are my thoughts at present. Further experiments by me will have to await either swapping the screen of this device to the other one with the smashed screen, or again fooling with SPFT to see why not all of the partitions included in the Russian stock ROM are showing up as available to be flashed to the device. Any brilliant ideas here, please sing out.

---------- Post added at 03:20 AM ---------- Previous post was at 02:20 AM ----------

Holy crap, that was it. I've restored it!

The Russian ROM contained an earlier version of SPFT, ver. 5.1604.00, and when I ran that one, it located all the partition files that could be flashed to the device.

No missing system and cache partition files, as was the case when I was using ver 5.18.24 of SPFT, for some unknown reason.

I flashed every partition available in the ROM, and now I'm back in business. I will have to re-root and reinstall TWRP, but that should be cake, relatively speaking.

Man, it was so worth writing that wall of text, rehearsing every step of the way I had moved, because in the end that's what saved me!