-
Notifications
You must be signed in to change notification settings - Fork 1
PCD
Questions asked about PCDs
PCDs are declared as part of the DEC, and referenced in a modules INF and a package’s DSC.
- PCDs of type FeatureFlag are declared as CONST variables in every module that uses that PCD
- PCDs of type FixedAtBuild are also declared as CONST variables in every module that uses that PCD
- PCDs if type PatchableInModule are declared as ‘volatile’ variables in every the module that uses that PCD.
- PCDs of type Dynamic/DynamicEx are global to the entire platform. There are 3 subtypes of Dynamic/DynamicEx. The first is VPD, which are Read-Only and is stored in an uncompressed section of the system FLASH/ROM. The second is HII, which are R/W and Non-Volatile, and they are mapped to an EFI Variable which is named by a GUID + UnicodeString + ByteOffset. The third is Default, which are R/W and Volatile, which means their contents are lost every time the platform is reset or power cycled.
Yes, there is PCD Library call depending on the type and size of the PCD variable
The PCD Documentation is part of the Build description specifications. Such that there is a section in each of the DEC, DSC, FDF and INF specifications that list the syntax of the PCD for each type of spec.
Not currently
The package owner assigns a unique token with the PCD entries.
The FeatureFlag PCD can be used to enable or disable drivers during runtime. If the platform designer wants to not include the feature or driver then there are a couple of possibilities. Use different .DSC and .FDF files to have them removed. Another is to use “–D” with the build command line to pass macros into the build. There is an active feature request for PCDs to be used to enable/disable drivers at build time. This is a capability that will be made available in a future release of the EDK II.
There minimal support with PCD and ACPI because the ASL complier is built as a separate part of the build process.
Packages designed properly should be able to use and port by only adjust PCD values—hard-coded values require touching sources
Nothing prevents using PCDs for large structures
Yes, Use DynamicHii PCD type that should reference the Varstore structure stored to efivariable—dynamic pcd –statement token space guid in token space, etc for that specific setting compute offset & put into DSC file
EDK 1 uses Macros to initialize array variables. How do you use fixed PCD in an array element in a library?
I’ve tried to use PCD Fixed at build but I get error using fixedPCDget32 in a library module. What is the scheme to initialize an array with fixed values in a library?
A) You cannot use a fixed PCD get call for a global structure or global initialization from a library. This is a limit from the PCD design. The reason is the PCD value can be set on a per module bases. For example if you have 5 modules linking for the same library the modules can override the values of the PCD. This was done for Build performance so that each library would be built only one time. The FixedPCDget is allowed to be used within a module but not within the libraries.
B) I recommend having portions of your library having global structures or variables – Pre initialize as much of the global you can that does not require the use of PCDs. Then introduce a library constructor and then in your code for the constructor you can use the FixedPCDGetnn to fill in the value as opposed to pre initialized in the data section
There is no GUI interface but the BUILD with “-Y PCD” option for the platform will create a report for that platform. It will show at the module level.
The best way is to look at the Mdepkg .chm. It should list what the PCD is and it’s characteristics with descriptions of each. The .chm is created from the .dec file that defines the PCDs using the Doxygen tool.
When modifying PCDs within the token space for different products the different products will have the entire PCD token space for that package as opposed to just a few PCDs that would need to be changed per a product.
There are too many PCDs in the .chm. Is there any other means for documentation for porting/ integrating?
The .CHM is the package scope. The other aspect is distributing a module needs to have documentation for integration. Need to list dependencies for module. The documentation should follow at the module level and listing out the PCDs and their default working.