This is XiaomiPro. Works m.2 card perfectly.. I don't know because on the air not.

I can’t find the solution to actívate m.2 wifi. in older versions of this model it works without problems

@johnnync21 - The only "wifi" option I see in your setup is "Wifi SAR" What PCIE port is that slot using? I can change it's topology to M2, that may fix the issue
Try checking with some other device in that slot, and use this app to get the info
Utility to view some info on PCI devices

If it's SATA slot, see if you can find similar slot # info in HWINFO64 or AIDA64 etc, topology for SATA Slots can be set to M2 as well (Per slot)

Nvme m.2 SLOT is in port 9

That one is already set to M2 by default Maybe a certain driver needs installed, or this first setting needs changed (RST controlled or not?)

All variables not working to activate other devices other than a ssd nvme

Did you NVME Mod the BIOS already?

yes..

Well you don't need to change it away from NVME anyway, so no need to wrestle with trying other methods, unless you really want to?
Options would be H20UVE, Grub w/ setup_var, or modified grub files 2/3 with setup_var2 and setup_var3, or possibly mod BIOS to directly change the options. What method did you already try, and how exactly is it failing?

Maybe not all traces or resistors are in place for it to work for NVME same as it would for NVME, or do you think both would need the same and you already confirmed other M2 work OK?

This is going to be long: bear with me, or skip to the middle of the next post for the TL;DR.

I ran into a similar situation with a Lenovo Y700-17ISK laptop (Skylake/Sunrise Point-H, also Insyde H2O BIOS, 2015 model).

I already flashed a modified custom BIOS earlier to make the SetupUtility more interesting by exposing the advanced settings (most of which could be modified with H2OUVE anyway but that takes away all the fun from it).

Recently I had a little time to play with it some more. One annoyance about this laptop is that it's very inconvenient to get to the EEPROM chip as it's located on the not easily accessible side of the system board, so a lot of things have to be disassembled, numerous ZIF connectors, which are not engineered for heavy use, have to be disconnected, and finally the paper-thin system board has to be flipped upside down before any flashing is even possible. Also, every time this happens repasting has to be done as well, which feels wasteful.

So this time I decided I'd try my best to make sure the laptop won't have to be disassembled again soon, it's just much more convenient (and also faster) to simply flash the BIOS with FPTW. The only thing between me and this goal were 5 or so layers of protection preventing me from doing just that, but I've happily got around all of them:

1. Temporarily disabling ME

In one of the BIOS updates for this laptop the ME had to be reflashed as well and for that Lenovo issued something called a "fool style update" (sic! I guess it was supposed to be "full-style update").

The update included a special utility called WinTest.exe, which can be used to temporary disable the ME for flashing. As I understand this is is equivalent to the much more pedestrian way of shorting pins 1 and 5 on the audio chip.

2. Editing the descriptor

With the ME temporarily disabled, descriptor can be edited to allow reading and writing at any time. This is however not enough for the BIOS, the "protection" of which (from the paying customer) is supposed to be the responsibility of the device manufacturer.

3. Removing BIOS Lock

This one was easy, there is a (hidden) SetupUtility option to switch it off. The setting can also be changed with H2OUVE. I'm not sure if this is even properly implemented on this laptop at all. Backflash can be enabled with another Lenovo utility (ChgBoot.exe bfen)

4. Protected Range Registers, themselves protected by
5. Flash Configuration Lockdown (FLOCKDN) flag

These two are not that straightforward. Here's what the situation looked like originally (only quoting the relevant lines of the output to save space but I hope posting the full command line here will help someone with a similar issue as it saves the time figuring it out how to use Chipsec):

FLOCKDN:

python chipsec_util.py mmio read SPIBAR 0x4 0x4

[CHIPSEC] Read SPIBAR + 0x4: 0x0000E000
 

- or -

python chipsec_main.py -m common.spi_lock

[*] HSFS = 0x    E000 << Hardware Sequencing Flash Status Register (SPIBAR + 0x4)
    [15] FLOCKDN          = 1 << Flash Configuration Lock-Down 
 

PRRs:

python chipsec_util.py mmio read SPIBAR 0x84 0x4
python chipsec_util.py mmio read SPIBAR 0x88 0x4

- or -

python chipsec_main.py -m common.bios_wp

