https://bugzilla.tianocore.org/show_bug.cgi?id=201
In V3, Use Odt to replace ODT, Cke to replace CKE, Id to replace ID,
and Cl to replace CL in structure field name.
In V2, separate DDR3, DDR4 and LPDDR definition into the different files;
use the different SPD prefix as structure definitions for each SPD type.
Cc: Giri P Mudusuru <giri.p.mudusuru@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
VM related defs are now in EbcVmTest.h, and opocode related definitions in
Ebc.h.
Because it is used by both the EBC Debugger and driver,
EbcDebugSignalException() sees its definition factorized in
EbcDebuggerHook.h.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=239
When the input path for API PathRemoveLastItem() is a root path like
'fs0:\', the API will return TRUE (indicating a directory or file was
removed from the path) and modifies the path to 'fs0:'. In fact, there's
no directory or file removed in the above case.
This commit adds additional check to resolve this issue and modifies the
API's description to make it more straightforward.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
The SpinLock functions in the SynchronicationLib use volatile
parameters to keep compiler from optimizing these functions
too much. The volatile keyword is missing from the Interlocked*()
functions in this same library class. Update the library class
to consistently use volatile on all functions in this class.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Jeff Fan <jeff.fan@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kinney@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
If the FvImage buffer is not at its required alignment, then ASSERT().
Also update the function header description of BuildFv(2)Hob()
correspondingly.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=205
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@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>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=181
Add size check for 8-bit, 16-bit, and 32-bit enums
to make sure they follow the UEFI Specification 2.3.1
Data Types.
<Enumerated Type>
Element of a standard ANSI C enum type declaration.
Type INT32.or UINT32. ANSI C does not define the
size of sign of an enum so they should never be
used in structures. ANSI C integer promotion rules
make INT32 or UINT32 interchangeable when passed as
an argument to a function.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=180
The PCI_SEGMENT_LIB_ADDRESS() macro puts the Segment number
into bits 32..47 of the logical address that is returned.
The portable method to put Segment in this bit range is to
use LShitU64(). For 64-bit CPUs, this is optimized well
by the compiler. For 32-bit CPUs, a call to LSHiftU64()
is included in the generated binaries. However, if the
Segment parameter is 0, then no shift is required. Add
a check for Segment set to 0 and provide an optimized
macro implementation that does not call LShiftU64().
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Several modules use ARRAY_SIZE() already; centralize the definition. (The
module-specific macro definitions are guarded by #ifndef directives at
this point.)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Cecil Sheng <cecil.sheng@hpe.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Daryl McDaniel <edk2-lists@mc2research.org>
Cc: David Wei <david.wei@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Gary Lin <glin@suse.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Tim He <tim.he@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
ASSERT_EFI_ERROR() cannot be used in BASE type modules because
- the replacement text calls EFI_ERROR(),
- EFI_ERROR() is defined in "MdePkg/Include/Uefi/UefiBaseType.h",
- the inclusion of "UefiBaseType.h" is not required for BASE type modules.
While
ASSERT (!RETURN_ERROR (StatusParameter))
would be a functional statement in BASE type modules, it would be less
convenient and less informative: ASSERT_EFI_ERROR() prints the actual
StatusParameter.
Hence add ASSERT_RETURN_ERROR(), paralleling ASSERT_EFI_ERROR(). Copy the
original macro definition and update it as follows:
- replace EFI with RETURN,
- wrap overlong lines in the comment block and in the code,
- EFI_D_ERROR is deprecated, so employ DEBUG_ERROR instead.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=166
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # RVCT
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Move Shell/ShellDynamicCommand/ShellParameters definitions from
ShellPkg to MdePkg.
The following patches will rename the header file name.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Correct the typos in some header files of MdePkg.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
HiiImage.h uses EFI_GRAPHICS_OUTPUT_BLT_PIXEL which is defined in
GraphicsOutput.h. Include GraphicsOutput.h to avoid build failure
from consumer of HiiImage protocol.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Liming Gao <liming.gao@intel.com>
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Besides adding the missing structure
EFI_HII_IMAGE_DECODER_OTHER_INFO, the patch also correct some typo.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Rename the protocol header file to follow EDKII file
name rule before the HiiImageDecoder protocol is used
by anyone.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Add the implementation of API IsZeroBuffer() via C language for the
following library instances:
BaseMemoryLib
PeiMemoryLib
UefiMemoryLib
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
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 RVCT compiler in --gnu mode appears to simply strip of the __builtin
prefix when it encounters calls to __builtin_xxx() functions, and so
the __builtin_unreachable() we emit for GCC results in linker errors
regarding undefined references against 'unreachable()'.
So define UNREACHABLE() to a NOP instead.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
In latest UEFI2.6 spec, the type of the fourth parameter in function
GetImageInfo() is "EFI_IMAGE_OUTPUT", but in the header file, it is
"EFI_IMAGE_INPUT". Now correct it to follow the spec.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Cecil Sheng <cecil.sheng@hpe.com>
Cc: Abner Chang <abner.chang@hpe.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
This adds support for GCC 5.x in LTO mode for IA32, X64, ARM and
AARCH64. Due to the fact that the GCC project switched to a new
numbering scheme where the first digit is now incremented for every
major release, the new toolchain is simply called 'GCC5', and is
intended to support all GCC v5.x releases.
Since IA32 and X64 enable compiler optimizations (-Os) for both DEBUG
and RELEASE builds, LTO support is equally enabled for both targets.
On ARM and AARCH64, DEBUG builds are not optimized, and so the LTO
optimizations are only enabled for RELEASE.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
When using GCC to build for X64, we switched to the position independent
small code model, which is much more efficient in terms of code generation
and runtime relocation footprint, and produces binaries that can execute
correctly from any offset.
However, the PIC routines are by default geared towards hosted binaries
containing symbol references that may resolve to definitions in other
dynamic objects, and for this reason, most symbol references are indirected
via a GOT entry (which also results in a .reloc fixup entry) unless we
annotate them.
For this reason, we introduced the 'protected' visibility annotation for
all symbol definitions and references, by setting the GCC visibility
pragma. However, as it turns out, this is not sufficient for all versions
of GCC, and in some cases (GCC 5.x using the GCC49 toolchain tag), may
still result in GOT based relocations.
So switch to 'hidden' visibility instead, which is slightly stronger, and
fixes this issue for the versions of GCC that exhibit the problem.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
When building position independent (PIC) ELF objects, the GCC compiler
assumes that each symbol with external linkage may potentially end up
being exported from a shared library, which means that each of those
symbols may be subject to symbol preemption, i.e., the executable
linking to the shared library at runtime may override symbols exported
by the shared library, and every internal reference held by the shared
library itself *must* be made to point to the overridden version instead.
For this reason, PIC code symbol references always go via the Global
Offset Table (GOT), even if the code in question references symbols that
are defined in the same compilation unit. The GOT refers to each symbol
by absolute address, and so each entry is subject to runtime relocation.
Since not every symbol with external linkage is ultimately exported from
a shared library, the GCC compiler allows control over symbol visibility
using attributes, command line arguments and pragmas, where 'protected'
means that the symbol is only referenced by the shared library itself.
Due to the poor hygiene in EDK2 regarding the use of the 'static'
modifier, many symbols that are local to their compilation unit end up
being referenced indirectly via the GOT when building PIC code.
In UEFI, there are no shared libraries and so there is no need to deal
with symbol preemption, and we can mark every symbol reference protected.
The only method that applies to all symbol definitions as well as
declarations is the #pragma. So set the visibility 'protected' pragma when
building PIC code for X64 using GCC. Note that this affects code generated
with the -fpie compiler switch as well as the -fpic compiler switch.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Tested-By: Liming Gao <liming.gao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
This is never set anymore, so unsetting it or testing whether it is unset
no longer makes any sense.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Tested-By: Liming Gao <liming.gao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Both GCC and LLVM 3.8 64bits support new variable argument (VA)
intrinsics for Microsoft ABI, enable these new VA intrinsics for
GNUC family 64bits code build. These VA intrinsics are only
permitted use in 64bits code, so not use them in 32bits code build.
The original 32bits GNU VA intrinsics has the same calling convention
as MS, so we don't need change them.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Steven Shi <steven.shi@intel.com>
[ardb: update CPP logic so that the change only applies to X64]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Tested-By: Liming Gao <liming.gao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
GCC v4.4 does not implement __builtin_unreachable(), so avoid using
it when building with this version or earlier.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Tested-By: Liming Gao <liming.gao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
The "Pci22.h" header file defines the macro EFI_PCI_CAPABILITY_ID_HOTPLUG
with value 0x06. According to all of:
- later parts of the same header file,
- Appendix H ("Capability IDs") of the PCI Local Bus Specification
Revision 2.3,
- and Chapter 2 ("Capability IDs") of the PCI Code and ID Assignment
Specification Revision 0.9,
0x06 means "CompactPCI Hot Swap". It does not mean "PCI Hot-Plug": that
capability is described by ID 0x0C:
0Ch PCI Hot-Plug -- This Capability ID indicates that the associated
device conforms to the Standard Hot-Plug Controller model.
Therefore EFI_PCI_CAPABILITY_ID_HOTPLUG is arguably a misnomer. PciBusDxe
(mis-)uses EFI_PCI_CAPABILITY_ID_HOTPLUG in the IsSHPC() helper function
to identify PCI Hot-Plug capability.
In order to preserve compatibility with existent code, leave
EFI_PCI_CAPABILITY_ID_HOTPLUG alone, and introduce
EFI_PCI_CAPABILITY_ID_SHPC with the right ID value.
Cc: "Johnson, Brian J." <bjohnson@sgi.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <Ruiyu.ni@intel.com>
v2:
*add some new arch types for PXE boot.
refine the definition of arch types for http boot
Add a new head file Dhcp.h in Mde/Include/IndustryStandard, normalize the
universal option numbers and other network number tags.
Cc: Sriram Subramanian <sriram-s@hpe.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Cc: Wu Jiaxin <jiaxin.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo <lubo.zhang@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
The definitions are required by certain platform initialization
code.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Reviewed-by: Amy Chan <amy.chan@intel.com>
When a variable is compared to NULL as part of an ASSERT() call, the
code implies that the variable may be NULL. Certain Static Analyzers,
such as the Clang Static Analyzer, then issue false warnings for any
untested access of that pointer, even though that defeats the
intention behind ASSERT(). This patch flags the position after
_ASSERT() as unreachable for Static Analyzers to indicate that if the
variable is NULL, execution cannot pass.
As the ANALYZER-prefixed version is used, the executables will not
have any code stripped during compilation.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser <Marvin.Haeuser@outlook.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
The NORETURN attribute informs compilers and analyzers that the flagged
function cannot return. This may improve the quality of the optimizations.
The UNREACHABLE() macro informs compilers and analyzers that its position
cannot be reached, for example eliminating implicit returns.
It is recommended to be used together with the NORETURN attribute to prevent
warnings regarding the function flagged as 'noreturn' returning.
The ANALYZER-prefixed versions have the same effects, but exclude compilers.
They may be used to surpress warnings of static analyzers, such as possible
dereferencing of a NULL pointer when dereferencing it after having checked it
via ASSERT().
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser <Marvin.Haeuser@outlook.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>