Failsafe and Optimal are being ignored

[BoringBoredom]

Failsafe and Optimal are being ignored, as seen here and here. I lack the necessary information on how to proceed implementing a workaround for these (probably very common) cases. If anyone can point me towards documentation or forum/blog posts dissecting this topic, please post here.

[HappyRogue658]

I have found in my testing (see link below) that it takes optimized default settings from NVRAM. The solution would look like this:

1. User does all the things described in the UEFI Editor manual, but also this happens:
2. User extracts NVRAM, "as is" (ffs), resulting in Volume_FFSv2_AmiNvramMainRomAreaGuid.vol and uploads it in addition to the other 4 files.
   Btw, if the new UEFI Tool was able to re-insert things, one could extract/insert only the variable that holds the defaults and not the entire NVRAM, but it is what it is. Perhaps a different tool can be found to do this? chipsec would be a candidate. It can extract "StdDefaults_4599D26F-1A11-49B8-B91F-858745CFF824_NV+BS+RT_0.bin" from a ROM image, a file that is just 12 KB in size. And I believe chipsec can also re-insert things back into the ROM image.
3. UEFI editor changes the byte in NVRAM (AmiNvramMainRomArea) that holds the default value for the setting that the user wants to change.
4. User downloads files, uses UEFI Tool 0.28.0 to re-insert Volume_FFSv2_AmiNvramMainRomAreaGuid.vol and other files as applicable.
5. User flashes BIOS, loads optimized defaults.

So, how does UEFI Editor know what byte to change in NVRAM.bin?
It needs to find the variable within StdDefaults that contains the setting that the user wants to change. Then it needs to add the offset of the setting (question).

Example:
User intends to change the optimized default for "Low Power S0 Idle Capability" from 0x0 to 0x1.
UEFI Editor already knows that the variable that contains this setting is called "Setup". It also knows the setting's offset within the variable called Setup is "0x5d"

Now, where is "Setup" within "StdDefault" within "AmiNvramMainRomAreaGuid"?

What is Setup's offset within "StdDefault" within "AmiNvramMainRomAreaGuid"?

In hex editor, it looks like this.

Now, knowing that the Setup variable's body starts at 0xb8 within the user uploaded Volume_FFSv2_AmiNvramMainRomAreaGuid.vol file, add to that, the offset that UEFI Editor already knows is 0x5d.

From there, adding "0x5d" gives us 0x115. This is the byte that needs changing to 0x1.

I have posted some of my findings here: [Guide] Enabling hidden BIOS settings on Gigabyte Z690 mainboards. Only chapter 4 will be of interest to you.

[BoringBoredom]

Has this been tested on other vendors' boards as well?

[HappyRogue658]

So far, this has only been tested on one mainboard. If it helps, I have a few Intel PCs that I could test it with: ASUS Prime H470-PLUS, ASRock B360M-HDV, Gigabyte B660M DS3H DDR4. Also, Laptops (Intel 10th gen, 11th gen). Don;t know how much of this applies to Laptops though.
Do you think there's a chance, that this NVRAM editing as described above, can be automated and put into UEFI Editor?

[BoringBoredom]

  Do you think there's a chance, that this NVRAM editing as described above, can be automated and put into UEFI Editor?

Short answer: Very likely.

Long answer:
First off, I'll have to force people to upload a 5th file every time, even if they don't intend to modify it. I'm not willing to deal with the potential can of bugs and complexity of making uploads optional. That's why I want to make sure it works on a multitude of different combinations and not just on Intel + Gigabyte before "bloating" the editor even more. Dealing with the instructions for extracting and replacing is also not something I'm looking forward to. People already struggle with the UEFITool NE & 0.28.0 mash-up too much as is.

I've looked into the Volume_FFSv2_AmiNvramMainRomAreaGuid.vol file a bit:

It basically boils down to whether the gap between NVAR and the VarStoreName is always 7 bytes and the gap between the VarStoreName and offset 0x0 is always 1, so I can automatically determine the offset of offset 0x0 of each VarStore. I haven't looked at other vendors and platforms yet.

[HappyRogue658]

Today, I tested this with my ASUS Prime H470-PLUS, to see if this works across different mainboard manufacturers.

At first, I tried to change defaults in UEFI Editor and then to re-insert the resulting AMITSESetupData_body.bin. The I flashed and loaded optimized defaults. This did not work (which I kind of expected at this point but I wanted to try it).

Then, I tried with the NVRAM StdDefaults method that I described above and this worked.

Now we know, it works with ASUS too.

To this, I can add, the offset of Setup was once again 0x8b. This is because it seems that the Setup variable is always first among the StdDefaults. But the other variables occur in different order, and therefore have different offsets within NVRAM. I excepted this. If this is done programmatically, the offsets/positions of StdDefault variables/VarStors, like PchSetup, cannot be assumed to be in the same place in every BIOS. Rather, they need to be found using UEFI Tool or some other tool.

