This issue happens when using Structured PCD.
Build tool use set to store the cflags for compile PcdValueInit.c,
that is the order of cflags is disorder.
This patch make -U, /U flags appear before -D, /D
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Commit 3c59d94637 ("BaseTools/FCE: Add a tool FCE") added a new tool
that is always built. Pre-existing tools locate the makefile includes
with relative paths, but FCE uses EDK_TOOLS_PATH, adding a new dependency
on having sourced edksetup.sh before building BaseTools.
Change FCE GNUmakefile to match other tools.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
(a) OvmfPkg first had to resolve the TpmMeasurementLib class -- for
SECURE_BOOT_ENABLE only -- when the DxeImageVerificationLib instance
became dependent on TpmMeasurementLib. For details, refer to commit
0d28d286bf ("OvmfPkg: resolve TpmMeasurementLib dependency
introduced in r14687", 2013-09-21).
(b) At the time, only one instance of TpmMeasurementLib existed, namely
DxeTpmMeasurementLib. This lib instance didn't do anything -- like it
was desirable for OVMF --, because OVMF didn't include any Tcg / TrEE
protocol implementations.
(c) In commit 308521b133 ("MdeModulePkg: Move TpmMeasurementLib
LibraryClass from SecurityPkg", 2015-07-01), TpmMeasurementLibNull was
introduced.
(d) In commit 285542ebbb ("OvmfPkg: Link AuthVariableLib for following
merged variable driver deploy", 2015-07-01), a TpmMeasurementLib
resolution became necessary regardless of SECURE_BOOT_ENABLE. And so
TpmMeasurementLib was resolved to TpmMeasurementLibNull in OVMF, but
only in the non-SECURE_BOOT_ENABLE case. This step -- possibly, the
larger series containing commit 285542ebbb -- missed an opportunity
for simplification: given (b), the DxeTpmMeasurementLib instance
should have been simply replaced with the TpmMeasurementLibNull
instance, regardless of SECURE_BOOT_ENABLE.
(e) In commit 1abfa4ce48 ("Add TPM2 support defined in trusted computing
group.", 2015-08-13), the TrEE dependency was replaced with a Tcg2
dependency in DxeTpmMeasurementLib.
(f) Starting with commit 0c0a50d6b3 ("OvmfPkg: include Tcg2Dxe module",
2018-03-09), OVMF would include a Tcg2 protocol implementation,
thereby satisfying DxeTpmMeasurementLib's dependency. With
TPM2_ENABLE, it would actually make sense to consume
DxeTpmMeasurementLib -- however, DxeTpmMeasurementLib would never be
used without SECURE_BOOT_ENABLE.
Therefore, we have the following four scenarios:
- TPM2_ENABLE + SECURE_BOOT_ENABLE: works as expected.
- Neither enabled: works as expected.
- Only TPM2_ENABLE: this build is currently incorrect, because
Variable/RuntimeDxe consumes TpmMeasurementLib directly, but
TpmMeasureAndLogData() will never reach the TPM because we link
TpmMeasurementLibNull into the variable driver. This is a problem from
the larger series containing (f).
- Only SECURE_BOOT_ENABLE: this build works as expected, but it is
wasteful -- given that the protocol database will never contain Tcg2
without TPM2_ENABLE, we should simply use TpmMeasurementLibNull. This is
a problem from (d).
Resolving TpmMeasurementLib to DxeTpmMeasurementLib as a function of
*only* TPM2_ENABLE, we can fix / optimize the last two cases.
v2:
- Amend the title and description suggested by Laszlo
- Move TpmMeasurementLib to the existed TPM2_ENABLE block
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Gary Lin <glin@suse.com>
Message-Id: <20190704040731.5303-1-glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
ArmVirtPkg was created before we introduced the Package Reviewer (R:)
role in Maintainers.txt. However, we have always had an informal
agreement that if Ard or Laszlo is absent, I can review patches by
the still present one for going into ArmVirtPkg.
Plus, as one of the ArmPkg maintainers, it makes sense for me to have
better visibility of goings-on in ArmVirtPkg.
So let's formalise that, and add myself as a Package Reviewer, to be
CC:d on patches (while not taking up full maintainer responsibilities).
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Make the -h command line option a binary flag. Now, colour
highlighting is enabled whenever this flag is set (stateless),
instead of being dependent on previous acpiview command
invocations.
By removing the parameter required with the -h flag the command
line parsing logic becomes simpler.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Remove redundant whitespace characters at the beginning of the strings
describing IORT table field names.
When dumping ACPI table contents, the indentation level for printing
field names is controled using the 'Indent' argument to the 'ParseAcpi'
function. In the IORT acpiview parser, both 'Indent' and extra
whitespace characters are used for indentation, which results in
excess indentation.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
According to the acpiview documentation, the -v flag enables verbose
output and it is set on default.
Moreover, the acpiview UEFI shell tool dumps the same output with
and without this flag set.
Therefore this patch removes the superfluous -v flag from allowed
command line parameters.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The current documentation for the acpiview UEFI shell tool states
that the '-c' flag enables consistency checks on ACPI table data.
However, these checks are enabled anyway by default.
This patch keeps ACPI table validation as a default option, but it
makes it possible to turn ACPI table validation off by setting the
newly-introduced '-q' flag. Consequently, the '-c' flag is removed.
The remaining code changes in this patch make a number of consistency
checks optional (but enabled by default):
1. ACPI table field offset mismatch.
2. ACPI table field validation functions provided in the ACPI_PARSER
arrays.
3. Table checksum computation.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Print an extra newline character at the end DBG2 table parsing in order
to make the output resemble the one for other ACPI table parsers.
With this change, there is now a blank line between the DBG2 table dump
and the 'Table Statistics' section.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Move printing double newline character ('\n\n') from the beginning of
ACPI table checksum validation message to the end of the raw binary
data dump.
This way acpiview table dump looks similar regardless of whether Table
Checksum is validated or not.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Acpiview currently allows displaying help info by specifying both
-? and /? flags. This patch removes /? from valid command line
flags that can be passed to the acpiview tool, as this
flag is not used for such purpose in other UEFI shell commands.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Calling DisconnectController() on children isn't part of the job of
EFI_DRIVER_BINDING_PROTOCOL.Stop() as it only needs to deallocate
resources allocated in Start(). The disconnection will happen when
both DevicePath and XenBus protocols gets uninstalled.
Reported-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Message-Id: <20190701111403.7007-1-anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
In XenBusDxe, the XenBusAddDevice() opens the gXenIoProtocolGuid on
behalf of child controllers. It is never closed and prevents us from
uninstalling the protocol.
Close it where we stop all the children in XenBusDxe->Stop().
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190701105012.25758-1-anthony.perard@citrix.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1678
Use the PcdPlatformRecoverySupport to control the function
of platform recovery in BDS.
First, set the variable's ("OsIndicationsSupported")
EFI_OS_INDICATIONS_START_PLATFORM_RECOVERY bit base on the pcd.
It would affect the variable "OsIndications".
While the platform does not support the platform recovery,
it is inappropriate to set a PlatformRecovery#### variable. So
skip setting the variable. But it should remain the behavior of
booting from a default file path (such as \EFI\BOOT\BOOTX64.EFI)
to be compatible with the previous version UEFI spec.
Add memory check before build platform default boot option. If
fail to allocate memory for the defualt boot file path, put the
system into dead loop to indicate it is unable to boot.
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>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael Turner <Michael.Turner@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
