This is a shell application to dump dynamic PCD settings.
Type DumpDynPcd -?/h/H to get help information.
Type DumpDynPcd -v/V to get version information.
Type DumpDynPcd [PcdName] to get Pcd information.
https://bugzilla.tianocore.org/show_bug.cgi?id=1541
v2:1.Add static for global variables.
2.Change the parameter amount of InternalStrnCatGrow in DumpDynPcd.c.
3.Add open brace according to EDK II C Coding Standards Specification.
4.Remove the dependency on ShellPkg.dec in DumpDynPcd.inf.
v3:Add static for all global variables and internal functions.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1597
Currently RTData are allocated at/after ReadyToBoot to store the
contents in HiiDatabase and the HII configurations for OS runtime
utilization.
Some platforms may meet S4 resume issue since the allocation after
ReadyToBoot cause memory map change.
Now this patch is to do some overallocation to minimize the number
of memory allocations after ReadyToBoot and also add warning
message when do allocation after ReadyToBoot.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
After commit 57df17fe26, some static check reports suspicious NULL pointer
deference at line:
Entry->MachineType = Entry->Emulator->MachineType;
^^^^^^^^^^^^^^^
within function PeCoffEmuProtocolNotify().
However, 'Entry->Emulator' is guaranteed to have a non-NULL value when
previous call to the CoreHandleProtocol() returns EFI_SUCCESS.
This commit will re-write the return status check for CoreHandleProtocol()
to add explicit NULL pointer check for protocol instance pointer.
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1483
This commit will add the PEI BlockIO (2) PPIs support for AHCI mode ATA
devices.
More specifically, the driver will consume the ATA AHCI host controller
PPI for ATA controllers working under AHCI code within the system. And
then produces the below additional PPIs for each controller:
EFI PEI Recovery Block IO PPI
EFI PEI Recovery Block IO2 PPI
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1483
Due to the limited resource on the VTd DMA buffer size in the PEI phase,
the driver will limit the maximum transfer block number for 48-bit
addressing.
According to PCDs:
gIntelSiliconPkgTokenSpaceGuid.PcdVTdPeiDmaBufferSize|0x00400000
gIntelSiliconPkgTokenSpaceGuid.PcdVTdPeiDmaBufferSizeS3|0x00200000
The default buffer size allocated for IOMMU mapping is:
* 4M bytes for non-S3 cases;
* 2M bytes for S3
For ATA devices in 48-bit address mode, the maximum block number is
currently set to 0xFFFF. For a device with block size equal to 512 bytes,
the maximum buffer allowed for mapping within AhciPei driver will be close
to 32M bytes. Thus, this commit will limit the 48-bit mode maximum block
number to 0x800, which means 1M-byte maximum buffer for mapping when the
block size of a device is 512 bytes. By doing so, potential failure on
calls to the IOMMU 'Map' service can be avoided.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
The DxeCapsuleLibFmp code accesses the ESRT table to decide whether
a certain capsule is an FMP capsule. Since the UEFI spec mandates
that the ESRT resides in EfiBootServicesData memory, this results
in problems at OS runtime, since the firmware implementation itself
cannot access memory that has not been virtually remapped.
So let's take a private copy of the ESRT at ReadyToBoot, and store
it in EfiRuntimeServicesData memory. The ESRT's size is order 10s
of bytes so the memory footprint is going to be negligigble.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
As reported by Gary, the recent LoadImage/StartImage changes to
accommodate dispatching PE/COFF images built for foreign architectures
may result in a crash when loading an IA32 option ROM into a X64 VM
running OVMF:
Loading driver at 0x0007E537000 EntryPoint=0x0007E53C06D 8086100e.efi
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 7F003B98
ProtectUefiImageCommon - 0x7F002BC0
- 0x000000007E537000 - 0x000000000009F900
Image type IA32 can't be started on X64 UEFI system.
ASSERT MdeModulePkg/Core/Dxe/Mem/Pool.c(698): Head->Signature == ((('p') |
('h' << 8)) | ((('d') | ('0' << 8)) << 16)) || Head->Signature
== ((('p') | ('h' << 8)) | ((('d') | ('1' << 8)) << 16))
This turns out to be caused by the deferred image loading code in BDS,
which ends up trying to free an uninitialized 'ExitData' pointer.
Given that ExitData is never actually used, let's just get rid of it
entirely. While we're at it, drop the pointless assignment of Status
as well.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Gary Lin <glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Now that the EBC machine type is no longer classified as a
natively supported machine type on the architectures that can
support it via the EBC interpreter, the EBC specific handling
in DXE core is no longer used and can be removed.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Implement the new EDK2 PE/COFF image emulator protocol so that we can
remove the EBC specific handling in the DXE core and other places in
the core code.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Allow PE/COFF images that must execute under emulation for Driver####
options, by removing the redundant machine type check from the BDS code.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Delete the explicit machine type check for option ROM images, and instead,
rely on the LoadImage() boot service to decide whether an option ROM can
be dispatched or not. This permits platforms to ship with emulators to
execute option ROMs that are not native to the processor architecture.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
When encountering PE/COFF images that cannot be supported natively,
attempt to locate an instance of the PE/COFF image emulator protocol,
and if it supports the image, proceed with loading it and register it
with the emulator.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Introduce a protocol that can be invoked by the image loading services
to execute foreign architecture PE/COFF images via an emulator.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1462
Original logic is that checking the CapsuleUpdate variable
and do the EnterS3WithImmediateWake if the system require a
capsule update. The EnterS3WithImmediateWake is usually
implemented in Platform ResetSystemLib instance and it may
do some operation for capsule update. For now, thess preparations
of capsule are platform reset notify functions' duty. Most
platforms need flush cache to memory before warm reset during
capsule update and this operation is added to capsule flow.
So it is safe to remove it and do not affect the capsule update
function.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
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>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Commit 05fd2a9268
("MdeModulePkg/NvmExpressPei: Consume S3StorageDeviceInitList LockBox")
added a dependency on LockBoxLib to NvmExpressPei, causing builds using
MdeModulePkg.dsc to fail on architectures other than IA32/X64 with
missing reference to
gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode.
Add a resolution for LockBoxNullLib for ARM/AARCH64 to restore builds.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
The system environment: virtual-CDROM(USB interface) via BMC, insert a
iso file to CDROM, like ubuntu-18.04.1-server-arm64.iso, change CDROM
to first boot option.
With release version bios, disconnecting CDROM when boot to
"1 seconds left, Press Esc or F2 to enter Setup"
then system will get a exception.
The root cause is the EFI_BLOCK_IO_PROTOCOL for UsbMass will be uninstalled
in this situation after print some transfer error. The status will be
invalid parameter. This line will get a exception for BlockIo not point
to right address:
AllocatePool (BlockIo->Media->BlockSize)
So, here need to judge the status after ASSERT_EFI_ERROR.
The Bugzilla tracker for this:
https://bugzilla.tianocore.org/show_bug.cgi?id=1631
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ming Huang <ming.huang@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Driver was supporting only 32b DMA support for V3 controllers. Add
support for 64b DMA as well for completeness.
For V4.0 64b support, driver was looking at incorrect capability
register bit. Fix for that is present as well.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1583
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com>
Tested-by: Eugene Cohen <eugene@hp.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1135
For 4bit BMP, there are only 2^4 = 16 colors in the palette.
But when a corrupted BMP contains more than 16 colors in the palette,
today's implementation wrongly copies all colors to the local
PaletteValue[16] array which causes stack overflow.
The similar issue also exists in the logic to handle 8bit BMP.
The patch fixes the issue by only copies the first 16 or 256 colors
in the palette depending on the BMP type.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
