Lenovo P50 Bricked by BIOS update

[IanP50]

@lfb6 - Looks like using the Lenovo bios update utility has closed down some of the security.

I’m getting this error when I try to flash with fpt:

Error 368: Failed to disable write protection for the BIOS space.
FPT Operation Failed.

That’s a shame, as I really didn’t want to strip the laptop down again.

Interesting about external ports being routed through the discrete GPU. As you say, that would tie in with what I’m seeing. I don’t think the discrete GPU is completely dead, as it does show up if I scan with HWiNFO64. Interestingly, this shows the GPU also has some sort of bios. Not sure we can do much with it though.

I haven’t changed any Thunderbolt settings in bios, and don’t have any Thunderbolt devices. I did update the Thunderbolt firmware yesterday, but it made no difference.

Thanks,
Ian.

[lfb6]

@IanP50 Same security was there before bios update. Disabling bios safety would require testing/ flashing different versions, too.

Interesting that you can see the Nvidia device in HwInfo but not in device manager! These devices have their own OROM (bios) for legacy boot and a GOP driver/ GOP VBT for UEFI boot built into system bios. But the video bios information in you screenshot is ‘pretty much Intel’, that’s the Intel legacy video bios/OROM (in 6A5F1EF9-C478-42BA-A4DB-C7846CC7DB57). The video bios for GM 107 (B17608F9-E955-4DA8-8762-03AE634A52EB) has version 82.07.9D.00.14 - but device- ID and Nvidia driver seem to be correct.

There might be the possibility, that Windows got ‘confused’ as well. What information about display adapters is in device manager now? Please check events, too, sometimes Windows recognizes devices wrongly as different device ‘known from before’.

EDIT Regarding “external display ports are routed/ powered through the discrete GPU”: This wouldn’t correspond to the setups referred to when explaining Optimus, muxed and muxless.

[IanP50]

@lfb6 - Here’s what I see in Device Manager.

It’s not repeatable, but I have been able to get rid of the Code 43 error by disabling and then re-enabling the device. That said, It won’t do it now. Even when the error wasn’t showing, I still didn’t have external displays.

I’m starting to think that I do have a hardware problem.

I’ve had a look through the Event Viewer logs, and can’t see any reference to this problem. Searching for ‘Code 43’ finds nothing either.

Thanks,
Ian.

[Lost_N_BIOS]

@IanP50 - Try remove the device in device manager (Delete driver is asked).
I would actually uninstall the Nvidia driver and clean with driver cleaner first, then boot to windows, and uninstall device from device manager (then also delete driver if asked), then reboot and re-scan for changes if it does not auto-reinstall.
Then install nvidia driver again and see if fixed.

Did you maybe bump card while inside, little loose maybe, or was it part of the PCB itself? I think it’s a MXM card, so should be removable, but you’d have to pull off heatsink to reseat the card.
Did you ever dump other chips? It’s possible the EC FW was messed up during the initial brick, it would be on a similar chip as the BIOS possibly (unless in QFP Package), 128K-1MB usually.

vBIOS itself (For several models) is within the main BIOS region, inside the main DXE volume, so it should not be messed up

We can get past error 368 possibly, but it may leave error 167 or 28 and still require flash programmer, hard to know without trying.
Also, you may be able to flash certain volumes in the BIOS region, without flashing it all at once, and not have any error (Please show me image result >> FPTw.exe -i)
Keep Boot Guard is enabled in mind here, you cannot edit/change any colored area of the BIOS as seen in UEFITool NE or = brick

To try and bypass 368 without flash programmer, you can either do yourself with RU method, or you can dump vars via H2OUVE and send to me and I will edit, then you program back, both methods info below
Or, it may be possibly without either of the below, if your BIOS has S3 sleep bug >> Put system to Sleep (S3, not hibernate) for one minute, then wake it up and try again, if you still get error 368 move onto next, your BIOS does not have the bug

RU method to unlock BIOS Lock is here, Go to section 2.2 and make bootable USB with RU program, then read 2.3-2.5
http://forum.notebookreview.com/threads/…-issues.812372/

