Date   

Does data constraint comments affect the build?

Konstantin Aladyshev
 

Is there any value in data constraint comments in the INF file? I mean
these:
```
## SOMETIMES_PRODUCES
## CONSUMES
## SOMETIMES_PRODUCES
## PRODUCES
## TO_START
## BY_START
```
Are they purely informational? Do they affect the build process in any way?
Can they break the build somehow?


Re: Token values are not produced for PCDs under 'PcdsDynamic' section

Konstantin Aladyshev
 

Thanks Guomin! I've managed to get PcdMyDynamicExVar32 working, but I still have troubles with PcdMyDynamicVar32...

MyPkg/MyPkg.dec:
```
[PcdsDynamic]
gMyPkgTokenSpaceGuid.PcdMyDynamicVar32|0x31313131|UINT32|0x30000001

[PcdsDynamicEx]
gMyPkgTokenSpaceGuid.PcdMyDynamicExVar32|0x32323232|UINT32|0x40000001
```

MyPkg/Myapp/Myapp.inf:
```
[Pcd]
gUefiLessonsPkgTokenSpaceGuid.PcdMyDynamicVar32

[PcdEx]
gUefiLessonsPkgTokenSpaceGuid.PcdMyDynamicExVar32
```

MyPkg/Myapp/Myapp.c:
```
Print(L"PcdMyDynamicExVar32=%x\n", PcdGet32(PcdMyDynamicExVar32));
PcdSet32S(PcdMyDynamicExVar32, 52);
Print(L"PcdMyDynamicExVar32=%x\n", PcdGet32(PcdMyDynamicExVar32));

Print(L"PcdMyDynamicVar32=%x\n", PcdGet32(PcdMyDynamicVar32));
PcdSet32S(PcdMyDynamicVar32, 52);
Print(L"PcdMyDynamicVar32=%x\n", PcdGet32(PcdMyDynamicVar32));
```

Also I've modified OvmfPkg source:
OvmfPkg/OvmfPkgX64.fdf
```
[FV.DXEFV]
...
+ INF MyPkg/MyApp/MyApp.inf
```
OvmfPkg/OvmfPkgX64.dsc
```
+ [PcdsDynamicExDefault]
+ gUefiLessonsPkgTokenSpaceGuid.PcdMyDynamicExVar32

[PcdsDynamicDefault]
+ gUefiLessonsPkgTokenSpaceGuid.PcdMyDynamicVar32
...
```


After OVMF recompilation I see both variables in a PCD database:
hexeditor Build/OvmfX64/RELEASE_GCC5/FV/Ffs/80CF7257-87AB-47f9-A3FE-D50B76D89541PcdDxe/DXEPcdDataBaseSec.raw

However only `PcdMyDynamicExVar32` works correctly in my app. I think it is because of the fact that Token value for PcdMyDynamicVar32 is still 0 in `Build/UefiLessonsPkg/RELEASE_GCC5/X64/UefiLessonsPkg/PCDLesson/PCDLesson/DEBUG/AutoGen.h`
```
#define _PCD_TOKEN_PcdMyDynamicVar32_1 0U
#define _PCD_GET_MODE_32_PcdMyDynamicVar32_1 LibPcdGet32(_PCD_TOKEN_PcdMyDynamicVar32_1)
#define _PCD_GET_MODE_SIZE_PcdMyDynamicVar32_1 LibPcdGetSize(_PCD_TOKEN_PcdMyDynamicVar32_1)
#define _PCD_SET_MODE_32_PcdMyDynamicVar32_1(Value) LibPcdSet32(_PCD_TOKEN_PcdMyDynamicVar32_1, (Value))
#define _PCD_SET_MODE_32_S_PcdMyDynamicVar32_1(Value) LibPcdSet32S(_PCD_TOKEN_PcdMyDynamicVar32_1, (Value))

#define _PCD_TOKEN_gUefiLessonsPkgTokenSpaceGuid_PcdMyDynamicExVar32 1073741825U
#define _PCD_TOKEN_PcdMyDynamicExVar32 _PCD_TOKEN_gUefiLessonsPkgTokenSpaceGuid_PcdMyDynamicExVar32
#define _PCD_GET_MODE_32_PcdMyDynamicExVar32 LibPcdGetEx32(&gUefiLessonsPkgTokenSpaceGuid, _PCD_TOKEN_PcdMyDynamicExVar32)
#define _PCD_GET_MODE_SIZE_PcdMyDynamicExVar32 LibPcdGetExSize(&gUefiLessonsPkgTokenSpaceGuid, _PCD_TOKEN_PcdMyDynamicExVar32)
#define _PCD_SET_MODE_32_PcdMyDynamicExVar32(Value) LibPcdSetEx32(&gUefiLessonsPkgTokenSpaceGuid, _PCD_TOKEN_PcdMyDynamicExVar32, (Value))
#define _PCD_SET_MODE_32_S_PcdMyDynamicExVar32(Value) LibPcdSetEx32S(&gUefiLessonsPkgTokenSpaceGuid, _PCD_TOKEN_PcdMyDynamicExVar32, (Value)
```

What am I doing wrong?


Re: Token values are not produced for PCDs under 'PcdsDynamic' section

Konstantin Aladyshev
 

Sorry, I didn't understand your answer. Could you please elaborate it for me.

I'm trying to write `UEFI_APPLICATION` and test its execution in UEFI
Shell in QEMU running OVMF.
I also use `DxePcdLib` as PcdLib in my package DSC file:
```
[LibraryClasses]
...
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
```
In this library LibPcdGet32 is translate to:
```
UINT32
EFIAPI
LibPcdGet32 (
IN UINTN TokenNumber
)
{
return GetPcdProtocol()->Get32 (TokenNumber);
}
```
So the correct `TokenNumber` should be passed for this to work correctly.