[BoringBoredom]

To this, I can add, the offset of Setup was once again 0x8b. This is because it seems that the Setup variable is always first among the StdDefaults. But the other variables occur in different order, and therefore have different offsets within NVRAM. I excepted this. If this is done programmatically, the offsets/positions of StdDefault variables/VarStors, like PchSetup, cannot be assumed to be in the same place in every BIOS. Rather, they need to be found using UEFI Tool or some other tool.

I'm aware the addresses are different. Check the image I sent above. It might be possible to figure out the offsets using just the .vol file, but I haven't bothered checking other UEFIs yet. I'm going to postpone this until UEFITool NE implements file insertion.
LongSoft/UEFITool#67 (comment)

[londbell]

Same problems on Gigabyte Z170N-GAMING 5;
Above 4G and CFG-Lock can not load optimal but dvmt pre-allocated can load;
bios.zip

[frankr2994]

I have a couple dells here that I've flashed the bios a few dozen times in an attempt to over clock them. (It's just something to do) the issue above seems to be what I was facing. I ended up finding a copy of the correct version of amisce which doesn't change defaults but mostly accomplished what I needed. I'm more than willing to test out anything of them. I have a programmer to flash if bricked which I've had to use alot lol.

[Maxinator500]

It might not be possible to implement an unified workaround. Vendors do things differently. Thus, if workaround would require changing some fickle piece of code, you would need to write a very flexible algorithm.

I want to present a routine that might be what you looking for.
There is such a thing in Aptio as setup tokens, which are used to customize the build process. One of them is USE_AMI_DEFAULTS. See the link for description.
If the token was not enabled, the TseVarBuildAMIDefaults function will never be executed.
https://github.com/xtdumpling/RAIDOOBMODULE/blob/master/AmiTsePkg/Core/em/AMITSE/CommonHelper.c#L608
https://github.com/xtdumpling/RAIDOOBMODULE/blob/master/AmiTsePkg/EDK/MiniSetup/TseAdvanced/TseAdvanced.c#L3080

Executing which, I think, is the solution for Failsafe and Optimal are being ignored.
The function can be found in AMITSE SCT by the "ConstructDefaults4FirstBootGuid" string.

But referring londbell:

Above 4G and CFG-Lock can not load optimal but dvmt pre-allocated can load;

Things are not that simple. In some cases, Defaults can be controlled by NVRAM too, along with values set in AMIBCP.

[irusanov]

I can confirm this method worked on Asus Crosshair X670E Gene to force CSM by default, by changing the failsafe value at the given offset.

[Slendermid]

by changing the failsafe value at the given offset.

explain this

[irusanov]

by changing the failsafe value at the given offset.

explain this

It's the same method explained in one of the earlier posts: #9 (comment)

I've changed the value in AmiNvramMainRomArea. The base address and header size and the offset are the same as the Setup variable is the first one for me as well. Then reinserted everything back and flashed with usb flashback function.

[Denisuu]

First off, a huge thank you to @BoringBoredom for this amazing tool!

I can confirm that the NVRAM editing method described by @HappyRogue658 for setting defaults works on the ASUS ROG STRIX B760-I board as well.

Since this board doesn’t have USB-Flashback, I disabled Publish HII Resources and Password protection of Runtime Variables. I then tested setup_var and ru_uefi, but both resulted in write protection errors. Instead, I used the latest version of SCEWIN/AMISCE (v5.05.01.0002) to disable the BIOS lock.

Afterward, I made a BIOS dump with FPTwin and used UEFI-Editor to modify the access levels and flashed it back with FPTwin.

On this board, I had to change access level 9 to 1 to make hidden features visible. I also edited the NVRAM and noticed something interesting: if I reset the BIOS to factory defaults and dump it, the second NVRAM area doesn’t exist. However, when I change some settings and make another dump, a second entry appears.

Additionally, UEFI-Editor sometimes shows values that aren’t present in the menu or in the AMISCE NVRAM export. For instance, when I try to set certain options, like Adaptive Mode, using SCE, I get an "out of range" error and the value doesn’t change.

I’m not sure where UEFI-Editor gets these values?

Some other examples are Intel Default Settings like 'Extreme' or SVID Behavior 'Trained,' that don't seem to have NVRAM values. I’m hesitant to try in change values values in another way as I don’t know what might happen. I’d prefer to avoid having to use my hardware flasher to recover incase it goes wrong.

[Maxinator500]

noticed something interesting: if I reset the BIOS to factory defaults and dump it, the second NVRAM area doesn’t exist. However, when I change some settings and make another dump, a second entry appears.