You will change the following, and you will NOT be making the change in “Setup” as discussed in the guide
BIOS Lock, VarStoreInfo (VarOffset/VarName): 0x14
Location you need to make edit in >> “PCHSetup” >> GUID >> 4570B7F1-ADE8-4943-8DC3-406472842384

Change offset 0x14 (Line 10, out to column 4 = 0x14), change 01 to 00 (If already 00, then nothing to do here, programmer required, or pinmod may work as well to unlock FD, if lock in FD is only one preventing BIOS region flash)

Dump vars method >> download the following package, and run the command below from each versions folder that directly contains it’s exe. Before doing this, make sure you have secure boot disabled in BIOS, any BIOS password removed, and TPM/Encryption disabled.
Once done, copy the entire folder somewhere, delete everything but any created vars.txt and then repackage this and send to me, this way all created vars.txt remain in place in the folders of the version that created them.

https://www.sendspace.com/file/8v98ya

H2OUVE.exe -gv vars.txt

[lfb6]

@IanP50 You normally don’t have to scroll/ search through the event viewer. Device manager, open device, tab ‘events’, klick on ‘view all events’ should give you the list to all events related to that device.

There should at least be some warnings. Check both Intel and Nvidia. I’d like to see the last 3 to 4 entries on the events tab for both devices, if possible. Code 43 means 'driver reported problem, that could mean a lot of things…

I’d still give the ‘good bios’ with own parts a try- but I understand that disassembling isn’t a very attractive option right now.


@Lost_N_BIOS Nvidia chip is on mainboard, nothing to change/ remove/ reseat.

EC firmware is first MB of Bios region (in paddng), do you think there is another/ second location? TPM has it’s own firmware, and Thunderbolt chip has own firmware, this chip is known to brick if filled with garbage, but was never in use here?

[IanP50]

@Lost_N_BIOS - I’ve tried removing/deleting the driver multiple times, but the outcome is the same.

There’s no way to even see the Nvidia GPU without removing the fan assembly. Even then it’s soldered directly onto the motherboard, so I can’t really do anything with the hardware.

Thanks for all the detail about flashing the bios. I think it’s probably easier for me to just take it all apart again. I’m getting pretty good at it now.

@lfb6 - Wow, you do indeed learn something new every day. I didn’t know you could show Event Viewer entries like that.

Just noticed that both the Intel and Nvidia are showing the same error.

Intel - Device PCI\VEN_8086&DEV_191B&SUBSYS_222E17AA&REV_06\3&e89b380&0&10 requires further installation.
Nvidia - Device PCI\VEN_10DE&DEV_13B0&SUBSYS_222E17AA&REV_A2\4&374f1360&0&0008 requires further installation.

Event Viewer doesn’t show any errors or warning for the Intel, but this is what I get for the Nvidia.

My brother suggested trying to boot into Ubuntu (Linux) from a USB drive, as this would completely bypass the system bios, and would be another way to test the hardware. I gave it a try, but it failed to run with the error:

I can’t find much info on this error, but someone suggested that ‘nouveau’ was something to do with Nvidia. I tried the same Ubuntu USB drive on an older Lenovo T510, and that ran fine, so it still points to a hardware problem.

I’ll try flashing the other ‘good bios’ and see what happens.

P.S. How do you embed those small clickable images on this forum. I’ve found the spoilers, but can’t see how this is done.

Thanks,
Ian.

[lfb6]

@IanP50 Thanks.

I still think it’s ‘bios’/ bios settings. The ‘Good bios’ has one entry pchsetup in NVRAM, your latest dump has 5 entries that contain pchsetup in the header, but all are ‘invalid’. The PCH is quite a central element, I’d think it might have some tasks in connecting graphics, too. Maybe it’s just not initialised properly?

That’s a thing I disagree with your brother. Hardware initialisation is done by bios, distributing PCIe lines for example and such things can’t be undone/ changed by OS afaik.

