Feng, Bob C [Thu, 14 Feb 2019 08:48:03 +0000 (16:48 +0800)]
BaseTools: Fixed a code bug for Pcd Array.
For example, PCD gUefiOvmfPkgTokenSpaceGuid.Test001 datatype is Array:
TEST1[2]
and the filed TEST1UINT64ARRAY in TEST1 is also an array:
UINT64 TEST1UINT64ARRAY[2];
Then the following filed assignment in DSC will cause build failure.
gUefiOvmfPkgTokenSpaceGuid.Test001[0].TEST1UINT64ARRAY|{'A','B'}
The root cause is build tool generate incorrect PcdValueInit.c File.
Feng, Bob C [Mon, 18 Feb 2019 09:20:25 +0000 (17:20 +0800)]
BaseTools: Fixed a bug in Vpd handling
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: 5695877ec8f636bd4ad873ef50eceb9da7a0f382 which only update the
Vpd offset for default SKU but not other SKUs.
Sami Mujawar [Sat, 15 Dec 2018 12:31:47 +0000 (12:31 +0000)]
DynamicTablesPkg: Arm IORT Table Generator
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.
Sami Mujawar [Sat, 15 Dec 2018 12:29:49 +0000 (12:29 +0000)]
DynamicTablesPkg: Arm PCI MCFG Table Generator
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.
Sami Mujawar [Sat, 15 Dec 2018 12:28:23 +0000 (12:28 +0000)]
DynamicTablesPkg: Arm DBG2 Table Generator
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.
Sami Mujawar [Sat, 15 Dec 2018 12:27:03 +0000 (12:27 +0000)]
DynamicTablesPkg: Arm SPCR Table Generator
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.
Sami Mujawar [Sat, 15 Dec 2018 12:25:52 +0000 (12:25 +0000)]
DynamicTablesPkg: Arm ACPI GTDT Generator
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.
Sami Mujawar [Sat, 15 Dec 2018 12:23:59 +0000 (12:23 +0000)]
DynamicTablesPkg: Arm ACPI MADT Generator
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.
Sami Mujawar [Sat, 15 Dec 2018 12:22:45 +0000 (12:22 +0000)]
DynamicTablesPkg: Arm ACPI FADT Generator
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.
Sami Mujawar [Sat, 15 Dec 2018 12:20:23 +0000 (12:20 +0000)]
DynamicTablesPkg: Arm Raw/DSDT/SSDT Generator
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.
Sami Mujawar [Sat, 15 Dec 2018 12:18:52 +0000 (12:18 +0000)]
DynamicTablesPkg: Dynamic Table Manager Dxe
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.
Sami Mujawar [Sat, 15 Dec 2018 12:17:06 +0000 (12:17 +0000)]
DynamicTablesPkg: Dynamic Table Factory Dxe
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.
Sami Mujawar [Sat, 15 Dec 2018 12:01:12 +0000 (12:01 +0000)]
DynamicTablesPkg: Configuration Manager Helper
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).
Sami Mujawar [Sat, 15 Dec 2018 11:59:07 +0000 (11:59 +0000)]
DynamicTablesPkg: Configuration Manager Objects
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.
Sami Mujawar [Sat, 15 Dec 2018 11:58:07 +0000 (11:58 +0000)]
DynamicTablesPkg: Arm NameSpace Objects
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.
Sami Mujawar [Sat, 15 Dec 2018 11:57:13 +0000 (11:57 +0000)]
DynamicTablesPkg: Standard NameSpace Objects
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.
Sami Mujawar [Sat, 15 Dec 2018 11:52:30 +0000 (11:52 +0000)]
DynamicTablesPkg: Table Generator definition
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.
Sami Mujawar [Mon, 3 Dec 2018 11:13:31 +0000 (11:13 +0000)]
DynamicTablesPkg: Dynamic Tables Framework
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.
Star Zeng [Sat, 12 Jan 2019 15:23:30 +0000 (23:23 +0800)]
MdeModulePkg: Remove EmuVariableRuntimeDxe
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323
Merge EmuVariable and Real variable driver.
The real variable driver has been updated to support emulated
variable NV mode.
This patch removes EmuVariableRuntimeDxe after platforms are
migrated to use the merged variable driver.
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>
Shenglei Zhang [Mon, 18 Feb 2019 08:20:37 +0000 (16:20 +0800)]
MdeModulePkg/PropertiesTableAttributesDxe: Remove this driver
This functionality of this driver has been deprecated and
no platform employs this driver. It can be removed completely.
https://bugzilla.tianocore.org/show_bug.cgi?id=1475
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Shenglei Zhang [Thu, 14 Feb 2019 02:43:10 +0000 (10:43 +0800)]
MdePkg/BaseLib: Change a variable type in a bitwise operation
Change the type of variable Chr from CHAR8 to UINT32 in a
bitwise operation, to make the two variables in the operation
have the same size.
https://bugzilla.tianocore.org/show_bug.cgi?id=1527
According to PI1.7 Spec, report extended data describing an
EFI_STATUS return value along with
EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR and
EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED status code
when fail to load or start boot option image.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Sean Brogan <sean.brogan@microsoft.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
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>
Feng, Bob C [Fri, 1 Feb 2019 08:51:43 +0000 (16:51 +0800)]
BaseTools: Fix the build report issue about Structure PCD
https://bugzilla.tianocore.org/show_bug.cgi?id=1472
build report use incorrect method to parse DynamicDefault/DynamicExDefault
and DynamicVpd/DynamicExVpd structure Pcd value.
Pete Batard [Mon, 4 Feb 2019 12:47:36 +0000 (12:47 +0000)]
EmbeddedPkg/Library: Add VirtualRealTimeClockLib
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.
EFI_PEI_CORE_FV_LOCATION_PPI may be passed by platform
when PeiCore not in BFV so SecCore has to search PeiCore
either from the FV location provided by
EFI_PEI_CORE_FV_LOCATION_PPI or from BFV.
Test: Verified on internal platform and booting successfully.
Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
Shenglei Zhang [Tue, 29 Jan 2019 08:16:36 +0000 (16:16 +0800)]
OvmfPkg/README: Remove UNIXGCC
Remove UNIXGCC in OvmfPkgIa32.dsc, OvmfPkgIa32X64.dsc
and OvmfPkgX64.dsc.
Remove content related to UNIXGCC in README.
https://bugzilla.tianocore.org/show_bug.cgi?id=1377
Shenglei Zhang [Thu, 31 Jan 2019 08:24:08 +0000 (16:24 +0800)]
BaseTools/tools_def.template: Remove VS2003 and VS2005
VS2003 and VS2005 are too old.There is no verification
for them.
https://bugzilla.tianocore.org/show_bug.cgi?id=1377
v3:1.Instead of removing MS_VS_BIN, change MS_VS_BIN from
VS2005_BIN to VS2008_BIN.
2.Instead of removing MS_VS_DLL, change MS_VS_DLL from
VS2005_DLL to VS2008_DLL.
Shenglei Zhang [Fri, 25 Jan 2019 07:52:46 +0000 (15:52 +0800)]
MdePkg: Change function parameter type
Change type of parameter Opcode from UINT16 to UINTN
in EFI_S3_SAVE_STATE_WRITE and EFI_S3_SAVE_STATE_INSERT.
According to PI 1.6(Errata A), the type of Opcode in
EFI_S3_SAVE_STATE_WRITE and EFI_S3_SAVE_STATE_INSERT should
be UINTN not UINT16.
https://bugzilla.tianocore.org/show_bug.cgi?id=1517
When a device under PPB contains option ROM but doesn't require 32bit
MMIO, ProgrameUpstreamBridgeForRom() cannot correctly restore the
PPB MEM32 RANGE BAR. It causes the 32bit MMIO conflict which may
cause system hangs in boot.
The root cause is when ProgrameUpstreamBridgeForRom() calls
ProgramPpbApperture() to restore the PPB MEM32 RANGE BAR, the
ProgramPpbApperture() skips to program the BAR when the resource
length is 0.
This patch fixes this issue by not calling ProgramPpbApperture().
Instead, it directly programs the PPB MEM32 RANGE BAR.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com> Cc: Dandan Bi <dandan.bi@intel.com>
Eric Dong [Thu, 14 Feb 2019 05:37:27 +0000 (13:37 +0800)]
SecurityPkg/OpalPassword: Update strings on Opal Setup page
https://bugzilla.tianocore.org/show_bug.cgi?id=1506
Updated some descriptions on SETUP page to avoid user confusion.
Currently it shows "1.0 UEFI Opal Driver", however it may be mislead user to think
it is only for Opal drive but not for Pyrite drive.
Chen A Chen [Mon, 11 Feb 2019 05:42:19 +0000 (13:42 +0800)]
MdeModulePkg/CapsuleApp: Fix memory leak issue.
This issue is caused by FileInfoBuffer variable. This is a pointer array
and each elements also pointer to a memory buffer that is allocated and
returned by AllocateCopyPool function.
Laszlo Ersek [Wed, 6 Feb 2019 09:08:53 +0000 (10:08 +0100)]
ArmVirtPkg/ArmVirtXen: don't set Pcd*ImageVerificationPolicy
According to the
PCDs not used by modules or in conditional directives
sections of all the build reports for
{AARCH64,ARM} x {Xen} x {DEBUG,NOOPT,RELEASE} x {feat-1}
(6 builds in total), PcdOptionRomImageVerificationPolicy,
PcdFixedMediaImageVerificationPolicy, and
PcdRemovableMediaImageVerificationPolicy are not used in any of those
builds.
Restrict the settings to the ArmVirtQemu and ArmVirtQemuKernel platforms
(preserving the -D SECURE_BOOT_ENABLE restriction in the process).
("feat-1" stands for "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D
SECURE_BOOT_ENABLE -D TTY_TERMINAL", while "feat-0" stands for "".)
Laszlo Ersek [Wed, 6 Feb 2019 09:08:53 +0000 (10:08 +0100)]
ArmVirtPkg: don't set PcdDebugClearMemoryValue
According to the
PCDs not used by modules or in conditional directives
sections of all the build reports for
{AARCH64,ARM} x {Qemu,QemuKernel,Xen} x {RELEASE} x {feat-0,feat-1}
(12 builds in total), the PCD is not used in any of those builds.
Rather than just restrict the PCD setting to ($(TARGET) != RELEASE),
remove the setting completely. The current value is identical to the 0xAF
default in "MdePkg/MdePkg.dec", which recognizes Andrew Fish, and so it's
unlikely to ever change.
("feat-1" stands for "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D
SECURE_BOOT_ENABLE -D TTY_TERMINAL", while "feat-0" stands for "".)
Laszlo Ersek [Tue, 5 Feb 2019 23:58:56 +0000 (00:58 +0100)]
ArmVirtPkg: clean up PcdSetNxForStack setting (applies to ArmVirtQemu only)
According to the
PCDs not used by modules or in conditional directives
sections of all the build reports for
{AARCH64,ARM} x
{QemuKernel,Xen} x
{DEBUG,NOOPT,RELEASE} x
{feat-0,feat-1}
(24 builds in total), the PCD is not used in any of those builds.
Move the setting from "ArmVirt.dsc.inc" to "ArmVirtQemu.dsc", to reflect
reality.
We originally moved the PCD setting in the opposite direction in commit 8aab575c26e9 ("ArmVirtPkg: enable non-executable DXE stack for all
platforms", 2017-03-07), generalizing it. However, as the comment itself
states, and according to all 36 ArmVirt build reports:
{AARCH64,ARM} x
{Qemu,QemuKernel,Xen} x
{DEBUG,NOOPT,RELEASE} x
{feat-0,feat-1}
the PCD is only consumed by "MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf", and
that module is only included in the ArmVirtQemu platform.
("feat-1" stands for "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D
SECURE_BOOT_ENABLE -D TTY_TERMINAL", while "feat-0" stands for "".)
According to the information of the above BZ-1408 and other platform
owners, NVM Express devices are becoming more likely to be a critical
part during the boot process.
This commit will add the calls to 'REPORT_STATUS_CODE' when there is a
failure happens during the NVM Express controller/device initialization
process.
Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bret Barkelew <brbarkel@microsoft.com> Cc: Jian J Wang <jian.j.wang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
Ard Biesheuvel [Wed, 6 Feb 2019 00:08:22 +0000 (00:08 +0000)]
MdePkg/BaseLib: implement SpeculationBarrier() for ARM and AArch64
Replace the dummy C implementation of SpeculationBarrier() with
implementations consisting of the recommended DSB SY + ISB sequence,
as recommended by ARM in the whitepaper "Cache Speculation Side-channels"
version 2.4, dated October 2018.
To avoid potential NULL pointer dereference issue. Initialize them at
the beginning of the function. This patch is a supplement which was missed
at e98212cb5d59fff8f385d9179ad7f1a3ce9cf215 commit.
Stefan Berger [Fri, 25 Jan 2019 21:30:29 +0000 (16:30 -0500)]
OvmfPkg: Add TCG2 Configuration menu to the Device Manager menu
This patch adds the TCG2 Configuration menu to the Device Manager
menu. We can apparently reuse the sample Tcg2ConfigDxe from
SecurityPkg/Tcg/Tcg2Config without obvious adverse effects. The
added TCG2 Configuration menu now shows details about the attached
TPM 2.0 and lets one for example configure the active PCR banks
or issue commands, among other things.
The code is added to Ovmf by building with -DTPM2_ENABLE and
-DTPM2_CONFIG_ENABLE.
Liming Gao [Mon, 14 Jan 2019 02:31:27 +0000 (10:31 +0800)]
MdeModulePkg DxeCapsuleLibFmp: Update SupportCapsuleImage() for Fake Capsule
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1088
Per UEFI spec, the fake capsule image with the header only is a valid case
in QueryCapsuleCpapbilities(). So, SupportCapsuleImage() is updated to
support this case.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
BaseTools: Fix build failure when specifying multiple BUILDTARGET
With Python3, the dict.value() method returns an iterator.
If a dictionary is updated while an iterator on its keys is used,
a RuntimeError is generated.
Converting the iterator to a list() forces a copy of the mutable
keys in an immutable list which can be safely iterated.
Commit f8d11e5a4aaa converted various uses but missed one:
When specifying multiple BUILDTARGET, the first target builds
successfully, but then the PGen.BuildDatabase._CACHE_ dictionary is
updated, and accessing the next target triggers a RuntimeError.
Convert this iterator to an immutable list, to solve this build error:
(Please send email to edk2-devel@lists.01.org for help, attaching following call stack trace!)
(Python 3.5.3 on linux) Traceback (most recent call last):
File "BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line 2387, in Main
MyBuild.Launch()
File "BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line 2141, in Launch
self._MultiThreadBuildPlatform()
File "BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line 1921, in _MultiThreadBuildPlatform
self.Progress
File "BaseTools/Source/Python/AutoGen/AutoGen.py", line 304, in __init__
self._InitWorker(Workspace, MetaFile, Target, Toolchain, Arch, *args, **kwargs)
File "BaseTools/Source/Python/AutoGen/AutoGen.py", line 477, in _InitWorker
for BuildData in PGen.BuildDatabase._CACHE_.values():
RuntimeError: dictionary changed size during iteration
Note: The culprit commit (f8d11e5a4aaa) can not be found with bisection.
In 9c2d68c0a299 the build tools default to the python version provided
by the ${PYTHON} environment variable, however the Python3 transition is
not functional before d943b0c339fe. f8d11e5a4aaa falls between the
previous two.
Laszlo Ersek [Tue, 5 Feb 2019 11:22:13 +0000 (03:22 -0800)]
BaseTools/BuildReport: fix report for platforms/arches without struct PCDs
The goal of commit 97c8f5b9e7d3 ("BaseTools:StructurePCD value display
incorrect in "Not used" section.", 2019-02-02) was to display the full
contents of such structure PCDs in the build report that were set in the
platform DSC or the FDF, but not used in any module INFs. The listings
would appear in the
PCDs not used by modules or in conditional directives
section of the build report.
Commit 97c8f5b9e7d3 assumed that any (platform, architecture) combination
would have a (possibly empty) set of structure PCD (and so the set of the
structure PCDs could be filtered for set-but-unused ones).
This is not the case: in "DscBuildData.py", in method
UpdateStructuredPcds(), if "S_pcd_set" remains an empty OrderedDict(),
then it is not added to "GlobalData.gStructurePcd" *at all*, for the
current (platform, architecture) combination.
As a result, when the PCD report tries to fetch the set of structure PCDs
for the current (platform, architecture), "GlobalData.gStructurePcd" does
not return an empty OrderedDict(); instead, it raises a KeyError. Fix it
by defaulting to an empty OrderedDict(), with the get() method.
Leif Lindholm [Thu, 1 Nov 2018 15:01:48 +0000 (15:01 +0000)]
IntelFrameworkPkg: fix build for AARCH64/ARM
Contrary to what the name suggests, some modules in this package are used
on other architecture. ARM is already listed in SUPPORTED_ARCHITECTURES
in the .dsc, but AARCH64 was never added - so do that.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Leif Lindholm [Thu, 1 Nov 2018 14:58:22 +0000 (14:58 +0000)]
IntelFrameworkModulePkg: fix build for AARCH64/ARM
Contrary to what the name suggests, some modules in this package are used
on other architecture. ARM is already listed in SUPPORTED_ARCHITECTURES
in the .dsc, but AARCH64 was never added.
Add that, and force inclusion of CompilerIntrinsicsLib and
BaseStackCheckLib for AARCH64/ARM to make the build successful.
Leif Lindholm [Thu, 1 Nov 2018 14:51:50 +0000 (14:51 +0000)]
AppPkg: fix webserver build for !Ia32/X64
The WebServer application is not meant to be Ia32/X64 specific, and would
build for other architectures, if it wasn't for the
#include <Register/Msr.h>
in WebServer.h. Move that statement to Mtrr.c instead, which is the only
consumer, and is already being filtered out for other architectures.
Fix issues that reported by Edk2 coding style check tool(ECC) that:
in Comment, <@param SystemTable> does NOT consistent with parameter
name MmSystemTable.