If there are multiple sku used in a platform and
gEfiMdeModulePkgTokenSpaceGuid.PcdNvStoreDefaultValueBuffer PCD
is used, build will fail.
This is a regression issue introduced by the commit:
5695877ec8 which only update the
Vpd offset for default SKU but not other SKUs.
This patch is going to fix this issue.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
In ParseDevPathValue, the binary data need to convert to string
for python3 and python2 compatiblity.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
MaxSizeUserSet is missing in Pcd deepcopy function.
This patch is to add it back to Pcd deepcopy function.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.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>
This patch introduces the dynamic table factory protocol
that provides an interface to register and retrieve
registered 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>
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>
This patch defines a helper macro 'GET_OBJECT_LIST()' that
expands to a function that uses the configuration manager
protocol to retrieve configuration manager object(s).
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <alexei.fedorov@arm.com>
Introduce configuration manager protocol interface
that is used by the dynamic tables framework core
to communicate with configuration manager.
Configuration manager is a platform specific module
that implements the configuration manager protocol.
Table generators use this interface to retrieve the
hardware information from the configuration manager.
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 tables frameworks core communicates with the
platform specific implementation using the configuration
manager protocol interface. The dynamic tables framework
core uses this interface to retrieve information required
for generating the firmware tables. This information is
represented in the form of objects, which are classified
as standard namespace objects, Arm namespace objects or
as Custom/OEM namespace objects.
The configuration manager objects provides a convenient
way for wrapping up the namespaces using a well defined
configuration manager object Id.
The configuration manager is a platform specific component
that collates the platform information required for generating
firmware tables and represents them as configuration manager
objects.
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 tables frameworks core communicates with the
platform specific implementation using the configuration
manager protocol interface. The dynamic tables framework
core uses this interface to retrieve information required
for generating the firmware tables. This information is
represented in the form of objects, which are classified
as standard namespace objects, Arm namespace objects or
as Custom/OEM namespace objects.
This patch introduces the definitions for the Arm namespace
objects.
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 tables frameworks core communicates with the
platform specific implementation using the configuration
manager protocol interface. The dynamic tables framework
core uses this interface to retrieve information required
for generating the firmware tables. This information is
represented in the form of objects, which are classified
as standard namespace objects, Arm namespace objects or
as Custom/OEM namespace objects.
This patch introduces the definitions for standard
namespace objects.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <alexei.fedorov@arm.com>
This patch introduces the interfaces and definitions for
implementing a Device Tree 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>
This patch introduces the required interfaces and definitions
for implementing a SMBIOS 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>
This patch introduces the required interfaces and definitions
for implementing an ACPI 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>
A Table generator is a component that implements the logic
for building a firmware table. This is typically implemented
as a library and registers itself with a table factory.
Table generators are further classified based on type of table
it generates, a namespace that signifies if the implementation
is standard or an OEM specific implementation and a table Id.
This patch introduces the definitions used for describing a
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 dynamic tables framework is designed to generate standardised
firmware tables that describe the hardware information at
run-time. A goal of standardised firmware is to have a common
firmware for a platform capable of booting both Windows and Linux
operating systems.
Traditionally the firmware tables are handcrafted using ACPI
Source Language (ASL), Table Definition Language (TDL) and
C-code. This approach can be error prone and involves time
consuming debugging.
In addition, it may be desirable to configure platform hardware
at runtime such as: configuring the number of cores available
for use by the OS, or turning SoC features ON or OFF.
This patch introduces Dynamic Tables Framework which also provides
mechanisms to reduce the amount of effort required in porting
firmware to new platforms. A more detailed description is in
the Readme.md file.
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 check for 1.[1-9][0-9].* was removed since qemu jumped to 2.0
after 1.7.
Changed 2.*.* to [2-9].*.* to match major releases 3 - 9.
Added [1-9][0-9]*.*.* to match major releses >= 10.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1481
Today's MtrrLib contains a bug, for example:
when the original cache setting is WB for [0xF_0000, 0xF_8000) and,
a new request to set [0xF_0000, 0xF_4000) to WP,
the cache setting for [0xF_4000, 0xF_8000) is reset to UC.
The reason is when MtrrLibSetBelow1MBMemoryAttribute() is called the
WorkingFixedSettings doesn't contain the actual MSR value stored in
hardware, but when writing the fixed MTRRs, the code logic assumes
WorkingFixedSettings contains the actual MSR value.
The new fix is to change MtrrLibSetBelow1MBMemoryAttribute() to
calculate the correct ClearMasks[] and OrMasks[], and use them
directly when writing the fixed MTRRs.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1114
V2: simplify the code logic.
update
if (!mHaveExitedBootServices &&
(StatusCodeData != (EFI_STATUS_CODE_DATA *) StatusCodeBuffer)) {
gBS->FreePool (StatusCodeData);
}
to
if (StatusCodeData != (EFI_STATUS_CODE_DATA *) StatusCodeBuffer) {
gBS->FreePool (StatusCodeData);
}
V3:
And the code below into the else condition (stack buffer is not enough)
in /DxeReportStatusCodeLib/ReportStatusCodeLib.c
if (gBS == NULL || gBS->AllocatePool == NULL || gBS->FreePool == NULL) {
return EFI_UNSUPPORTED;
}
V4:
Refine code logic.
When report status code with ExtendedData data,
and the extended data can fit in the local static buffer,
there is no need to use AllocatePool to hold the ExtendedData data.
This patch is just to do the enhancement to avoid using AllocatePool.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Cc: Michael Turner <Michael.Turner@microsoft.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
If use a structure pcd in fdf, build tool crash
This is a regression issue introduced by py3 patch set.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Generate report fail when -Y EXECUTION_ORDER in build command.
This patch is going to fix this issue.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
This is designed to be used on platforms where a a real RTC is not
available and relies on an RtcEpochSeconds variable having been set or,
if that is not the case, falls back to using the epoch embedded at
compilation time.
Note that, in order to keep things simple for the setting of the
compilation time variable, only GCC environments with UNIX-like shells
and where a 'date' command is available are meant to be supported for
now.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