But as I said Token for my variable is set to 0 for some reason in AutoGen.h:
```
#define _PCD_TOKEN_PcdMyDynamicVar32 0U
```

On Tue, Jun 29, 2021 at 12:25 PM Jiang, Guomin <guomin.jiang@intel.com> wrote:

Hi



This should be compiled into PCD PEIMs and PCD DXE Drivers.



It will be contained by firmware eventually.



It seem that you haven’t changed the firmware, so the firmware can’t get the value and freeze.



Thanks

From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Konstantin Aladyshev
Sent: Tuesday, June 29, 2021 1:00 AM
To: discuss@edk2.groups.io
Subject: [edk2-discuss] Token values are not produced for PCDs under 'PcdsDynamic' section



Hello!



I'm trying to understand dynamic PCDs in EDK2.



I've added this code to my package DEC file:

```

[PcdsDynamic]
gMyPkgTokenSpaceGuid.PcdMyDynamicVar32|42|UINT32|0x00000004

```

And have added this code to my app INF file:

```

[Pcd]
gMyPkgTokenSpaceGuid.PcdMyDynamicVar32

```



I'm trying to use PCD in my application like this:

```
Print(L"PcdMyDynamicVar32=%d\n", PcdGet32(PcdMyDynamicVar32));
PcdSet32S(PcdMyDynamicVar32, 52);
Print(L"PcdMyDynamicVar32=%d\n", PcdGet32(PcdMyDynamicVar32));

```



But when I try to compile, the token number is not populated to the AutoGen.h:

```

#define _PCD_TOKEN_PcdMyDynamicVar32 0U
#define _PCD_GET_MODE_32_PcdMyDynamicVar32 LibPcdGet32(_PCD_TOKEN_PcdMyDynamicVar32)
#define _PCD_GET_MODE_SIZE_PcdMyDynamicVar32 LibPcdGetSize(_PCD_TOKEN_PcdMyDynamicVar32)
#define _PCD_SET_MODE_32_PcdMyDynamicVar32(Value) LibPcdSet32(_PCD_TOKEN_PcdMyDynamicVar32, (Value))
#define _PCD_SET_MODE_32_S_PcdMyDynamicVar32(Value) LibPcdSet32S(_PCD_TOKEN_PcdMyDynamicVar32, (Value))

```

Because of that I get 0 in the first `PcdGet32` call and my application freezes at the `PcdSet32S` call.





But if I change `[PcdsDynamic]` to [PcdsDynamicEx] in my package DEC file token value will be populated:

```

#define _PCD_TOKEN_gMyPkgTokenSpaceGuid_PcdMyDynamicVar32 1073741828U
#define _PCD_TOKEN_PcdMyDynamicVar32 _PCD_TOKEN_gMyPkgTokenSpaceGuid_PcdMyDynamicVar32
#define _PCD_GET_MODE_32_PcdMyDynamicVar32 LibPcdGetEx32(&gMyPkgTokenSpaceGuid, _PCD_TOKEN_PcdMyDynamicVar32)
#define _PCD_GET_MODE_SIZE_PcdMyDynamicVar32 LibPcdGetExSize(&gMyPkgTokenSpaceGuid, _PCD_TOKEN_PcdMyDynamicVar32)
#define _PCD_SET_MODE_32_PcdMyDynamicVar32(Value) LibPcdSetEx32(&gMyPkgTokenSpaceGuid, _PCD_TOKEN_PcdMyDynamicVar32, (Value))
#define _PCD_SET_MODE_32_S_PcdMyDynamicVar32(Value) LibPcdSetEx32S(&gMyPkgTokenSpaceGuid, _PCD_TOKEN_PcdMyDynamicVar32, (Value))

```



What is my mistake? Why is the token value not populated when `[PcdsDynamic]` is used?





Best regards,

Konstantin Aladyshev


回复: [edk2-discuss] Difference between boolean PCD fixed at build and a PCD feature flag

gaoliming
 

Yes. Feature PCD is same to Boolean fixed at build PCD.



Thanks

Liming

发件人: discuss@edk2.groups.io <discuss@edk2.groups.io> 代表 Konstantin Aladyshev
发送时间: 2021年6月29日 4:46
收件人: discuss@edk2.groups.io
主题: [edk2-discuss] Difference between boolean PCD fixed at build and a PCD feature flag



What is the difference between boolean PCD fixed at build and a PCD feature flag?

```

[PcdsFixedAtBuild]
gMyPkgTokenSpaceGuid.PcdMyVarBool|FALSE|BOOLEAN|0x00000004

[PcdsFeatureFlag]
gMyPkgTokenSpaceGuid.PcdMyFeatureFlagVar|FALSE|BOOLEAN|0x20000001

```

I'm looking at the AutoGen files and the result from both of these PCDs is practically the same.



