This reverts commit bc9e4194cf.
This change causes the dependent header files are missing in Makefile.
It makes the incremental build not work. So, revert this change.
Cc: Bob Feng<bob.c.feng@Intel.com>
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Bob Feng<bob.c.feng@Intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2150
v4:
The v3 posting didn't do what it promised to do, so do it now for real.
V3 changes:
change to mov instruction (non locking instuction) instead
of xchg to simplify design.
V2 changes:
Add xchg 16 bit instructions to handle sgdt and sidt base
63:48 bits and 47:32 bits.
Add comment to explain why xchg 64bit isnt being used
Split lock happens when a locking instruction is used on mis-aligned data
that crosses two cachelines. If close source platform enables Alignment
Check Exception(#AC), They can hit a double fault due to split lock being
in CpuExceptionHandlerLib.
sigt and sgdt saves 10 bytes to memory, 8 bytes is base and 2 bytes is limit.
The data is mis-aligned, can cross two cacheline, and a xchg
instruction(locking instuction) is being utilize.
Signed-off-by: John E Lofgren <john.e.lofgren@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Due to needs a tackling the deficiency of the AP API, it's necessary to
ensure that in non-blocking mode previous AP executed command is
finished before starting new one.
To remedy above:
1) execute AcquireSpinLock instead AcquireSpinLockOrFail - this will
ensure time "window" to eliminate potential race condition between
BSP and AP spinLock release in non-blocking mode.
This also will eliminate possibility to start executing new AP
function before last is finished.
2) remove returns EFI_STATUS - EFI_NOT_READY - in new scenario returned
status is not necessary to caller.
Signed-off-by: Damian Nikodem <damian.nikodem@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Krzysztof Rusocki <krzysztof.rusocki@intel.com>
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2201
An error occurs using special VpdPcd that is not used in the Inf file
In dsc:
[PcdsDynamicExVpd.common.DEFAULT]
gBoardModuleTokenSpaceGuid.test1|*|{CODE({
{0x0} // terminator
})}
In dec:
[PcdsDynamicEx]
# Vpd GPIO table
gBoardModuleTokenSpaceGuid.test1|{0}|GPIO_INIT_CONFIG[]|0x50000018 {
<HeaderFiles>
Library/GpioLib.h
<Packages>
MdePkg/MdePkg.dec
}
ValueError: invalid literal for int() with base 0: '*'
This Patch is going to fix issue
Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
The StandaloneMmPkg .DSC file went out of sync with the changes
applied to the package when I enabled this code on the Synquacer
platform in edk2-platforms. So apply the necessary changes to make
this package build in isolation.
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Build-tested-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2188
build -p MdeModulePkg\MdeModulePkg.dsc -a IA32 -m
MdeModulePkg\Universal\PCD\Pei\Pcd.inf
Error:
AttributeError: 'PlatformInfo' object has no attribute
'DynamicPcdList'
The DSC data object used to build a separate module today
is PlatformInfo rather than PlatformAutoGen
'PlatformAutoGen' object has attribute 'DynamicPcdList'
This patch is going to fixed this issue
Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
The header files are used but missing in INF, which causes
warning message when building them.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
After upgrading the CI system we use for building the ArmVirtPkg
targets, we started seeing failures due to the NOOPT build running
out of space when using the CLANG38 toolchain definition combined
with clang 7.
We really don't want to increase the FD/FV sizes in general to
accommodate this, so parameterize the relevant quantities and
increase them by 50% for NOOPT builds.
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Today's behavior is to enable 5l paging when CPU supports it
(CPUID[7,0].ECX.BIT[16] is set).
The patch changes the behavior to enable 5l paging when two
conditions are both met:
1. CPU supports it;
2. The max physical address bits is bigger than 48.
Because 4-level paging can support to address physical address up to
2^48 - 1, there is no need to enable 5-level paging with max
physical address bits <= 48.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
When building BaseTools, GNUmakefile builds create directory
BaseTools/Source/C/libs/. On the other hand, Makefile builds use libs
as an nmake pseudo target, so it either must NOT exist as a file or
directory, OR it must phony dependency like .PHONY. The latter
solution conflicts with NmakeSubdirs.py. Therefore, I make it go away
in the cleanall target. I could also add it to the clean target, but
it strikes me that cleanall should be more forceful.
Signed-off-by: Burt Silverman <burtms@gmail.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2157
Hii Pcd links to a efi variable. The Variable
default value is evaluated by related Hii Pcds
setting. If multiple Hii Pcds links to one variable,
and the offset overlap, the later Hii Pcds setting
should be effective. There is a tool bug that is if
the Pcds are in different dsc file which are included
into the platform dsc file, build tool does not get
the Pcds relative position correctly. That means
build tool does not know which Pcd is the later one. As
the result, the variable default value will be incorrect.
This patch is to fix this bug.
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
To support auto-connection, EFI_BLUETOOTH_LE_SMP_DATA_TYPE needs to
add a new data type EfiBluetoothSmpPeerAddressList which associates
with a list of Bluetooth per address connected before.
This new data type was added in UEFI spec 2.7b.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1778
We are going to add keyword (lower case) 'static' for functions and global
variables which are not referenced outside their current C file.
However, the ECC tool only recognizes upper case 'STATIC' at this moment.
This will lead to issue reports for new codes that follow the above coding
style.
This patch is going to handle lower case 'static'
Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
The LoadImage() boot service is a bit unusual in that it allocates
resources in a particular failure case; namely, it produces a valid
"ImageHandle" when it returns EFI_SECURITY_VIOLATION. This is supposed to
happen e.g. when Secure Boot verification fails for the image, but the
platform policy for the particular image origin (such as "fixed media" or
"removable media") is DEFER_EXECUTE_ON_SECURITY_VIOLATION. The return code
allows platform logic to selectively override the verification failure,
and launch the image nonetheless.
ArmVirtPkg/PlatformBootManagerLib does not override EFI_SECURITY_VIOLATION
for the kernel image loaded from fw_cfg -- any LoadImage() error is
considered fatal. When we simply treat EFI_SECURITY_VIOLATION like any
other LoadImage() error, we leak the resources associated with
"KernelImageHandle". From a resource usage perspective,
EFI_SECURITY_VIOLATION must be considered "success", and rolled back.
Implement this rollback, without breaking the proper "nesting" of error
handling jumps and labels.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
Fixes: 23d04b58e2
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Incorporate the stack protector library into the AARCH64 build of
the Shell binaries as a NULL library resolution, to avoid build
errors when the compiler injects stack integrity checks.
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Acked-by: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
In some cases, the CLANG38 toolchain profile in LTO mode emits GOT
based relocations in spite of our attempts to avoid this, by using
hidden visibility, -Bsymbolic etc.
On AARCH64, we managed to work around this by processing the GOT
based relocations in GenFw. As it turns out, the same issue exists
on 32-bit ARM, but unfortunately, we cannot use a similar trick to
get rid of the GOT entry, and the relocation metadata is insufficient
to locate the GOT entry in the binary.
Note that in this particular case, we are interested in PIE linking
only (i.e., producing a .rela section containing dynamic relocations
that the startup code can process directly), and not in position
independent code generation, and by passing the -pie option to the
linker directly using -Wl,-pie (and dropping -shared), we can coerce
the GOLD linker into doing only the former rather than both when it
performs its LTO code generation.
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2153
Current logic will skip searching EFI_PEI_CORE_FV_LOCATION_PPI when the
PPI in PpiList having EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST flag,
but platform may pass single PPI in PpiList that should be supported.
Changed the logic to verify PpiList first before checking
EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST flag.
Test: Verified both single EFI_PEI_CORE_FV_LOCATION_PPI and multiple
PPIs in PpiList cases and both can boot with the PeiCore
specified by EFI_PEI_CORE_FV_LOCATION_PPI.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Chasel Chiu <chasel.chiu@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