[*] BIOS Region: Base = 0x00200000, Limit = 0x007FFFFF
SPI Protected Ranges
------------------------------------------------------------
PRx (offset) | Value    | Base     | Limit    | WP? | RP?
------------------------------------------------------------
PR0 (84)     | 87FF06C0 | 006C0000 | 007FFFFF | 1   | 0 
PR1 (88)     | 857F029A | 0029A000 | 0057FFFF | 1   | 0 
PR2 (8C)     | 00000000 | 00000000 | 00000000 | 0   | 0 
PR3 (90)     | 00000000 | 00000000 | 00000000 | 0   | 0 
PR4 (94)     | 00000000 | 00000000 | 00000000 | 0   | 0 
 
[!] SPI protected ranges write-protect parts of BIOS region (other parts of BIOS can be modified)
 

(Continued below)

If it weren't for the FLOCKDN flag, the PRRs could be dealt with as follows:

python chipsec_util.py mmio write SPIBAR 0x84 0x4 0x00000000
python chipsec_util.py mmio write SPIBAR 0x88 0x4 0x00000000

I believe this is equivalent to what prr2.exe does. Unfortunately it won't fly with FLOCKDN. I tried a couple approaches that could make it possible to remove the PRRs without having to resort to external flashing. I think it could work with an exploit like this one by Cr4sh (also check out his excellent write-up: Exploring and Exploiting Lenovo) but the laptop in question is somewhat too new to be affected, or maybe with a specially-crafted S3 Boot Script, which can also applied with Chipsec's s3script_modify.

In the end since I already had a plan to disassemble the laptop one more time anyway, I decided to follow the path of least resistance, that is to defeat the protection by modifying the UEFI firmware where FLOCKDN is set, which at last brings me in line with the topic of this thread.

TL;DR In my BiosRegionLockDxe there are 2 places where the value 0x8000 (= 2^15, equivalent to testing for the most significant bit, which is FLOCKDN) appears. Since one of those places looks similar to what @Wootever posted, I first tried the quick fix of changing the value to 0x0 as well (so that the test is always negative). However, this changed nothing, both FLOCKDN and PRRs were still in place. I then delved deeper into the disassembled code and it occured to me that FLOCKDN seems to be set outside this module (perhaps somehow dependent on the return value from it) but the module itself is responsible for implementing the Protected Range Registers.

In the end, I replaced two conditional jumps in the module entry point with NOPs (0x66 0x90), which bypasses nearly all of the code in this module. FLOCKDN still gets set but it doesn't matter anymore because the PRRs are zeroed:

python chipsec_main.py -m common.bios_wp

[*] BIOS Region: Base = 0x00200000, Limit = 0x007FFFFF
SPI Protected Ranges
------------------------------------------------------------
PRx (offset) | Value    | Base     | Limit    | WP? | RP?
------------------------------------------------------------
PR0 (84)     | 00000000 | 00000000 | 00000000 | 0   | 0 
PR1 (88)     | 00000000 | 00000000 | 00000000 | 0   | 0 
PR2 (8C)     | 00000000 | 00000000 | 00000000 | 0   | 0 
PR3 (90)     | 00000000 | 00000000 | 00000000 | 0   | 0 
PR4 (94)     | 00000000 | 00000000 | 00000000 | 0   | 0 
 
[!] None of the SPI protected ranges write-protect BIOS region
 

And I can finally flash the BIOS the way it's meant to be flashed:


The output is from a command-line wrapper script I wrote to automate the operations a bit, I can share it if anyone is interested but basically the BIOS flash is done with FPTW64.

Some practical considerations (perhaps only for this particular laptop):

1. Flashing an image generated with Insyde H2O Easy Binary Editor (EZE) (x86) 100.00.03.04 seems to end up with a boot loop, and the only way to recover from it is to use an external programmer. Perhaps this tool is too new for this platform, version 100.00.02.13 seems to work fine.
2. Reflashing ME (2MB) or the whole chip contents (8MB), which includes the ME with another (earlier) version seems to cause a boot loop as well but this can be resolved by just taking off the cover and unplugging both batteries for a while to reset the settings to their defaults.
3. Boot loops caused by incorrect BIOS settings can generally be resolved the same way as in (2).

can u help me how to do it? i need flash modded insyde bios but got Protected Range Registers are currently set by bios

@abbytan , but did you say you installed the modded BIOS?

Zitat von abbytan im Beitrag Insyde H2O bios unlocking/flashing

---

it worked, thanks.

---

yes i installed it, but when i wanna flash other modded bios i got PRRs on Bios

Zitat von abbytan im Beitrag #44

---

when i wanna flash other modded bios i got PRRs on Bios

---