The SCP holds some power information that could be advertised
through the _CPC object. The communication with the SCP is done
through SCMI protocols (c.f. ArmScmiDxe).
Use the SCMI protocols to query information and feed it to
the DynamicTablesPkg.
Acked-by: Leif Lindholm <quic_llindhol@quicinc.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Add the support for X64 compilation to the CI.
- Fix the signed and unsigned variable comparision.
warning C4018: '>': signed/unsigned mismatch
- Fix the NOOPT build error for IA32 by replacing
64bit shift operator with LShiftU64.
Cc: Pierre Gondois <pierre.gondois@arm.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Add the support for X64 compilation to the CI.
Fix the compilation errors.
Cc: Pierre Gondois <pierre.gondois@arm.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The Section 6.1.3, SMBIOS specification version 3.6.0 describes the
handling of test strings in SMBIOS tables.
Text strings are added at the end of the formatted portion of the SMBIOS
structure and are referenced by index in the SMBIOS structure.
Therefore, introduce a SmbiosStringTableLib to simplify the publishing
of the string set.
SmbiosStringTableLib introduces a concept of string table which records
the references to the SMBIOS strings as they are added and returns an
string reference which is then assigned to the string field in the
formatted portion of the SMBIOS structure. Once all strings are added,
the library provides an interface to get the required size for the string
set. This allows sufficient memory to be allocated for the SMBIOS table.
The library also provides an interface to publish the string set in
accordance with the SMBIOS specification.
Example:
EFI_STATUS
BuildSmbiosType17Table () {
STRING_TABLE StrTable;
UINT8 DevLocatorRef;
UINT8 BankLocatorRef;
SMBIOS_TABLE_TYPE17 *SmbiosRecord;
CHAR8 *StringSet;
...
// Initialize string table for 7 strings
StringTableInitialize (&StrTable, 7);
StringTableAddString (&StrTable, "SIMM 3", &DevLocatorRef);
StringTableAddString (&StrTable, "Bank 0", &BankLocatorRef);
...
SmbiosRecord = AllocateZeroPool (
sizeof (SMBIOS_TABLE_TYPE17) +
StringTableGetStringSetSize (&StrTable)
);
...
SmbiosRecord->DeviceLocator = DevLocatorRef;
SmbiosRecord->BankLocator = BankLocatorRef;
...
// get the string set area
StringSet = (CHAR8*)(SmbiosRecord + 1);
// publish the string set
StringTablePublishStringSet (
&StrTable,
StringSet,
StringTableGetStringSetSize (&StrTable)
);
// free string table
StringTableFree (&StrTable);
return EFI_SUCCESS;
}
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Pierre Gondois <pierre.gondois@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: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
The Platform Communication Channel Table (PCCT) generator collates
the relevant information required for generating a PCCT table from
configuration manager using the configuration manager protocol.
The DynamicTablesManager then install the PCCT table.
From ACPI 6.4, s14 PLATFORM COMMUNICATIONS CHANNEL (PCC):
The platform communication channel (PCC) is a generic mechanism
for OSPM to communicate with an entity in the platform.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Add support library to allow for customization of _OSC and slot info.
The functions in the library are unchanged,
with the exception of adding PciInfo pointer to the APIs.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This generator allows to generate a SSDT table describing
a Pci express Bus. It uses the following CmObj:
- EArmObjCmRef
- EArmObjPciConfigSpaceInfo
- EArmObjPciAddressMapInfo
- EArmObjPciInterruptMapInfo
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3682
To: Sami Mujawar <sami.mujawar@arm.com>
To: Alexei Fedorov <Alexei.Fedorov@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
In the GIC interrupt model, logical processors are required to
have a Processor Device object in the DSDT and must convey each
processor's GIC information to the OS using the GICC structure.
Additionally, _LPI objects may be needed as they provide a method
to describe Low Power Idle states that defines the local power
states for each node in a hierarchical processor topology.
Therefore, add support to generate the CPU topology and the LPI
state information in an SSDT table.
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
The TableHelperLib contains helper functions. Some rely on
DynamicTablesPkg definitions (they use Configuration Manager objects).
Some others are more generic.
To allow using these generic functions without including
DynamicTablesPkg definitions, move them to a new AcpiHelperLib
library.
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
The Generic ACPI for Arm Components 1.0 Platform Design
Document, s2.6.4 "ASL code examples" provides information
to describe an Arm CoreLink CMN-600 Coherent Mesh Network
using an ASL definition block table.
The SSDT CMN-600 Table Generator uses the Configuration
Manager protocol to obtain the following information about
the CMN-600 device on the platform:
- the PERIPHBASE address location and address range;
- the ROOTNODEBASE address location;
- the number of Debug and Trace Controller (DTC)
and their respective interrupt number;
The CMN-600 mesh is described using the CM_ARM_CMN_600_INFO
and CM_ARM_EXTENDED_INTERRUPT structures in the Configuration
Manager.
The SSDT CMN-600 Table generator:
- gets the CMN-600 hardware information
from the configuration manager.
- uses the AmlLib interfaces to parse the AML
template BLOB and construct an AML tree.
- uses the AmlLib to update:
- the "_UID" value;
- the address location and range of the PERIPHBASE;
- the address location of the ROOTNODEBASE;
- the number of Debug and Trace Controller (DTC)
and their respective interrupt number;
- serializes the AML tree to an output buffer.
This output buffer contains the fixed-up AML code,
which is then installed as an ACPI SSDT table.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Co-authored-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Most platforms have several serial ports. These serial ports
are described to an operating system using definition block
tables.
The SSDT Serial Port Table Generator uses the Configuration
Manager protocol to obtain information for the Serial Ports
on the platform. The serial ports are described using the
CM_ARM_SERIAL_PORT_INFO structure. The EArmObjSerialPortInfo
ID is used to represent a standard serial port.
The SSDT Serial port fixup library provides interfaces to
generate a SSDT Serial port table based on the serial port
information. The SSDT Serial Port Table Generator uses the
SSDT serial port fixup library to build serial port
definition blocks and installs the SSDT tables.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
According to Arm Server Base Boot Requirements,
Platform Design Document version 1.2 revision D,
September 2, 2019, section '4.2.1.8 SPCR'; The
SPCR console device must be included in the DSDT.
Additionally, it is often desirable to describe the
serial ports available on a platform so that they
are available for use by a rich OS.
To facilitate the description of serial ports on a
platform a common SSDT Serial Port Fixup library is
introduced. It provides interfaces to build a SSDT
serial port definition block table based on the
serial port information.
The SSDT Serial Port Fixup library is used by the
SPCR, DBG2 and SSDT Serial Port generator to describe
the serial port information in a definition block.
+------------+ +------------+ +------------+
| SPCR Gen | | DBG2 Gen | | SERIAL Gen |
+------------+ +------------+ +------------+
+----------------------------------+
| SSDT Serial Port Fixup library |
+----------------------------------+
The SSDT Serial Port Fixup library:
- Parses the SSDT Serial Port template using the
AmlLib library to generate an AML tree.
- Updates the _UID, _HID and _CID values.
- Fixes up the Serial port base address, length
and the interrupt number in the _CRS descriptor.
- Fixes up the serial-port name.
- Serialises the AML Tree to a buffer containing
the definition block data.
The definition block data is then installed by the
corresponding table generator.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
ACPI Definition blocks are implemented using AML which has
a complex grammar making run-time generation of definition
blocks difficult. Dynamic AML is a feature of Dynamic Tables
framework that provides a solution for dynamic generation of
ACPI Definition block tables.
Since, AML bytecode represents complex AML grammar, an AmlLib
library is introduced to assist parsing and traversing of the
AML bytecode at run-time.
The AmlLib library parses a definition block and represents it
as an AML tree. The AML objects, methods and data are represented
as tree nodes. Since the AML data is represented as tree nodes,
it is possible to traverse the tree, locate a node and modify the
node data. The tree can then be serialized to a buffer (that
represents the definition block). This definition block containing
the fixed-up AML code can then be installed as an ACPI Definition
Block table.
Dynamic AML introduces the following techniques:
* AML Fixup
* AML Codegen
* AML Fixup + Codegen
AML Fixup is a technique that involves compiling an ASL template
file to generate AML bytecode. This template AML bytecode can be
parsed at run-time and a fixup code can update the required fields
in the AML template.
AML Codegen employs generating small segments of AML code.
AmlLib provides a rich set of APIs to operate on AML data for AML
Fixup and Codegen.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
If MDEPKG_NDEBUG is defined, then debug and assert related
macros wrapped by it are mapped to NULL implementations.
Therefore, add MDEPKG_NDEBUG flags for release builds of
DynamicTablesPkg.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The EdkII BaseTools have been updated to facilitate the
generation of C file containing AML data using the AmlToC
script. The build system follows the following sequence
for an ASL file compilation:
- The ASL file is preprocessed using the C preprocessor
- The Trim utility prunes the preprocessed file to removed
unwanted data.
- This file is compiled using an ASL compiler to generate
an AML file.
- The AmlToC python script reads the AML data and generates
a C file with an array containing the AML data.
- This C file containing a unique symbol name for the AML
data array is then compiled with the firmware module.
This removes the dependency on the ACPICA iASL compiler's
"-tc" option which achieved the same effect but was less
portable. Therefore, remove the "-tc" option from the ASL
flags as this option is only been supported by the ACPICA
iASL compiler.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The TianoCore EDKII project has introduced a Core CI infrastructure
using TianoCore EDKII Tools PIP modules:
* https://pypi.org/project/edk2-pytool-library/
* https://pypi.org/project/edk2-pytool-extensions/
More information on configuring the environment and running the
builds can be found in edk2\.pytool\Readme.md
This patch fixes the issues reported by the CI system mainly around
fixing typo errors and package dec and dsc files. A subsequent patch
enables the CI builds for the DynamicTablesPkg.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The SRAT generator uses the configuration manager protocol
to obtain the affinity information for the GICC, GIC ITS,
Memory, Generic Initiator, etc. and generates the SRAT table.
The table generator supports ACPI 6.3, SRAT table revision 3.
The ACPI and PCI device handles of the Generic Initiator
Affinity structures are represented using tokens. The
generator invokes the configuration manager protocol
interfaces and requests for objects referenced by tokens
to get the device handle information.
The Configuration Manager object definition for the GICC has
been updated to include the Proximity Domain, Clock Domain
and associated flag information. Similarly the Configuration
Manager object for the GIC ITS has been updated to include
the Proximity Domain information. These changes should not
impact any existing implementations as the new fields have
been added towards the end of the Configuration Manager
Objects.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The PPTT generator uses the configuration manager protocol to
obtain information about platform's processor topology and caches.
This data is then used to generate the PPTT table.
The table generator supports ACPI 6.3, PPTT table revision 2.
The dynamic PPTT generator also carries out extensive input
validation which includes cycle detection and MADT-PPTT
cross-validation. A number of architectural compliance checks
are also performed.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The IORT generator uses the configuration manager protocol
to obtain information about the PCI Root Complex, SMMU,
GIC ITS, Performance Monitoring counters etc. and generates
the IORT table.
The mappings between the components are represented using
tokens. The generator invokes the configuration manager
protocol interfaces and requests for objects referenced by
tokens to establish the link.
This table data is then used by the Table Manager to install
the IORT table.
The Table Manager then invokes the generator interface to free
any resources allocated by the IORT table generator.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <alexei.fedorov@arm.com>
The MCFG generator uses the configuration manager protocol
to obtain the PCI Configuration space information from the
platform configuration manager and builds the MCFG table.
This table data is then used by the Table Manager to install
the MCFG table.
The Table Manager then invokes the generator interface to free
any resources allocated by the MCFG table generator.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <alexei.fedorov@arm.com>
The DBG2 generator uses the configuration manager protocol
to obtain the debug serial port information from the platform
configuration manager. It then updates a template DBG2 table
structure. This table data is used by the Table Manager to
install the DBG2 table.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <alexei.fedorov@arm.com>
The SPCR generator uses the configuration manager protocol to
obtain the serial port information from the platform configuration
manager. It then updates a template SPCR table structure. This
table data is used by the Table Manager to install the SPCR table.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <alexei.fedorov@arm.com>
The GTDT generator uses the configuration manager protocol to
obtain information about the architectural and platform timers
available on the platform and generates the ACPI GTDT table.
This table data is then used by the Table Manager to install
the GTDT table.
The Table Manager then invokes the generator interface to free
any resources allocated by the GTDT table generator.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <alexei.fedorov@arm.com>
The MADT generator uses the configuration manager protocol to
obtain information about the Arm interrupt controllers (GICC,
GICD, etc.) and generates the ACPI MADT table. This table data
is then used by the Table Manager to install the MADT table.
The Table Manager then invokes the generator interface to free
any resources allocated by the MADT table generator.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <alexei.fedorov@arm.com>
The FADT generator collates the relevant information required
for generating a FADT table from configuration manager using
the configuration manager protocol. It then updates a template
FADT table structure. This table data is used by the Table
Manager to install the FADT table.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <alexei.fedorov@arm.com>
A Raw generator is a simple generator. This generator provides
the ability to install a binary blob (that contains ACPI table
data) as an ACPI table. The binary blob could be pre-generated
ACPI table data or it may be the pre-compiled output from an
iAsl compiler for a DSDT or SSDT table.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <alexei.fedorov@arm.com>
The dynamic table manager implements the top level component
that drives the table generation and installation process.
It uses the configuration manager protocol to get the list
of tables to be installed from the configuration manager.
It iterates through the list of tables, requests the table
factories for corresponding generators and invokes the
generator interface to build the tables.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <alexei.fedorov@arm.com>
The dynamic table factory dxe implements the dynamic table
factory protocol. It also implements the ACPI, SMBIOS and
DT table factories. The table generators register themselves
with the respective table factories and the factories are
responsible for instantiating instances of the generators
to build the firmware tables.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <alexei.fedorov@arm.com>
A helper library that implements common functionality
for use by table generators.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <alexei.fedorov@arm.com>
Pierre Gondois
Abdul Lateef Attar
Sami Mujawar
Jeff Brasen
Krzysztof Koch
Michael D Kinney