The device manager UI library creates a UiApp submenu that contains a
list of network devices in the system. The logic that creates this menu
assumes that all handles have been connected to their drivers, but this
is not guaranteed in the general case: due to the way UiApp is constructed,
this logic runs before the UiApp entrypoint is invoked, which is where
ConnectAll() is normally called to ensure that all existing controllers
are connected to their drivers. Moving this call into DeviceManagerUiLib
is not an option, since it is incorporated into UiApp via NULL library
class resolution, and so it may not be included to begin with.
So work around this by doing an explicit additional ConnectAll() before
populating the pages.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Link: https://edk2.groups.io/g/devel/topic/72879609#57075
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2652
According to the File description, the File is optional and can be NULL.
Signed-off-by: Guomin Jiang <guomin.jiang@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Use submodule way to access brotli in MdeModulePkg based on
brotli version 666c3280cc11dc433c303d79a83d4ffbdd12cc8d.
The newly added BrotliDecUefiSupport.h/.c are used by directory
'brotli'.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2559
Cc: Liming Gao <liming.gao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=2505
* Add unit test of DxeResetSystemLib library
instance that uses cmocka interfaces to mock the
UEFI Runtime Services Table and its ResetSystem()
service. When a unit test uses the cmocka
interfaces, the unit test does not support being
run from target environments.
cmocka APIs: https://api.cmocka.org/index.html
This example puts the unit test in a UnitTest
directory below the library INF file and this location
means the unit test is only designed to work this
this one library instance.
* Add Test/MdeModulePkgHostTest.dsc to build host
based unit tests
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Bret Barkelew <Bret.Barkelew@microsoft.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2001
For S3BootScriptLib APIs:
S3BootScriptSaveIoWrite
S3BootScriptSaveMemWrite
S3BootScriptSavePciCfgWrite
S3BootScriptSavePciCfg2Write
S3BootScriptSaveSmbusExecute
S3BootScriptSaveInformation
S3BootScriptSaveInformationAsciiString
S3BootScriptLabel (happen in S3BootScriptLabelInternal())
possible numeric truncations will happen that may lead to S3 boot script
entry with improper size being returned to store the boot script data.
This commit will add checks to prevent this kind of issue.
Please note that the remaining S3BootScriptLib APIs:
S3BootScriptSaveIoReadWrite
S3BootScriptSaveMemReadWrite
S3BootScriptSavePciCfgReadWrite
S3BootScriptSavePciCfg2ReadWrite
S3BootScriptSaveStall
S3BootScriptSaveDispatch2
S3BootScriptSaveDispatch
S3BootScriptSaveMemPoll
S3BootScriptSaveIoPoll
S3BootScriptSavePciPoll
S3BootScriptSavePci2Poll
S3BootScriptCloseTable
S3BootScriptExecute
S3BootScriptMoveLastOpcode
S3BootScriptCompare
are not affected by such numeric truncation.
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Acked-by: Jian J Wang <jian.j.wang@intel.com>
Before writing data to FIFO, wait for the serial port to be ready,
to make sure both the transmit FIFO and shift register empty. Code
comment was saying the right thing but code was missing a check.
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com>
The LoadFile protocol can report such a large buffer size that we cannot
allocate enough reserved pages for. This particularly affects HTTP(S)
Boot, if the remote file is very large (for example, an ISO image).
While the TianoCore wiki mentions this at
<https://github.com/tianocore/tianocore.github.io/wiki/HTTP-Boot#ram-disk-image-size>:
> The maximum RAM disk image size depends on how much continuous reserved
> memory block the platform could provide.
it's hard to remember; so log a DEBUG_ERROR message when the allocation
fails.
This patch produces error messages such as:
> UiApp:BmExpandLoadFile: failed to allocate reserved pages:
> BufferSize=4501536768
> LoadFile="PciRoot(0x0)/Pci(0x3,0x0)/MAC(5254001B103E,0x1)/
> IPv4(0.0.0.0,TCP,DHCP,192.168.124.106,192.168.124.1,255.255.255.0)/
> Dns(192.168.124.1)/
> Uri(https://ipv4-server/RHEL-7.7-20190723.1-Server-x86_64-dvd1.iso)"
> FilePath=""
(Manually rewrapped here for keeping PatchCheck.py happy.)
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
EnterS3WithImmediateWake () no longer has any callers, so remove it
from ResetSystemLib.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Add edk2 platform boot manager protocol which would have platform
specific refreshes to the auto enumerated as well as NV boot options
for the platform.
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2382
Add ARM/Aarch64 which were missing to VALID_ARCHITECTURES
in LzmaCustomDecompressLib.inf
Cc: Liming Gao <liming.gao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
After unifying the definition of size_t, EBC compiler has failure.
So don't compile this inf file for EBC
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2398
Cc: Liming Gao <liming.gao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
Define the same macro in the different OS. It can make CLANG generate the same
image in the different host OS.
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
The HiiConstructConfigHdr() function takes the "DriverHandle" parameter in
order to fetch the device path from it, and then turn the device path into
PATH routing information.
The HiiConstructConfigHdr() function is called from
VariableCleanupHiiExtractConfig(), which is only installed when "Type" is
"VarCleanupManually" in PlatformVarCleanup().
In that case, we create "Private->DriverHandle" as a new handle, and
install "mVarCleanupHiiVendorDevicePath" on it. Then we pass
"Private->DriverHandle" to HiiAddPackages(), which consumes the device
path for routing purposes.
It follows that the "DriverHandle" argument passed to
HiiConstructConfigHdr() should be the same driver handle, for matching
routing.
Currently we pass "Private->HiiHandle", which is clearly a typo, because
it is the return value of HiiAddPackages(), and stands for the published
HII package list.
Therefore this patch addresses an actual bug.
The typo has not been flagged by compilers because the UEFI spec
regrettably defines both EFI_HANDLE and EFI_HII_HANDLE as (VOID*).
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
HiiGetHiiHandles() returns an array of EFI_HII_HANDLEs, not EFI_HANDLEs.
HiiGetString() takes an EFI_HII_HANDLE, not an EFI_HANDLE.
This change is a no-op in practice; it's a semantic improvement.
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
GetModuleInfoFromHandle() takes an EFI_HANDLE -- (VOID*) -- as first
parameter, but InsertFpdtRecord() passes (EFI_HANDLE*) -- (VOID**).
(VOID**) converts silently to (VOID*), which is why the wrong cast is
masked.
Note that the *value* that is passed is alright -- therefore this patch
does not change behavior --, it's just semantically wrong to pass an
(EFI_HANDLE*) where an EFI_HANDLE is expected.
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2212
In binary model the same binary may have to support both
S3 enabled and disabled scenarios, however not all DXE
drivers linking PiDxeS3BootScriptLib can return error to
invoke library DESTRUCTOR for releasing resource.
To support this usage model below PCD is used to skip
S3BootScript functions when PCD set to FALSE:
gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable
Test: Verified on internal platform and S3BootScript
functions can be skipped by PCD during boot time.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Chasel Chiu <chasel.chiu@intel.com>
Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
There is no sourceX offset in case when
Configure->PixelFormat == PixelBlueGreenRedReserved8BitPerColor.
We are copying most left pixels instead of copying required rectangle.
Signed-off-by: Gris87 <Gris87@yandex.ru>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Tested-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
the Image was loaded and an ImageHandle was created with a valid
EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
This follows UEFI Spec.
But if the caller of LoadImage() doesn't have the option to defer
the execution of an image, we can not treat EFI_SECURITY_VIOLATION
like any other LoadImage() error, we should unload image for the
EFI_SECURITY_VIOLATION to avoid resource leak.
This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
for the callers in UefiBootManagerLib which don't have the policy to defer
the execution of the image.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Philippe Mathieu-Daude <philmd@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
the Image was loaded and an ImageHandle was created with a valid
EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
This follows UEFI Spec.
But if the caller of LoadImage() doesn't have the option to defer
the execution of an image, we can not treat EFI_SECURITY_VIOLATION
like any other LoadImage() error, we should unload image for the
EFI_SECURITY_VIOLATION to avoid resource leak.
This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
for the callers in DxeCapsuleLibFmp which don't have the policy to defer
the execution of the image.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Philippe Mathieu-Daude <philmd@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2186
Add the new introduced terminal types to related setup menu to change
the terminal type from setup. Most platforms would have its own
configure setup menu and they need to change it to support these.
The new introduced terminal types are Linux, XtermR6, VT400 and SCO.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
The description of parameter CapFileName is missing in comments.
So add the description.
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
RecoveryLib.h and PeiRecoveryLibNull have been deprecated from 2009,
so remove them.
https://bugzilla.tianocore.org/show_bug.cgi?id=1299
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
S3Lib.h and PeiS3LibNull have been deprecated since 2009, so remove them.
https://bugzilla.tianocore.org/show_bug.cgi?id=1299
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Add missing NULL pointer check for CapsuleNameBufStart.
Also add comments to notice that capsule name integrity check assumes
the capsule has been validated by IsValidCapsuleHeader().
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Chao B Zhang <chao.b.zhang@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Chao B Zhang <chao.b.zhang@intel.com>
REF: https://github.com/tianocore/tianocore.github.io/wiki/
UEFI-Capsule-on-Disk-Introducation
CoDCheckCapsuleOnDiskFlag() is to check if CapsuleOnDisk flag in
"OsIndications" Variable is enabled. It is used to indicate whether
capsule on disk is provisioned in normal boot path.
CoDClearCapsuleOnDiskFlag() is to to clear CapsuleOnDisk flags,
including "OsIndications" and "BootNext" variable.
CoDRelocateCapsule() is to relocate the capsules from EFI system
partition. Depends on PcdCapsuleInRamSupport, there are two solutions
to relocate the capsule on disk images:
When Capsule In Ram is supported, the Capsule On Disk images are
relocated into memory, and call UpdateCapsule() service to deliver
the capsules.
When Capsule In Ram is not supported, the Capsule On Disk images are
relocated into a temp file which will be stored in root directory on
a platform specific storage device. CapsuleOnDiskLoadPei PEIM will
retrieve the capsules from the relocation temp file and report
capsule hobs for them.
CoDRemoveTempFile() is to remove the relocation temp file in the next
boot after capsules are processed.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Chao B Zhang <chao.b.zhang@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Chao B Zhang <chao.b.zhang@intel.com>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Capsule-
on-Disk-Introducation
CoDCheckCapsuleOnDiskFlag() is to check if CapsuleOnDisk flag in
"OsIndications" Variable is enabled. It is used to indicate whether
capsule on disk is provisioned in normal boot path.
CoDClearCapsuleOnDiskFlag() is to to clear CapsuleOnDisk flags,
including "OsIndications" and "BootNext" variable.
CoDRelocateCapsule() is to relocate the capsules from EFI system
partition. Depends on PcdCapsuleInRamSupport, there are two solutions
to relocate the capsule on disk images:
When Capsule In Ram is supported, the Capsule On Disk images are
relocated into memory, and call UpdateCapsule() service to deliver
the capsules.
When Capsule In Ram is not supported, the Capsule On Disk images are
relocated into a temp file which will be stored in root directory on
a platform specific storage device. CapsuleOnDiskLoadPei PEIM will
retrieve the capsules from the relocation temp file and report
capsule hobs for them.
CoDRemoveTempFile() is to remove the relocation temp file in the next
boot after capsules are processed.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Chao B Zhang <chao.b.zhang@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Chao B Zhang <chao.b.zhang@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1722
Since we have merged this one into MdePkg,
remove it now.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Some buses doesn't allow 8 bit MMIO read/write, this adds support for
32 bits read/write
Signed-off-by: "Tien Hock, Loh" <tien.hock.loh@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1458
Implement the new API ResetSystemWithSubtype. Depend on Uefi Spec
2.8 chapter 8.5.1, the ResetData is valid while the ResetStatus
is EFI_SUCCESS regardless of the ResetType. Also change the function
ResetPlatofrmSpecificGuid to directly call ResetSystemWithSubtype
to reduce the duplicated code.
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: Hao Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1460
Refer to Uefi spec 2.8, the ResetData is valid while ResetStatus
is EFI_SUCCESS regardless of the ResetType is EfiResetPlatformSpecific
or not.
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: Hao Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1460
Refer to Uefi spec 2.8, the ResetData is valid while ResetStatus
is EFI_SUCCESS regardless of the ResetType is EfiResetPlatformSpecific
or not. So change the comments of ResetSystem.
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: Hao Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1460
Refer to Uefi spec 2.8, the ResetData is valid while ResetStatus
is EFI_SUCCESS regardless of the ResetType is EfiResetPlatformSpecific
or not.
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: Hao Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1460
Refer to Uefi spec 2.8, the ResetData is valid while ResetStatus
is EFI_SUCCESS regardless of the ResetType is EfiResetPlatformSpecific
or not.
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: Hao Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1728
Currently Emulator meets ASSERT when enter setup->Continue->enter setup.
When re-enter setup, the FeDriverHandle in FileExplorerLib Constructor
is not NULL which cause InstallMultipleProtocolInterfaces failure,
then ASSERT. So here set FeDriverHandle to NULL after uninstalling
protocols on it in the Destructor function to avoid this issue.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1728
Currently Emulator meets ASSERT when enter setup->Continue->enter setup.
When re-enter setup, the BmmDriverHandle in BMMUiLib Constructor
is not NULL which cause InstallMultipleProtocolInterfaces failure,
then ASSERT. So here set BmmDriverHandle to NULL after uninstalling
protocols on it in Destructor function to avoid this issue.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Eric Dong <eric.dong@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>
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>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1683
We will remove IntelFrameworkModulePkg,
but BaseUefiTianoCustomDecompressLib may still need
to be used. So move BaseUefiTianoCustomDecompressLib
from IntelFrameworkModulePkg to MdeModulePkg.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Jian J Wang <jian.j.wang@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: Hao Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1549
Add a PEI debug library instance PeiDebugLibDebugPpi base on
DebugPpi. Using the combination of the DebugServicePei and
this lib instance can reduce the image size of PEI drivers.
Notes: this library instance can be used only the PEIM
DebugSerivicePei is runed and install the gEdkiiDebugPpiGuid.
And this library contian the depx of gEfiPeiPcdPpiGuid, that
means the PcdPei.inf cannot use this library instance. The
PcdPei.inf should use the same library instance that the
PEIM DebugServicePei consumes.
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>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael Turner <Michael.Turner@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Liming Gao <liming.gao@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>
Ard Biesheuvel
Guomin Jiang
Shenglei Zhang
Daniel Schaefer
Michael D Kinney
Hao A Wu
Ashish Singhal
Laszlo Ersek
Ard Biesheuvel
Zhiguang Liu
Liming Gao
Leif Lindholm
Chasel Chiu
Gris87
Dandan Bi
Zhichao Gao
Vitaly Cheptsov via Groups.Io
Xu, Wei6
Zhang, Chao B
Tien Hock, Loh
Bret Barkelew
Ming Huang