AutoGen.c
```
GLOBAL_REMOVE_IF_UNREFERENCED const BOOLEAN _gPcd_FixedAtBuild_PcdMyVarBool = _PCD_VALUE_PcdMyVarBool;
GLOBAL_REMOVE_IF_UNREFERENCED const BOOLEAN _gPcd_FixedAtBuild_PcdMyFeatureFlagVar = _PCD_VALUE_PcdMyFeatureFlagVar;
```
AutoGen.h
```
#define _PCD_TOKEN_PcdMyVarBool 0U
#define _PCD_SIZE_PcdMyVarBool 1
#define _PCD_GET_MODE_SIZE_PcdMyVarBool _PCD_SIZE_PcdMyVarBool
#define _PCD_VALUE_PcdMyVarBool 0U
extern const BOOLEAN _gPcd_FixedAtBuild_PcdMyVarBool;
#define _PCD_GET_MODE_BOOL_PcdMyVarBool _gPcd_FixedAtBuild_PcdMyVarBool
//#define _PCD_SET_MODE_BOOL_PcdMyVarBool ASSERT(FALSE) // It is not allowed to set value for a FIXED_AT_BUILD PCD

#define _PCD_TOKEN_PcdMyFeatureFlagVar 0U
#define _PCD_SIZE_PcdMyFeatureFlagVar 1
#define _PCD_GET_MODE_SIZE_PcdMyFeatureFlagVar _PCD_SIZE_PcdMyFeatureFlagVar
#define _PCD_VALUE_PcdMyFeatureFlagVar ((BOOLEAN)0U)
extern const BOOLEAN _gPcd_FixedAtBuild_PcdMyFeatureFlagVar;
#define _PCD_GET_MODE_BOOL_PcdMyFeatureFlagVar _gPcd_FixedAtBuild_PcdMyFeatureFlagVar
//#define _PCD_SET_MODE_BOOL_PcdMyFeatureFlagVar ASSERT(FALSE) // It is not allowed to set value for a FIXED_AT_BUILD PCD
```



Are there any actual differences between those two methods of defining a PCD? Or is `PcdsFeatureFlag` simply a syntactic sugar?


Re: Token values are not produced for PCDs under 'PcdsDynamic' section

Guomin Jiang
 

You need add your PCD into OVMF and make sure the OVMF.fd include it.

You can check the code in MdeModulePkg\Universal\PCD\Dxe\Service.c for detail.

-----Original Message-----
From: Konstantin Aladyshev <aladyshev22@gmail.com>
Sent: Tuesday, June 29, 2021 5:47 PM
To: Jiang, Guomin <guomin.jiang@intel.com>
Cc: discuss@edk2.groups.io
Subject: Re: [edk2-discuss] Token values are not produced for PCDs under
'PcdsDynamic' section

Sorry, I didn't understand your answer. Could you please elaborate it for me.

I'm trying to write `UEFI_APPLICATION` and test its execution in UEFI Shell in
QEMU running OVMF.
I also use `DxePcdLib` as PcdLib in my package DSC file:
```
[LibraryClasses]
...
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
```
In this library LibPcdGet32 is translate to:
```
UINT32
EFIAPI
LibPcdGet32 (
IN UINTN TokenNumber
)
{
return GetPcdProtocol()->Get32 (TokenNumber); } ``` So the correct
`TokenNumber` should be passed for this to work correctly.

But as I said Token for my variable is set to 0 for some reason in AutoGen.h:
```
#define _PCD_TOKEN_PcdMyDynamicVar32 0U ```

On Tue, Jun 29, 2021 at 12:25 PM Jiang, Guomin <guomin.jiang@intel.com>
wrote:

Hi



This should be compiled into PCD PEIMs and PCD DXE Drivers.



It will be contained by firmware eventually.



It seem that you haven’t changed the firmware, so the firmware can’t get
the value and freeze.



Thanks

From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of
Konstantin Aladyshev
Sent: Tuesday, June 29, 2021 1:00 AM
To: discuss@edk2.groups.io
Subject: [edk2-discuss] Token values are not produced for PCDs under
'PcdsDynamic' section



Hello!



I'm trying to understand dynamic PCDs in EDK2.



I've added this code to my package DEC file:

```

[PcdsDynamic]
gMyPkgTokenSpaceGuid.PcdMyDynamicVar32|42|UINT32|0x00000004

```

And have added this code to my app INF file:

```

[Pcd]
gMyPkgTokenSpaceGuid.PcdMyDynamicVar32

```



I'm trying to use PCD in my application like this:

```
Print(L"PcdMyDynamicVar32=%d\n", PcdGet32(PcdMyDynamicVar32));
PcdSet32S(PcdMyDynamicVar32, 52); Print(L"PcdMyDynamicVar32=%d\n",
PcdGet32(PcdMyDynamicVar32));

```



But when I try to compile, the token number is not populated to the
AutoGen.h:

```

#define _PCD_TOKEN_PcdMyDynamicVar32 0U #define
_PCD_GET_MODE_32_PcdMyDynamicVar32
LibPcdGet32(_PCD_TOKEN_PcdMyDynamicVar32)
#define _PCD_GET_MODE_SIZE_PcdMyDynamicVar32
LibPcdGetSize(_PCD_TOKEN_PcdMyDynamicVar32)
#define _PCD_SET_MODE_32_PcdMyDynamicVar32(Value)
LibPcdSet32(_PCD_TOKEN_PcdMyDynamicVar32, (Value)) #define
_PCD_SET_MODE_32_S_PcdMyDynamicVar32(Value)
LibPcdSet32S(_PCD_TOKEN_PcdMyDynamicVar32, (Value))

```

Because of that I get 0 in the first `PcdGet32` call and my application freezes
at the `PcdSet32S` call.





But if I change `[PcdsDynamic]` to [PcdsDynamicEx] in my package DEC file
token value will be populated:

