Run "fptw -i" command and show me a picture. At the dump image you provided there are some weird things. The Flash Descriptor points to a wrong BIOS starting offset. It says that the BIOS starts at 0x500000 even though it starts at 0x580000. The first address points to somewhere inside the ME region, which does not make sense. That should be the reason behind the failure to perform a general reset (-greset). Once the BIOS start offset is fixed, I noticed via UEFITool that two BIOS modules have incorrect checksums which I also fixed by rebuilding them with the same tool. Now the image can be properly read by all tools such as UEFITool, MMTool and Flash Image Tool. So the next step is to fix the ME by following the cleanup guide & disabling the defunct/problematic Intel Anti-Theft technology. Problem is, I don't think that the ME configuration (DATA) settings are read properly. This is probably due to a corrupted ME region and not because of the old FITC version that we have for ME6 (we have 6.0.40, still newer than Lenovo's 6.0.31 firmware). I'd like to check another dump from such a system to see if these problems I've seen are a one time thing. From what I can read, these issues are universal. The SPI image of these systems was messed up from the factory. It seems that Lenovo had also recalled a lot of these machines due to fire hazard back in the day even though that is not really related to this extra issue. Not a very successful machine apparently.

Anyway, what I suggest is for you to first flash the "fix_1" image I've build and attached which has a proper BIOS start and corrected BIOS module checksums. It's probably the wrong BIOS address which causes all these issues. After you flash it, remove the jumper and restart. Then post another picture of "fptw -i" and retry "fptw -greset". If after the reset the problem remains, we'll need to clean/fix the ME region as well. But I'm not very confident doing that as long as Flash Image Tool cannot properly detect the ME region's OEM settings/configuration. We will try it though if "fix_1" fails.

What I said can also be seen at the "fptw -i" picture, the ME ends at 0x580000 whereas the BIOS starts at 0x500000 instead of 0x580000. That BIOS access error you get might be an actual implemented security measure or could be due to the broken BIOS start offset at the Flash Descriptor. You can reflash/fix the FD and after a restart reflash the BIOS by using "fptw -f desc_fix.bin -desc" and "fptw -f bios_fix.bin -bios" commands respectively. Remove the ME_Disable jumper and test again after another restart.

So the system boots with the jumper set but it doesn't otherwise? Check the manual to see what these beeps mean.

We should have tried the FD fix only for starters. Maybe the two small BIOS checksum fixes caused this. If the system worked after fixing the FD but not after BIOS then it's surely that. When you flashed the BIOS only, it worked, right? Meaning, it didn't complain about protected ranges? In such case, that previous error was indeed due to the FD mess-up. But that doesn't change the fact that the BIOS probably needs a reflash now. Try a clear CMOS first just in case but I doubt it will help with the current problem. Hopefully you can recover the BIOS via whatever method Lenovo has implemented. If you do, leave the BIOS as it is and check if the FD is fixed by running "fptw -i" command. To not have to mess with the ME and figure out why the settings are not read properly by FITC, we would need the wrong BIOS offset at FD to be the cause of your initial troubles.

You have an AMI bios. At the Lenovo M90z Hardware Maintenance Manual, you will find the procedure on how to repair a bad BIOS flash at pages 274-275. These steps assume you have created a BIOS update optical disc, instructions for which can be found at pages 273-274. Lenovo includes the BIOS region only at their updates so it should only affect the BIOS and not the fixed FD. What's interesting is that the stock Lenovo BIOS does not show any checksum errors at UEFITool, which good and the opposite of your own dump.