I tried that, and I am pretty confident that Fn+R is the correct combination for my laptop (nothing else is doing anything), but it does not even try flashing anything for some odd reason, and the fan does not flare up (it does become louder, but even then, I need to put my ear right by my laptop to hear anything, probably because I had replaced the thermal paste on the CPU and dGPU, as well as the thermal pads on the VRAM, with PCM thermal pads, which are really doing a great job, since even under heavy load the highest temps stay below 50°C).
Will this be of any help?
Setup Utility
Fixed: No
File GUID: FE3542FE-C1D3-4EF8-657C-8048606FF670
Type: 07h
Attributes: 00h
Full size CCE96h (839318)
Header size: 18h (24)
Body size: CCE7Eh (839294)
Tail size: 0h (0)
State: F8h
Header checksum: 5Eh, valid
Data checksum: AAh, valid
PE32 image section
Offset: 1C4h
Type: 10h
Full size: CCCA4h (838820)
Header Size: 4h (4)
Body Size: CCCA0h (838816)
DOS Signature: 5A4Dh
PE Signature: 00004550h
Machine type: x86-64
Number of sections: 5
Characteristics: 2022h
Optional header signature: 020Bh
Subsystem: 000Bh
Address of entry point: 7F7B8h
Base of code: 2A0h
Image base: 0h
Aperture Description
29879h-299E8h
128MB
299EFh-299F7h
256MB
299FCh-29A04h
512MB
29A09h-29A11h
1024MB
29A16h-29A20h
2048MB
29A25h-29A2Fh
4096MB
29A34h-29A3Eh
Update: Never mind, IFRExtract shows me the following:
0x77862 One Of: Aperture Size, VarStoreInfo (VarOffset/VarName): 0x17F, VarStore: 0x1234, QuestionId: 0xA04, Size: 1, Min: 0x0, Max 0x1F, Step: 0x0 {05 91 21 0D 22 0D 04 0A 34 12 7F 01 10 10 00 1F 00}
0x77873 One Of Option: 128MB, Value (8 bit): 0x0 {09 07 23 0D 00 00 00}
0x7787A One Of Option: 256MB, Value (8 bit): 0x1 (default) {09 07 24 0D 30 00 01}
0x77881 One Of Option: 512MB, Value (8 bit): 0x3 {09 07 25 0D 00 00 03}
0x77888 One Of Option: 1024MB, Value (8 bit): 0x7 {09 07 26 0D 00 00 07}
0x7788F One Of Option: 2048MB, Value (8 bit): 0xF {09 07 27 0D 00 00 0F}
0x77896 One Of Option: 4096MB, Value (8 bit): 0x1F {09 07 28 0D 00 00 1F}
0x7789D End One Of {29 02}
Update 2: Still no dice, same exact error as before.
Might as well be that it’s not graphics or text but uefi or legacy…
That’s the information we already had?
Unclear what you meant here.
- I assume your system is ME11, Intel CSME System Tools v11 r46 still has a DOS version of flash programming tool (fpt.exe). Try to dump your bios to have a valid backup. (Lenovo doesn’t provide complete firmware images)
If you’re very luck you might be able to rewrite the corresponding NVRAM block?
fpt command syntax
fpt -i (information)
fpt -d spi.bin
if this gives an error try each region for itself:
fpt -DESC -d fd.bin
fpt -GBE -d gbe.bin
fpt -ME -d me.bin
fpt -BIOS -d biosreg.bin
-
Recovery procedures do often have requirements regarding the USB stick- often FAT32 and not to big, and sometimes one has to try several sticks?
-
If DOS still works, ru.exe might help http://ruexe.blogspot.com/
RU 5.32.0423 BETA still has a dos version and your machine isn’t too new?
(No experience with the DOS version though)
I’m sorry that I am not using the quote system, it seems broken for me (perhaps due to something with the Firefox version on my sister’s laptop or the WebView/Jelly version combination on my Razer Phone 2)
Nope, my system is setup for UEFI+CSM, with UEFI boot preferred, plus the UEFI “optimizations” (I forget what that option actually does) enabled, so probably not that.
True, I confused valie/valuestore with the offset.
That is certainly true, and I was not aware (or had forgotten) of the CSME tools including FPR, so I’ll try that.
Or would you recommend RU.exe instead, as FreeDOS (and presumably also MS-DOS) works fine here, I have more than enough flash drives, which I have verified to not to cause issues with my specific laptop.
Recommend first to do a backup with fpt (please report back if you got a complete firmware image).
Working in normal use doesn’t automatically mean that an USB stick will work with the recovery procedure. Using them with an OS is different to use just a bios module sitting in a small boot block and using maybe just a old FAT driver since the boot block not very often gets updated?
It shouldn’t work like that, as the laptop fan speed will be set to a specific %, like when a BIOS update takes place. If Fn+R does something, there is still hope. Maybe keep trying, holding the key combination for a max of 5mins while having the USB with the file plugged in. This is the easiest way to try unbricking the laptop and it resets all BIOS settings to their default. Other approaches involving using a programmer requires you to set your S/N, built-in windows key, etc.
No problem, I shall report back after attempting to backup with FPT.
Then I have no idea, however my guess is that whatever is preventing H2OFFT-D from flashing the firmware, is probably preventing Crisis from actually trying to flash as well.
S/N, built-in windows key, etc.can normally be kept / restored when working on a dump of own firmware. And a dump is anyway necessary since Lenovo has only the bios region in its updates, FD, ME need to be taken from own dump.
Alright, I finally had an opportunity to download the CSME Tools and RU, since I won’t have access to laptop but my own in a few minutes, and I will be offline again in around an hour or so, for around ~28 hours (I had initially thought that this will be on Wednesday, but that turned out to be me looking at the wrong calendar), so any possible follow-up replies will be from my Razer Phone 2 (which I will not be using for downloading any additional tools, as I need to repair/replace it’s USB-C port and workaround a manufacturing design flaw with it before I use it again and completely destroy it).
Update: The Host CPU does not have read access to the target flash area, is what I am getting now.
For which of the commands?
Usually whatever BIOS Lenovo features comes with the EC firmware and other regions. In my case the firmware that they supply is at 8979KB which is way more than what the BIOS chip can handle (8192KB). BIOS region is around 6144KB.
No, not usually, check their Thinkcentre series for example. But for many consumer notebooks its a complete image. And in this case I was wrong and you are right, it’s a complete image!
Still the question @moriel5 Which command did give the ‘no access’ message?
fpt -d bios.bin
I did successfully dump the descriptor position however, with -“d -desc”.
OK, thanks- still missing results for:
fpt -i (information)
fpt -ME -d me.bin
fpt -BIOS -d biosreg.bin
I hope that it might be possible to read the bios region and it’s the ME region giving this error…
It certainly is, which corrobates with me not being able to do other things that require permission from the ME.
-i also backs this up:
°Signature: VALID
°°Component 1 - 8192KB (65536Kb)
°Regions:
°°DESC - Base: 0x00000000, Limit: 0x00000FFF
°°BIOS - Base: 0x00210000, Limit: 0x007FFFFF
°°CSME - Base: 0x00001000, Limit: 0x0020FFFF
°°Gbe - Not present
°°PDR - Not present
°°EC - Not present
°Master Region Access:
°°CPU/BIOS - ID: 0x00, Read: 0x00B, Write: 0x00A
°°ME - ID: 0x00, Read: 0x00D, Write: 0x00C
°°Gbe - ID: 0x00, Read: 0xFFF, Write: 0xFFF
°°EC - ID: 0x00, Read: 0xFFF, Write: 0xFFF
Total Accessible Memory SPI Memory: 8192KB, Total Installed SPI Memory: 8192KB
And now I really need to be offline, so I’ll be back in around ~28 hours.
Please attach ot post the bios region.
Regarding a valid backup- since Lenovo provides a complete firmware image the ME region can be taken therefrom, the only region with machine specific data is the bios region.
Alright, I am back now.
No problem, here they are:
80Q7.rar (8.4 MB)
bioss.fd: Original Lenovo firmware from Lenovo’s website.
BIOS.BIN: Firmware dump with CSME FPT.
DESC.BIN: Descriptor dump with CSME FPT.
body.bin: UEFI Padding region containing the ME firmware, extracted from bioss.fd with UEFITool.
Note about the ME firmware, the resulting file extracted from bioss.fd (not from my backup) with UEFITool has MEAnalyzer complaining about it being incomplete/corrupted, with 0x800000 being expected, not 0x2CE000, and warning that it exceeds the Engine/Graphics region.
Also, I checked with MEAnalyzer whether H2OFFT-D backs up a complete image that contains the ME firmware, and it looks like it does not.
Bios.fd: Complete image from 0x000C10 to 0x800C0F (the not- marked!)
Machine specific data in 2 LENV area at
for bios region 0x24000 to 0x25FFF
for complete image 0x234000 to 0x235FFF
So you got everything for a complete restore.
Next thing would to try for me would be to read (and to write) to NVRAM area with fpt, but I have to have some undisturbed minutes to look up the addresses.
(“body.bin” in your zip makes no sense)
I don’t think FPT would be able to flash at all the BIOS region as it could be write protected, with the bypass having to disable BIOS lock, FPRR, and possibly more. If OP can boot into RU.EFI and reverse the setting that bricked the BIOS, it can be recoverable but I cannot confirm this.