MTL IoT FSP does not set up DPR

[miczyg1]

The MTL IoT FSP 4122_56 does not program the host bridge DPR register. When attempting to initialize Intel TXT with the aforementioned FSP, the DPR check in coreboot yields an error that DPR is not programmed:

[DEBUG]  TEE-TXT: MCH DPR 0x00000001
[DEBUG]  TEE-TXT: MCH DPR base @ 0x00000000 size 0 MiB
[ERROR]  TEE-TXT: MCH DPR protection not active.

Parameters passed to FSP:

FSP_M_CONFIG->VmxEnable = 1;
FSP_M_CONFIG->TxtImplemented = 1;
FSP_M_CONFIG->Txt = 1;
FSP_M_CONFIG->SinitMemorySize = 0x50000;
FSP_M_CONFIG->TxtHeapMemorySize = 0xf0000;
FSP_M_CONFIG->TxtDprMemorySize = 4 << 20;
FSP_M_CONFIG->TxtDprMemoryBase = 1;
FSP_M_CONFIG->BiosAcmBase = acm_base; // 256K aligned address of S-ACM in CBFS
FSP_M_CONFIG->BiosAcmSize = acm_size;
FSP_M_CONFIG->ApStartupBase = 1;

FSP_S_CONFIG->TxtEnable = 1;

Older versions of the FSP also do not program DPR. It is simply being locked without programming the TSEG base and DPR size into it. For comparison ADL FSP did program DPR correctly. Currently it is impossible to initialize Intel TXT properly without making workarounds in host firmware that will program DPR before FSP MemoryInit with last known good TSEG base and requested DPR size, assuming that configuration does not change.

[miczyg1]

Actually, it can't even be workarounded. When attempted to program the unlocked DPR before FSP MemoryInit, the top of DPR (bits 31:20 of the register) remain unchanged (equal to zero), while EPM and DPR size are getting updated. I presume the DPR programming must happen before certain MRC steps?

[pietrushnic]

@nate-desimone, any chance someone from Intel can look at it?

[nate-desimone]

@miczyg1, @pietrushnic - It looks like DPR programming got moved to the NotifyPhase(EnumInitPhaseAfterPciEnumeration) API. Is your bootloader calling that API?

[miczyg1]

@miczyg1, @pietrushnic - It looks like DPR programming got moved to the NotifyPhase(EnumInitPhaseAfterPciEnumeration) API. Is your bootloader calling that API?

I see. Unfortunately not, it was skipped and replaced by native register programming. However, in the NEX MTL MR1 v4053_57 sources I didn;t see the DPR being programmed. It was simply locked in the MRC, as seen by the MTL IoT FSP v4122_56 aforementioned in the issue. SO I was under the impression it is not programmed. If the lock happens in MRC, then the NotifyPhase(EnumInitPhaseAfterPciEnumeration) would not be able to program it either.

I assume it has changed after v4122_56, so we will have to give MR3 v5124_47 FSP a try and see what comes out of it. We may either program the DPR ourselves (it should not be locked after SiliconInit API nor MemoryInit API then) or let it be done by FSP.

[mkopec]

Unfortunately, even using MR3 v5124_47 and calling NotifyPhase(EnumInitPhaseAfterPciEnumeration), the issue is still present. This is the state of the DPR after the NotifyPhase, according to coreboot:

[INFO ]  TEE-TXT: DPR capable 1
[DEBUG]  TEE-TXT: MCH DPR 0x00000001
[DEBUG]  TEE-TXT: MCH DPR base @ 0x00000000 size 0 MiB
[ERROR]  TEE-TXT: MCH DPR protection not active.