| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Add the missing parser for EArchCommonObjTpm2DeviceInfo.
This missing parser causing assert for EArchCommonObjMcfgPciConfigSpaceInfo
and EArchCommonObjPciRootPortInfo parser.
Signed-off-by: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
|
|
This change introduces support for root port devices and their
corresponding _PRT (PCI Routing Table) entries in the PCIe SSDT.
Updates the PCIe SSDT generator to detect and use the root port token.
When available, the generator reads the configuration and creates device
entries with appropriate _PRT tables.
Signed-off-by: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
|
|
Adds RootPortInfoToken to PCIe config space object to
support addition of root port devices in PCIE SSDT.
Updates the ConfigurationManagerObjectParser to include the new token.
Signed-off-by: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
|
|
Introduce new architecture common namespace object
for PCIe root ports in the DynamicTables package.
This object holds information:
- PCIe root port address in device and function format
- Reference token information to the PCIe routing table object
- Slot number information for the root port
Also updates ConfigurationManagerObjectParser to parse
the new object and populate the relevant fields.
Signed-off-by: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
|
|
- Adds AcpiMcfgLib library to X64 DynamicTableFactoryDxe
- Adds AcpiSpcrLib library to X64 DynamicTableFactoryDxe
- Adds AcpiSsdtPcieLib library to X64 DynamicTableFactoryDxe
- Rearrage the libraries in alphabetical order
Signed-off-by: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
|
|
X64 platforms supports WordIo and uncached PCIe resources.
Hence, include WordIo and uncached PCIe resources in _CRS.
Signed-off-by: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
|
|
Using abstract tokens ensures no collisions with non-generated tokens.
Signed-off-by: Sarah Walker <Sarah.Walker2@arm.com>
|
|
Add a parser for IORT. Currently generates PCI Root Complex and SMMUv3
nodes.
Signed-off-by: Sarah Walker <Sarah.Walker2@arm.com>
|
|
Add generation of GIC ITS identifier array and group CmObjs.
Signed-off-by: Sarah Walker <Sarah.Walker2@arm.com>
|
|
Implement a helper to add an array as a CmObj.
Signed-off-by: Sarah Walker <Sarah.Walker2@arm.com>
|
|
Implement function to add a CmObj with a token provided by the caller. This
is intended to be used with abstract tokens, the value of which is generated
by the caller.
Signed-off-by: Sarah Walker <Sarah.Walker2@arm.com>
|
|
The current Arm GICC parser only supports one PMU IRQ shared between all
cores. Newer systems use a unique PMU IRQ per core.
Signed-off-by: Sarah Walker <Sarah.Walker2@arm.com>
|
|
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>
|
|
Signed-off-by: Sarah Walker <Sarah.Walker2@arm.com>
|
|
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>
|
|
Update the SMBIOS table dispatcher dependency table to add the
table dependencies for SMBIOS table Type 19, Type 20, Type 27,
Type 35 and Type 37.
The SMBIOS table Type 35 can have dependency on 6 other SMBIOS
tables. Therefore, increase the MAX_SMBIOS_DEPENDENCY to 6, and
also update the SMBIOS table dispatcher table accordingly.
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>
|
|
SMBIOS Structure Types 0 through 127 (7Fh) are reserved
for and defined by the SMBIOS specification. Types 128
through 256 (80h to FFh) are available for system and
OEM-specific information.
Therefore, define a new type 'SMBIOS_TABLE_TYPE' that
represents a SMBIOS structure type and include it in
the definition of CM_STD_OBJ_SMBIOS_TABLE_INFO.
Acked-by: Abner Chang <abner.chang@amd.com>
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>
|
|
To generate SSDT for TPM2 device using DynamicTablePkg,
add TPM2 Device information
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>
|
|
Add the following objects:
- EArchCommonObjProxDomainInfo
- EArchCommonObjProxDomainRelationInfo
- EArchCommonObjSystemLocalityInfo
- EArchCommonObjMemoryProxDomainAttrInfo
- EArchCommonObjMemoryLatBwInfo
- EArchCommonObjMemoryCacheInfo
allowing to generate HMAT/SLIT tables.
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>
|
|
TPM2 ACPI table revision 5 add CRB interface with FF-A method.
This patch supports generation of TPM2 ACPI table revision 5 with
this method.
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
|
|
- Add unit tests for CEDT generator.
Signed-off-by: Nick Graves <nicholasgraves@google.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>
|