‘Require further installation’- that’s always the first entry when Windows finds out that the devuce needs a driver. In device manager you have to scroll down to see latest entry. One of the first entries almost always will be “requires further installation”.

Pictures: The easiest way is to have them in the forum, means to attach them. This way the posts remain consistent/ complete even if you some time begin to clean up your image ‘cloud’. On the other hand there are now some pictures and bios dumps here which have for example you serial and embedded Windows license. (But there’s no limit for time to edit posts.)
=> Attach file, Browse, Upload, Insert

[Lost_N_BIOS]

@lfb6 - EC FW in BIOS may be copy, it’s also in stock BIOS package separately, that’s why I asked if he saw or dumped any other similar to BIOS SOIC8 chips.
He should look on board if he did not dump or check before, hopefully if this is part of the issue, the EC FW is in SOIC package not QFP. Yes, often EC FW/KBC FW is in it’s own chip, and only in BIOS as copy (like some BIOS have ME FW backup file too)
If GPU is part of the main PCB then yeah, nothing to worry about there! I was not sure due to vBIOS modules in BIOS all named MXMxxxx

What is current final state in BIOS now of bytes following “LNVBBSEC” and “INVALIDINVALID”?
If they do not match original BIOS content, these should be put back first, this may be the issue
Byte following “LNVBBSEC” >> FB
Bytes following “INVALIDINVALID” >> 15 DF 01 49 81 B0 29 8D 69

* Edit - Hmm, what you found above about PCHSetup in NVRAM is not good, at least one should be valid or yes as you suspect that may be an issue


@IanP50 - Thanks for confirmation about your testing removal of drivers and such, does that include actual “Removal” of device via device manager and rebooting too, or just driver removals?
This is two very different things, I was suggesting removing/cleaning driver and also remove device in device manager (and driver if asked)
I think the issue may be above, since I think I remember you guys wanting to leave that as is from the stock BIOS recovery stuff, but I’m not 100% sure what’s in BIOS now.

To embed image, you need to use the attach function located in advanced reply >> Button on far right at each post, in there you will find attach button far right as well
Guide/info here - [Guide] How to insert pictures or attach files to a post

[lfb6]

@Lost_N_BIOS Last state was ‘own padding restored’. But maybe it was an error to begin with a stock bios without this information… But a valid pchsetup should be in NVRAM in any case.

Byte following “LNVBBSEC” >> FB
Bytes following “INVALIDINVALID” >> 15 DF 01 49 81 B0 29 8D 69

[IanP50]

@lfb6 - I’ll tear the machine down this evening and flash the other ‘good’ bios’. Hopefully this will improve things. I think I also disagree with my brother. If you look at the details on the Lenovo bios download page, it does list bios updates for Linux systems.

@Lost_N_BIOS - Sorry, forgot to mention that I didn’t dump any other chips from the motherboard. Most of the board is covered in a black protective cover which I didn’t remove. Not sure if there are other SOIC type chips fitted. I’ll have a look later.

PCH sounds promising.

I completely removed the Nvidia driver. I completely removed it in device manager, and then used a program called DDU to completely remove everything. System was rebooted, and windows installed new driver.

Thanks,
Ian.

[lfb6]

I’m sorry, the PCHSetup story isn’t completely true, in the now used bios there is one pchsetup (unsure why I didn’t find it when I searched first time), but there are also 5 invalid entries which have same GUID- all 6 have 4570B7F1-ADE8-4943-8DC3-406472842384.

The 2 pchsetup from IanP50s bricked bios and the ‘good bios’ are quite similar (Length 5A4):
00000071: 00 01
00000074: 01 00

’now used’ to bricked:
00000037: 01 00
0000003B: 00 01
000000A1: 04 00
000000A2: 01 00
000000A3: 01 00
000000A4: 03 00
000000A5: 04 00
000002BF: 01 00
000002C0: 02 00
000002C4: 04 00
000002C8: 04 00

