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.