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

BIOS/UEFI Modding BIOS Modding Guides and Problems
41

Well, I wouldn’t rewrite the complete bios region, but just a bit in NVRAM, that possibly might not be in a protected range. But you’re right, it probably won’t work.

First thing Ru.exe does is warn to about non- AMI bioses, so it wont be “a 100% safe” either…

Edit:
fpt -d testff.bin -A 0x558500 -L 0x100

That should give you 256 bytes FF in the free space between NVRAM and FTW store

image
image1382×484 8.72 KB

image

If you get something different, attach it, don’t try to write it back!

fpt -f testff.bin -A 0x558500 -L 0x100

would try to write these 256 bytes back to the same place (and give you most probably an error message)

fpt can write down to a single byte, but flash pages are larger and even if you just change some bytes fpt has to rewrite a complete page of the SPI. So still danger of a brick.

Be careful with the syntax, don’t forget ‘0x’, it’d give different addresses.

42

I have no idea why the archive was .rar, as I had thought I had archived it as .zip, but whatever (I usually use .7z on my own devices.

That would certainly make sense, as the Crisis method usually takes upon unedited .fd does from Lenovo’s website.

And I agree that “body.bin” makes no sense, perhaps it’s just a Lenovo quirk.

43

Unfortunately, I cannot boot EFI payloads, and I still haven’t figured out how to load RU.exe’s EFI variables FreeDOS drivers.

44

Dumping that part went perfectly fine, however I won’t be able to verify what I had dumped for a few more hours, once I have access to my sister’s laptop.

45

While I can agree that making any bad changes to the BIOS is not 100% safe, RU.EFI actually can edit any settings made in the BIOS except it is also in hex. It worked with InsydeH2O for me. Since OP made changes to Aperture size, we know that we just need to change its value back to its default.

For an idea on what I mean, look here. Using UEFITool and the BIOS dump taken, we locate Aperture Size and find its VarOffset and VarStore. I made an attempt and didn’t get what I wanted so I reverted my changes. But it is possible to recover the BIOS with less to no harm if we are only changing values of a setting as it has already been done to brick their BIOS.

46

We were there already and know exactly what to change:

And it’s correct, the value is 0xF in the store in NVRAM

image
image1539×846 34.9 KB

The precision of fpt writing exactly these bytes back would be more safe than letting ru.efi do ‘something’. In the end it’s the same byte you change…

fpt -d apsize.bin -A 0x547C7D -L 0x1 should give you 0xF, correct the value in “apsize.bin” and write it back…

47

The data in testff.bin was identical, and the were no issues flashing it.

Regarding apsize.bin, ask was as you said it will be, and now my laptop is back up and running as it should.

Thank you very much for all of your help.

1 Like
48

I believe this whole conundrum must have been caused by me accidentally setting the aperture size instead of the DVMT size, since I wanted to experiment with that, however in my experience the old Intel HD iGPUs don’t really benefit from more than 256MB of dedicated RAM, which I have configured without any issues, so there is no real point in trying 2048MB of DVMT, especially since I had set the maximum to, well, Max.

49

:+1:

(The command was basically meant for AgentMod, I’d have you do one or two steps more just to be a 100% sure that it’s the correct address, but anyway :slight_smile: )

And just in case for others: That address is specific for this machine in this state! Where the last setup store ist in NVRAM is different for each machine!

(Regarding the possibility to transfer this solution a RU.exe way would be the easier solution)

50

Oh sorry I didn’t read that message. By the way if it is possible for you, can you look into my post regarding disabling spread spectrum? I didn’t want to bring it up here but the method is supposed to be similar to your solution for this post.