All five copies of 4570B7F1-ADE8-4943-8DC3-406472842384 in ‘now used’ are different and different to the one PCHsetup from ‘now used’, too. All 5 copies are different to PCHsetup from bricked/ good, too. Seems as if the system generated several copies for different configurations in the beginning? Bricked and good bios have only one single entry in NVRAM with this GUID.

Comparing files 1iv.vss and 2IV.VSS
00000082: 01 00
00000083: 01 00
00000084: 01 00
00000086: 01 00
00000087: 01 00
00000088: 01 00

Comparing files 1iv.vss and 3IV.VSS
00000037: 00 01
00000071: 00 01
00000073: 00 01
00000075: 00 01
000000A1: 00 04
000000A2: 00 01
000000A3: 00 01
000000A4: 00 03
000000A5: 00 04
000000AE: 00 01
00000100: 04 02
000002BF: 00 01
000002C0: 00 02
000002C4: 00 04
000002C8: 00 04

Comparing files 1iv.vss and 4IV.VSS
00000037: 00 01
00000071: 00 01
00000073: 00 01
00000075: 00 01
000000A1: 00 04
000000A2: 00 01
000000A3: 00 01
000000A4: 00 03
000000A5: 00 04
000002BF: 00 01
000002C0: 00 02
000002C4: 00 04
000002C8: 00 04

Comparing files 1iv.vss and 5IV.VSS
00000037: 00 01
000000A1: 00 04
000000A2: 00 01
000000A3: 00 01
000000A4: 00 03
000000A5: 00 04
000002BF: 00 01
000002C0: 00 02
000002C4: 00 04
000002C8: 00 04

Comparing files 1iv.vss and NOW_4570B7F1-ADE8-4943-8DC3-406472842384.VSS
00000002: 3C 3F
00000037: 00 01
00000082: 01 00
00000083: 01 00
00000084: 01 00
00000086: 01 00
00000087: 01 00
00000088: 01 00
000000A1: 00 04
000000A2: 00 01
000000A3: 00 01
000000A4: 00 03
000000A5: 00 04
000002BF: 00 01
000002C0: 00 02
000002C4: 00 04
000002C8: 00 04

Comparing files 1iv.vss and BRICKED_4570B7F1-ADE8-4943-8DC3-406472842384_PCHSETUP.VSS
00000002: 3C 3F
0000003B: 00 01
00000082: 01 00
00000083: 01 00
00000084: 01 00
00000086: 01 00
00000087: 01 00
00000088: 01 00

Comparing files 2iv.vss and BRICKED_4570B7F1-ADE8-4943-8DC3-406472842384_PCHSETUP.VSS
00000002: 3C 3F
0000003B: 00 01

Comparing files 3iv.vss and BRICKED_4570B7F1-ADE8-4943-8DC3-406472842384_PCHSETUP.VSS
00000002: 3C 3F
00000037: 01 00
0000003B: 00 01
00000071: 01 00
00000073: 01 00
00000075: 01 00
00000082: 01 00
00000083: 01 00
00000084: 01 00
00000086: 01 00
00000087: 01 00
00000088: 01 00
000000A1: 04 00
000000A2: 01 00
000000A3: 01 00
000000A4: 03 00
000000A5: 04 00
000000AE: 01 00
00000100: 02 04
000002BF: 01 00
000002C0: 02 00
000002C4: 04 00
000002C8: 04 00

Comparing files 4iv.vss and BRICKED_4570B7F1-ADE8-4943-8DC3-406472842384_PCHSETUP.VSS
00000002: 3C 3F
00000037: 01 00
0000003B: 00 01
00000071: 01 00
00000073: 01 00
00000075: 01 00
00000082: 01 00
00000083: 01 00
00000084: 01 00
00000086: 01 00
00000087: 01 00
00000088: 01 00
000000A1: 04 00
000000A2: 01 00
000000A3: 01 00
000000A4: 03 00
000000A5: 04 00
000002BF: 01 00
000002C0: 02 00
000002C4: 04 00
000002C8: 04 00

