[Guide] Usage of AMI’s AptioV UEFI Editor + FPT Flash Method

I think it’s good…
IF your bios changed, dump it again and extract ifr to check options.

ok cool, so I tried the FPT tool in Windows:

Where did you read the instructions to use Intel FPT tool???
Your system uses Intel ME 11, not 15 and the respective driver also needs to be installed in the OS.

EDIT: Flash Programming Tool Version 15.40.16.2534, you blind or what?

Intel (Converged Security) Management Engine: Drivers, Firmware and Tools (2-15) - Special Topics / Intel Management Engine - Win-Raid Forum (level1techs.com)

[Guide] Unlock Intel Flash Descriptor Read/Write Access Permissions for SPI Servicing - Special Topics / Intel Management Engine - Win-Raid Forum (level1techs.com)

@MeatWar hello can you see my problem? (in this post 13.)

My error 168 is crazy.

after see your bios, can you try read currently value
Data from IFR

Flash Protection Range Registers (FPRR) | VarStore: PchSetup, VarOffset: 0x683, Size: 0x1
Disabled: 0x0 (default)
Enabled: 0x1

first write it in uefi grub (Secure boot must disabled)
setup_var_cv VarStore VarOffset Size Value
setup_var_cv PchSetup 0x683 0x1 0x0
after that confirmation value by read value with command
setup_var_cv VarStore VarOffset Size
setup_var_cv PchSetup 0x683 0x1

Reboot CTRL+ALT+DEL

goto FPTW or fpt64.exe 64bit
TRY dump bios
fpt -bios -d biosmy.bin
try flashing that dumped bios
fpt -bios -f biosmy.bin

give result here

if still failed
try this
write command with legacy
setup_var 0x683 0x00

try upgrade you Management engine version from asus

i upgraded it(Management engine version.)
https://dlcdnets.asus.com/pub/ASUS/GamingNB/DriverforWin10/MEI/MEI_Consumer_ROG_Intel_Z_V2108.100.0.1053Sub2_22755.exe?model=ROG%20Zephyrus%20S17%20GX703

and i use grubshell. (secure boot is off.)

setup_var_cv PchSetup 0x683 0x1 0x0
setup_var_cv PchSetup 0x683 0x1

it worked.

but. ERROR 167 still occured.

this is my result.

btw, Am I clearly off my secureboot?

i know about grubshell not open when secureboot value is on.

you will succesfully dumped at first , FPRR lock do not prevent from dumping but doest now allow for flashing

i see your command in grubshell it only for writing data, you missing for reading current data, for now only focus only to 0x683 (FPRR) leaving 0x1c varstore

image

, it possible your bios setting get altered by some lock mechanism (set to default again) or we get wrong pchsetup (some bios use dual pch id with same id different but have sub id)
we need confirm that first
1.Read current data
setup_var_cv PchSetup 0x683 0x1
see at info set offset 0x683 is: (see data given by Modgrubshell) it must 0x1 (enabled), if it disabled 0x0 so is wrong pch data we worked ) out there i see some vendor using dual id
image

  1. try change to 0x0 (disabled)
    setup_var_cv PchSetup 0x683 0x1 0x0

reboot PC and going again to Grubshell
3. read again data
setup_var_cv PchSetup 0x683 0x1
see at info set offset 0x683 is: (see data given by Modgrubshell) it must 0x0 , if it going back to 0x1 (there something make that setting going to default)

Notes

Recent firmwares often stores BIOS settings into multiple varstores, and sometimes most of them are not in default “Setup” name. setup_var_cv allows accessing varying size variables in varstore with the given name.

based on notes makesure GUID in IFR is same as in showing in UEFI Shell, liek this example
image



Here is my result. I think your opinion is right. (Using dual id)
And I found GUID is correct (showing in grubshell and ifr showing)

i see it already in 0x0 state for 0x683, so we get wrong function id

use more advanced tool developed by same person

https://github.com/datasone/setup_var.efi

setup_var.efi <OFFSET> [<VALUE>] [-s <VALUE_SIZE>] [-n <VAR_NAME>] [-i <VAR_ID>]

OFFSET: The offset of value to be altered in the UEFI variable.
VALUE: The new value to write, capped at 64-bit. If not specified, the value at OFFSET will be read and shown.
VALUE_SIZE: Bytes of value to write, must be equal or larger than the size of <VALUE>, defaults to 0x1.
VAR_NAME: The name of UEFI variable to be altered, defaults to "Setup".
VAR_ID: Unique id for distinguishing variables with same name, which will be provided by setup_var.efi (when required).

OFFSET, VALUE, VALUE_SIZE and VAR_ID are numbers, and must be specified in hexadecimal with prefix "0x".

The program defaults to little endian for values ONLY while operating UEFI variables,
though it's recommended to only operate on one byte if you are not sure what this is or means.

Example: .\setup_var.efi 0x10E 0x1a -n CpuSetup

it’s more advanced grubshell ?

i’ll try it.

I found it cannot boot. it must run with grubshell?

try old version

all version tried. I failed.

I will find another way to run setup_var.efi

I found it and changed my fprr offset

Sadly… FPRR didn’t change value. (still 0x1)

I also tested ru.efi

But nothing happened

+++ I found another GUID (EE4E5898-3914-4259-9D6E-DC7BD79403CF)
I think it maybe have hidden option and FPRR.

all config edited by ModGrubShell normally default is not change permanently or not affect the dumped bios or original bios, it only altered default position of uefi config (we called bios settings file), if we want to apply that to permanent it need to be flashing

I know. But FPRR ERROR MAKES ME ANGRY.

THERE is no way to flash it?
[Ch341a?]

i think you can flash with programmer

update: other forum say you need disable CFG LOCK/MSR LOCK too for fprr

Oh thanks i ll try it today

@rofikkernel CFG LOCK mean MSR 0xE2 disable?

i try to find varies but there is 1 result.

Hello again…

I found Enable/Disable usage of SMM_BLOCKED MSR for MP sync in SMI features in CpuSetup UEFI Varies.

I think it could be disable FPRR…

but i don’t know about it. can you help me …?

use UEFI EDITOR to find id 0xXX and that menu