```

#define _PCD_TOKEN_gMyPkgTokenSpaceGuid_PcdMyDynamicVar32
1073741828U
#define _PCD_TOKEN_PcdMyDynamicVar32
_PCD_TOKEN_gMyPkgTokenSpaceGuid_PcdMyDynamicVar32
#define _PCD_GET_MODE_32_PcdMyDynamicVar32
LibPcdGetEx32(&gMyPkgTokenSpaceGuid,
_PCD_TOKEN_PcdMyDynamicVar32)
#define _PCD_GET_MODE_SIZE_PcdMyDynamicVar32
LibPcdGetExSize(&gMyPkgTokenSpaceGuid,
_PCD_TOKEN_PcdMyDynamicVar32)
#define _PCD_SET_MODE_32_PcdMyDynamicVar32(Value)
LibPcdSetEx32(&gMyPkgTokenSpaceGuid,
_PCD_TOKEN_PcdMyDynamicVar32,
(Value)) #define _PCD_SET_MODE_32_S_PcdMyDynamicVar32(Value)
LibPcdSetEx32S(&gMyPkgTokenSpaceGuid,
_PCD_TOKEN_PcdMyDynamicVar32,
(Value))

```



What is my mistake? Why is the token value not populated when
`[PcdsDynamic]` is used?





Best regards,

Konstantin Aladyshev


Re: Token values are not produced for PCDs under 'PcdsDynamic' section

Guomin Jiang
 

Hi

This should be compiled into PCD PEIMs and PCD DXE Drivers.

It will be contained by firmware eventually.

It seem that you haven’t changed the firmware, so the firmware can’t get the value and freeze.

Thanks
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Konstantin Aladyshev
Sent: Tuesday, June 29, 2021 1:00 AM
To: discuss@edk2.groups.io
Subject: [edk2-discuss] Token values are not produced for PCDs under 'PcdsDynamic' section

Hello!

I'm trying to understand dynamic PCDs in EDK2.

I've added this code to my package DEC file:
```
[PcdsDynamic]
gMyPkgTokenSpaceGuid.PcdMyDynamicVar32|42|UINT32|0x00000004
```
And have added this code to my app INF file:
```
[Pcd]
gMyPkgTokenSpaceGuid.PcdMyDynamicVar32
```

I'm trying to use PCD in my application like this:
```
Print(L"PcdMyDynamicVar32=%d\n", PcdGet32(PcdMyDynamicVar32));
PcdSet32S(PcdMyDynamicVar32, 52);
Print(L"PcdMyDynamicVar32=%d\n", PcdGet32(PcdMyDynamicVar32));
```

But when I try to compile, the token number is not populated to the AutoGen.h:
```
#define _PCD_TOKEN_PcdMyDynamicVar32 0U
#define _PCD_GET_MODE_32_PcdMyDynamicVar32 LibPcdGet32(_PCD_TOKEN_PcdMyDynamicVar32)
#define _PCD_GET_MODE_SIZE_PcdMyDynamicVar32 LibPcdGetSize(_PCD_TOKEN_PcdMyDynamicVar32)
#define _PCD_SET_MODE_32_PcdMyDynamicVar32(Value) LibPcdSet32(_PCD_TOKEN_PcdMyDynamicVar32, (Value))
#define _PCD_SET_MODE_32_S_PcdMyDynamicVar32(Value) LibPcdSet32S(_PCD_TOKEN_PcdMyDynamicVar32, (Value))
```
Because of that I get 0 in the first `PcdGet32` call and my application freezes at the `PcdSet32S` call.


But if I change `[PcdsDynamic]` to [PcdsDynamicEx] in my package DEC file token value will be populated:
```
#define _PCD_TOKEN_gMyPkgTokenSpaceGuid_PcdMyDynamicVar32 1073741828U
#define _PCD_TOKEN_PcdMyDynamicVar32 _PCD_TOKEN_gMyPkgTokenSpaceGuid_PcdMyDynamicVar32
#define _PCD_GET_MODE_32_PcdMyDynamicVar32 LibPcdGetEx32(&gMyPkgTokenSpaceGuid, _PCD_TOKEN_PcdMyDynamicVar32)
#define _PCD_GET_MODE_SIZE_PcdMyDynamicVar32 LibPcdGetExSize(&gMyPkgTokenSpaceGuid, _PCD_TOKEN_PcdMyDynamicVar32)
#define _PCD_SET_MODE_32_PcdMyDynamicVar32(Value) LibPcdSetEx32(&gMyPkgTokenSpaceGuid, _PCD_TOKEN_PcdMyDynamicVar32, (Value))
#define _PCD_SET_MODE_32_S_PcdMyDynamicVar32(Value) LibPcdSetEx32S(&gMyPkgTokenSpaceGuid, _PCD_TOKEN_PcdMyDynamicVar32, (Value))
```

What is my mistake? Why is the token value not populated when `[PcdsDynamic]` is used?


Best regards,
Konstantin Aladyshev


Difference between boolean PCD fixed at build and a PCD feature flag

Konstantin Aladyshev <aladyshev22@...>
 

What is the difference between boolean PCD fixed at build and a PCD feature flag?
```
[PcdsFixedAtBuild]
  gMyPkgTokenSpaceGuid.PcdMyVarBool|FALSE|BOOLEAN|0x00000004

[PcdsFeatureFlag]
  gMyPkgTokenSpaceGuid.PcdMyFeatureFlagVar|FALSE|BOOLEAN|0x20000001
```
I'm looking at the AutoGen files and the result from both of these PCDs is practically the same.

