Semi-Bricked IdeaPad 300-15ISK 80Q7 (H2O UEFI)

That is a good question, to which I can only speculate.

I don’t think that it would write actual settings to the NVRAM, but it may clear it, with the flashed firmware writing the factory settings on first boot.

That said, H2OFFT-D does have options that refer to “NV Storage”, could that be relevant?

Also, I have since tried to use “-forceit” and the different operators that pertain to verification and comparison, to no avail. No errors, but H2OFFT-D does not even try to carry out the actual flashing step.

I certainly hope that I won’t need to use my any of my CH341s, as I am not sure which is still functional, and I don’t have the luxury to use them at the moment, on account of lack of space (my desktop is usually unplugged until renovations are complete).
Perhaps I will be able to do so in around two weeks while preparing for 3mdeb’s next vPub, since I believe (I do not remember for sure) I have a backup that I had already made a few years back (Lenovo had literally stopped supporting the 300 models about half a year after they released them, and Intel had stopped releasing updates for the ME firmware (11.8.93.4323 Consumer LP C NPDM) before I had made the backup, so I am not worried on that front).

I’ve done the Crisis Recovery method too, although I never had your issue. That time it was a normal BIOS brick due to the changing of memory overclocking settings. But I didn’t get the part where you said the recovery didn’t work. Did the laptop actually enter into a recovery state (fan speed goes high, power led doesn’t light up, etc)?

0x5BC35 VarStore: VarStoreId: 0x1234 [A04A27F4-DF00-4D42-B552-39511302113D], Size: 0xFA0, Name: SystemConfig {24 23 F4 27 4A A0 00 DF 42 4D B5 52 39 51 13 02 11 3D 34 12 A0 0F 53 79 73 74 65 6D 43 6F 6E 66 69 67 00}

0x7769A 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}
0x776AB One Of Option: 128MB, Value (8 bit): 0x0 {09 07 23 0D 00 00 00}
0x776B2 One Of Option: 256MB, Value (8 bit): 0x1 (default) {09 07 24 0D 30 00 01}
0x776B9 One Of Option: 512MB, Value (8 bit): 0x3 {09 07 25 0D 00 00 03}
0x776C0 One Of Option: 1024MB, Value (8 bit): 0x7 {09 07 26 0D 00 00 07}
0x776C7 One Of Option: 2048MB, Value (8 bit): 0xF {09 07 27 0D 00 00 0F}
0x776CE One Of Option: 4096MB, Value (8 bit): 0x1F {09 07 28 0D 00 00 1F}
0x776D5 End One Of {29 02}

If you can still boot something- try to change the variable back?

It never did enter the recovery state. It read the contents of the flash drive (the flash drive in question has an LED with distinct patterns for receiving power and actual drive activity), and decided not to do anything, in roughly the same amount of time it took for the same to happen when running H2OFFT-D under FreeDOS.

Also, I have accidentally discovered that pressing any button together with Fn(? At least it works with R, F, and B) before pressing the power button, whether the charger was connected or not, and releasing after the orange LED lights up, directly brings the laptop to try booting an OS from external media.

I was unable to even read the variables, although that could be due to my limited experience with configuring firmwares via their hexadecimal values.

I tried running “H2OFFT-D.exe 0x5BC35 -rv -lg:A04A27F4-DF00-4D42-B552-39511302113D”, as well as the same just with “0x7769A” instead of “0x5BC35”.

The error in question was:
Error: IHISI failed. (00h)
Internal error 10
Error: VATS: Variable not found.

Not used to H2xxx tools and their syntax. But I wonder where 0x5BC35 and 0x7769A come from? I did once use dumpstore and setvar (link)

A variable store normally is referenced by GUID and the variable by its position, here possibly A04A27F4-DF00-4D42-B552-39511302113D for the GUID, the variable would be 0x17F

And I’d try to dump the store first and to check if 0x17F really is 0xF before trying to write.

(One way you’re right, you’re almost bricked anyway, but on the other hand changing something relevant in the wrong place could lead to some extra work when working on the dump)

Ah, sorry. I didn’t realize that you were presenting an example, I had taken those values from your post as I thought that they were the relevant values in my case.
I’ll look into my firmware image (I did another dump with H2OFFT-D a few hours ago) and try to figure things out on Sunday, as I won’t be online until then.

Regarding the my command, I’m glad that I at least got the GUID part right, even if I did not understand what they value was supposed to be (In retrospect though, you did spell it out pretty clearly, and I simply failed to notice, so that is completely on me).
Thankfully, I did not even try to write anything beyond a simple flash of the Lenovo-supplied firmware image, as I am well aware of the headaches involved (I have bricked several Android devices in the past, as well as broke a few Windows and Linux installations, and even a Mac OS 9 installation at one point), “-rv” stands for “read value”.

Hopefully this experience will assist me in the future with trying to add support with FlashROM.

0x5BC35 and 0x7769A are from the output of ifrextract, I assume they refernce positions in the originating module

FN+R for me runs the recovery mode, I kept holding it while having the USB plugged in and powered the laptop on (making sure it is also charging). I continued to hold the FN+R key combination until the laptop started to beep. It may reboot if it was unable to find the correct file in the USB. I never thought it would allow booting through an external media if the BIOS was kind of bricked.

Seems changing the settings for aperture size bricked graphics mode only, so the system might still boot something text- mode based since bios code itself is still fine/ unbricked!

As written it might be possible to revert the settings with tools like setvar.
(The commandline options for H2OFFT-D are not known to me, maybe it has a switch for that, too)
(And it’s still unclear if crisis mode will reset this NVRAM store to defaults)

I’ll look into it in a few moments.

This was quite the surprise for me.

Now the question is, can I boot into a UEFI shell like this.

From H20OFFT-D’s help menu (/?), it looks like -rv is to read a specific value, while -wv is to write a specific value, but if I can boot into a UEFI shell, it will make things much easier.

Edit: My memory failed me, -fv is to write (flash) a specific value, not -wv.

And oddly enough, the situation has slightly changed now. No longer are any key shortcuts allowing me to boot anything, only bringing me directly to BIOS boot (unfortunately, anything UEFI will not display anything other than a blinking cursor on a blank screen, including UEFI shells), but only Fn+R does anything (as should be in an expected situation), while just plain turning on the machine works as should… except for displaying anything, unless it is a legacy BIOS-booted OS (I have not yet tried anything GUI, but I do not believe it will work).

For me it resets the entire BIOS, so it should work for OP. The procedure to do the recovery is probably same to similar as I have the 81HQ type laptop.

Carefully follow the steps to enter crisis mode (no need to plug in the USB if you want to see whether it would work or not):

  1. Leave the laptop switched off
  2. Hold FN+R and keep holding that key combination
  3. Plug the charger into the laptop
  4. Turn on the laptop

For me the fan speeds were noticeably higher so if you notice that first then it may be obvious that you have entered the laptop in such state. In that case if it couldn’t find the correct BIOS firmware file, then it would reboot automatically (if I keep holding FN+R it would again enter crisis mode).
This is for my laptop so it can vary for you especially with the key combinations.

Interestingly, I only get a blinking orange light for slightly longer than I hold Fn+R (and I have held it for more than 5 minutes) after which it reboots, with no changes to the situation.

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)