Sorry but surely this means ME has not been fully configured either by mistake so we need to commit ME config? Isn’t the fix toggling ME out of manufacturing mode?
PTT just seems to be a symptom of the ME being in manufacturing mode and thus the configuration is not set.
There is nothing about PTT at all in BIOS/manual I don’t think EVGA had any idea about it:
https://www.evga.com/support/manuals/files/131-SX-E295.pdf
You are correct. The FPF are set when Manufacturing Mode is Disabled for the first time (normally at the OEM factory) and thus the platform is FPF Committed. PTT does not work in Manufacturing Mode (no FPF commitment) so that’s why it’s not shown at all. So, now that you still have read/write access to the Engine region (Manufacturing Mode Enabled), download the attached Engine region which has PTT fully enabled. Flash via “fptw -rewrite -me -f 1E295112_ME_PTT.bin” followed by “fptw -greset”. After the reboot, run “fptw -closemnf”. PTT should now be Enabled.
1E295112_ME_PTT.rar (1.14 MB)
Due to other issues I was not able to do this earlier. Flashed your version, reset, then closed man-mode.
Just done it now - and FPFs are now set but still no dice. It seems it is not as easy as it sounds:
1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
FW Capabilities value is 0x100140
Feature enablement is 0x100140
FW Capabilities 0x00100140
Intel(R) Capability Licensing Service - PRESENT/ENABLED
Intel(R) Dynamic Application Loader - PRESENT/ENABLED
Service Advertisement & Discovery - NOT PRESENT
Intel(R) NFC Capabilities - NOT PRESENT
Intel(R) Platform Trust Technology - NOT PRESENT
To me it seems the issue is still that PTT is shown as "NOT PRESENT" and not simply present/disabled as on other boards. Thus there is "nothing to enable" since it is not present.
The question is how the FW capabilities are being set. Pity I liked this board.
evga_x299_mfclosed.txt (9.13 KB)
I’m also attaching MEManuf in case that contains any more data than the above.
x299_memanuf.txt (1.9 KB)
The forum is buggy with txt attachments so you should compress them first. Either way, I can tell you for a fact that the problem is not related to CSME firmware. The problem is either hardware or BIOS related. Since I doubt that there is any other way to disable PTT in hardware (other than FPF which is set properly), I believe that there is an EVGA BIOS issue which can be fixed with an update from their part. The BIOS is probably always setting PTT to Disabled at boot with no option exposed to the menu so that’s why you see Not Present at MEInfo. You should contact EVGA and let them know that you cannot enable PTT.
Plutomaniac - sure BIOS can easily fix it - but I think we know EVGA won’t do it. Not a cat’s chance in hell. In fairness until relatively recently ASUS did not provide PTT either even though they could have done it for generations - instead relying on socket for external TPM for some reason.
I thought what we’re trying to do here is to include (not saying “enabled” since that enables present caps) ME capabilities that have not been included by the BIOS. To me it was not clear that the BIOS sets the FW caps “in stone” (not just FPFs) and modifying the ME flags cannot include additional caps no matter what.
It seems it may be possible to enable caps that are included (present) but not enabled by modifying ME but there’s no way to enable caps that are not included (not present) even committing FPF flags or what-not. That is a pity.
The CSME FW Capabilities define the SKU. All Consumer firmware have the same capabilities. All Corporate firmware have the same capabilities. There is no special EVGA CSME firmware SKU with its own FW Capabilities which has PTT disabled. An exception is Apple with their Slim SKU but that’s another story. The FW Capabilities are set by provisioning the firmware via Flash Image Tool. Some of them can then be Enabled/Disabled via MEBx (relevant to Corporate SKU, AMT for example) or via BIOS options which are respected by the CSE, provided that they don’t conflict with any FPF values. All of the provisioning and FPF commitment is done by the CSE, the BIOS can just hide or show a few of them. What I’m saying is that the FW Capabilities are always there, not missing or not included. After that, it’s a matter of FIT provisioning and BIOS showing. That’s an important distinction.
Honestly I don’t understand why EVGA would deny giving the user the option to enable PTT. Especially on a 300$ motherboard for a high-end workstation platform such as X299. That wouldn’t be cool, at least on my books. Before condemning them though, I don’t remember if you said anything about contacting their support. If not, I suggest you ask them but make sure to try the proper channels and not forums, live chats or similar which are usually run by volunteers who don’t even know what CSME is. It is worth a try in my opinion. 
Plutomaniac - I hope the previous did not come across the wrong way: I’m not trying to question you or start an argument etc.
I’m simply trying to understand why what we’ve done does not work and perhaps learn something for other people. I am thankful for your help - as I said I think we’re missing something here.
But I do think there’s more than meets the eye here: Both the EVGA and Asus are the same platform* and running the same CSME ME (consumer). But the features are different. We changed/enabled them, we set the FPF flags etc. But the FW Caps are different. And on the EVGA they have not changed despite or changes.
I am also not sure we realise the difference between “not present” and “disabled”. Clearly “not present” cannot be changed through ME modification alone.
If the BIOS through a call (or calls) sets the flags for ME “FW Caps” then they are effectively “set in stone” and cannot be changed. What I mean you cannot enable something that is “not present”.
My understanding - based on what you say - is that FIT/platform determines FW Caps and BIOS/perhaps drivers enables/disables them. But then BIOS could not enable PTT either since it is “not present”.
On Asus (not X299 but Z170) even with external TPM socket, PTT was always “present” but there was no option to enable. Do you see what I mean? So perhaps you could enable it by modifying ME to have “start-up state: enable” but that’s because it was “present/disabled”. But here it is “not present” completely.
* NB. It seems platform IDs are different between the ASUS and EVGA. Perhaps we should have changed platform then?
ASUS:
FW Capabilities value is 0x20110540
Feature enablement is 0x20110140
Platform type is 0x71440322
EVGA:
FW Capabilities value is 0x100140
Feature enablement is 0x100140
Platform type is 0x714F0322
Do we know of documentation on the flags? AMT SDK?
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 .