Comparing files 5iv.vss and BRICKED_4570B7F1-ADE8-4943-8DC3-406472842384_PCHSETUP.VSS
00000002: 3C 3F
00000037: 01 00
0000003B: 00 01
00000082: 01 00
00000083: 01 00
00000084: 01 00
00000086: 01 00
00000087: 01 00
00000088: 01 00
000000A1: 04 00
000000A2: 01 00
000000A3: 01 00
000000A4: 03 00
000000A5: 04 00
000002BF: 01 00
000002C0: 02 00
000002C4: 04 00
000002C8: 04 00

[Lost_N_BIOS]

@lfb6 - Thanks for confirmation! Yes, I considered maybe the dumped data from bricked BIOS is not correct, so I checked two other dumps, and from those I can only gather that the LNVBBSEC followign byte should be FB
The bytes following INVALIDINVALID do not match in ANY BIOS I check, except maybe one byte “B0” matches @User32 dump that I have (his bytes = 2F 84 5B 0B 5F 55 B0 70 01 8A) So may be worth testing this just to rule it out, then if no change put back to original.
And yes, I agree, valid PCHSetup entry is critical in NVRAM, if it should be there. I’m not seeing this though, in either “Good” dump I have, the one IanP50 posted here or User32’s - Show me what you’re looking at please and thanks Maybe I’m blind… (probably)
Ohh, I see in VSS2 store, I was thinking actual NVRAM modules that are outside of VSS2 store (like RTC, DB, KEK, PK etc - Like all those are what I expected you were talking about, don’t see any in either good BIOS for PCHSetup, which is unexpected really.)

@IanP50 - Yes, if you don’t mind looking, it may be good idea to check for other chips and dump if you find, in case one is EC FW we can look and see if it’s corrupted or not, or at least if it looks similar to the copy in BIOS.
While we’re discussing this, are you now on the same BIOS version that you was at time of brick? Often BIOS and EC FW need to match, so if BIOS update process bricked the EC FW or never got to flash it, then it may be older version still (or corrupted etc)
So that’s another reason we should check, if we can find and dump it. Sometimes this is stored in QFP package though, or QFN, Quad Flat package is square chip with usually 32-64 contacts all around, QFN similar but all are under it
These are not something you can program via programmer unless done via KB ribbon cable method (which I don’t know how, only know about)

Thanks for confirmation of what you did in regards to driver. That means you did not try what I mentioned initially.
First, uninstall nvidia driver, and to DDU cleaner, then boot to OS and “Remove” the device in device manager (uninstall it, remove driver if asked, then reboot)

[lfb6]

@Lost_N_BIOS EC firmware is unchanged version to pre brick, but IanP50 updated from 59 to 62 and update contains EC firmware.

Package BIOS ECP
1.62 1.62 (N1EET89W) 1.18 (N1EHT38W)
1.60 1.60 (N1EET87W) 1.18 (N1EHT38W)
1.59 1.59 (N1EET86W) 1.18 (N1EHT38W)

Where do you see NVRAM modules that are outside of these both VSS2 stores?


@InaP50 “My brother suggested trying to boot into Ubuntu (Linux) from a USB drive, as this would completely bypass the system bios, …” Well, if Linux bypasses your bios you could’ve easily started Linux with your bricked machine. Hradware initialisation is done by bios/ UEFI firmware for every OS! (It’s called ‘bricked’ for a reason)

Good luck for the flash! I’d suggest the bios region from #78 combined with your own FD/GbE/ME (first 7 MB).

[IanP50]

@Lost_N_BIOS - I’ll have a look for other chips tonight, and dump any I find. I’ll also go back through the removal procedure again, and do exactly how you explained it.

As per lfb6’s last post, I updated from 1.59 to 1.62 when we thought we’d got everything fixed.

@lfb6 - I didn’t understand a lot of what you wrote, but I thank you for it anyway. I hope it makes more sense to lost_N_BIOS.

Thanks,
Ian.

[Lost_N_BIOS]

@lfb6 - As mentioned, it’s very likely the EC FW in BIOS may not be the one used, it may be in another chip. Version may not indicate changes in there or not, and what’s in chip may be corrupted too.
So what’s in that chip needs to be checked, to see what is actually there. Then, we can further discuss what’s going on, if anything, with EC FW

