The BootScriptInsert() and BootScriptLabel() functions take the in/out
parameter "Position" as (EFI_S3_BOOT_SCRIPT_POSITION*), and pass it to
S3BootScriptMoveLastOpcode() and S3BootScriptLabel(), respectively.
The callees take the in/out parameter "Position" as (VOID**). Add explicit
casts for clarity.
There is no change in functionality.
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: Hao A Wu <hao.a.wu@intel.com>
The SmiHandlerRegister() function explicitly casts "SmiHandler" (of type
(SMI_HANDLER*)) to EFI_HANDLE, when outputting "DispatchHandle".
Apply the same cast in the counterpart function SmiHandlerUnRegister(),
which compares multiple "SmiHandler"s against the input "DispatchHandle".
This is a semantic cleanup; there is no functional change.
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: Ray Ni <ray.ni@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Unlike the InstallMultipleProtocolInterfaces() boot service, which takes
an (EFI_HANDLE*) as first parameter, the
UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as
first parameter.
These are actual bugs. They must have remained hidden until now because
they are on error paths. Fix the UninstallMultipleProtocolInterfaces()
calls.
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>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Clean up two issues around FindFileEx():
- The "AprioriFile" parameter's type differs between the function
declaration and the function definition. The correct type is
(EFI_PEI_FILE_HANDLE*).
- "FfsFileHeader" has type (EFI_FFS_FILE_HEADER*); for clarity, we should
cast it explicitly to EFI_PEI_FILE_HANDLE when assigning it to
(*AprioriFile).
This is a semantic cleanup, there is no functional change.
Cc: Dandan Bi <dandan.bi@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>
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>
EFI_REGISTER_KEYSTROKE_NOTIFY and EFI_UNREGISTER_KEYSTROKE_NOTIFY require
the notification handle to have type (VOID*). The notification handle has
nothing to do with the EFI_HANDLE type.
This change is a semantic fix; functionally, it's a no-op.
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: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.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>
The PI spec (v1.7) correctly specifies "EFI_RUNTIME_EVENT_ENTRY.Event" in
natural language, but the field type in the structure definition itself is
wrong -- it should be EFI_EVENT, not (EFI_EVENT*).
This spec bug is likely unfixable for compatibility reasons, and so edk2
works it around already. We should clearly document the workaround.
Functionally, this patch is a no-op.
(I've also requested a non-normative (informative) clarification for the
PI spec: <https://mantis.uefi.org/mantis/view.php?id=2017>.)
Cc: Dandan Bi <dandan.bi@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>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Dandan Bi <dandan.bi@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>
EfiCreateProtocolNotifyEvent() takes a (VOID**) for "Registration",
similarly to gBS->RegisterProtocolNotify(). We should pass the address of
an actual pointer-to-VOID, and not the address of an EFI_EVENT. EFI_EVENT
just happens to be specified as (VOID*), and has nothing to do with the
registration.
The same applies to gMmst->MmRegisterProtocolNotify().
"mFtwRegistration", "mFvRegistration", and "mFvbRegistration" are used for
nothing else.
This change is a no-op in practice; it's a semantic improvement.
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>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.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>
The existing loop is set to call PlatformBootManagerWaitCallback every
second except the last one. We believe this is a mistake as it prevents
the called code from performing timeout expiration tasks such as, for
instance, ensuring that the last segment of a progress bar is displayed
before continuing (which is a current issue for the RPi3 platform).
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2195
This PCD has been moved to NetworkPkg.dec file.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2196
Network related guid definitions have been moved into NetworkPkg.dec.
So, they can be removed from MdeModulePkg.dec.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Siyuan Fu <siyuan.fu@intel.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>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1546
This patch implements the EFI_STORAGE_SECURITY_COMMAND_PROTOCOL in the
ScsiDiskDxe driver.
Support is currently limited to the RPMB Well-known LUN for UFS devices.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Christopher J Zurcher <christopher.j.zurcher@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1546
Replacing "magic numbers" in the Peripheral Type check with defines for
the reserved range from IndustryStandard/Scsi.h
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Christopher J Zurcher <christopher.j.zurcher@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1546
Currently UfsPassThru only checks for 8 common LUNs. This adds a check
for the RPMB Well-known LUN and sets the corresponding bit-mask. Further
handling of the WLUN is already present in the driver.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Christopher J Zurcher <christopher.j.zurcher@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2218
There is a bug in current driver code that makes
it impossible for it to work with devices that
only work in legacy speed mode since the function
EmmcSwitchToHighSpeed will return with EFI_INVALID_PARAMETER
for such bus mode. Since the logic in that function will
work well for SdMmcMmcLegacy this patch just allows
to call this function with SdMmcMmcLegacy bus mode.
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Tested-by: Hao A Wu <hao.a.wu@intel.com>
Tested-by: Marcin Wojtas <mw@semihalf.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2218
SD specification recommends switching card bus timing before
switching bus timing in controller. Emmc driver used to do
this switch other way around. This commit adds controller
timing switch in EmmcSwitchBusTiming function to enforce this
order and removes all controller timing programming from
EmmcSwitchToXXX functions.
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Tested-by: Hao A Wu <hao.a.wu@intel.com>
Tested-by: Marcin Wojtas <mw@semihalf.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2218
Stopping the SD clock before switching host controller
bus timing is only necessary if preset value enable is
set in host controller. Code that performs switch to
HS200 doesn't check this condition right now and we also
don't do the SD clock stop before any other bus timing switch
in host controller. Since the driver is generally not ready to support
host controller with preset value enable set we removed this
code.
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Tested-by: Hao A Wu <hao.a.wu@intel.com>
Tested-by: Marcin Wojtas <mw@semihalf.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2219
First previous patch remove the VT100Plus's arrow keys' support.
Add it back.
The arrow keys would send ESC [A through to ESC [D. Add this
support for the new introduced terminal type.
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: Liming Gao <liming.gao@intel.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.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 caller in PlatformDriOverrideDxe 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>
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>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2186
Extend the support types of terminal console driver. New added types
are Linux, XtermR6, VT400 and SCO.
Refer to
https://www.ssh.com/ssh/putty/putty-manuals/0.68/Chapter4.html#config-funkeys
Add the missing VT100+ function keys map.
Add F1-F12 function keys map for 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: Liming Gao <liming.gao@intel.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2186
A common terminal console software Putty support various types of
keyboard type, such as normal mode, Linux mode, Xterm R6, Vt400,
VT100+ and SCO. Refer to the link:
https://www.ssh.com/ssh/putty/putty-manuals/0.68/Chapter4.html#config-funkeys
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: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Fix regression issue caused by 0d85e67714
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
FILE GUID in MdeModulePkg\Universal\SerialDxe\SerialDxe.inf is
same to the one gEdkiiSerialPortLibVendorGuid.
Its FILE GUID should be updated to another value.
https://bugzilla.tianocore.org/show_bug.cgi?id=2144
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: Hao A Wu <hao.a.wu@intel.com>
The PCD is moved to PcAtChipsetPkg so remove it from
MdeModulePkg.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
The Fpdt driver (FirmwarePerformanceDxe) saves a memory address across
reboots, and then does an AllocatePage for that memory address.
If, on this boot, that memory comes from a Runtime memory bucket,
the MAT table is not updated. This causes Windows to boot into Recovery.
This patch blocks the memory manager from changing the page
from a special bucket to a different memory type. Once the buckets are
allocated, we freeze the memory ranges for the OS, and fragmenting
the special buckets will cause errors resuming from hibernate (S4).
The references to S4 here are the use case that fails. This
failure is root caused to an inconsistent behavior of the
core memory services themselves when type AllocateAddress is used.
The main issue is apparently with the UEFI memory map -- the UEFI memory
map reflects the pre-allocated bins, but the actual allocations at fixed
addresses may go out of sync with that. Everything else, such as:
- EFI_MEMORY_ATTRIBUTES_TABLE (page protections) being out of sync,
- S4 failing
are just symptoms / consequences.
This patch is cherry pick from Project Mu:
a9be767d9b
With the minor change,
1. Update commit message format to keep the message in 80 characters one line.
2. Remove // MU_CHANGE comments in source code.
3. Update comments style to follow edk2 style.
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: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Liming Gao <liming.gao@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
Initialize PageMapLevel5Entry at the beginning of the function.
This commit will fix a GCC 4.8.5 build failure introduced by commit
b3527dedc3.
OvmfPkg build failure wtih gcc 4.8.5 still exists at latest edk2 version.
The commit 46f8a68916 seems not to fix
the build failure completely.
Cc: Dandan Bi <dandan.bi@intel.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Since the transfer has been finished in previous patches,
gEfiDpcProtocolGuid can be removed.
https://bugzilla.tianocore.org/show_bug.cgi?id=1949
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: Hao A Wu <hao.a.wu@intel.com>
Move Dpc.h from MdeModulePkg to NetworkPkg. And remove the
dependency on MdeModulePkg.dec in INFs.
https://bugzilla.tianocore.org/show_bug.cgi?id=1949
Cc: Siyuan Fu <siyuan.fu@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
This commit will fix a GCC 4.8.5 build failure introduced by commit
b3527dedc3.
PageMapLevel5Entry may be uninitialized in original code, which means
uninitialized pointer will be modified at some circumstance.
So relocate the operation of PageMapLevel5Entry++ in order to make sure
the pointer could be modified only when it is initialized.
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
The header files are used but missing in INF,which causes
generating warning message when building them.
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: Hao A Wu <hao.a.wu@intel.com>
After update Oniguruma from v6.9.0 to v6.9.3, two null pointer check
should be added.
This change bases on the patch https://edk2.groups.io/g/devel/message/45183.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2066
Update Oniguruma to the latest version v6.9.3.
Oniguruma https://github.com/kkos/oniguruma
This release is the security fix release. It includes the changes:
Fixed CVE-2019-13224
Fixed CVE-2019-13225
Fixed many problems (found by libfuzzer programs)
Verify VS2015, GCC5 build.
Verify RegularExpressionProtocol GetInfo() and Match() function.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Cinnamon Shia <cinnamon.shia@hpe.com>
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=1343
This commit adds EDKII_UFS_HC_PLATFORM_PROTOCOL implementation
in UfsPassThruDxe driver in version 1. Driver assumes that at
most one instance of the protocol exists in the system. Presence
of the protocol is not mandatory.
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=1343
Private data has been refactored to use EDKII_UFS_HC_INFO structure
to store host controller capabilities and version
information. Getting host controller data has been moved
into single place and is done before host controller enable.
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=1343
UfsExecUicCommand function has been refactored to allow
the caller to check the command results which is important
for commands such as UIC read.
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=1343
EDKII_UFS_HC_PLATFORM_PROTOCOL will allow the platform to inject
platform specific logic into standard UFS flows. Right now we
support callbacks pre and post host controller enable and pre
and post link startup. Provided callbacks allow the platform
driver to inject UIC programming after HCE is set which is
a standard initialization step covered by UFS specification as
well as cover some additional use cases during other callbacks.
For instance platform driver may switch to fast mode after link
startup.
We also allow the platform to override host controller capabilities
and version which might be useful to manage silicon bugs or
allow testing experimental features from new versions of the
specification.
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2008
DxeIpl is responsible to create page table for DXE phase running
either in long mode or in 32bit mode with certain protection
mechanism enabled (refer to ToBuildPageTable()).
The patch updates DxeIpl to create 5-level page table for DXE phase
running in long mode when PcdUse5LevelPageTable is TRUE and CPU
supports 5-level page table.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Eric Dong <eric.dong@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2008
The PCD indicates if 5-Level Paging will be enabled in long mode.
5-Level Paging will not be enabled when the PCD is TRUE but CPU
doesn't support 5-Level Paging.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Eric Dong <eric.dong@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>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1525
The patch is to merge multiple FMP instances into single ESRT entry
when they have the same GUID.
The policy to LastAttemptStatus/LastAttemptVersion of ESRT entry is:
If all the LastAttemptStatus are LAST_ATTEMPT_STATUS_SUCCESS, then
LastAttemptVersion should be the smallest of LastAttemptVersion. If
any of the LastAttemptStatus is not LAST_ATTEMPT_STATUS_SUCCESS,
then the LastAttemptVersion/LastAttemptStatus should be the values
of the first FMP instance whose LastAttemptStatus is not
LAST_ATTEMPT_STATUS_SUCCESS.
To detect possible duplicated GUID/HardwareInstance, a table of
GUID/HardwareInstance pairs from all the EFI_FIRMWARE_IMAGE_DESCRIPTORs
from all FMP instances is built. If a duplicate is found, then generate
a DEBUG_ERROR message, generate an ASSERT(), and ignore the duplicate
EFI_FIRMWARE_IMAGE_DESCRIPTOR.
Add an internal worker function called FmpGetFirmwareImageDescriptor()
that retrieves the list of EFI_FIRMWARE_IMAGE_DESCRIPTORs from a single
FMP instance and returns the descriptors in an allocated buffer. This
function is used to get the descriptors used to build the table of
unique GUID/HardwareInstance pairs. It is then used again to generate
the ESRT Table from all the EFI_FIRMWARE_IMAGE_DESCRIPTORs from all the
FMP instances. 2 passes are performed so the total number of
descriptors is known. This allows the correct sized buffers to always
be allocated.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Eric Jin <eric.jin@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>
Until now, during the USB device enumeration when its PortState
USB_PORT_STAT_CONNECTION bit was not set, the stack was not informed
that the device is not present. Fix that by returning appropriate
error code.
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=1948
Update the data structure signatures in the PiSmmCore
to be unique. Some of the signatures are the same as those
used by the DxeCore. For example, the memory pool head and
tail structures use the same signature in the PiSmmCore
and DxeCore. This means the use of the wrong FreePool API
will not be noticed at the time FreePool is called and a
failure can occur much later. By making the signatures
unique, misuse of an API is caught at that time the API is
called.
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: Eric Dong <eric.dong@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
1.Update @parm to @param in function comments in Presentation.c.
2.Add missing period (.) in some function comments.
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: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=1920
Check ConfigAccess protocol is available before process user input.
Signed-off-by: GregX Yeh <gregx.yeh@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Ted Kuo <ted.kuo@intel.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1922
The Type4 Voltage field may be various.
So this patch adds it into the blacklist.
Signed-off-by: Star Zeng <star.zeng@intel.com>
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: Donald Kuo <donald.kuo@intel.com>
Cc: Chasel Chiu <chasel.chiu@intel.com>
Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=1796
Bug fixed in PciBusDxe\PciLib.c.
Removed the redundant second call to PciSearchDevice sub-routine when the
PCD for the Hot-Plug support is disabled.
Signed-off-by: Ashraf Javeed <Ashraf.javeed@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Ray Ni <ray.ni@intel.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>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1678
Add a pcd PcdPlatformRecoverySupport to conditionally
set an OS indications bit and set the 'PlatformRecovery####'
variable. This pcd would also control whether the BDS
support platform recovery or not.
Update the uni file to add the prompt and help string base on
the description in dec file.
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>
https://bugzilla.tianocore.org/show_bug.cgi?id=1882
Implement support for GetOperatingParamters notify phase
in SdMmcHcDxe driver. GetOperatingParameters notify phase
is signaled before we start card detection and initialization.
Code has been updated for both eMMC and SD card controllers to
take into consideration those new parameters. Initialization process
has been divided into 2 steps. In the first step we bring the link
up to the point where we can get card identification data(Extended
CSD in eMMC case and SWITCH command response in SD card case). This
data is later used along with controller capabilities and operating
parameters passed in GetOperatingParameters phase to choose preferred
bus settings in GetTargetBusSettings function. Those settings are later
on to start bus training to high speeds. If user passes incompatible
setting with selected bus timing driver will assume it's standard behavior
with respect to that setting. For instance if HS400 has been selected as a
target bus timing due to card and controller support bus width setting of
4 and 1 bit won't be respected and 8 bit setting will be chosen instead.
Tests on Marvell boards were also performed by Marcin Wojtas
<mw@semihalf.com>:
https://edk2.groups.io/g/devel/message/42999
Board 1 (out of tree): SD - OK, MMC - OK
Board 2: (Armada80x0McBin): SD - OK, MMC - OK
Board 3: (Armada70x0Db): SD - problems, MMC - OK
Please note that the problem on Armada70x0Db SD devices are introduced by
adding new types of SD bus modes, a subsequent patch within edk2-platforms
repository will be proposed to address it.
(More details can be referred from the above link.)
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Regression-tested-by: Sumit Garg <sumit.garg@linaro.org>
https://bugzilla.tianocore.org/show_bug.cgi?id=1882
The new notify phase allows platform to configure additional
bus parameters in addition to parameters that can already be configured
with capability override. Specifically we allow to configure bus width,
clock frequency and driver strength. If platform doesn't wish to configure
some of the parameters it can left it on default values and driver will
assume it's standard behavior with respect to those parameters.
The definition of the SD_MMC_BUS_MODE has been extended to
incorporate SD card default speed and high speed.
Tests on Marvell boards were also performed by Marcin Wojtas
<mw@semihalf.com>:
https://edk2.groups.io/g/devel/message/42999
Board 1 (out of tree): SD - OK, MMC - OK
Board 2: (Armada80x0McBin): SD - OK, MMC - OK
Board 3: (Armada70x0Db): SD - problems, MMC - OK
Please note that the problem on Armada70x0Db SD devices are introduced by
adding new types of SD bus modes, a subsequent patch within edk2-platforms
repository will be proposed to address it.
(More details can be referred from the above link.)
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Regression-tested-by: Sumit Garg <sumit.garg@linaro.org>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1341
Since UFS specification requires the data buffer specified
in PRDT to be DWORD aligned in size we had a code in
UfsInitUtpPrdt that aligned the data buffer by rounding down
the buffer size to DWORD boundary. This meant that for SCSI
commands that wanted to perform unaligned data transfer(such as
SENSE command) we specified to small buffer for the data to fit
and transfer was aborted. This change introduces code that allocates
auxiliary DWORD aligned data buffer for unaligned transfer. Device
transfers data to aligned buffer and when data transfer is over driver
copies data from aligned buffer to data buffer passed by user.
Signed-off-by: Mateusz Albecki <mateusz.albecki@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>
In current implementation we are checking for device presence every
time we execute UIC command. To make UfsExecUicCommands more generic
checking device presence has been moved to UfsDeviceDetection.
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1935
Before use the memory that is allocated through AllocateZeroPool,
we should check the memory pointer is valid to avoid using the
NULL pointer.
Add check for VariableArrayAddress that is returned from
GetScatterGatherHeadEntries. If it is NULL, directly return
the error status.
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: Star Zeng <star.zeng@intel.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
REF: https://github.com/tianocore/tianocore.github.io/wiki/
UEFI-Capsule-on-Disk-Introducation
This module provides PPI to load Capsule On Disk temp relocation file
from Root Directory file system, retrieve the capsules from the temp
file and create capsule hobs for these capsules.
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>
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>
REF: https://github.com/tianocore/tianocore.github.io/wiki/
UEFI-Capsule-on-Disk-Introducation
If Capsule On Disk mode, call Capsule On Disk Load PPI to load
capsules. When it fails, still goes to Firmware Update boot path.
BDS will clear corresponding indicator and reboot later on.
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>
REF: https://github.com/tianocore/tianocore.github.io/wiki/
UEFI-Capsule-on-Disk-Introducation
Introduce PcdCapsuleInRamSupport to turn on/off Capsule In Ram feature.
Platform could choose to drop CapsulePei/CapsuleX64 and not to support
Capsule In Ram.
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>
REF: https://github.com/tianocore/tianocore.github.io/wiki/
UEFI-Capsule-on-Disk-Introducation
Set EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED bit of
"OsIndicationsSupported" variable to indicate the Capsule On
Disk is supported or not, according to PcdCapsuleOnDiskSupport.
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>
REF: https://github.com/tianocore/tianocore.github.io/wiki/
UEFI-Capsule-on-Disk-Introducation
This patch will add Capsule On Disk related definition, including
GUID, PPI and PCDs:
The Capsule On Disk Name GUID indicates the capsule is to store
Capsule On Disk file names.
The Pei Capsule On Disk PPI provides service to retrieve capsules
from Capsule On Disk temp relocation file on mass storage devices
and create capsule hob for these capsules.
Pei Boot In CapsuleOnDisk Mode Ppi indicates current boot mode is
capsule on disk mode.
PcdCapsuleOnDiskSupport is used to enable/disable Capsule On Disk.
PcdCapsuleInRamSupport is used to enable/disable Capsule In Ram.
PcdCoDRelocationFileName specifies the Capsule On Disk temp
relocation file name.
PcdCodRelocationDevPath specifies platform specific device to store
Capsule On Disk temp relocation file.
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>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1840
1. Introduce an internal header file to put definitions in it.
2. Add missing '\n' in usage.
3. Fix the dead loop of CapsuleApp -L.
4. Fix the bug that CapsuleApp -OD cannot perform capsules in sub-
folder.
5. Optimize the handling for option -NR and -OD to support both
'CapsuleApp <Capsule> -OD -NR' and 'CapsuleApp <Capsule> -NR -OD'.
6. Check if Capsule-On-Disk is supported by "OsIndicationsSupported"
variable firstly before processing capsules. If not supported, prompt
an error message and quit the process.
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>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1901
The original logic is ASSERT if fail to create HOB. But
that doesn't make sense for release version. So it is required
to set the Buffer to null to indicate the failure.
Cc: Jian J Wang <jian.j.wang@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: Liming Gao <liming.gao@intel.com>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1853
UnicodeValueToStringS would remain two bytes for the first
parameter to set the null- terminate. So remove this change
in Mu.
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: 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>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Zhichao gao <zhichao.gao@intel.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1853
Rename the MACRO from MAX_SG_LIST_HEADS to DEFAULT_SG_LIST_HEADS.
GetScatterGatherHeadEntries: use allocated buffer instead of fixed
array to handle the condition which the SG list is larger then the
array size.
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: 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>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Zhichao gao <zhichao.gao@intel.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1853
AreCapsulesStaged do not need to return the status, only boolean
result is useful. So directly return a boolean value.
Cannot initialize the variable at its definition.
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: 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>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Zhichao gao <zhichao.gao@intel.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1853
Remove API specifier AreCapsulesStaged and GetScatterGatherHeadEntries
because they are internal used.
Add space between function name and bracket.
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: 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>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Zhichao gao <zhichao.gao@intel.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1853
Code change form Mu project:
https://github.com/microsoft/mu_basecore/blob/release/201903/
MdeModulePkg/Universal/CapsulePei/UefiCapsule.c#L801
Separate the capsule check function from GetCapsuleDescriptors
to AreCapsulesStaged. The original one is unclear.
Avoid querying the capsule variable twice. Use a fixed array
to cache the SG list during count the number of SG list. Then
allocate memory buffer to save the SG list from array.
Using MemoryAllocationLib instead of memory function in Pei
services.
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: 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>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Zhichao gao <zhichao.gao@intel.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=1879
This commit will add codes to produce the NVM Express PassThru PPI.
Signed-off-by: Maggie Chu <maggie.chu@intel.com>
Reviewed-by: 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: Star Zeng <star.zeng@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=1879
This commit will add the definitions of Nvm Express PassThru PPI.
This PPI will provide services that allow NVM commands to be sent
to NVM Express devices during PEI phase.
More specifically, the PPI will provide services to:
* Sends an NVM Express Command Packet to an NVM Express controller
or namespace (by service 'PassThru');
* Get the list of the attached namespaces on a controller
(by services 'GetNextNameSpace');
* Get the identification information (DevicePath) of the underlying
NVM Express host controller (by service 'GetDevicePath').
Signed-off-by: Maggie Chu <maggie.chu@intel.com>
Reviewed-by: 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: Star Zeng <star.zeng@intel.com>
https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Capsule-
on-Disk-Introducation
This module provides PPI to load Capsule On Disk temp relocation file
from Root Directory file system, retrieve the capsules from the temp
file and create capsule hobs for these capsules.
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>
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>
https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Capsule-
on-Disk-Introducation
If Capsule On Disk mode, call Capsule On Disk Load PPI to load
capsules. When it fails, still goes to Firmware Update boot path.
BDS will clear corresponding indicator and reboot later on.
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>
https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Capsule-
on-Disk-Introducation
Introduce PcdCapsuleInRamSupport to turn on/off Capsule In Ram feature.
Platform could choose to drop CapsulePei/CapsuleX64 and not to support
Capsule In Ram.
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>
https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Capsule-
on-Disk-Introducation
Set EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED bit of
"OsIndicationsSupported" variable to indicate the Capsule On
Disk is supported or not, according to PcdCapsuleOnDiskSupport.
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>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1840
1. Add missing '\n' in usage.
2. Fix the dead loop of CapsuleApp -L.
3. Fix the bug that CapsuleApp -OD cannot perform capsules in sub-
folder.
4. Optimize the handling for option -NR and -OD to support both
'CapsuleApp <Capsule> -OD -NR' and 'CapsuleApp <Capsule> -NR -OD'.
5. Check if Capsule-On-Disk is supported by "OsIndicationsSupported"
variable firstly before processing capsules. If not supported, prompt
an error message and quit the process.
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
This patch will add Capsule On Disk related definition, including
GUID, PPI and PCDs:
The Capsule On Disk Name GUID indicates the capsule is to store
Capsule On Disk file names.
The Pei Capsule On Disk PPI provides service to retrieve capsules
from Capsule On Disk temp relocation file on mass storage devices
and create capsule hob for these capsules.
Pei Boot In CapsuleOnDisk Mode Ppi indicates current boot mode is
capsule on disk mode.
PcdCapsuleOnDiskSupport is used to enable/disable Capsule On Disk.
PcdCapsuleInRamSupport is used to enable/disable Capsule In Ram.
PcdCoDRelocationFileName specifies the Capsule On Disk temp
relocation file name.
PcdCodRelocationDevPath specifies platform specific device to store
Capsule On Disk temp relocation file.
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=1857
Add the missing instances to the [Components] of dsc file
for build only.
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 A Wu <hao.a.wu@intel.com>
SERIAL_DXE_FILE_GUID is used in different places, create a single
define that other can use. Also fix SerialDxe to actually use
EDKII_SERIAL_PORT_LIB_VENDOR_GUID in the device path instead of the
FILE_GUID.
Suggested-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Message-Id: <20190606131459.1464-2-anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1412
Original logic:
Connect the graphics device -> connect it as graphics consoles
and initialize its parameters(Mode = -1, invalid) -> connect it
as console spliter and add the device to the list(use SetMode to
set mode to the user defined mode or the best mode the devices
supported if the mode is invalid. *clear the screen at this phase*)
Changed logic:
Connect the graphics device -> connect it as graphics consoles
and initialize its parameters(initialize the mode to the user
defined mode or the best mode. *directly set the mode value without
using SetMode, that would not clear the screen) -> connect it as
console spliter and add the device to the list(use SetMode to set
mode to the user defined mode or the best mode the devices supported
if the mode is invalid. *now the mode is already set, so it would
not clear the screen*).
Also remove the section of SetMode for debug version.
Impact: as the text mode may not be an invalid value, the SetMode
may have no chance to be called during reconnect the graphics device.
That means the screen may not be cleaned after finishing reconnect
operation. There is one common condition: shell command "recoonect -r".
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>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1412
For Console Out device, it would always set all present devices'
text out mode again through ConSplitterTextOutSetMode while adding
devices. That may cause the screen cleared for serval times.
So add a BOOLEAN to judge if it is adding device then we will not
set the same text mode again for same console out device.
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 A Wu <hao.a.wu@intel.com>
When assigning a physical PCIe device to a QEMU/KVM guest, PciBusDxe may
find that the extended config space is not (fully) implemented. In
LocatePciExpressCapabilityRegBlock(), "CapabilityEntry" may be read as
0xFFFF_FFFF at a given config space offset, after which the loop gets
stuck spinning on offset 0xFFC (the read at offset 0xFFC returns
0xFFFF_FFFF most likely as well).
Another scenario (not related to virtualization) for triggering the above
is when a Conventional PCI bus -- exposed by a PCIe-to-PCI bridge in the
topology -- intervenes between a PCI Express Root Port and a PCI Express
Endpoint. The Conventional PCI bus limits the accessible config space of
the PCI Express Endpoint, even though the endpoint advertizes the PCI
Express capability. Here's a diagram, courtesy of Alex Williamson:
[PCIe Root Port]--[PCIe-to-PCI]--[PCI-to-PCIe]--[PCIe EP]
->| |<- Conventional PCI bus
Catch reads of 0xFFFF_FFFF in LocatePciExpressCapabilityRegBlock(), and
break out of the scan with a warning message. The function will return
EFI_NOT_FOUND.
Cc: Alex Williamson <alex.williamson@redhat.com>
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: Star Zeng <star.zeng@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
This reverts commit 7cea4d71a8.
Said commit was not suitable for pushing during the edk2-stable201905 hard
feature freeze; it was pushed only by mistake. The subject line referenced
EmulatorPkg, but the patch changed MdeModulePkg/UiApp, regressing the
display of the CPU speed from SMBIOS in multiple platforms.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
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>
Cc: Star Zeng <star.zeng@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1877
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1686
The bug reporter wish to display nothing as the CPU is virtual
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1862
Current implementation of function AhciModeInitialization() has an
incorrect assumption that the value in the CAP (offset 00h) register will
always be greater than the highest bit set for the value in the PI (offset
0Ch) register.
This will lead to an issue that hard disk devices may not be found in the
non-S3 boot path for some AHCI controller capabilities.
More specifically, variable 'PortInitializeBitMap' will have the value
from 'Private->PortBitMap', which will be 0xFFFFFFFF in non-S3 boot path.
When the CAP register is of value 0x1 and PI register with value 0x4
(meaning port 2 is available), the current logic will only enumerate port
0. And the device attached behind port 2 will not be enumerated.
To address this issue, variable 'PortInitializeBitMap' will now take the
bitwise and result between 'Private->PortBitMap' and the value read from
the PI register.
Please note that there will be no function impact for S3 path, since in
this case, the bits being set in 'Private->PortBitMap' will be a subset
of the bits being set in the PI register. Their bitwise and operation will
still be the value of 'Private->PortBitMap'.
Cc: Maggie Chu <maggie.chu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Laszlo Ersek
Pete Batard
Liming Gao
Leif Lindholm
Chasel Chiu
Zurcher, Christopher J
Albecki, Mateusz
Gao, Zhichao
Gris87
Dandan Bi
Vitaly Cheptsov via Groups.Io
Shenglei Zhang
Ray Ni
Mike Turner
Xu, Wei6
Jin, Eric
Marcin Wojtas
Michael D Kinney
GregX Yeh
Star Zeng
Javeed, Ashraf
Bret Barkelew
Maggie Chu
Zhang, Chao B
Anthony PERARD
Aaron Antone
Zhiguang Liu
Hao A Wu