This behaviour is normal to EFI firmwares. The first NVRAM area is meant to always remain unchanged, it stores variables at their default values. And the second NVRAM area is created based on the first area, along with changes you applied in setup utility. When you click load defaults the bios switches to the first NVRAM, while its copy gets deleted.

Additionally, UEFI-Editor sometimes shows values that aren’t present in the menu or in the AMISCE NVRAM export. For instance, when I try to set certain options, like Adaptive Mode, using SCE, I get an "out of range" error and the value doesn’t change.

There might be many instances with the same name but in different sub-menus. Sure you didn't miss one? UEFI Editor is basically enhanced version of AMIBCP, so it should expose every setting as it does AMIBCP. But it also has search function. You can try it on SVID voltage and see if there really 2 of them.

[Denisuu]

There might be many instances with the same name but in different sub-menus. Sure you didn't miss one? UEFI Editor is basically enhanced version of AMIBCP, so it should expose every setting as it does AMIBCP. But it also has search function. You can try it on SVID voltage and see if there really 2 of them.

I see what you mean, for example, undervolt protection appears in multiple menus, but all point to the same offset.

What I meant is that, in this case, the fields aren’t duplicates. They are visible by default (without needing to unhide anything) but have fewer dropdown options than UEFI-Editor shows. The issue is that UEFI-Editor displays options that a AMISCE NVRAM dump says don't exist.

These are the options I can set:

// File Name : nvram.txt
// Created on 01/04/25 at 19:06:48    
// AMISCE Utility. Ver 5.05.01.0002
// Copyright (c) 2021 AMI. All rights reserved.

HIICrc32= 7B139387

Setup Question	= Global Core SVID Voltage
Help String	= Configure the global Core Voltage requested by the cores.
Result may be influenced by ActualVRM Core Voltage.
Token	=2CD9	// Do NOT change this line
Offset	=16B
Width	=01
BIOS Default	=[00]Auto 
Options	=*[00]Auto	// Move "*" to the desired Option
         [01]Manual Mode

You see, [03] Adaptive Mode isn't there, if I add it and try to set it AMISCE throws an Out of range error.

According to UEFI-Editor Adaptive Mode does exist.

But it's not shown in the menu and can't be set in NVRAM (Except with Hex editor)

Similarly, Intel Default Settings doesn't include Extreme as an option, and the un-hidden SVID Behavior doesn't include Trained, even though UEFI-Editor suggests they exist. I'm not sure if these values truly don't exist, or if AMISCE simply restricts access to them. I don't know if attempting to set them manually with a hex editor would be a good idea.

[Maxinator500]

in this case, the fields aren’t duplicates.

Then I was not right on that. Didn't check, still don't wanna download bios file.

If you look at the items in the IFR txt file you'll probably get a clue. I mean, options under a setting can be suppressed as well. If AMISCE is capable of handling this, this may be the reason some options arent available.

[Denisuu]

Then I was not right on that. Didn't check, still don't wanna download bios file.

No worries at all! I wasn’t expecting you to. Thanks for replying and clearing some things up!

If you look at the items in the IFR txt file you'll probably get a clue. I mean, options under a setting can be suppressed as well. If AMISCE is capable of handling this, this may be the reason some options aren't available.

You’re absolutely right, the options in the IFR extract do have a SuppressIf { 0A 82 } condition. However, searching for 0A 82 gives 2,982 occurrences. Is there a straightforward way to toggle 0A 82 so all SuppressIf { 0A 82 } conditions are no longer applied?

IFR_Extractor_output - Global Core SVID Voltage

