Sughosh Ganu [Mon, 3 Dec 2018 07:19:01 +0000 (12:49 +0530)]
StandaloneMM: Include the newly added library class for MMU functions
The MMU functions needed for StandaloneMM image are now exported
through a separate library class. Make the corresponding change in the
core's entry point inf file so that it references the correct library
class for modifying the MMU attributes.
Achin Gupta [Mon, 3 Dec 2018 07:20:54 +0000 (12:50 +0530)]
StandaloneMmPkg: Zero data structure explicitly
Introduction of the -mstrict-align flag results in GCC attempting
to use memset to zero out the InitMmFoundationSvcArgs structure.
In the absence of this C library function, this patch explicitly
zeroes this data structure prior to use.
Achin Gupta [Mon, 3 Dec 2018 07:20:53 +0000 (12:50 +0530)]
StandaloneMmPkg: Enforce alignment check for AArch64
On AArch64, Standalone MM during the SEC phase runs in S-EL0 with
SCTLR_EL1.A=1. This patch adds the -mstrict-align compiler flag to
ensure that the generated code is compliant with the runtime
alignment checks.
On AArch64, we can only use 48 address bits while running in UEFI,
while the GCD and UEFI memory maps may describe up to 52 bits of
physical address space. For this reason, MAX_ADDRESS was reduced
to 48 bits, to ensure that the firmware does not inadvertently
attempt to allocate memory that we cannot access.
However, MAX_ADDRESS is used in runtime drivers as well, and
runtime drivers may deal with kernel virtual addresses, which have
bits [63:48] set. In fact, the OS may be running with 64 KB pages
and pass addresses into the runtime services that use up to 52
bits of address space, either with the top bits set or cleared,
even if the physical address space does not extend beyond 48 bits.
In summary, changing MAX_ADDRESS is a mistake, and needs to be
reverted.
This patch is one of build tool performance improvement
series patches.
This patch is going to use join function instead of
string += string2 statement.
Current code use string += string2 in a loop to combine
a string. while creating a string list in a loop and using
"".join(stringlist) after the loop will be much faster.
[V2]
Optimize this patch so that it can be easy to review.
This patch is just apply the change to original files while
not create new similar files.
[V1]
This patch is one of build tool performance improvement
series patches.
This patch is going to use python list to store the parser data
instead of using sqlite database.
The replacement solution is as below:
SQL insert: list.append()
SQL select: list comprehension. for example:
Select * from table where field = “something”
->
[ item for item in table if item[3] == “something”]
SQL update: python map function. for example:
Update table set field1=newvalue where filed2 = “something”.
-> map(lambda x: x[1] = newvalue,
[item for item in table if item[2] == “something”])
SQL delete: list comprehension.
With this change, We can save the time of interpreting SQL statement
and the time of write database to file system
Currently, AutoGen and GenFds run in different python interpreters. The
parser are duplicated. This patch is going to create new API for GenFds
and have the build to call that API instead of executing GenFds.py. As
such, the GenFds and build can share the parser data.
This patch is expected to save the time of GenFds about 2~3 seconds.
More details will be logged in BZ.
This is the summary measure data generated from python cProfile for
building Ovmf.
Currently: 8379147 function calls (8135450 primitive calls) in 12.580 seconds
After applying this patch: 3428712 function calls (3418881 primitive calls) in 8.944 seconds
Feng, Bob C [Thu, 1 Nov 2018 14:57:08 +0000 (22:57 +0800)]
BaseTool: Filter out unused structure pcds
V2:
Fixed the issue that V1 adds new check
to the Pcds in the platform unused library INF files.
It breaks the existing platform.
V1?
The current code handle all the structure pcds
even if there is no module or library use them.
This patch is going to filter out the unused structure pcds.
Ard Biesheuvel [Wed, 5 Dec 2018 08:15:48 +0000 (09:15 +0100)]
BaseTools/CommonLib: drop the use of MAX_ADDRESS
The macro MAX_ADDRESS represents the largest virtual address that
is valid for a certain architecture. For the BaseTools, this quantity
is irrelevant, since the same tools can be used to build for different
targets.
Since we only refer to it in a single place, which is an ASSERT() that
doesn't seem particularly useful (it ensures that memcpy() will not
be called with arguments that will make it read beyond the end of the
address space and wrap around), let's drop the ASSERT and all references
to MAX_ADDRESS.
Shenglei Zhang [Fri, 30 Nov 2018 02:30:05 +0000 (10:30 +0800)]
BaseTools: Remove tools only used by DuetPkg
Given that DuetPkg will be removed, tools only used by
DuetPkg can also be removed after its removal operation.
https://bugzilla.tianocore.org/show_bug.cgi?id=1322
v2:Remove these tools in Makefile and GNUmakefile.
v4:Remove these tools in BinWrappers/PosixLike/ and
UserManuals.
Shenglei Zhang [Fri, 30 Nov 2018 02:30:38 +0000 (10:30 +0800)]
DuetPkg: Remove DuetPkg
DuetPkg depends on Legacy BIOS to provide a UEFI environment.
It was invented in the era when UEFI environment is hard to find.
Since now UEFI is very popular in PC area, we could stop the
official support of this package and remove it from the master.
https://bugzilla.tianocore.org/show_bug.cgi?id=1322
Ard Biesheuvel [Thu, 29 Nov 2018 12:22:46 +0000 (13:22 +0100)]
BaseTools/CommonLib: drop definition of MAX_UINTN
The maximum value that can be represented by the native word size
of the *target* should be irrelevant when compiling tools that
run on the build *host*. So drop the definition of MAX_UINTN, now
that we no longer use it.
Ard Biesheuvel [Thu, 29 Nov 2018 12:05:38 +0000 (13:05 +0100)]
BaseTools/CommonLib: get rid of 'native' type string parsing routines
Parsing a string into an integer variable of the native word size
is not defined for the BaseTools, since the same tools may be used
to build firmware for different targets with different native word
sizes.
Ard Biesheuvel [Wed, 5 Dec 2018 07:56:58 +0000 (08:56 +0100)]
BaseTools/CommonLib: add definition of MAX_UINT32
Since we will be dropping the definition of MAX_UINTN, whose meaning
is ambiguous for the BaseTools, add a definition of MAX_UINT32 that
we can switch to.
Ard Biesheuvel [Thu, 29 Nov 2018 12:13:32 +0000 (13:13 +0100)]
BaseTools/CommonLib: use explicit 64-bit type in Strtoi()
Don't use the native word size string to number parsing routines,
but instead, use the 64-bit one and cast to UINTN.
Currently, the only user is in Source/C/DevicePath/DevicePathFromText.c
which takes care to use Strtoi64 () unless it assumes the value fits
in 32-bit, so this change is a no-op even on 32-bit build hosts.
Ard Biesheuvel [Thu, 29 Nov 2018 12:00:20 +0000 (13:00 +0100)]
BaseTools/CommonLib: avoid using 'native' word size in IP address handling
In the context of the BaseTools, there is no such thing as a native word
size, given that the same set of tools may be used to build a firmware
image consisting of both 32-bit and 64-bit modules.
So update StrToIpv4Address() and StrToIpv6Address() to use UINT64
types instead of UINTN types when parsing strings.
Shenglei Zhang [Fri, 23 Nov 2018 05:43:41 +0000 (13:43 +0800)]
BaseTools: Remove GenVtf
GenVtf C tool is IPF specific. IPF support has been removed
from edk2 trunk. This tool can be removed.
https://bugzilla.tianocore.org/show_bug.cgi?id=1349
v2:Remove GenVtf in Makefile and GNUmakefile.
v3:Remove BinWrappers/PosixLike/GenVtf and the user manual
of GenVtf.
Ard Biesheuvel [Fri, 30 Nov 2018 11:28:29 +0000 (12:28 +0100)]
ArmVirtPkg/QemuVirtMemInfoLib: trim the MMIO region mapping
QEMU/mach-virt is rather unhelpful when it comes to tracking down
NULL pointer dereferences that occur while running in UEFI: since
we have NOR flash mapped at address 0x0, inadvertent reads go
unnoticed, and even most writes are silently dropped, unless you're
unlucky and the instruction in question is one that KVM cannot
emulate, in which case you end up with a QEMU crash like this:
and a warning in the host kernel log that load/store instruction
decoding is not supported by KVM.
Given that the first page of the flash device is not actually
used anyway, let's reduce the mappings of the peripheral space
and the flash device (both of which cover page #0) to only cover
what is actually required:
For ArmVirtQemu, the resulting virtual mapping looks roughly like:
- [0, 4K) : flash, unmapped
- [4K, 2M) : flash, mapped as WB+X RAM
- [2M, 64M) : flash, unmapped
- [64M, 128M) : varstore flash, will be mapped by the NOR flash driver
- [128M, 256M) : peripherals, mapped as device
- [256M, 1GB) : 32-bit MMIO aperture, translated IO aperture, ECAM,
will be mapped by the PCI host bridge driver
- [1GB, ...) : RAM, mapped.
After this change, any inadvertent read or write from/to the first
physical page will trigger a translation fault inside the guest,
regardless of the nature of the instruction, without crashing QEMU.
The primary FV contains the firmware boot image, which is not
runtime updatable in our case. So exposing it to the NOR flash
driver is undesirable, since it may attempt to modify the NOR
flash contents. It is also rather pointless, since we don't
keep anything there that we care to expose. (the SEC and PEI
phase modules are not executable from DXE context, and the
contents of the embedded DXE phase FV are exposed by the DXE
core directly via the FVB2 protocol)
So let's disregard the NOR flash block that covers the primary
FV.
Ard Biesheuvel [Fri, 30 Nov 2018 11:28:27 +0000 (12:28 +0100)]
ArmPkg/ArmMmuLib ARM: handle unmapped sections when updating permissions
The ARM ArmMmuLib code currently does not take into account that
setting permissions on a region should take into account that a
region may not be mapped yet to begin with.
So when updating a section descriptor whose old value is zero,
pass in the address explicitly.
Ard Biesheuvel [Fri, 30 Nov 2018 11:28:26 +0000 (12:28 +0100)]
ArmPkg/ArmMmuLib ARM: handle unmapped section in GetMemoryRegion()
GetMemoryRegion() is used to obtain the attributes of an existing
mapping, to permit permission attribute changes to be optimized
away if the attributes don't actually change.
The current ARM code assumes that a section mapping or a page mapping
exists for any region passed into GetMemoryRegion(), but the region
may be unmapped entirely, in which case the code will crash. So check
if a section mapping exists before dereferencing it.
Liming Gao [Thu, 29 Nov 2018 00:55:56 +0000 (08:55 +0800)]
MdeModulePkg: Correct PCD name in MdeModulePkg.uni
https://bugzilla.tianocore.org/show_bug.cgi?id=1363
New PCD PcdVpdBaseAddress64 is added in MdeModulePkg.dec.
Its string token in MdeModulePkg.uni should match to its name.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Cc: Bi Dandan <dandan.bi@intel.com> Cc: Star Zeng <star.zeng@intel.com> Reviewed-by: Bi Dandan <dandan.bi@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
Ard Biesheuvel [Mon, 26 Nov 2018 21:36:33 +0000 (22:36 +0100)]
BeagleBoardPkg/PrePi: base GCD memory space size on CPU's PA range
Derive the size of the GCD memory space map directly from the CPU's
information registers rather than from the PcdPrePiCpuMemorySize PCD,
which will be removed.
Ard Biesheuvel [Mon, 26 Nov 2018 21:35:02 +0000 (22:35 +0100)]
ArmVirtPkg/PrePi: base GCD memory space size on CPU's PA range
Derive the size of the GCD memory space map directly from the CPU's
information registers rather than from the PcdPrePiCpuMemorySize PCD,
which will be removed.
Ard Biesheuvel [Mon, 26 Nov 2018 21:34:05 +0000 (22:34 +0100)]
ArmPlatformPkg/PrePi: base GCD memory space size on CPU's PA range
Derive the size of the GCD memory space map directly from the CPU's
information registers rather than from the PcdPrePiCpuMemorySize PCD,
which will be removed.
Ard Biesheuvel [Mon, 26 Nov 2018 21:22:20 +0000 (22:22 +0100)]
ArmPkg/CpuPei: base GCD memory space size on CPU's PA range
Derive the size of the GCD memory space map directly from the CPU's
information registers rather than from the PcdPrePiCpuMemorySize PCD,
which will be removed.
Ard Biesheuvel [Fri, 23 Nov 2018 12:14:28 +0000 (13:14 +0100)]
ArmPkg/ArmMmuLib: take the CPU supported maximum PA space into account
In preparation of dropping PcdPrePiCpuMemorySize entirely, base the
maximum size of the identity map on the capabilities of the CPU.
Since that may exceed what is architecturally permitted when using
4 KB pages, take MAX_ADDRESS into account as well.
Ard Biesheuvel [Tue, 27 Nov 2018 12:23:35 +0000 (13:23 +0100)]
MdePkg/ProcessorBind.h AARCH64: limit MAX_ADDRESS to 48 bits
AArch64 supports the use of more than 48 bits for physical and/or
virtual addressing, but only if the page size is set to 64 KB,
which is not supported by UEFI. So redefine MAX_ADDRESS to cover
only 48 address bits.
Ard Biesheuvel [Tue, 27 Nov 2018 14:25:42 +0000 (15:25 +0100)]
ArmVirtPkg/QemuVirtMemInfoLib: remove 1:1 mapping of top of PA range
Currently, we map DRAM as EFI_MEMORY_WB, and the remainder of the
entire virtual address space is mapped with EFI_MEMORY_UC attributes,
regardless of whether any devices actually reside there.
Now that we are relaxing the address space limit to more than 40 bits,
mapping all that address space actually takes up more space in page
tables than we have so far made available as temporary RAM. So let's
get rid of the mapping rather than increasing the available RAM, given
that the mapping is not particularly useful anyway.
Ard Biesheuvel [Tue, 27 Nov 2018 14:18:38 +0000 (15:18 +0100)]
ArmVirtPkg/FdtPciHostBridgeLib: map ECAM and I/O spaces in GCD memory map
Up until now, we have been getting away with not declaring the ECAM
and translated I/O spaces at all in the GCD memory map, simply because
we map the entire address space with device attributes in the early PEI
code, and so the ECAM space will be mapped wherever it ends up.
Now that we are about to make changes to how ArmVirtQemu reasons
about the size of the address space, it would be better to get rid
of this mapping of the entire address space, since it can get
arbitrarily large without real benefit.
So start by mapping the ECAM and translated I/O spaces explicitly,
instead of relying on the early PEI mapping.
This function is exposed by the MemoryAllocationLib header.
An AllocateZeroPool() function has been added to fix modules depending on
this library and this function.
Liming Gao [Tue, 20 Nov 2018 08:05:56 +0000 (16:05 +0800)]
BaseTools Script: Update ConvertFceToStructurePcd to report warning messages
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1297
When the header files are not found for the used C structure, this script will
report the warning, let user know there is no header file to define C structure.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Wang BinX A <binx.a.wang@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Achin Gupta [Tue, 27 Nov 2018 10:43:57 +0000 (16:13 +0530)]
ArmPkg/ArmMmuLib: Add MMU Library suitable for use in S-EL0.
The Standalone MM environment runs in S-EL0 in AArch64 on ARM Standard
Platforms. Privileged firmware e.g. ARM Trusted Firmware sets up its
architectural context including the initial translation tables for the
S-EL1/EL0 translation regime. The MM environment will still request ARM
TF to change the memory attributes of memory regions during
initialization.
The Standalone MM image is a FV that encapsulates the MM foundation
and drivers. These are PE-COFF images with data and text segments.
To initialise the MM environment, Arm Trusted Firmware has to create
translation tables with sane default attributes for the memory
occupied by the FV. This library sends SVCs to ARM Trusted Firmware
to request memory permissions change for data and text segments.
This patch adds a simple MMU library suitable for execution in S-EL0 and
requesting memory permissions change operations from Arm Trusted Firmware.
PI v1.5 Specification Volume 4 defines Management Mode Core Interface
and defines EFI_MM_COMMUNICATION_PROTOCOL. This protocol provides a
means of communicating between drivers outside of MM and MMI
handlers inside of MM.
This patch implements the EFI_MM_COMMUNICATION_PROTOCOL DXE runtime
driver for AARCH64 platforms. It uses SMCs allocated from the standard
SMC range defined in DEN0060A_ARM_MM_Interface_Specification.pdf
to communicate with the standalone MM environment in the secure world.
This patch also adds the MM Communication driver (.inf) file to
define entry point for this driver and other compile
related information the driver needs.
Achin Gupta [Tue, 27 Nov 2018 10:43:53 +0000 (16:13 +0530)]
ArmPkg: Add PCDs needed for MM communication driver.
This patch defines PCDs to describe the base address and size of
communication buffer between normal world (uefi) and standalone MM
environment in the secure world.
Ard Biesheuvel [Wed, 21 Nov 2018 11:58:28 +0000 (12:58 +0100)]
ArmPlatformPkg/NorFlashPlatformLib: remove unused Guid member from struct
We no longer use per-instance GUIDs to identify NOR flash banks so
there is no longer a need to define them. Drop the Guid member from
the NOR_FLASH_DESCRIPTION type.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Thomas Abraham <thomas.abraham@arm.com>
Liming Gao [Thu, 22 Nov 2018 14:10:29 +0000 (22:10 +0800)]
MdeModulePkg PCD: Add DynamicEx PcdVpdBaseAddress64 for non SPI platform
https://bugzilla.tianocore.org/show_bug.cgi?id=1356
Current PcdVpdBaseAddress is 32bit static Pcd. NON SPI platform needs to
configure it as Dynamic PCD. Emulator platform (such as NT32) may set its
value to 64bit address.
To meet with this usage, 64bit DynamicEx PcdVpdBaseAddress64 is introduced.
If its value is not zero, it will be used.
If its value is zero, static PcdVpdBaseAddress will be used.
When NON SPI platform enables VPD PCD, they need to set PcdVpdBaseAddress64.
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> Cc: Dandan Bi <dandan.bi@intel.com>
Liming Gao [Thu, 22 Nov 2018 13:41:41 +0000 (21:41 +0800)]
OvmfPkg: Don't include TftpDynamicCommand in XCODE5 tool chain
https://bugzilla.tianocore.org/show_bug.cgi?id=1355
XCODE doesn't support HII resource section. TftpDynamicCommand driver depends
on HII resource section. To let OvmfPkg boot to shell on XCODE5 tool chain,
don't include TftpDynamicCommand driver.
Ard Biesheuvel [Wed, 21 Nov 2018 11:58:27 +0000 (12:58 +0100)]
ArmVirtPkg/NorFlashQemuLib: discover NOR flash banks dynamically
NorFlashQemuLib is one of the last remaining drivers in ArmVirtPkg
that are not based on the device tree received from QEMU.
For ArmVirtQemu, this does not really matter, given that the NOR
flash banks are always the same: the PEI code is linked to execute
in place from flash bank #0, and the fixed varstore PCDs refer to
flash bank #1 directly.
However, ArmVirtQemuKernel can execute at any offset, permitting it
to be used as an intermediary loader when running QEMU with secure
world emulation enabled, in which case NOR flash bank #0 is secure
only and contains the secure world firmware. In this case,
NorFlashQemuLib should not expose the first flash bank at all.
To prevent introducing too much internal knowledge about which flash
bank is accessible under which circumstances, let's switch to using
the DTB to decide which flash banks to expose to the NOR flash driver.
Ard Biesheuvel [Wed, 21 Nov 2018 11:58:26 +0000 (12:58 +0100)]
ArmVirtPkg/FdtClientDxe: take DT node 'status' properties into account
DT has a [pseudo-]standardized 'status' property that can be set on
any node, and which signifies that a node should be treated as
absent unless it is set to 'ok' or 'okay'. So take this into account
when iterating over nodes.
Ard Biesheuvel [Wed, 21 Nov 2018 11:58:25 +0000 (12:58 +0100)]
ArmPlatformPkg/NorFlashDxe: use one GUID plus index to identify flash banks
Currently, each flash bank controlled by ArmPlatformPkg/NorFlashDxe
has its own VendorHw GUID, and instances of NorFlashPlatformLib
describe each bank to the driver, along with the GUID for each.
This works ok for bare metal platforms, but it would be useful for
virtual platforms if we could obtain this information from a
device tree, which would require us to invent GUIDs on the fly,
given that the 'cfi-flash' binding does not include a GUID.
So instead, let's switch to a single GUID for all flash banks,
and update the driver's device path handling to include an index
to identify each bank uniquely.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Thomas Abraham <thomas.abraham@arm.com>
Ard Biesheuvel [Wed, 21 Nov 2018 11:58:24 +0000 (12:58 +0100)]
ArmPlatformPkg/NorFlashDxe: prepare for devicepath format change
A subsequent patch will change the layout of devicepath nodes
produced by this driver. In preparation, make some tweaks to
the code to use a packed struct for the devicepath and to pass
the device index to NorFlashCreateInstance(). These are cosmetic
changes only, the resulting binaries should be identical.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Thomas Abraham <thomas.abraham@arm.com>
Ard Biesheuvel [Fri, 23 Nov 2018 18:54:59 +0000 (19:54 +0100)]
ArmPkg: remove now unused BsdLib.h
The last remaining users of the BdsLib.h header reside in the
edk2-platforms tree, and so it has been copied there. This
allows us to remove the original from ArmPkg.
Internal code quality scanning found 2 constant if
statements related to FixedPcdGet8 () usage.
Since the PCD can be PatchableInModule too, it should be
changed to PcdGet8 () to fix this issue.
Test: Verified on internal platform and booted successfully.
Cc: Jiewen Yao <Jiewen.yao@intel.com> Cc: Desimone Nathaniel L <nathaniel.l.desimone@intel.com> Cc: Wu Hao A <hao.a.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
MdeModulePkg/Variable: add debug logs in VariableServiceSetVariable
Print debug messages if size of the VariableName plus DataSize exceeds
Max(Auth|Voltaile)VariableSize bytes. The messages will be useful if any
platform specific value of Max(Auth|Voltaile)VariableSize PCDs have to
be changed.
Cc: Star Zeng <star.zeng@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
Ard Biesheuvel [Tue, 20 Nov 2018 01:53:13 +0000 (17:53 -0800)]
ArmPkg/ArmSmcPsciResetSystemLib: add missing call to ExitBootServices()
Our poor man's implementation of EnterS3WithImmediateWake () currently
sets a high TPL level to disable interrupts, and simply calls the
PEI entrypoint again after disabling the MMU.
Unfortunately, this is not sufficient: DMA capable devices such as
network controllers or USB controllers may still be enabled and
writing to memory, e.g., in response to incoming network packets.
So instead, do the full ExitBootServices() dance: allocate space and
get the memory map, call ExitBootServices(), and in case it fails, get
the memory map again and call ExitBootServices() again. This ensures
that all cleanup related to DMA capable devices is performed before
doing the warm reset.
In function GetSectionFromAnyFvByFileType, the input parameter "Buffer"
and "size" should not be NULL, so add ASSERT here to avoid any checker
report that the NULL pointer may be used.
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: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Dandan Bi [Wed, 7 Nov 2018 08:14:22 +0000 (16:14 +0800)]
MdeModulePkg/DisplayEngine: Remove useless NULL ptr check for NewPos
In function UiDisplayMenu, the NewPos ptr which used to point to the
highlight menu entry. It will always point to the menu entry which
need to be highlighted or the gMenuOption menu if the highlight menu
is not found.
So we can remove the NULL ptr check for NewPos in this function.
And add the ASSERT code to avoid if any false positive reports
of NULL pointer dereference issue raised from static analysis.
Cc: Liming Gao <liming.gao@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Hao Wu <hao.a.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Zhang, Chao B [Tue, 20 Nov 2018 01:47:19 +0000 (09:47 +0800)]
SecurityPkg: Update TCG PFP spec revision.
UEFI TCG has aligned with TCG PFP 1.03 v51 along with Errata Version 1.0.
Update spec version accordingly.
Spec Link:
https://trustedcomputinggroup.org/wp-content/uploads/PC-ClientSpecific_Platform_Profile_for_TPM_2p0_Systems_v51.pdf
https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-Firmware-Profile-for-TPM-2-0-v1p03_r51-errata-v1p0_170426.pdf
Cc: Yao Jiewen <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Zhang, Chao B <chao.b.zhang@intel.com> Reviewed-by: Yao Jiewen <jiewen.yao@intel.com>
The VMWare SVGA display device implemented by Qemu (-vga vmware) uses
an I/O-type BAR which is laid out such that some register offsets are
not aligned to the read/write width with which they are expected to be
accessed. However, we reverted the initialization of VMWare SVGA device,
we don't need such unaligned I/O.
The VMWare SVGA model now -- since commit 104bd1dc70 in QEMU --
falls back to stdvga (that is, Bochs) if we don't setup VMWare SVGA
FIFO.
To simplify QemuVideoDxe, we don't intend to implement the VMWare SVGA
FIFO setup feature. It means our current VMW SVGA driver code is
basically dead. To simplify the problem, we will replace the old
VMWare SVGA driver to Bochs interface. It should work on all QEMU
version.
The first step for using Bochs interface is to revert old driver.
The VMWare SVGA display device implemented by Qemu (-vga vmware) uses
an I/O-type BAR which is laid out such that some register offsets are
not aligned to the read/write width with which they are expected to be
accessed. However, we will revert the initialization of VMWare SVGA
device later, we don't need such unaligned I/O.
Marcin Wojtas [Fri, 9 Nov 2018 23:01:27 +0000 (07:01 +0800)]
MdeModulePkg/SdMmcPciHcDxe: Allow overriding base clock frequency
Some SdMmc host controllers are run by clocks with different
frequency than it is reflected in Capabilities Register 1.
It is allowed by SDHCI specification ver. 4.2 - if BaseClkFreq
field value of the Capability Register 1 is zero, the clock
frequency must be obtained via another method.
Because the bitfield is only 8 bits wide, a maximum value
that could be obtained from hardware is 255MHz.
In case the actual frequency exceeds 255MHz, the 8-bit BaseClkFreq
member of SD_MMC_HC_SLOT_CAP structure occurs to be not sufficient
to be used for setting the clock speed in SdMmcHcClockSupply
function.
This patch adds new UINT32 array ('BaseClkFreq[]') to
SD_MMC_HC_PRIVATE_DATA structure for specifying
the input clock speed for each slot of the host controller.
All routines that are used for clock configuration are
updated accordingly.
This patch also adds new IN OUT BaseClockFreq field
in the Capability callback of the SdMmcOverride,
protocol which allows to update BaseClkFreq value.
The patch reuses original commit from edk2-platforms: 20f6f144d3a8 ("Marvell/Drivers: XenonDxe: Allow overriding base clock
frequency")
Tomasz Michalec [Fri, 9 Nov 2018 23:01:25 +0000 (07:01 +0800)]
MdeModulePkg/SdMmcPciHcDxe: Add UhsSignaling to SdMmcOverride protocol
Some SD Host Controllers use different values in Host Control 2 Register
to select UHS Mode. This patch adds a new UhsSignaling type routine to
the NotifyPhase of the SdMmcOverride protocol.
UHS signaling configuration is moved to a common, default routine
(SdMmcHcUhsSignaling). After it is executed, the protocol producer
can override the values if needed.
Marcin Wojtas [Fri, 9 Nov 2018 23:01:24 +0000 (07:01 +0800)]
MdeModulePkg/SdMmcPciHcDxe: Add an optional parameter in NotifyPhase
In order to ensure bigger flexibility in the NotifyPhase
routine of the SdMmcOverride protocol, enable using an
optional phase-specific data. This will allow to exchange
more information between the protocol producer driver
and SdMmcPciHcDxe in the newly added callbacks.
Provides PCD selection for FSP Wrapper to support Dispatch
mode. Also PcdFspmBaseAddress should support Dynamic for
recovery scenario (multiple FSP-M binary in flash)
Test: Verified on internal platform and both API and
DISPATCH modes booted successfully.
Cc: Jiewen Yao <Jiewen.yao@intel.com> Cc: Desimone Nathaniel L <nathaniel.l.desimone@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Provides PCD selection for FSP Wrapper to support Dispatch
mode. Also PcdFspmBaseAddress should support Dynamic for
recovery scenario (multiple FSP-M binary in flash)
Test: Verified on internal platform and both API and
DISPATCH modes booted successfully.
Cc: Jiewen Yao <Jiewen.yao@intel.com> Cc: Desimone Nathaniel L <nathaniel.l.desimone@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Chasel Chiu <chasel.chiu@intel.com>