Well then, apparently it’s not a good idea to set the aperture size to 2GB after unlocking the firmware (I really have no idea why I had done so), since now I cannot boot to any OS, nor access the firmware settings via F2, with only a black screen and a blinking cursor greeting me.
Interestingly enough, the keyboard does respond, as evidenced by numlock and caps lock turning on and off as expected.
Trying to recover via Crisis is not really working for me as of yet (filename is D5_Crisis.bin, from D5CN47WW). but interestingly enough, it allows me to boot into FreeDOS from a flashdrive, which works perfectly fine.
Any idea as of how to recover from this state? Perhaps somehow clean-flashing the firmware from FreeDOS?
From some experimentation with H2OFFT-D under FreeDOS, it appears that my issues are stemming from the laptop not flashing the firmware, since it is the same version, as backing up the firmware, as well as anything other than actually flashing anything, works without any issues.
Actually trying to flash shows no error, it just skips flashing.
So now I need to figure out how to force the firmware to actually flash.
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)?
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.
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.
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)
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):
Leave the laptop switched off
Hold FN+R and keep holding that key combination
Plug the charger into the laptop
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.