AutoGen.c
```
GLOBAL_REMOVE_IF_UNREFERENCED const BOOLEAN _gPcd_FixedAtBuild_PcdMyVarBool = _PCD_VALUE_PcdMyVarBool;
GLOBAL_REMOVE_IF_UNREFERENCED const BOOLEAN _gPcd_FixedAtBuild_PcdMyFeatureFlagVar = _PCD_VALUE_PcdMyFeatureFlagVar;
```
AutoGen.h
```
#define _PCD_TOKEN_PcdMyVarBool  0U
#define _PCD_SIZE_PcdMyVarBool 1
#define _PCD_GET_MODE_SIZE_PcdMyVarBool  _PCD_SIZE_PcdMyVarBool
#define _PCD_VALUE_PcdMyVarBool  0U
extern const  BOOLEAN  _gPcd_FixedAtBuild_PcdMyVarBool;
#define _PCD_GET_MODE_BOOL_PcdMyVarBool  _gPcd_FixedAtBuild_PcdMyVarBool
//#define _PCD_SET_MODE_BOOL_PcdMyVarBool  ASSERT(FALSE)  // It is not allowed to set value for a FIXED_AT_BUILD PCD

#define _PCD_TOKEN_PcdMyFeatureFlagVar  0U
#define _PCD_SIZE_PcdMyFeatureFlagVar 1
#define _PCD_GET_MODE_SIZE_PcdMyFeatureFlagVar  _PCD_SIZE_PcdMyFeatureFlagVar
#define _PCD_VALUE_PcdMyFeatureFlagVar  ((BOOLEAN)0U)
extern const  BOOLEAN  _gPcd_FixedAtBuild_PcdMyFeatureFlagVar;
#define _PCD_GET_MODE_BOOL_PcdMyFeatureFlagVar  _gPcd_FixedAtBuild_PcdMyFeatureFlagVar
//#define _PCD_SET_MODE_BOOL_PcdMyFeatureFlagVar  ASSERT(FALSE)  // It is not allowed to set value for a FIXED_AT_BUILD PCD
```

Are there any actual differences between those two methods of defining a PCD? Or is `PcdsFeatureFlag` simply a syntactic sugar?


Token values are not produced for PCDs under 'PcdsDynamic' section

Konstantin Aladyshev <aladyshev22@...>
 

Hello!

I'm trying to understand dynamic PCDs in EDK2.

I've added this code to my package DEC file:
```
[PcdsDynamic]
  gMyPkgTokenSpaceGuid.PcdMyDynamicVar32|42|UINT32|0x00000004
```
And have added this code to my app INF file:
```
[Pcd]
  gMyPkgTokenSpaceGuid.PcdMyDynamicVar32
```

I'm trying to use PCD in my application like this:
```
Print(L"PcdMyDynamicVar32=%d\n", PcdGet32(PcdMyDynamicVar32));
PcdSet32S(PcdMyDynamicVar32, 52);
Print(L"PcdMyDynamicVar32=%d\n", PcdGet32(PcdMyDynamicVar32));
```

But when I try to compile, the token number is not populated to the AutoGen.h:
```
#define _PCD_TOKEN_PcdMyDynamicVar32  0U
#define _PCD_GET_MODE_32_PcdMyDynamicVar32  LibPcdGet32(_PCD_TOKEN_PcdMyDynamicVar32)
#define _PCD_GET_MODE_SIZE_PcdMyDynamicVar32  LibPcdGetSize(_PCD_TOKEN_PcdMyDynamicVar32)
#define _PCD_SET_MODE_32_PcdMyDynamicVar32(Value)  LibPcdSet32(_PCD_TOKEN_PcdMyDynamicVar32, (Value))
#define _PCD_SET_MODE_32_S_PcdMyDynamicVar32(Value)  LibPcdSet32S(_PCD_TOKEN_PcdMyDynamicVar32, (Value))
```
Because of that I get 0 in the first `PcdGet32` call and my application freezes at the `PcdSet32S` call.


But if I change `[PcdsDynamic]` to [PcdsDynamicEx] in my package DEC file token value will be populated:
```
#define _PCD_TOKEN_gMyPkgTokenSpaceGuid_PcdMyDynamicVar32  1073741828U
#define _PCD_TOKEN_PcdMyDynamicVar32  _PCD_TOKEN_gMyPkgTokenSpaceGuid_PcdMyDynamicVar32
#define _PCD_GET_MODE_32_PcdMyDynamicVar32  LibPcdGetEx32(&gMyPkgTokenSpaceGuid, _PCD_TOKEN_PcdMyDynamicVar32)
#define _PCD_GET_MODE_SIZE_PcdMyDynamicVar32 LibPcdGetExSize(&gMyPkgTokenSpaceGuid, _PCD_TOKEN_PcdMyDynamicVar32)
#define _PCD_SET_MODE_32_PcdMyDynamicVar32(Value)  LibPcdSetEx32(&gMyPkgTokenSpaceGuid, _PCD_TOKEN_PcdMyDynamicVar32, (Value))
#define _PCD_SET_MODE_32_S_PcdMyDynamicVar32(Value)  LibPcdSetEx32S(&gMyPkgTokenSpaceGuid, _PCD_TOKEN_PcdMyDynamicVar32, (Value))
```

What is my mistake? Why is the token value not populated when `[PcdsDynamic]` is used?


Best regards,
Konstantin Aladyshev


Enable UART CTS and RTS in edk2

Antony Abee
 

Hi,

We are developing edk2 bios image for our custom board which is based on Ampere SOC.

Custom board has Uart connections as below:
Uart0

* DB9 connector (Uefi console)
* CTS/RTS signals from SOC

Uart3

* DB9 connector
* CTS/RTS signals from GPIO

We have following queries:

1. CTS/RTS signals have usage in edk2 ? or this is useful in OS level only ?
2. Where to enable CTS/RTS control register bits in edk2 source for ampere platform ?
3. Where to configure GPIO's for Uart3 CTS and RTS signals in edk2 source for ampere platform ?
4. Not able to find gpio pad configuration for ampere platform in edk2 source.
5. Could you please help to clarify the above queries ?

Thanks & Regards,
Antony


Re: How to build your own firmware based upon EDK2 for Windows 10 QEMU

Andrew Fish
 

Wong,

