Implement a support library for SMBIOS-related SMC calls. Currently this
implements a function to return the SoC ID.
Signed-off-by: Sarah Walker <Sarah.Walker2@arm.com>
BuildAndInstallMultipleSmbiosTables() can dereference a NULL pointer if the
SMBIOS table builder returns a NULL CmObjToken array.
Signed-off-by: Sarah Walker <Sarah.Walker2@arm.com>
Abstract tokens simplify linking of generated tables. They allow for tables
to be search for not just by existing ConfigurationManager object
references, but also by arbitrary tokens generated by the table generators
themselves.
Signed-off-by: Sarah Walker <Sarah.Walker2@arm.com>
Add the SMBIOS Table generator code to the DynamicTablesPkg.
This change includes adding new logic to the DynamicTableManager
to process and add SMBIOS tables and augmenting the existing SMBIOS
Factory generator to include installing multiple SMBIOS tables.
Signed-off-by: Girish Mahadevan <gmahadevan@nvidia.com>
In preparation to introduce Dynamic SMBIOS support the
following 2 changes are required:
1. Use ProtocolNotify Event for generating the ACPI tables
and don't include the ACPI protocol in the Depex section
for DynamicTableManagerDxe Driver.
This is because if a platforms doesn't do ACPI based boot or if
doesn't want to install SMBIOS tables we still want the
DynamicTableManager to be dispatched to install the SMBIOS or ACPI
tables respectively.
2. Split the logic for building the ACPI tables to a separate file.
Signed-off-by: Girish Mahadevan <gmahadevan@nvidia.com>
Some SMBIOS tables do not have a fixed dependency and can depend on any
other SMBIOS tables. Therefore, the SMBIOS dispatcher cannot define a
fixed sequence for dispatching these tables. A possible solution is to
defer the dispatch of such SMBIOS tables towards the end, assuming that
the dependent SMBIOS tables would have been dispatched by then.
Therefore, introduce a dispatch order attribute such that SMBIOS tables
that have a fixed dependency sequence are configured as Default Ordered,
and the SMBIOS tables that do not have a fixed dependency have an Order
attribute specifying an Order Level. An Order Level is used to sequence
the dispatch of Ordered SMBIOS tables.
The Default Ordered SMBIOS tables are dispatched first and a dependency
walk is performed to dispatch the dependent tables by iterating through
the SMBIOS_TABLE_DISPATCHER.Dependency[].
Once all Default ordered SMBIOS tables have been dispatched, the Ordered
SMBIOS tables would be scheduled for dispatch in increasing order as of
the Order Level, e.g. OrderL1, OrderL2, ...
Note: The dispatcher does not perform a dependency walk for the Ordered
SMBIOS tables as the expectation is that the dependent SMBIOS tables
would be already dispatched.
A top level dispatch function DispatchSmbiosTables() has been introduced
to schedule the dispatch of Default Ordered and Ordered SMBIOS tables.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Cc: Alexei Fedorov <Alexei.Fedorov@arm.com>
Cc: Pierre Gondois <pierre.gondois@arm.com>
Cc: Girish Mahadevan <gmahadevan@nvidia.com>
Cc: Jeff Brasen <jbrasen@nvidia.com>
Cc: Ashish Singhal <ashishsingha@nvidia.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Cc: William Watson <wwatson@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Cc: Jose Marinho <Jose.Marinho@arm.com>
Some SMBIOS structure/table fields have dependency on other SMBIOS
structures/tables. These dependencies are established using handles
pointing to the dependent tables.
A SMBIOS table handle can be obtained by either installing a SMBIOS
table or by allocating a handle, which requires complex management
to avoid any clashes.
Obtaining a SMBIOS handle by installation requires that the dependent
table is installed before the parent SMBIOS table can be installed.
Therefore, introduce a SMBIOS table dispatcher that walks the SMBIOS
dependency list and schedules the dependent tables to be installed
before the parent table is installed.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Cc: Alexei Fedorov <Alexei.Fedorov@arm.com>
Cc: Pierre Gondois <pierre.gondois@arm.com>
Cc: Girish Mahadevan <gmahadevan@nvidia.com>
Cc: Jeff Brasen <jbrasen@nvidia.com>
Cc: Ashish Singhal <ashishsingha@nvidia.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Cc: William Watson <wwatson@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Cc: Jose Marinho <Jose.Marinho@arm.com>
edk2 is dropping support for the ARM32 architecture. This
commit removes ARM32 code from DynamicTablesPkg. This also
drops irrelevant VALID_ARCHITECTURES comments from infs that
are not arch specific.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
All DynamicTablesPkg libraries and drivers execute in the DXE phase,
where both AMD and Intel platforms operate in X64 (64-bit) mode.
Therefore, IA32 (32-bit) support is no longer required for DynamicTablesPkg.
Signed-off-by: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
Introduce EArchCommonObjMcfgPciConfigSpaceInfo as an alias for
EArchCommonObjPciConfigSpaceInfo.
The CM_ARCH_COMMON_PCI_CONFIG_SPACE_INFO object is utilized by both
the MCFG and ACPI SSDT PCIE generators. Assigning a unique configuration
object ID ensures the platform configuration driver supplies the correct data.
Signed-off-by: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
Introduce Tpm2DeviceTableLib to generate SSDT table which describes
Tpm2 devices.
This dynamic table generation is controlled by PcdGenTpm2DeviceTable
which default value is FALSE.
When it is TRUE, the TPM2 device ssdt table is generated when TPM2 ACPI
table is generated.
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
Introduce an X64-specific implementation of the
SsdtSerialPortFixupLib library class.
Utilizes the AML library to generate COM or serial device dynamically.
Signed-off-by: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
Adds AML code generation for Serial UART resource descriptor.
This commit introduces helper functions to generate
AML resource data for serial UART resource descriptor.
Signed-off-by: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
Adds AML code generation for IRQ resource descriptor.
This commit introduces helper functions to generate
AML resource data for IRQ resource descriptors.
Signed-off-by: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
Update unit tests to use GoogleTestLib.h instead
of gtest.h so the edk2 extensions for google tests
are always available.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Introduce optional configuration objects to specify interrupt and terminal types.
When the platform supplies this information,
the SPCR table is updated to reflect the provided values.
If the interrupt type is 8259,
the corresponding IRQ number is set in the SPCR table.
Signed-off-by: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
Introduce a common architecture SLIT table generator library
that retrieves locality domain distance information from
the configuration manager and generates the table accordingly.
Signed-off-by: abdattar <AbdulLateef.Attar@amd.com>
Following the addition of the CM_ARCH_COMMON_PROXIMITY_DOMAIN_INFO
object, rework the Srat Generator.
A Warning message is issued when the Original ProximityDomain
fields are used.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Proximity domains Ids should now be described using the
CM_ARCH_COMMON_PROXIMITY_DOMAIN_INFO object. This adds a level
of indirection: a Token allows to retrieve a
CM_ARCH_COMMON_PROXIMITY_DOMAIN_INFO object, and this object might
either have a hard-coded Id, or rely on the MetadataObjLib to
generate an Id.
Add a GetProximityDomainId () function to the CmObjHelperLib to
factorize this level of abstraction and allow other generators
to re-use the logic.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The SRAT/HMAT/SLIT tables describe the relations between
ProximityDomain IDs. These proximity domains might represent
memory domains, CPUs, IO, etc.
ProximityDomain IDs are mere IDs. They don't represent anything
and could be generated by the DynamicTablesPkg framework. These
IDs are currently hard-coded by the ConfigurationManager developer.
In order to:
- avoid the developer to keep track of the used ProximityDomain IDs
- have a better internal representation of the relation between
CPUs sharing the same ProximityDomain ID
allow the developer to use Tokens pointing to ProximityDomain
structures.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The ACPI specification v6.5, sTable 5.158: Processor Structure Flags
states that:
"""
The processor container will have a matching ID
value returned through the _UID method. As not every pro-
cessor hierarchy node structure in PPTT may have a matching
processor container, this flag indicates whether the ACPI pro-
cessor ID points to valid entry. Where a valid entry is possible
the ACPI Processor ID and _UID method are mandatory.
"""
And in:
Table 5.157: Processor Hierarchy Node Structure
"""
If the processor structure rep-
resents a group of associated processors, the structure might
match a processor container in the name space. In that case
this entry will match the value of the _UID method of the as-
sociated processor container. Where there is a match it must
be represented. The flags field, described in Processor Struc-
ture Flags, includes a bit to describe whether the ACPI pro-
cessor ID is valid.
"""
The DynamicTablesPkg currently creates a processor container:
- in the SSDT CPU Topology generator, with the _HID=ACPI0010,
and with a valid _UID
- in the PPTT table
for each CM_ARCH_COMMON_PROC_HIERARCHY_INFO structure.
Thus:
- all the processor containers should have the VALID bit set
if the SSDT CPU Topology table is present.
- if the SSDT CPU Topology table is present, but there is no
PPTT table, then the state of the VALID bit is ignored.
A contrario, an example where the VALID bit should not be set
would be if:
- the SSDT CPU Topology generator is absent
- no processor container is created in the SSDT topology,
i.e. if a flat hierarchy is created.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Some generators share some logic in how they handle CmObj.
In an effort to factorize this code, create a CmObjHelperLib,
aiming to host the common CmObj manipulation logic.
Start by adding a CheckAcpiTablePresent() function, allowing
to check if an ACPI table is in the list of the tables to
install.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The processor containers might have an associated _UID:
- in their SSDT topology representation
- in their PPTT representation, in the "ACPI Processor ID" field
The _UID of the processor containers is independently generated
by the PPTT and SSDT CPU topology generators. Make use of the newly
created MetadataObjLib to generate a unique and common per-processor
container _UID values.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The processor containers might have an associated _UID:
- in their SSDT topology representation
- in their PPTT representation, in the "ACPI Processor ID" field
The _UID of the processor containers is independently generated
by the PPTT and SSDT CPU topology generators. Make use of the newly
created MetadataObjLib to generate a unique and common per-processor
container _UID values.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The newly added MetadataObjLib allows to store information either:
- generated by the DynamictTablesPkg framework
- provided by a ConfigurationManager
- parsed from another source of information
This information might be subject to validation/verification.
This step can only be done once the firmware tables generated
by the DynamictTablesPkg have been generated.
Add a new GetMetadataRoot() callback to the
EDKII_DYNAMIC_TABLE_FACTORY_PROTOCOL. This callback allows
to fetch the Metadata Root, allowing to access all the Metadata
information generated. This Metadata is then validated by the
DynamicTableManagerDxe.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Built on top of the MetadataObjLib, this library aims to
provide functions for each METADATA_ID to:
- Generate new Metadata on the fly: the caller provides
minimal information for a METADATA_ID, and the library
generates the missing information.
- Validate all the Metadata objects for a METADATA_ID.
For instance, _UID must be unique for a _HID/_CID/EISAID.
This patch also adds support for generation/validation of:
- UIDs:
For each EISAID or NameId, UIDs must be unique. The generation
if UIDs is done by a per-EISAID/NameId incrementing counter.
The validation of the Metadata consists in checking for the
uniqueness of the UID per EISAID/NameId.
- ProximityDomains:
Proximity Domain Ids are generated by a counter, starting
from 0.
The validation of the Metadata consists in checking for
the uniqueness of the proximity domain Ids.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The DynamicTablesPkg allows to generate firmware tables based on
information provided by a user or another source of information
(a device tree for instance).
Some information might be implicitly generated by generators.
For instance, for ACPI tables, AML names or Uids are created by
generators, but not provided by the user or another source of
information.
Some generators might need to cross-reference object/generated data
that was previous generated for an object by another generator.
For instance, there are three different generators creating serial
ports in the AML namespace. These 3 generators must ensure not to use
an Id which was not already created by another generator.
Another example would be a generator needing to reference the AML
path of a serial port. As the AML path is dynamically generated, this
is currently not possible to do.
Add a MetaDataObjLib library to keep track of the meta-data previously
generated for an object.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
ProximityDomain31To8[0] is overwritten by the ProximityDomain
at bits [17-24] and [25-31]. Populate ProximityDomain31To8[1]
and ProximityDomain31To8[2] instead.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
- Generate CEDT table from ConfigurationManager objects.
- Only CHBS and CFMWS sub-tables are supported currently.
Signed-off-by: Nick Graves <nicholasgraves@google.com>
- Add objects for CEDT CHBS and CEDT CFMWS. These describe CXL host
bridges and CXL fixed memory windows, respectively.
Signed-off-by: Nick Graves <nicholasgraves@google.com>
Migrate these packages to use the up-to-date BaseFdtLib instead
of the EmbeddedPkg relic that is going away.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Leif Lindholm <leif.lindholm@oss.qualcomm.com>
This commit adds a hostbased test for the
Dbg2Generator library. The test is designed to
be run on a host machine against a UEFI image
that has been built with the DynamicTablesPkg.
The test exercises the Dbg2Generator library by
building an ACPI DBG2 from a list of devices.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
This commit adds support for building non-serial DBG2 devices
1. Add new common namespace objects:
- EArchCommonObjMemoryRangeDescriptor
- EArchCommonObjDbg2DeviceInfo
2. Enhance DBG2 table generator:
- Add support for non-serial DBG2 devices
- Support multiple debug devices
- Improve memory handling with proper allocation checks
- Add better cleanup in error paths
3. Update configuration manager:
- Add parsers for new common namespace objects
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
- This patch is intended to fix the debug macro issue reported from
the Debug Macro Checking.
- Remove the redundant comma between two debug message string.
Signed-off-by: Jason1 Lin <jason1.lin@intel.com>
Relocate StaToken detection and _STA method generation logic
within the loop for each processor object.
Signed-off-by: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
In some failure legs of BuildMadtTable (), we could end up in
FreeMadtTableResources () with (*Table == NULL). That's a valid error
state and should be tolerated by FreeMadtTableResources () instead of
ASSERTing.
Signed-off-by: Jake Garver <jake@nvidia.com>
Reviewed-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Jeshua Smith <jeshuas@nvidia.com>
The CREATE_CM_OBJECT_ID() and CREATE_TABLE_GEN_ID() macros shift an enum
by 31 bits. As enums are signed integers, this generates a portability
finding from cppcheck. To resolve the finding, we'll cast the enum values
to the type expected as output from the macro.
Signed-off-by: Jake Garver <jake@nvidia.com>
Reviewed-by: Girish Mahadevan <gmahadevan@nvidia.com>
