Don’t worry cam234, it did not come across the wrong way at all. What you’re trying to do is perfectly understandable and more than expected on such a platform.
They key to solving this issue is not FW Capabilities but Feature Shipment Time State NVAR or Feature Enablement NVAR. It is a 32-bit (dword) field stored at BIOS NVRAM which controls what Engine features are Enabled or Disabled, set via mechanisms such as MEBx or FIT provisioning. The Enabled features work only if there are no FPF set by the OEM which disallow their use. For PTT, we are interested in bit 29 when the dword is in Little Endian (LE) or bit 2 when the dword is in Big Endian (BE). The Feature Enablement values above are in BE so we have:
ASUS: 0x20110140 = 00100000000100010000000101000000b
EVGA: 0x00100140 = 00000000000100000000000101000000b
That clearly shows that, in your BIOS Feature Enablement NVAR value, PTT is set to Disabled. Now, we are able to view and usually change some Engine NVAR via Flash Programming Tool. I say usually because some of those NVAR values require Manufacturing Mode to be enabled (which we just disabled). I think though that we can change Feature Enablement NVAR even when the EOM is set (fingers crossed). Let’s try it. You need to run Flash Programming Tool with command “fptw64 -cfggen” which should create a text file called “fpt.cfg” or similar. Then we have to change the “FeatureShipState” value inside the text file and flash it back via “fptw64 -u -in fpt.cfg”. In order to see the NVAR and how to change them properly, can you compress and attach the resulting “fpt.cfg” text file?
Many thanks Plutomaniac. OK I’ve done this on both X299 boards (attached).
Asus:
OEMSkuRule = 0x4DDB5442
FeatureShipState = 0x21FE5043
PTTEnable = 0x01
EVGA:
OEMSkuRule = 0x4DFE5042
FeatureShipState = 0xA1FE5047
PTTEnable = 0x01
PTT is enabled on both. Strange that EVGA has more flags set than the ASUS.
Should I just copy them from the ASUS and set on EVGA then?
PS. I renamed each CFG on each system so I don’t think they are reversed. Not sure why EVGA would have more bits set???
FPT.zip (2.68 KB)
Mmm, I see PTT is enabled even on EVGA. What’s certain is that the documentation for those bits is outdated but OEMs have newer ones. So we don’t know what those different bits mean. What you can do is just flash back the ASUS .cfg file and hopefully it will be accepted even after EOM. I don’t think OEMSkuRule can be changed after EOM but FeatureShipState is more likely. Try both of them first as they are at the ASUS configuration file. If not, try only FeatureShipState.
We’re not lucky I’m afraid:
Reading FOV Input File [ FPT_new.cfg ]…
Error 529: NVAR access in the system caused a general error.
FPT Operation Failed.
Well that error is not helpful at all. Did you try the EVGA config but with only the FeatureShipState from ASUS (without changing OEMSkuRule)? If that does not help either, here are all FPT commands which could of interest for NVAR manipulation:
- -CVARS → Lists all the current manufacturing line configurable variables.
- -U → Update. Updates the NVARs in the flash. The user can update the multiple FOVs by specifying their names and values in the parameter file. The parameter file must be in an INI file format (the same format generated by the –cfggen command). The -in option is used to specify the input file.
- -O → Output File. The file used by FPT to output NVAR information.
- -IN → Input File. The file used by FPT for NVAR input. This option flag must be followed by a text file (i.e., fpt –u –in FPT.cfg). The tool updates the NVARs contained in the text file with the values provided in the input file. User can also use FPT –cfggen to generate this file.
- -N → Name. Specifies the name of the NVAR that the user wants to update in the image file or flash. The name flag must be used with Value (-v).
- -V → Value. Specifies the value for the NVAR variable. The name of variable is specified in the Name flag. The Value flag must follow the Name flag.
- -CFGGEN → NVAR Input file generation option. This creates a file which can be used to update the line configurable NVARS.
- -R → NVAR Read. FPT uses this option to retrieve NVAR value for a specific NVAR file name. The value of the variable is displayed. By default, all non- secure variables are displayed in clear-text and secure NVAR will be displayed in HASH. The -hashed option can be used to display the hash of a value instead of the clear-text value.
- -VARS → Display Supported Variables. FPT uses this option to display all variables supported for the -R and -COMPARE commands.
- -COMMIT → Commit. FPT uses this option to commit all setfile commands. NVARs changes to NVAR and cause relevant reset accordingly. If no pending variable changes are present, Intel ME does not reset and the tool displays the status of the commit operation.
- -COMMITFPF → Commits NVAR values to FPF via firmware and prevents further modification of FPFs.
- -READFPF → Displays programmed FPF values.
- -COMPAREFPF → Compare the FPF with a value passed in by the user.
- -FPFS → Displays a list of the FPFs.
Yes. I first modified a copy of the cfg_evga as you said changing the 2 params with one from ASUS. Then I tried to flash back the original one (unmodified) just to see if it works. Same error.
I can generate it just fine, but cannot write it back. As you said perhaps because we closed manufacturing mode? Maybe it means it cannot set them.
Until now none of the commands have ever thrown any errors. Everything is latest (OS, ME driver, ME FW, CSME tools, etc.)
Let me try some other commands and see what I can do…
OT: Come back ASUS - all is forgiven, Valentine’s Day is coming - if only I’d realised PTT was missing earlier none of this would have happened ;))
So testing setting individual NVars:
– Listing NV Vars works –
Supported Variables:
====================
"Config Server FQDN" (same as "CfgSrvFqdn")
"Config Server IPv6/IPv4 Address" (same as "CfgSrvAdr")
"Config Server IPv6/IPv4 Port" (same as "CfgSrvPort")
"Disable All Pre-Installed Certificate Hashes" (same as "DisCertHash")
"Domain Name" (same as "DomainName")
"eDP Port Configuration" (same as "EDP_PORT_CFG")
"Embedded Host Based Configuration Enabled" (same as "EhbcState")
"FeatureShipState"
"Firmware KVM Screen Blanking" (same as "ScreenBlankingEn")
"FWUpdLcl"
"GPIO" (same as "GpioNvar")
"Host Name" (same as "HostName")
"Intel(R) AMT Idle Timeout" (same as "IdleTO")
"Intel(R) AMT Watchdog Automatic Reset Enabled" (same as "AmtWdAutoReset")
"Intel(R) PTT Supported" (same as "PTTEnable")
"LSPCON Port Configuration" (same as "LSPCON_PORT")
"MEBxPassword"
"NFC SMBus Address" (same as "NfcSmbusAddr")
"ODM ID used by Intel(R) Services" (same as "ODM_ID")
"OEM Customizable Certificate 1" (same as "OEMCustomCert1")
"OEM Customizable Certificate 2" (same as "OEMCustomCert2")
"OEM Customizable Certificate 3" (same as "OEMCustomCert3")
"OEM Tag" (same as "OEM_TAG")
"OEMSkuRule"
"Opt-in Policy" (same as "OptInPolicy")
"PKI Domain Name Suffix" (same as "PkiDns")
"RCFG/ZTC" (same as "Rcfg")
"Redirection Privacy / Security Level" (same as "Privacy/SecurityLevel")
"Redirection"
"Reserved ID used by Intel(R) Services" (same as "ReservedID")
"System Integrator ID used by Intel(R) Services" (same as "SystemIntegratorID")
"WLAN Power Well" (same as "SetWLANPowerWell")
FPT Operation Successful.
– Reading works –
FPTW64.exe -r "OEMSkuRule"
Variable: "OEMSkuRule"
Value: 42 50 FE 4D (0x4DFE5042)
Retrieve Operation: Successful
– Updating does not –
FPTW64.exe -u -n "OEMSkuRule" -v 0x4DFE5042
Error 529: NVAR access in the system caused a general error.
FPT Operation Failed.
I suppose the same happens with “-u -n FeatureShipState -v”. It would make sense for the error to be either due to EOM or because the BIOS has general NVRAM protections in place. The latter wouldn’t be surprising from a security standpoint. Technically PTT is enabled even at FeatureShipState so I’m out of ideas. Maybe it’s something extra but I doubt it, that’s all the documentation and prior knowledge covers. Unlocking read/write access again will be a huge PITA (unless you use a programmer) so at this point I would insist and try to convince EVGA to help out by fixing the BIOS. They have no reason to say no.
Oh yes - I do have a couple of programmers ;)) And the BIOS is socketed. Let me know what you need me to do 
Just need to check I have the same BIOS chip and make a backup on which to test; should have done that already to be honest…
PS. OK I will (also) take it with EVGA as you say; but I am pretty sure it is “political” as it seems their other boards don’t enable PTT either - I very much doubt it is an error but a conscious decision to not provide it. Perhaps I should complain to Microsoft that EVGA are in violation of their W10 logo guidelines by not providing a TPM option ;))
You have programmers and the SPI is socketed? What are we even talking about? Play time! 
Honestly you can just reflash the stock EVGA BIOS/SPI with the programmer and you’ll be at the same initial state with the exception of FPF which will be committed this time as their setting is permanent. But that’s not a problem as we specifically enabled them correctly. Once you have read/write access again, try the fpt commands again. Let’s see if that’s it.
Indeed I strongly suggest asking EVGA. Who knows, you might get an answer such as “Yeap, you’re right. We’ll release a new BIOS with a fix”.
PTT is supported in the latest EVGA BIOS.
What about intel PTT initial power-up state? Did you set it to Yes?
I don’t understand should I enable this option or leave as is .