If you are building OvmfPkgX64.dsc then you can add driver or apps to OvmfPkgX64.dsc [1] to get it to build, and add it to OvmfPkgX64.fdf [2] to get it in the ROM.

[1] https://github.com/tianocore/edk2/blob/master/OvmfPkg/OvmfPkgX64.dsc
[2] https://github.com/tianocore/edk2/blob/master/OvmfPkg/OvmfPkgX64.fdf

Thanks,

Andrew Fish

On Jun 12, 2021, at 6:59 AM, tbtbfaker@gmail.com wrote:

Hi,

I am currently working on a project where I would have to customize the EFI ROM file for my Windows 10. To emulate firmware, I have built latest edk2 as well as OVMF. I am able to run OVMF using QEMU but I have no clue on the next step in order to make custom firmware to run Windows 10 in QEMU.

Can anyone advise on what I should look at next?

Regards,
Wong





Enabling UART CTS / RTS support in edk2

Antony Abee
 

Hi All,

We are developing an edk2 bios image for our custom board which is based on Ampere SOC.

Our custom board has
Uart0 - uefi logs
Uart3 - Connected to DB9 connector.

For uart0 the cts and rts signals are from SOC itself. Whereas for Uart3, cts and rts signals are from GPIO.

Uart Driver used: ARM PL011 UART driver.

We have below queries.
1. Does CTS and RTS signals have usage in edk2 ? or this will be taken care in OS level ?
2. Where to enable CTS/RTS bits of uart control registers in edk2 ?
3. Where to configure the GPIO's as CTS and RTS functionality in edk2 ?

Could anyone help on this ?

Thanks.


How to build your own firmware based upon EDK2 for Windows 10 QEMU

tbtbfaker@...
 

Hi,

I am currently working on a project where I would have to customize the EFI ROM file for my Windows 10. To emulate firmware, I have built latest edk2 as well as OVMF. I am able to run OVMF using QEMU but I have no clue on the next step in order to make custom firmware to run Windows 10 in QEMU.

Can anyone advise on what I should look at next?

Regards,
Wong


Re: CXL 2.0 Type 3 Support

Leif Lindholm
 

Hi Chris,

Apologies, I missed this when it went out (I'm even worse at reading
-discuss than I am -devel).

I am also interested in this, and my team will need to start working
on this soon unless someone has something already in the pipeline and
are willing to share it with the world.

Best Regards,

Leif

On Wed, Mar 10, 2021 at 11:17:02 -0500, Chris Browy wrote:
Hi,

We’ve working with patch series on top of the QEMU CXL 2.0 Type 3
adding Data Object Exchange (DOE) for CDAT and Compliance Mode.
This is required to support CXL 2.0 device enumeration and setup of
SRAT/HMAT tables for OS handoff.

https://lore.kernel.org/qemu-devel/1615322029-13038-1-git-send-email-cbrowy@avery-design.com/T/#ma47459bfbcd29cf28f11ee9389e5a2ac966a64e1

Based on QEMU version:

https://gitlab.com/bwidawsk/qemu/-/tree/cxl-2.0v4

Do you have a roadmap for edk2 support for CXL 2.0? This is the
last piece of the puzzle!

Best Regards,
Chris Browy




--
Chris Browy





EFI_IMAGE_LOAD_EVENT.ImageLocationInMemory is not useful

Satoshi Tanda
 

Hi,

It appears that the EFI_IMAGE_LOAD_EVENT.ImageLocationInMemory field can contain practically useless garbage value in some cases. I do not think it is "really" intentional and think it should be fixed.

Some TCG PCR events such as EV_EFI_RUNTIME_SERVICES_DRIVER populate log entries as EFI_IMAGE_LOAD_EVENT, and one of its fields ImageLocationInMemory should contain the base address of the image being measured. As-is, this field may be populated with the address of the temporal buffer as opposed to buffer that is eventually used to execute the image. This makes contents of the ImageLocationInMemory field useless, because the buffer is freed and its contents is destroyed quickly. It would have been substantially more useful if the field contained the address of the final image location, especially for runtime drivers where an operating system could later inspect its contents accordingly to the log.

The problem appears to be that, in CoreLoadImageCommon(), FHand.Source is allocated by GetFileBufferByFilePath() and passed to gSecurity2->FileAuthentication() if the SourceBuffer argument is not supplied. This results in logging the address of the temporal boot-time pool, which is released as soon as the function ends.
https://github.com/tianocore/edk2/blob/e0cb5e1814a67bb12dd476a72d1698350633bcbb/MdeModulePkg/Core/Dxe/Image/Image.c#L1215

It does not explicitly violates the TCG spec, and even if this is fixed, the ImageLocationInMemory value for boot drivers and applications would have been useless for an OS anyway. But, as-is, the field is too often useless because many cases, including with the "load" UEFI shell command, hits the above condition.

Could this be changed in a way to log the image address that is/will be executed, and not a temporal address? I could file a bugzilla case if that's reasonable.

Best,
Satoshi


Website

elijah alkhoury <alkhouryelijah13@...>
 

Hello, I am seeking help with tianocore.


Re: Having problem when xHCI create Setup Stage TRB

Wu, Hao A
 

Thanks a lot.

Best Regards,
Hao Wu

-----Original Message-----
From: xiewenyi (A) <xiewenyi2@huawei.com>
Sent: Thursday, May 27, 2021 4:32 PM
To: Wu, Hao A <hao.a.wu@intel.com>; discuss@edk2.groups.io
Subject: Re: [edk2-discuss] Having problem when xHCI create Setup Stage
TRB

OK, I will submit a BZ bug and patch soon.

Thanks
Wenyi

