The format specifier for the LoadOptions field of the LoadedImage protocol
is "%s". However, the data in LoadOptions is often generic binary data. A
format specifier of "%x" is more appropriate for this field.
Using "dh -v" with format specifier "%s" on BIOS images based on EDK II
source before commit 891d844 can cause a crash.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
The original logic assumes GOP hande is son of PCI handle but it
is not always true.
Below wordings are from UEFI Spec:
If a graphics device supports multiple frame buffers, then
handles for the frame buffers must be created first, and then the
handles for the video output devices can be created as children of
the frame buffer handles.
So the GOP handle could be grandson of the PCI handle.
EfiBootManagerGetGopDevicePath(VideoController) is used to fix
this bug.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
v2: Handle error case in SockCreateChild and fix typo issue
when we destroy the socket Sock and its associated
protocol control block, we need to first close the
parent protocol, then remove the protocol from childHandle
and last to free any data structures that allocated in
CreateChild. But currently, we free the socket data (Socket ConfigureState)
before removing the protocol form the childhandle. So if the up layer
perform the driverbing stop to abort tcp session and send the tcp reset
packet, it will failed.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo <lubo.zhang@intel.com>
Cc: Wu Jiaxin <jiaxin.wu@intel.com>
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
v2: Handle error case in SockCreateChild and fix typo issue
when we destroy the socket Sock and its associated
protocol control block, we need to first close the
parent protocol, then remove the protocol from childHandle
and last to free any data structures that allocated in
CreateChild. But currently, we free the socket data
(Socket ConfigureState) before removing the protocol
form the childhandle. So if the up layer want to send the
tcp reset packet in it's driver binding stop function, it will failed.
The IpInstance destroy state is redundant and may cause
ip transmit failed if up layer want to send ip packet.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo <lubo.zhang@intel.com>
Cc: Wu Jiaxin <jiaxin.wu@intel.com>
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
Http boot on X64 platform is faild, this is caused by the incorrect
type conversion when getting port number from Url.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo <lubo.zhang@intel.com>
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Cc: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
v2:
* Add the check in Ip4Config2SetDefaultIf to avoid the DHCP configuration
case.
Ip4config2 doesn't check the validity of Ip/Netmask pair, which
leads to the invalid combination of Ip and Netmask setting.
This patch is to resolve the issue.
Cc: Hegde Nagaraj P <nagaraj-p.hegde@hpe.com>
Cc: Subramanian Sriram <sriram-s@hpe.com>
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Sriram Subramanian <sriram-s@hpe.com>
Reviewed-by: Hegde Nagaraj P <nagaraj-p.hegde@hpe.com>
Since qemu v2.7.0, the pkgversion appears to have a bug:
$ ./configure --target-list=x86_64-softmmu --with-pkgversion=foo
Results in this output:
$ x86_64-softmmu/qemu-system-x86_64 -version
QEMU emulator version 2.8.90(foo)
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
This appears to have been introduced in:
67a1de0d19 Makefile: Derive "PKGVERSION" from "git describe" by default
The previous commit (077de81a4c) produces this output:
$ x86_64-softmmu/qemu-system-x86_64 -version
QEMU emulator version 2.6.50 (foo), Copyright (c) 2003-2008 Fabrice Bellard
Now the OvmfPkg/build.sh script uses grep with '-o' to return only the
matched text.
grep -E is also used with a simple regex to extract only the digits of
the version.
qemu-bug: https://bugs.launchpad.net/bugs/1673373
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Raise exception for invalid BSF option in GenCfgOpt.py
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Richard Thomaiyar <richard.marian.thomaiyar@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
The previous patch has problem on handling capsule
request at runtime.
This patch fixed the issue.
Cc: Chao Zhang <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Chao Zhang <chao.b.zhang@intel.com>
Current PI spec has no clear description about whether the
SkuId could be changed multiple times or not during one boot.
If the SkuId could be changed multiple times during one boot,
different modules may get inconsistent PCD values.
And DynamicHii PCD maps to UEFI variable, once one DynamicHii
PCD(UEFI variable) is set for one SkuId, then the PCD value
will be always from UEFI variable but not PCD database, even
the SkuId is set to other value.
This patch is to update PCD drivers to allow SkuId to be
changed only once during one boot.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Commit e7b24ec978 ("ArmPkg/UncachedMemoryAllocationLib: map uncached
allocations non-executable") adds code that manipulates the GCD memory
space attributes of a newly allocated uncached region without checking
whether this region expose these attributes in its capabilities mask.
Given that the intent is to remove executable permissions from the region,
this is a fairly pointless exercise to begin with, regardless of whether
it is correct or not. The reason is that RO/XP memory attributes in the
GCD memory space map or the UEFI memory map are completely disconnected
from the actual mapping permissions used in the page tables.
So instead, invoke the CPU arch protocol directly, and add the non-exec
attributes in the page tables directly.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Tested-by: Ryan Harkin <ryan.harkin@linaro.org>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=370
Use GLOBAL_REMOVE_IF_UNREFERENCED for some memory profile global variables,
then their symbols could be removed when memory profile is disabled.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=370
Use GLOBAL_REMOVE_IF_UNREFERENCED for some SMRAM profile global variables,
then their symbols could be removed when SMRAM profile is disabled.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Since we use the Attempt and index as the attempt variable name instead of
the MAC address plus index, we need to update this to check the whether
the Controller handle is configured to use DNS protocol
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo <lubo.zhang@intel.com>
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Cc: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
Network interface type should be checked before the conversion between
text device path node and MAC device path. Otherwise, the MAC text string
can't be converted to the representation of a device node, which leads to
the series failure of network HII configuration(e.g. IP, VLAN, HTTP Boot
configuration in Network Device List).
Cc: Liming Gao <liming.gao@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Drop the explicit S3SaveState protocol and opcode management; instead,
create ACPI S3 Boot Script opcodes for the WRITE_POINTER commands with
QemuFwCfgS3Lib functions.
In this case, we have a dynamically allocated Context structure, hence the
patch demonstrates how the FW_CFG_BOOT_SCRIPT_CALLBACK_FUNCTION takes
ownership of Context.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
We cannot entirely eliminate the manual boot script building in this
driver, as it also programs lower-level chipset registers (SMI_EN,
GEN_PMCON_1) at S3 resume, not just registers exposed via fw_cfg.
We can nonetheless replace the manually built opcodes for the latter class
of registers with QemuFwCfgS3Lib function calls. We preserve the ordering
between the two sets of registers (low-level chipset first, fw_cfg
second).
This patch demonstrates that manual handling of S3SaveState protocol
installation can be combined with QemuFwCfgS3Lib, even without upsetting
the original order between boot script fragments. An S3SaveState notify
function running at TPL_CALLBACK can safely queue another S3SaveState
notify function at TPL_CALLBACK with QemuFwCfgS3CallWhenBootScriptReady().
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
In the DXE fw_cfg instance:
- QemuFwCfgS3Enabled() queries S3 enablement via fw_cfg. This behavior is
shared with the PEI fw_cfg instance, and the DXE fw_cfg instance already
pulls in the function from "QemuFwCfgS3PeiDxe.c".
- If QemuFwCfgS3Enabled() returns TRUE, the client module is permitted to
call QemuFwCfgS3CallWhenBootScriptReady().
We provide a fully functional implementation for
QemuFwCfgS3CallWhenBootScriptReady(). A protocol notify is installed at
TPL_CALLBACK for EFI_S3_SAVE_STATE_PROTOCOL. If / once the protocol is
available, the client module's Callback() function is called, which is
expected to produce ACPI S3 Boot Script opcodes using the helper
functions listed below. In QemuFwCfgS3CallWhenBootScriptReady(), we also
allocate a reserved memory buffer, sized & typed by the client module,
for the opcodes and (internally) the fw_cfg DMA operations to work upon,
during S3 resume.
This behavior is unique to the DXE fw_cfg instance. Thus, add the
function to "QemuFwCfgS3Dxe.c".
- The QemuFwCfgS3ScriptWriteBytes(), QemuFwCfgS3ScriptReadBytes(),
QemuFwCfgS3ScriptSkipBytes(), and QemuFwCfgS3ScriptCheckValue()
functions are also implemented usefully, since the client module's
Callback() function is expected to invoke them.
Each of the first three functions produces MEM_WRITE, IO_WRITE, and
MEM_POLL opcodes, to set up the DMA command in reserved memory, to start
the DMA transfer, and to check the DMA result, respectively.
The QemuFwCfgS3ScriptCheckValue() function produces a MEM_POLL opcode to
validate an unsigned integer field in data that was read via
QemuFwCfgS3ScriptReadBytes().
This behavior is again unique to the DXE fw_cfg instance, so add the
functions to "QemuFwCfgS3Dxe.c".
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
In the PEI fw_cfg instance:
- QemuFwCfgS3Enabled() queries S3 enablement via fw_cfg. This behavior is
shared with the DXE fw_cfg instance, and the PEI fw_cfg instance already
pulls in the function from "QemuFwCfgS3PeiDxe.c".
- If QemuFwCfgS3Enabled() returns TRUE, the client module is permitted to
call QemuFwCfgS3CallWhenBootScriptReady(). However, in the PEI phase we
have no support for capturing ACPI S3 Boot Script opcodes, hence we
return RETURN_UNSUPPORTED unconditionally. This behavior is unique to
the PEI fw_cfg instance, so add the function to "QemuFwCfgS3Pei.c".
- Consequently, the QemuFwCfgS3ScriptWriteBytes(),
QemuFwCfgS3ScriptReadBytes(), QemuFwCfgS3ScriptSkipBytes(), and
QemuFwCfgS3ScriptCheckValue() functions must never be called. (They
could only be called from the client module's callback, but
QemuFwCfgS3CallWhenBootScriptReady() will never install such callback in
the PEI fw_cfg instance -- see above.)
This behavior is not unique to the PEI fw_cfg instance (it is shared
with the Base Null instance), so pull in these functions from
"QemuFwCfgS3BasePei.c".
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
In the Base Null instance:
- QemuFwCfgS3Enabled() returns constant FALSE. This is unique to the Base
Null instance, and the function is already present in
"QemuFwCfgS3Base.c".
- The QemuFwCfgS3CallWhenBootScriptReady() function must never be called
(according to the documentation, given the above). This is also unique
to the Base Null instance, so implement the function in
"QemuFwCfgS3Base.c".
- Consequently, the QemuFwCfgS3ScriptWriteBytes(),
QemuFwCfgS3ScriptReadBytes(), QemuFwCfgS3ScriptSkipBytes(), and
QemuFwCfgS3ScriptCheckValue() functions must never be called either.
This behavior is not unique to the Base Null instance (it will be shared
with the PEI fw_cfg instance), so add these functions to
"QemuFwCfgS3BasePei.c".
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Introduce the following APIs:
- QemuFwCfgS3CallWhenBootScriptReady(): central function that registers a
callback function, with a context parameter, for when ACPI S3 Boot
Script opcodes can be produced. This function also allocates reserved
memory for the opcodes to operate upon.
The client module is supposed to produce the boot script fragment in the
callback function.
- QemuFwCfgS3ScriptWriteBytes(), QemuFwCfgS3ScriptReadBytes(),
QemuFwCfgS3ScriptSkipBytes(), QemuFwCfgS3ScriptCheckValue(): helper
functions, available only to the above callback function, for composing
the boot script fragment. QemuFwCfgS3ScriptSkipBytes() can double as a
plain "select" whenever necessary.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
At this point we're ready to retire QemuFwCfgS3Enabled() from the
QemuFwCfgLib class, together with its implementations in:
- ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
- OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
Extend all modules that call the function with a new QemuFwCfgS3Lib class
dependency. Thanks to the previously added library class, instances, and
class resolutions, we can do this switch now as tightly as possible.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
QemuFwCfgS3Enabled() in "OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c"
queries the "etc/system-states" fw_cfg file.
The same implementation is now available factored-out in
"OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3PeiDxe.c". It is available to
PEIMs through the PeiQemuFwCfgS3LibFwCfg instance, and to DXE_DRIVER and
DXE_RUNTIME_DRIVER modules through the DxeQemuFwCfgS3LibFwCfg instance.
Resolve QemuFwCfgS3Lib accordingly.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
QemuFwCfgS3Enabled() in "ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c"
returns constant FALSE.
The same implementation is now available factored-out in
"OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3Base.c".
Resolve QemuFwCfgS3Lib to BaseQemuFwCfgS3LibNull.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
This patch introduces PeiQemuFwCfgS3LibFwCfg, a limited functionality
QemuFwCfgS3Lib instance, for PEI phase modules.
The patch also introduces DxeQemuFwCfgS3LibFwCfg, a full functionality
QemuFwCfgS3Lib instance, for DXE_DRIVER and DXE_RUNTIME_DRIVER modules.
These library instances share the QemuFwCfgS3Enabled() function. The
function actually uses fw_cfg; the implementation is copied from
"OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c".
The library instances will diverge in the following patches.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This library instance returns constant FALSE from QemuFwCfgS3Enabled(),
and all other library functions trigger assertion failures. It is suitable
for QEMU targets and machine types that never enable S3.
The QemuFwCfgS3Enabled() implementation is copied from
"ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c". Stubs for further
QemuFwCfgS3Lib APIs (with assertion failures, see above) will be added
later.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This library class will enable driver modules (a) to query whether S3
support was enabled on the QEMU command line, (b) to produce fw_cfg DMA
operations that are to be replayed at S3 resume time.
Declare the library class in OvmfPkg/OvmfPkg.dec, and add the library
class header under OvmfPkg/Include/Library/. At the moment, the only API
we expose is QemuFwCfgS3Enabled(), which we'll first migrate from
QemuFwCfgLib. Further interfaces will be added in later patches.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Suggested-by: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The recently introduced memory protection features inadvertently broke
the boot on all PrePi platforms, because the changes to explicitly use
EfiBootServicesCode for loading the DxeCore PE/COFF image need to be
applied in a different way for PrePi. So add a simple helper function
that sets the type of an allocation to EfiBootServicesCode, and invoke
it to allocate the space for DxeCore.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Michael Zimmermann <sigmaepsilon92@gmail.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
UPT used to use "B:" as the temp directory which may cause conflict,
now it will choose a valid volume. Also UPT now accepts empty sections.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hess Chen <hesheng.chen@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
modsi3.S references the symbol '__divsi3' by '___divsi3' which assumes
the prefix is always required and supported. Use ASM_PFX() instead
to support all compilers.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser <Marvin.Haeuser@outlook.com>
At worst case, OCR register may always not set BIT31. It will cause
original code enter to dead loop. Adding a break for such case.
Cc: Hao Wu <hao.a.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Feng Tian <feng.tian@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
The reason is that we observe that a platform may use same Handler
for different context.
In order to support Unregister such handler, we have to input
context information as well.
Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
The reason is that we observe that a platform may use same Handler
for different context.
In order to support Unregister such handler, we have to input
context information as well.
Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
The reason is that we observe that a platform may use same Handler
for different context.
In order to support Unregister such handler, we have to input
context information as well.
Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
The commit refines the comment description for EFI_PRINT2S_PROTOCOL
service ASCII_VALUE_TO_STRING_S.
This service will not ASSERT when the input/output parameter 'Buffer' is
not aligned on a 16-bit boundary.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
The commit refines the comment description for PrintLib API
AsciiValueToStringS.
This API will not ASSERT when the input/output parameter 'Buffer' is not
aligned on a 16-bit boundary.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
The commit refines the comment description for PrintLib API
AsciiValueToStringS.
This API will not ASSERT when the input/output parameter 'Buffer' is not
aligned on a 16-bit boundary.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Ruiyu Ni
Jeff Westfahl
Zhang Lubo
Jiaxin Wu
Dandan Bi
Jordan Justen
Thomaiyar, Richard Marian
Jiewen Yao
Star Zeng
Ard Biesheuvel
Laszlo Ersek
Hess Chen
Marvin Häuser
Feng Tian
Hao Wu