REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2844
Update Reclaim() to return the error status from the reclaim
operation and not the status of SynchronizeRuntimeVariableCache()
that can be EFI_SUCCESS even through the status from reclaim
is an error. Without this change, the return status from
SetVariable() can be EFI_SUCCESS even though the variable was
not actually set. This occurs if the variable store is full
and a Reclaim() is invoked to free up space and even after all
possible space is freed, there is still not enough room for
the variable being set. This condition should return
EFI_OUT_OF_RESOURCES.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2786
In order to support enable/disable report status code through memory
or serial dynamic, change the following PCDs from [PcdsFeatureFlag] to
[PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]:
PcdStatusCodeUseSerial
PcdStatusCodeUseMemory
The original plaforms can use PcdsFixedAtBuild in .dsc files to save size.
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Ming Tan <ming.tan@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2701
Recording to the spec, the reconnect is activated upon exiting of the
formset or the browser. Exiting is by user but form-browser internal
logic. That means the reconnection is only happened when user press
ESC or _EXIT action to exit form.
Driver callback may update HII form dynamically so form-browser needs
to refresh its internal data. It's not exiting formset for user
exactly and they didn't know what happened. So use a flag to record
that and do not reconnect driver if updated by callback.
Signed-off-by: Walon Li <walon.li@hpe.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Its been observed that in MenuManagerMenuApp when user
selects a different BootOption using Up/Down key, the
current Cursor position is not chaning.
Still points to the old BootOption.
This changes first dispalys/redraws the old BootOption
followed by new BootOption. Doing so will make current
cursor pointing to the user selected BootOption.
Signed-off-by: Abdul Lateef Attar <abdul@marvell.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
UEFI boot options may exist but have the LOAD_OPTION_ACTIVE flag
cleared. This means that the boot option should not be selected
by default, but it does not mean it should be omitted from the
boot selection presented by the boot manager: for this purpose,
another flag LOAD_OPTION_HIDDEN exists.
Given that the latter flag exists solely for the purpose of omitting
boot options from the boot selection menu, and LOAD_OPTION_XXX flags
can be combined if desired, hiding inactive boot options as well is
a mistake, and violates the intent of paragraph 3.1.3 of the UEFI
specification (revision 2.8 errata A). Let's fix this by dropping
the LOAD_OPTION_ACTIVE check from the code that populates the boot
selection menu.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Add bitmask to structure which gives a binary-inspectable mechanism to
determine if a capsule contains an authentication section or depex section.
(UEFI 2.8 errata a, mantis 2026)
Signed-off-by: Oleksiy Yakovlev <oleksiyy@ami.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
OnigurumaIntrinsics.c is now not used. So the implement of function
'memcpy' is now not., which causes build failure with CLANG9 and
XCODE. I remove OnigurumaIntrinsics.c and move the necessary function
implement to OnigurumaUefiPort.c/h.
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>
The MM communicate 2 protocol was introduced to factor out the mismatch
between traditional MM, which requires the physical address of the MM
buffer to be passed, and standalone MM, which copies the MM communicate
buffer data into a separate buffer, requiring the virtual address. For
this reason, MM communicate 2 carries both addresses, allowing the
implementation to decide which address it needs.
This hides this implementation detail from the callers of the protocol,
which simply passes both addresses without having to reason about what the
implementation of the protocol actually needs.
Note that the old version of the protocol is retained, in order to support
existing implementations that don't require this flexibility.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
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>
Set the default value of PcdAcpiExposedTableVersions for Aarch64
platforms to 0x20. Previously, the default was set to 0x3E for all
platforms. The new value removes ACPI 1.0b compatability, which forces
the use of XSDT 64-bit pointer, as required by Arm SBBR specification.
This also resolves an error reported by acpiview command, as seen on
the RPi (see https://github.com/pftf/RPi4/issues/25).
Signed-off-by: Samer El-Haj-Mahmoud <samer@elhajmahmoud.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2665
ReportDispatcher() is called by a software module to report a status code.
The interface is generic and can be called frequently throughout the boot
under various conditions. A certain set of conditions can cause the
currently implemented algorithm for resource exhaustion to fail. A sample
scenario:
1. ReportStatusCode() is called at a TPL higher than one of the registered
status code listeners making the call to the listener deferred until
TPL is lowered.
2. Additional calls to ReportStatusCode() occur, so the data buffer
continues to expand.
3. A call to ReportStatusCode() is made from within a memory allocation
call (e.g. CoreAllocatePoolPages ()) which is protected from re-
entrancy with mPoolMemoryLock. This will cause the ReallocatePool()
call in ReportDispatcher() to fail. Because the end pointer was already
moved to account for the data size, the end pointer is now moved
beyond the buffer and invalid.
This commit saves the original end pointer value into a local variable
called "FailSafeEndPointer" which tracks a safe end pointer to revert to
in the case the allocated buffer size (CallbackEntry->EndPointer -
CallbackEntry->StatusCodeDataBuffer) is still not large enough for the
data.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Kun Qin <Kun.Qin@microsoft.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
NonDiscoverablePciDeviceDxe currently #defines the module-internal
PCI_MAX_BARS macro, with value 6 (and type "int").
Remove this private macro definition, and adopt PCI_MAX_BAR from
"MdePkg/Include/IndustryStandard/Pci22.h". Both the value and the type
remain unchanged (the standard PCI_MAX_BAR macro expands to 0x0006).
"NonDiscoverablePciDeviceIo.h" gets the definition of PCI_MAX_BAR via its
existent #include <IndustryStandard/Pci.h> directive.
Build-tested only.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200409113017.18233-1-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2062
This commit makes the behavior for PeiGetVariable() match the following
specification-defined behavior. It is now consistent with the DXE/SMM
variable driver implementation.
The UEFI specification v2.8 Errata A Section 8.2 "GetVariable()"
"Attributes" parameter description states:
"If not NULL, a pointer to the memory location to return the
attributes bitmask for the variable. See 'Related Definitions.'
If not NULL, then Attributes is set on output both when
EFI_SUCCESS and when EFI_BUFFER_TOO_SMALL is returned."
The attributes were previously only returned from the implementation
in Variable.c on EFI_SUCCESS. They are now returned on EFI_SUCCESS or
EFI_BUFFER_TOO_SMALL according to spec.
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Guomin Jiang <guomin.jiang@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2062
The UEFI specification v2.8 Errata A Section 8.2 "GetVariable()"
"Attributes" parameter description states:
"If not NULL, a pointer to the memory location to return the
attributes bitmask for the variable. See 'Related Definitions.'
If not NULL, then Attributes is set on output both when
EFI_SUCCESS and when EFI_BUFFER_TOO_SMALL is returned."
The attributes were previously only returned from the implementation
in Variable.c on EFI_SUCCESS. They are now returned on EFI_SUCCESS or
EFI_BUFFER_TOO_SMALL according to spec.
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Guomin Jiang <guomin.jiang@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
From the function description of GetIfrBinaryData(), FormSetGuid can be
NULL. However, FormSetGuid is passed to IsZeroGuid(). This causes exception
when FormSetGuid is NULL.
Signed-off-by: Nickle Wang <nickle.wang@hpe.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
ASSERT in PollMem_Conf, CopyMem_Conf, SetBarAttributes_Conf
Conformance Test.
SCT Test expect return as Invalid Parameter or Unsupported.
Added Checks for Function Parameters.
return Invalid or Unsupported if Check fails.
Added Checks in PciIoPollIo(), PciIoIoRead()
PciIoIoWrite()
Signed-off-by: Gaurav Jain <gaurav.jain@nxp.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
SdMmcPciHcDxe driver used to read response only after
command and data transfer completed. According to SDHCI
specification response data is ready after the command
complete status is set by the host controller. Getting
the response data early will help debugging the cases
when command completed but data transfer timed out.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Marcin Wojtas <mw@semihalf.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Tested-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
To allow for easier debug of failing commands we
have added a capability to print TRB and command
packet when we start execution of the TRB(on
DEBUG_VERBOSE level) and when the TRB failed to
execute correctly(on DEBUG_ERROR level). Additionally
we will also print error interrupt status and interrupt
status register on failed SD command.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Marcin Wojtas <mw@semihalf.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Tested-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
EDK2's implementation of the LoadImage() boot service permits non-native
binaries to be loaded (i.e., X64 images on IA32 firmware), but any
attempts to start such an image using StartImage() will return
EFI_UNSUPPORTED.
The integration of the PE/COFF emulator protocol into the DXE core
deviates slightly from this paradigm, given that its IsImageSupported
hook as well as its RegisterImage hook are invoked from LoadImage,
and by the time StartImage is called, no opportunity is given to the
provider of the PE/COFF emulator protocol to prevent an image from
being started if it only supports loading it.
To address this disparity, let's move the invocation of RegisterImage()
to the implementation of the StartImage() boot service, allowing the
emulator to permit LoadImage() but reject StartImage() on images that
turn out not to meet the requirements of the emulator as it is being
started.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Liming Gao <liming.gao@intel.com>