On 2021/5/27 16:26, Wu, Hao A wrote:
Thanks.
Could you help to submit a BZ bug tracker at:
https://bugzilla.tianocore.org/enter_bug.cgi?product=EDK2?
And could you help to propose a fix for this issue?

Best Regards,
Hao Wu

-----Original Message-----
From: xiewenyi (A) <xiewenyi2@huawei.com>
Sent: Thursday, May 27, 2021 4:20 PM
To: Wu, Hao A <hao.a.wu@intel.com>; discuss@edk2.groups.io
Subject: Re: [edk2-discuss] Having problem when xHCI create Setup
Stage TRB

Hi, Wu Hao

As TRT field is not set to EfiUsbNoData when Data Stage does not
exist, USB controller returns trb err and finally lead to usb enumerate fail.


Thanks
Wenyi

On 2021/5/27 15:24, Wu, Hao A wrote:
Hello,

Looking into the XHCI spec, I think the current implementation in
XhciDxe & XhciPei does not follow the spec when it comes to the TRT
field.

Could you help to provide more information on what error is met?
Thanks in advance.

Best Regards,
Hao Wu

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of
wenyi,xie via groups.io
Sent: Wednesday, May 26, 2021 2:09 PM
To: discuss@edk2.groups.io
Subject: [edk2-discuss] Having problem when xHCI create Setup Stage
TRB

Hello, everyone,

we meet a problem and are not sure if it's an issue, here's the
description.
According usb-xhci specification, at USB packet level, a Control
Transfer consists of multiple transactions partitioned into stages:
a setup stage, an optional data stage, and a terminating status stage.
If Data Stage does not exist, the Transfer Type flag(TRT) should be
No Data Stage.

But in function XhcCreateUrb() in file XhciSched.c, the Direction
is set to EfiUsbDataIn or EfiUsbDataOut.
Ep->Direction = ((EpAddr & 0x80) != 0) ? EfiUsbDataIn :
Ep->EfiUsbDataOut;

and then in function XhcCreateTransferTrb(), TRT is set to 3 or 2,
it will never be 0.
if (Urb->Ep.Direction == EfiUsbDataIn) {
TrbStart->TrbCtrSetup.TRT = 3;
} else if (Urb->Ep.Direction == EfiUsbDataOut) {
TrbStart->TrbCtrSetup.TRT = 2;
} else {
TrbStart->TrbCtrSetup.TRT = 0;
}

TRT Value Definition
0 No Data Stage
1 Reserved
2 OUT Data Stage
3 IN Data Stage




Re: Having problem when xHCI create Setup Stage TRB

wenyi,xie
 

OK, I will submit a BZ bug and patch soon.

Thanks
Wenyi

On 2021/5/27 16:26, Wu, Hao A wrote:
Thanks.
Could you help to submit a BZ bug tracker at: https://bugzilla.tianocore.org/enter_bug.cgi?product=EDK2?
And could you help to propose a fix for this issue?

Best Regards,
Hao Wu

-----Original Message-----
From: xiewenyi (A) <xiewenyi2@huawei.com>
Sent: Thursday, May 27, 2021 4:20 PM
To: Wu, Hao A <hao.a.wu@intel.com>; discuss@edk2.groups.io
Subject: Re: [edk2-discuss] Having problem when xHCI create Setup Stage
TRB

Hi, Wu Hao

As TRT field is not set to EfiUsbNoData when Data Stage does not exist, USB
controller returns trb err and finally lead to usb enumerate fail.


Thanks
Wenyi

On 2021/5/27 15:24, Wu, Hao A wrote:
Hello,

Looking into the XHCI spec, I think the current implementation in
XhciDxe & XhciPei does not follow the spec when it comes to the TRT field.

Could you help to provide more information on what error is met?
Thanks in advance.

Best Regards,
Hao Wu

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of
wenyi,xie via groups.io
Sent: Wednesday, May 26, 2021 2:09 PM
To: discuss@edk2.groups.io
Subject: [edk2-discuss] Having problem when xHCI create Setup Stage
TRB

Hello, everyone,

we meet a problem and are not sure if it's an issue, here's the description.
According usb-xhci specification, at USB packet level, a Control
Transfer consists of multiple transactions partitioned into stages: a
setup stage, an optional data stage, and a terminating status stage.
If Data Stage does not exist, the Transfer Type flag(TRT) should be
No Data Stage.

But in function XhcCreateUrb() in file XhciSched.c, the Direction is
set to EfiUsbDataIn or EfiUsbDataOut.
Ep->Direction = ((EpAddr & 0x80) != 0) ? EfiUsbDataIn :
Ep->EfiUsbDataOut;

and then in function XhcCreateTransferTrb(), TRT is set to 3 or 2,
it will never be 0.
if (Urb->Ep.Direction == EfiUsbDataIn) {
TrbStart->TrbCtrSetup.TRT = 3;
} else if (Urb->Ep.Direction == EfiUsbDataOut) {
TrbStart->TrbCtrSetup.TRT = 2;
} else {
TrbStart->TrbCtrSetup.TRT = 0;
}

TRT Value Definition
0 No Data Stage
1 Reserved
2 OUT Data Stage
3 IN Data Stage




Re: Having problem when xHCI create Setup Stage TRB

Wu, Hao A
 

Thanks.
Could you help to submit a BZ bug tracker at: https://bugzilla.tianocore.org/enter_bug.cgi?product=EDK2?
And could you help to propose a fix for this issue?

Best Regards,
Hao Wu

-----Original Message-----
From: xiewenyi (A) <xiewenyi2@huawei.com>
Sent: Thursday, May 27, 2021 4:20 PM
To: Wu, Hao A <hao.a.wu@intel.com>; discuss@edk2.groups.io
Subject: Re: [edk2-discuss] Having problem when xHCI create Setup Stage
TRB