The entire NVRAM volume contains MANY entries that are not inside VSS2, all that stuff above VSS2, like what I mentioned above, is an NVRAM store/entry.
Ohh, I see what you mean now! I was talking about the all the stuff in the expandable VSS2 vs the non-expandable VSS2 module
PCHSetup is NOT a stand alone store/entry in the expandable area as I expected to find when you guys were discussing this, and then I did not see in other good dumps either, which is surprising.


@IanP50 - Yes, please do. What I suggested not only removes the driver (which is all you had done till now), but also removes the device from windows and forces a reinstall of the actual device (not the driver only)

[lfb6]

@Lost_N_BIOS Would you please give me a hint which areas you mean? I identified the first volume with the 2 VSS2 stores, the FTW store and the EVSA store as NVRAM. Where can I find other parts of NVRAM?

Otherwise you have possibly read this document, nice explanation of P50 EC firmware update process: https://i.blackhat.com/USA-19/Thursday/u…-Controller.pdf

@IanP50 Chip for ME would possibly be MEC1653 (BGA chip?)

[Lost_N_BIOS]

@lfb6 - I’m talking about the VSS2 expandable stores, above what you are showing expanded in that image (And then non-expandable VSS2 only in bricked, other users known good dumps, or stock BIOS etc)
I have not seen/looked at the BIOS you are showing there, in the two VSS2 at top, is there PCHSetup entries?

Thanks for link at blackhat, I will check. That’s usually about hacking, and hopefully his EC FW is on SOIC chip, if his EC FW is messed up

ME FW is in the main BIOS chip only, so no other chip. Not sure what you meant about MEC1653, but if there is a chip there it’s not ME FW

@IanP50 - Did you test this graphics/monitor thing, before you updated to 1.62 BIOS?
If not, go back to older BIOS, and check, maybe it’s a BIOS bug, or some changed hidden or visible setting in BIOS is different than in the older BIOS you were originally using

[lfb6]

@Lost_N_BIOS MEC1653 is mentioned as chip for EC in the blackhat pdf- MEC1653 picture

The complete NVRAM stores were different with a masses of ‘invalid’ VSS entries after using stock bios without using the bytes following “LNVBBSEC” and “INVALIDINVALID” Those bytes were restored before updating to 1.62. NVRAM has still a lot more ‘invalid’ VSS entries than bricked and found good bios.

(Successfull) Steps were:

1.) Stock bios 1.59 with empty NVRAM (FD, ME, GbE from bricked bios) NO bytes following “LNVBBSEC” and “INVALIDINVALID” changed, all FF

masses of ‘invalid’ VSS entries

2.) Dumped bios 1.59 with freshly populated NVRAM VSS2 stores. EVSA store from bricked inserted. NO bytes following “LNVBBSEC” and “INVALIDINVALID” changed, all FF

3.) Newly dumped bios 1.59, now “FB” after “LNVBBSEC” and “15 DF 01 49 81 B0 29 8D 69 F5” after “INVALIDINVALID” put in place.

4.) Update to 1.62 after all seemed to work. BUT still large differences in NVRAM structure.

That’s the reason why I proposed to try with the ‘Good bios’ region with transfered personal EVSA store and original sequences LNVBBSEC"FB" and "INVALIDINVALID “15 DF 01 49 81 B0 29 8D 69 F5”. That’d be anyway version 1.59, would have a working NVRAM and all individual information from IanP50s laptop.

That’d be “Good_BIOS_region_own_EVSA_PAD.zip” from #78 and “p50_desc_gbe_me.zip” from #11

[IanP50]

Wow, you guys have been busy. Sorry it’s taken a while to respond, but I had to strip it down to the bare motherboard to go hunting for eeproms. I think I may have found it though. See attached file for the dump. It was a SOIC package, slightly smaller, but my programming clip fitted fine.

@Lost_N_BIOS - Followed your procedure for removing the Nvidia driver/device, but the result was the same. Still get error code 43. Same error in Event Viewer also.