Min.: 0.005V | Max.: 0.635V | Standard: By CPU | Increment: 0.005V", QuestionFlags: 0x0, QuestionId: 0x41, VarStoreId: 0x30, VarOffset: 0x165, Flags: 0x11, Size: 16, Min: 0x0, Max: 0xFFFF, Step: 0x1 { 07 94 E8 27 E9 27 41 00 30 00 65 01 00 11 00 00 FF FF 01 00 }
0x69FD4: Default DefaultId: 0x0 Value: 0 { 5B 07 00 00 01 00 00 }
0x69FDB: End { 29 02 }
0x69FDD: End { 29 02 }
0x69FDF: End { 29 02 }
0x69FE1: OneOf Prompt: "Global Core SVID Voltage", Help: "Configure the global Core Voltage requested by the cores. Result may be influenced by Actual VRM Core Voltage.", QuestionFlags: 0x10, QuestionId: 0x2CD9, VarStoreId: 0x30, VarOffset: 0x16B, Flags: 0x10, Size: 8, Min: 0x0, Max: 0x3, Step: 0x0 { 05 91 F0 27 F1 27 D9 2C 30 00 6B 01 10 10 00 03 00 }
0x69FF2: OneOfOption Option: "Auto" Value: 0, Default { 09 07 FC 26 10 00 00 }
0x69FF9: OneOfOption Option: "Manual Mode" Value: 1 { 09 07 87 27 00 00 01 }
0x6A000: SuppressIf { 0A 82 }
0x6A002: Uint64 Value: 0x0 { 45 8A 00 00 00 00 00 00 00 00 }
0x6A00C: Uint64 Value: 0x1 { 45 0A 01 00 00 00 00 00 00 00 }
0x6A016: Equal { 2F 02 }
0x6A018: End { 29 02 }
0x6A01A: SuppressIf { 0A 82 }
0x6A01C: EqIdValList QuestionId: 0x2DAD, Values: [0] { 14 08 AD 2D 01 00 00 00 }
0x6A024: OneOfOption Option: "Offset Mode" Value: 2 { 09 07 88 27 00 00 02 }
0x6A02B: End { 29 02 }
0x6A02D: End { 29 02 }
0x6A02F: SuppressIf { 0A 82 }
0x6A031: Uint64 Value: 0x0 { 45 8A 00 00 00 00 00 00 00 00 }
0x6A03B: Uint64 Value: 0x0 { 45 0A 00 00 00 00 00 00 00 00 }
0x6A045: Equal { 2F 02 }
0x6A047: End { 29 02 }
0x6A049: SuppressIf { 0A 82 }
0x6A04B: EqIdVal QuestionId: 0x1574, Value: 0x7 { 12 86 74 15 07 00 }
0x6A051: Not { 17 02 }
0x6A053: End { 29 02 }
0x6A055: SuppressIf { 0A 82 }
0x6A057: EqIdVal QuestionId: 0x1594, Value: 0x1 { 12 06 94 15 01 00 }
0x6A05D: OneOfOption Option: "Adaptive Mode" Value: 3 { 09 07 89 27 00 00 03 }
0x6A064: End { 29 02 }
0x6A066: End { 29 02 }
0x6A068: End { 29 02 }
0x6A06A: End { 29 02 }
0x6A06C: SuppressIf { 0A 82 }
0x6A06E: EqIdValList QuestionId: 0x2CD9, Values: [0, 2, 3] { 14 0C D9 2C 03 00 00 00 02 00 03 00 }
0x6A07A: String Prompt: " - CPU Core Voltage Override", Help: "Configure the voltage for the CPU Core.

I hope this is not too much off-topic.

B760-I IFR_Extractor_output.txt

[Maxinator500]

Is there a straightforward way to toggle 0A 82

Toggle all 2,982 occurrences? If so, I don't know any way. Often suppressions are nested, this makes almost impossible to toggle all of them using single expression.

[Denisuu]

Toggle all 2,982 occurrences? If so, I don't know any way.

It would probably be a very bad idea anyway.

I figured out by exporting the .json from UEFI-Editor, that the suppressions point to questionID's that don't have a name or description so they're not visible or searchable in this tool. I know what I need to do now, thanks for the help!

[BoringBoredom]

@Denisuu try hex-editing the setup.sct file to match this:

0x6A02F: 			SuppressIf  { 0A 82 }
0x6A031: 				Uint64 Value: 0x0 { 45 8A 00 00 00 00 00 00 00 00 }
- 0x6A03B: 					Uint64 Value: 0x0 { 45 0A 00 00 00 00 00 00 00 00 }
+ 0x6A03B: 					Uint64 Value: 0xFF { 45 0A FF 00 00 00 00 00 00 00 }
0x6A045: 					Equal  { 2F 02 }
0x6A047: 				End  { 29 02 }
0x6A049: 				SuppressIf  { 0A 82 }
0x6A04B: 					EqIdVal QuestionId: 0x1574, Value: 0x7 { 12 86 74 15 07 00 }
0x6A051: 						Not  { 17 02 }
0x6A053: 					End  { 29 02 }
0x6A055: 					SuppressIf  { 0A 82 }
- 0x6A057: 						EqIdVal QuestionId: 0x1594, Value: 0x1 { 12 06 94 15 01 00 }
+ 0x6A057: 						EqIdVal QuestionId: 0x1594, Value: 0xFF { 12 06 94 15 FF 00 }
0x6A05D: 						OneOfOption Option: "Adaptive Mode" Value: 3 { 09 07 89 27 00 00 03 }
0x6A064: 					End  { 29 02 }
0x6A066: 				End  { 29 02 }
0x6A068: 			End  { 29 02 }

If this still doesn't work, try moving 2902 from 0x6A066 to 0x6A053, in addition to the above changes.

[Denisuu]

@Denisuu try hex-editing the setup.sct file to match this:

That worked like a charm, also for the other options. Now everything I need, or might need in the future, is accessible. Thanks again!