Hi, Wu Hao

As TRT field is not set to EfiUsbNoData when Data Stage does not exist, USB
controller returns trb err and finally lead to usb enumerate fail.


Thanks
Wenyi

On 2021/5/27 15:24, Wu, Hao A wrote:
Hello,

Looking into the XHCI spec, I think the current implementation in
XhciDxe & XhciPei does not follow the spec when it comes to the TRT field.

Could you help to provide more information on what error is met?
Thanks in advance.

Best Regards,
Hao Wu

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of
wenyi,xie via groups.io
Sent: Wednesday, May 26, 2021 2:09 PM
To: discuss@edk2.groups.io
Subject: [edk2-discuss] Having problem when xHCI create Setup Stage
TRB

Hello, everyone,

we meet a problem and are not sure if it's an issue, here's the description.
According usb-xhci specification, at USB packet level, a Control
Transfer consists of multiple transactions partitioned into stages: a
setup stage, an optional data stage, and a terminating status stage.
If Data Stage does not exist, the Transfer Type flag(TRT) should be
No Data Stage.

But in function XhcCreateUrb() in file XhciSched.c, the Direction is
set to EfiUsbDataIn or EfiUsbDataOut.
Ep->Direction = ((EpAddr & 0x80) != 0) ? EfiUsbDataIn :
Ep->EfiUsbDataOut;

and then in function XhcCreateTransferTrb(), TRT is set to 3 or 2,
it will never be 0.
if (Urb->Ep.Direction == EfiUsbDataIn) {
TrbStart->TrbCtrSetup.TRT = 3;
} else if (Urb->Ep.Direction == EfiUsbDataOut) {
TrbStart->TrbCtrSetup.TRT = 2;
} else {
TrbStart->TrbCtrSetup.TRT = 0;
}

TRT Value Definition
0 No Data Stage
1 Reserved
2 OUT Data Stage
3 IN Data Stage




Re: Having problem when xHCI create Setup Stage TRB

wenyi,xie
 

Hi, Wu Hao

As TRT field is not set to EfiUsbNoData when Data Stage does not exist, USB controller
returns trb err and finally lead to usb enumerate fail.


Thanks
Wenyi

On 2021/5/27 15:24, Wu, Hao A wrote:
Hello,

Looking into the XHCI spec, I think the current implementation in XhciDxe & XhciPei
does not follow the spec when it comes to the TRT field.

Could you help to provide more information on what error is met?
Thanks in advance.

Best Regards,
Hao Wu

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of
wenyi,xie via groups.io
Sent: Wednesday, May 26, 2021 2:09 PM
To: discuss@edk2.groups.io
Subject: [edk2-discuss] Having problem when xHCI create Setup Stage TRB

Hello, everyone,

we meet a problem and are not sure if it's an issue, here's the description.
According usb-xhci specification, at USB packet level, a Control Transfer
consists of multiple transactions partitioned into stages: a setup stage, an
optional data stage, and a terminating status stage.
If Data Stage does not exist, the Transfer Type flag(TRT) should be No Data
Stage.

But in function XhcCreateUrb() in file XhciSched.c, the Direction is set to
EfiUsbDataIn or EfiUsbDataOut.
Ep->Direction = ((EpAddr & 0x80) != 0) ? EfiUsbDataIn : EfiUsbDataOut;

and then in function XhcCreateTransferTrb(), TRT is set to 3 or 2, it will never
be 0.
if (Urb->Ep.Direction == EfiUsbDataIn) {
TrbStart->TrbCtrSetup.TRT = 3;
} else if (Urb->Ep.Direction == EfiUsbDataOut) {
TrbStart->TrbCtrSetup.TRT = 2;
} else {
TrbStart->TrbCtrSetup.TRT = 0;
}

TRT Value Definition
0 No Data Stage
1 Reserved
2 OUT Data Stage
3 IN Data Stage




Re: Having problem when xHCI create Setup Stage TRB

Wu, Hao A
 

Hello,

Looking into the XHCI spec, I think the current implementation in XhciDxe & XhciPei
does not follow the spec when it comes to the TRT field.

Could you help to provide more information on what error is met?
Thanks in advance.

Best Regards,
Hao Wu

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of
wenyi,xie via groups.io
Sent: Wednesday, May 26, 2021 2:09 PM
To: discuss@edk2.groups.io
Subject: [edk2-discuss] Having problem when xHCI create Setup Stage TRB

Hello, everyone,

we meet a problem and are not sure if it's an issue, here's the description.
According usb-xhci specification, at USB packet level, a Control Transfer
consists of multiple transactions partitioned into stages: a setup stage, an
optional data stage, and a terminating status stage.
If Data Stage does not exist, the Transfer Type flag(TRT) should be No Data
Stage.

But in function XhcCreateUrb() in file XhciSched.c, the Direction is set to
EfiUsbDataIn or EfiUsbDataOut.
Ep->Direction = ((EpAddr & 0x80) != 0) ? EfiUsbDataIn : EfiUsbDataOut;

and then in function XhcCreateTransferTrb(), TRT is set to 3 or 2, it will never
be 0.
if (Urb->Ep.Direction == EfiUsbDataIn) {
TrbStart->TrbCtrSetup.TRT = 3;
} else if (Urb->Ep.Direction == EfiUsbDataOut) {
TrbStart->TrbCtrSetup.TRT = 2;
} else {
TrbStart->TrbCtrSetup.TRT = 0;
}

TRT Value Definition
0 No Data Stage
1 Reserved
2 OUT Data Stage
3 IN Data Stage



101 - 120 of 860