No, I didn’t think to test the external monitors before updating to 1.62. I’ve just flashed the bios back to 1.59 as requested by lfb6, but no change.

@lfb6 - I combined ‘Good_BIOS_region_own_EVSA_PAD.zip’ from #78 and ‘p50_desc_gbe_me.zip’, flashed to the chip, but still no change. All boots up fine, but same error (Code 43) with the Nvidia GPU in Device Manager.

Thanks,
Ian.

W25Q80BLNIG_dump.rar (161 KB)

[Lost_N_BIOS]

@lfb6 - OK, yes, that may be EC FW in that chip, but not ME FW. If it is as they say, then CH341A can’t be used, unless method is outlined there to use it via ribbon cable or otherwise

Stock BIOS that has not been powered up is not ideal to look at for what we’re discussing, since it’s empty and unpopulated, please look at BIOS post-power on, or other users dumps etc.
Then you will see what I mean about NVRAM stores usually in there, inside the expandable VSS2 volumes.
Invalid entries are not of concern, those will be replaced/removed as NVRAM is populated, entries are rebuilt, BIOS is used etc.
However, since you mentioned this at #1 above, with that image, I don’t see any (invalid entries) there, so not sure why you mention this?

#4 - NVRAM will always look different, as you use the system it’s rebuilt, stuff swaps around, stuff deleted/replaced/tossed out/marked invalid etc.
So this is nothing to worry about.

See ME FW question below

Here, in last post, confirmed working BIOS dump, with clean ME FW, but costs $3 to download (I don’t have membership)
https://vinafix.com/threads/thinkpad-p50…51.26576/page-2

Schematic and other paid downloads here
https://bios-fix.com/index.php?threads/l…bios-bin.37480/
Unsure of prices to join, how long etc, because you can’t see any of that until you join and login, then you upgrade account via below to download stuff
https://bios-fix.com/index.php?threads/h…-account.26821/

@IanP50 - Thanks for confirmation on all that, bummer to hear going back to 1.59 didn’t help. That may mean it’s an EC FW issue, hopefully the chip you found is EC FW and it’s not the chip lfb6 found at the blackhat guide
Bummer! That is KBC FW, not EC FW. It looks OK. So, that guide lfb6 found is probably correct, and you can’t flash this chip easily. If it’s even part of the issue?
All I know for sure is sometimes EC FW is updating during BIOS flash, and your system bricked during BIOS flash, so it could have been during, or before that and EC FW is messed up.
Likely not before, otherwise if it was that, and OK, and this was the issue, then flashing back in 1.59 would solve it

All below, from the PDF lfb6 linked above (Matthew Chapman link on page 21)
It says here, that EC FW is updated after BIOS, so if/when brick, that may not have happened, or may have been cut off mid-way etc, no way to know without looking at contents
http://zmatt.net/unlocking-my-lenovo-laptop-part-2/

Discussion of how to dump/flash the EC FW via JTAG is there at same area (near bottom)
https://ascnb1.ru/forma1/viewtopic.php?f=70&t=109179

From here, we now see method to update EC FW via windows!
This is done with Lenovo stock tools and stock EC FW .FL2, so we can reflash this just to be sure all is OK, without even having to check it’s current contents.
Do this while on 1.62 BIOS, with .FL2 from 1.62 package
http://zmatt.net/unlocking-my-lenovo-laptop-part-3/

Do you notice any other issues? Such as fan speeds high always, Memory speed or timings off?
Maybe ME FW is messed up. Did you guys clean ME FW, if yes, what ME FW was used as base? << lfb6?w

Speaking of ME FW, Did you update the ME FW yourself in “BrickedP50” BIOS?
If yes, how did you do that, what method, and was it OK/bootable after that, before the BIOS bricked?
Generally stock BIOS/ME does not contain “Latest” ME FW, and your stock package does not even contain ME FW at all,
But this bricked BIOS has latest ME FW, so I assumed you updated it, in some manner, at some point.