Cc: Dandan Bi <dandan.bi@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
ArmPlatformPkg/MemoryInitPeiLib: don't reserve primary FV in memory
Now that PrePi no longer exposes its internal code via special HOBs,
we can remove the special handling of the primary FV, which needed to
be reserved so that DXE core could call into the PE/COFF and LZMA
libraries in the PrePi module.
Ard Biesheuvel [Thu, 30 Nov 2017 15:18:39 +0000 (15:18 +0000)]
ArmPlatformPkg/PrePi: don't expose PE/COFF and LZMA libraries via HOBs
Avoid the need to preserve all memory exposed by PrePi indefinitely
by removing the 'feature' that exposes the PE/COFF and LZMA libraries
via special HOBs to other modules that may want to reuse the code.
Ard Biesheuvel [Thu, 30 Nov 2017 15:00:23 +0000 (15:00 +0000)]
BeagleBoardPkg: clone MemoryInitPeiLib
The common MemoryInitPeiLib implementation preserves the primary FV
holding the PrePi module and the compressed secondary FV, and removes
the memory it occupies from the memory map, hiding it from the OS.
The only platform that actual requires this is BeagleBoardPkg, since
it exposes the PeCoff and LZMA libraries in PrePi to DXE core via
special HOBs. So let's give BeagleBoard its own MemoryInitPeiLib, so
that we can clean up the generic version.
Clone the PrePi implementation for BeagleBoardPkg, so we can start
removing some of the awkward optimizations that we'd rather not keep
in reference code. Note that we only clone the unicore ARM flavor,
which is all we need for BeagleBoard.
In the case of PrePi, it involves libraries included by the SEC
startup code that are exposed to DXE core via HOBs containing function
pointers, which forces us to keep the primary FV reserved in memory.
Ard Biesheuvel [Thu, 30 Nov 2017 14:41:07 +0000 (14:41 +0000)]
EmbeddedPkg BeagleBoardPkg: move special HOB reuse libraries into platform
The BeagleBoard platform uses PeCoffLib and CustomDecompressLib
implementations that invoke the library code that resides in the PrePi
module via pointers exposed via special GUIDed HOBs. This is a nice hack,
but not necessarily something we want to carry in reference code.
So as a first step, move the libraries that expose this reused code into
BeagleBoardPkg, and remove it from EmbeddedPkg.
The function ArmPlatformInitializeSystemMemory() is defined by
ArmPlatformLib, but is only ever called when using the PrePeiCore
flavor of the startup code. Also, none of the remaining upstream
platforms actually implement anything in that function in the first
place. So let's just remove it altogether.
ArmVExpressLibCTA9x4 is unused, and rather outdated, given that it is
the last ArmPlatformLib implementation that executes both in the secure
and non-secure worlds, which is a model we no longer support for ARM
systems. So remove it.
Having a special porting manual for ARM platforms in general suggests
that ARM platforms are fundamentally different from ones based on other
architectures that are supported by UEFI. There may be some truth to
that, but the porting manual in Documentation/ArmPlatformPkg.txt is
hopelessly outdated, and did not give the best advice in the first
place*. So remove it.
* ArmPlatformLib as the mother of all platform abstractions is rather
unwieldy, and using ArmVExpressLibCTA9x4 as a template is not that
great an idea either.
Leif Lindholm [Thu, 30 Nov 2017 13:59:32 +0000 (13:59 +0000)]
BeagleBoardPkg: add CapsuleLib resolution
Commit 4bbcc285d5f7 ("ArmPkg/PlatformBootManagerLib: process pending
capsules") added a dependency on CapsuleLib. Add DxeCapsuleLibNull
resolution to BeagleBoardPkg.dsc to resolve this.
Commit a63be426f8e3 ("ArmPlatformPkg: Store initial timer value") caused
BeagleBoard to stop building, due to Omap35xxTimerLib lacking an
implementation of GetTimeInNanoSecond (). So add one.
Ruiyu Ni [Wed, 29 Nov 2017 10:14:59 +0000 (18:14 +0800)]
ArmVirtPkg: Fix build failure due to Tftp library removal
The TFTP command was converted from a NULL class library instance to a
dynamic shell command in commit 0961002352e9.
The ShellLib and FileHandleLib resolutions are moved from
[LibraryClasses.common.UEFI_APPLICATION] to [LibraryClasses.common]
because dynamic shell commands are implemented as DXE_DRIVER modules.
PcdShellLibAutoInitialize must be set to FALSE for both the shell app
itself and the dynamic shell command modules.
Leif Lindholm [Thu, 30 Nov 2017 10:14:39 +0000 (10:14 +0000)]
EmbeddedPkg: remove nonexistent FLASH_DEFINITION from package .dsc
For whatever reason, EmbeddedPkg.dsc included a FLASH_DEFINITION entry
pointing to a nonexistent EmbeddedPkg.fdf.
This used to be silently ignored, but recent BaseTools changes 5e9256cd7f54 ("BaseTools: Guid.xref contain information from FILE statements in FDF")
now caused builds against EmbeddedPkg.dsc to fail.
So delete the redundant entry.
To consume FIT table for Microcode update,
UefiCpuPkg/Feature/Capsule/MicrocodeUpdateDxe
needs to be updated to consume
IntelSiliconPkg/Include/IndustryStandard/FirmwareInterfaceTable.h,
but UefiCpuPkg could not depend on IntelSiliconPkg.
Since the Microcode update feature is specific to Intel,
we can first move the Microcode update feature code from
UefiCpuPkg to IntelSiliconPkg [first step], then update
the code to consume FIT table [second step].
This patch series is for the first step.
Note: No any code change in this patch, just move.
Next patch will update MicrocodeUpdate to build with the package.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Yonghong Zhu <yonghong.zhu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
Julien Grall [Wed, 29 Nov 2017 17:28:23 +0000 (01:28 +0800)]
MdeModulePkg/SerialDxe: Do not fail reset when SetAttributes is not supported
After commit 91cc526b15 "MdeModulePkg/SerialDxe: Fix not able to change
serial attributes", serial is initialized using the reset method that
will call SetAttributes.
However, SetAttributes may return EFI_INVALID_PARAMETER when a driver
does not support some parameters. This will be propagated by the reset
function and lead to UEFI failing to get the console setup.
For instance, this is the case when using the Xen console driver.
Fix it by introspecting the result and return EFI_SUCCESS when the
SetAttributes report an invalid parameter (i.e EFI_INVALID_PARAMETER).
Julien Grall [Wed, 29 Nov 2017 17:28:22 +0000 (01:28 +0800)]
MdeModulePkg/SerialDxe: Fix return valued in SerialSetAttributes
SerialSetAttributes is meant to match the behavior of the function
EFI_SERIAL_IO_PROTOCOL.SetAttributes() in the UEFI spec (v2.7). This
means the function can only return:
- EFI_SUCCESS
- EFI_INVALID_PARAMETER
- EFI_DEVICE_ERROR
However the function SerialPortSetAttributes may also validly return
EFI_UNSUPPORTED. For instance this is the case of the Xen Console
driver.
EFI_UNSUPPORTED could be also interpreted as "One or more of the attributes
has an unsupported value". So return EFI_INVALID_PARAMETER in that case.
Lastly, to prevent another return slipping in the future, all the errors
but EFI_INVALID_PARAMETER and EFI_UNSUPPORTED will return
EFI_DEVICE_ERROR.
DXE performance gauge record access functions might be reentered since
we are supporting something like USB hot-plug, which is a timer event
where gBS->ConnectController might be called and then PERF will be
called in CoreConnectSingleController.
When StartGaugeEx is being reentered, not only the gauge record might
be overwritten, more serious situation will be caused if gauge data
buffer reallocation procedure is interrupted, between line 180 and 187
in DxeCorePerformanceLib.c specifically. There, mMaxGaugeRecords will
be doubled twice (denoted as 4X), but mGaugeData only points to a
buffer of size 2X, which will probably cause the following 2X memory
to be overflowed when gauge records are increased.
So we add EFI lock with TPL_NOTIFY in StartGaugeEx/EndGaugeEx/GetGaugeEx
to avoid memory overflow and gauge data corruption.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Heyi Guo <heyi.guo@linaro.org> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
Dandan Bi [Tue, 28 Nov 2017 03:44:34 +0000 (11:44 +0800)]
PcAtChipsetPkg: Add description for new added PCD in commit e78aab9d2
Cc: Leo Duran <leo.duran@amd.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Chasel, Chiu [Thu, 23 Nov 2017 02:22:45 +0000 (10:22 +0800)]
IntelFsp2WrapperPkg: Support UPD allocation outside FspWrapper
UPD allocation and patching can be done outside FspWrapper
as implementation choice so adding a PCD to select between
original FspWrapper allocation model or outside model
Cc: Jiewen Yao <Jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Ruiyu Ni [Tue, 28 Nov 2017 08:35:06 +0000 (16:35 +0800)]
OvmfPkg: Add tftp dynamic command
The TFTP command was converted from a NULL class library instance
to a dynamic shell command in commit 0961002352e9.
This patch complements commit f9bc2f876326, which only removed the
old library, but didn't add the new dynamic command。
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien.grall@linaro.org>
Ruiyu Ni [Tue, 28 Nov 2017 08:27:43 +0000 (16:27 +0800)]
CorebootPayloadPkg: Fix build failure due to Tftp/Dp library removal
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Maurice Ma <maurice.ma@intel.com> Cc: Prince Agyeman <prince.agyeman@intel.com> Reviewed-by: Benjamin You <benjamin.you@intel.com>
Ruiyu Ni [Mon, 27 Nov 2017 01:38:08 +0000 (09:38 +0800)]
OvmfPkg/Sec: Fix 64bit SEC build failure
Original code breaks a single assembly code to multiple lines.
But, when VS CL.exe preprocesses the FixedPcdGet32() macro
invocation to the replacement text, it loses '\', and causes
NASM to fail.
Changing the multiple lines to one line to resolve the build failure.
Ruiyu Ni [Tue, 28 Nov 2017 11:43:16 +0000 (19:43 +0800)]
ShellPkg/DynamicCommand: Fix bug that cannot start in boot
When dynamic command drivers are built into FV and start during
boot, they fails. Because Shell protocol doesn't exist during boot.
The patch sets Shell protocol and also set PcdShellLibAutoInitialize
to FALSE to ensure that
1. Shell protocol check doesn't happen in driver's entry point.
2. Driver can get the Shell protocol in DynamicCommand.Handler().
Ruiyu Ni [Tue, 28 Nov 2017 11:38:39 +0000 (19:38 +0800)]
ShellPkg/ShellLib: Fix dynamic command fails to start during boot
The previous change in ShellLib: "commit 3d29f8c5e361525a0d2accfa7f5bb0a7210b8927
* ShellPkg/ShellLib: Constructor doesn't depend on ShellParameters"
resolved the issue when loading dynamic command driver from Shell
environment.
But when dynamic command driver is built into FV and started during
boot, the driver still fails to start because Shell protocol doesn't
exist at that time.
The patch changes ShellLib to:
1. Do not look for Shell and ShellParameters protocol when they are
non-NULL in ShellLibConstructorWorker();
The two protocols are assumed to be set by DynamicCommand.Handler.
When ShellInitialize() is called in DynamicCommand.Handler, this
change can prevent the two protocols to be changed to NULL by
the locating logic.
2. Do not reset the Shell and ShellParameters protocol to NULL in
ShellLibDestructor() when CloseProtocol() fails;
Dynamic command driver needs to set the PcdShellLibAutoInitialize
to FALSE in order to skip the constructor.
Current logic calls ShellLibDestructor() when the PCD is FALSE when
ShellInitialize() is called. The change prevent the two protocols
to be changed to NULL.
The two changes don't impact existing usage case so they are backward
compatible.
Ruiyu Ni [Tue, 28 Nov 2017 09:06:32 +0000 (17:06 +0800)]
ShellPkg: Fix the bug that handling Ctrl-C improperly
Current implementation resets the CTRL-C event early when printing
the shell prompt, when user types "<CTRL-C>ls<ENTER>", "ls" command
is terminated immediately when starts.
It's not an expected behavior from users' perspective.
Correct way is to reset the CTRL-C event just before running the
command, which is a bit later than current point.
Ruiyu Ni [Mon, 27 Nov 2017 01:17:24 +0000 (09:17 +0800)]
MdeModulePkg/AtaAtapiPassThru: Revert patch to disable PCI attributes
This patch caused Windows 10 S4 resume failure.
Considering the similar changes are reverted from PciBus driver,
revert the patch from AtaAtapiPassThru as well.
Revert "MdeModulePkg/AtaAtapiPassThru: disable the device
at ExitBootServices()"
Ruiyu Ni [Mon, 27 Nov 2017 01:13:51 +0000 (09:13 +0800)]
MdeModulePkg/AtaAtapiPassThru: Revert patch to disable Bus Master
This patch caused Windows 10 S4 resume failure.
Considering the similar changes are reverted from PciBus driver,
revert the patch from AtaAtapiPassThru as well.
Laszlo Ersek [Thu, 23 Nov 2017 21:32:19 +0000 (22:32 +0100)]
OvmfPkg/QemuBootOrderLib: let an OFW devpath match multiple UEFI boot opts
This means that SetBootOrderFromQemu() will preserve all UEFI boot options
matched by any given OFW devpath, such as PXEv4, HTTPv4, PXEv6 and HTTPv6
boot options for the same NIC. Currently we stop the matching / appending
for the OFW devpath coming from the outer loop whenever we find the first
UEFI boot option match in the inner loop.
(The previous patch was about multiple OFW devpaths matching a single UEFI
boot option (which should never happen). This patch is about a single OFW
devpath matching multiple UEFI boot options. With the "break" statement
removed here, the small optimization from the last patch becomes a bit
more relevant, because now the inner loop always counts up to
ActiveCount.)
The SetBootOrderFromQemu() function implements a nested loop where
- the outer loop iterates over all OpenFirmware (OFW) device paths in the
QEMU boot order, and translates each to a UEFI device path prefix;
- the inner loop matches the current (translated) prefix against all
active UEFI boot options in turn;
- if the UEFI boot option is matched by the translated prefix, the UEFI
boot option is appended to the "new" UEFI boot order, and marked as
"has been appended".
This patch adds a micro-optimization where already matched / appended UEFI
boot options are skipped in the inner loop. This is not a functional
change. A functional change would be if, as a consequence of the patch,
some UEFI boot options would no longer be *doubly* matched.
For a UEFI boot option to be matched by two translated prefixes, one of
those prefixes would have to be a (proper, or equal) prefix of the other
prefix. The PCI and MMIO OFW translation routines output such only in the
following cases:
- When the original OFW device paths are prefixes of each other. This is
not possible from the QEMU side. (Only leaf devices are bootable.)
- When the translation rules in the routines are incomplete, and don't
look at the OFW device paths for sufficient length (i.e., at nodes where
they would already differ, and the difference would show up in the
translation output).
This would be a shortcoming of the translation routines and should be
fixed in TranslatePciOfwNodes() and TranslateMmioOfwNodes(), whenever
identified.
Even in the second case, this patch would replace the double appending of
a single UEFI boot option (matched by two different OFW device paths) with
a correct, or cross-, matching of two different UEFI boot options. Again,
this is not expected, but arguably it would be more correct than duplicate
boot option appending, should it occur due to any (unexpected, unknown)
lack of detail in the translation routines.
Ruiyu Ni [Fri, 24 Nov 2017 09:26:24 +0000 (17:26 +0800)]
ShellPkg/dp: Convert from NULL class library to Dynamic Command
UEFI Shell spec defines Shell Dynamic Command protocol which is just
for the purpose to extend internal command.
So dp command is changed from NULL class library to be a driver
producing DynamicCommand protocol.
The guideline is:
1. Only use NULL class library for Shell spec defined commands.
2. New commands can be provided as not only a standalone application
but also a dynamic command. So it can be used either as an
internal command, but also as a standalone application.
DpApp.inf is to provide a standalone application.
DpDynamicCommand.inf is to provide a standalone driver producing
Dynamic Command protocol.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com>
Ruiyu Ni [Tue, 31 Oct 2017 02:47:31 +0000 (10:47 +0800)]
ShellPkg/tftp: Convert from NULL class library to Dynamic Command
UEFI Shell spec defines Shell Dynamic Command protocol which is just
for the purpose to extend internal command.
So tftp command is changed from NULL class library to be a driver
producing DynamicCommand protocol.
The guideline is:
1. Only use NULL class library for Shell spec defined commands.
2. New commands can be provided as not only a standalone application
but also a dynamic command. So it can be used either as an
internal command, but also as a standalone application.
TftpApp.inf is to provide a standalone application.
TftpDynamicCommand.inf is to provide a standalone driver producing
Dynamic Command protocol.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com>
Ruiyu Ni [Fri, 24 Nov 2017 08:01:41 +0000 (16:01 +0800)]
ShellPkg/ShellLib: Constructor doesn't depend on ShellParameters
When ShellLib is linked to a driver producing DynamicCommand
protocol, ShellParameters protocol is set by
DynamicCommand.Handler().
The driver image handle doesn't have ShellParameters protocol
installed.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com>
Jian J Wang [Thu, 23 Nov 2017 01:57:01 +0000 (09:57 +0800)]
MdeModulePkg/Core: Merge memory map after filtering paging capability
Once the paging capabilities were filtered out, there might be some adjacent entries
sharing the same capabilities. It's recommended to merge those entries for the OS
compatibility purpose.
This patch makes use of existing method MergeMemoryMap() to do it. This is done by
simply turning this method from static to extern, and call it after filter code.
This patch is related to an issue described at
https://bugzilla.tianocore.org/show_bug.cgi?id=753
This patch is also passed test of booting follow OSs:
Windows 10
Windows Server 2016
Fedora 26
Fedora 25
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
Ard Biesheuvel [Fri, 24 Nov 2017 09:43:50 +0000 (09:43 +0000)]
ArmVirtPkg/PrePi: don't export PE/COFF and LZMA libraries via HOBs
The PrePi code we inherited from ArmPlatformPkg contains a rather
obscure optimization, where entry points of the PE/COFF and LZMA
handling routines are recorded in special HOBs, allowing DXE core
to call into that code directly rather than carry its own copy of
these libraries.
Given that no ArmVirtPkg platforms actually include the library
resolutions* that take advantage of these optimizations, let's not
bother with them, and remove the associated code.
Laszlo Ersek [Wed, 22 Nov 2017 16:48:38 +0000 (17:48 +0100)]
MdeModulePkg/BdsDxe: fall back to a Boot Manager Menu loop before hanging
Under the following scenario:
- no UEFI bootable application available anywhere in the system,
- ... not even for the default platform recovery option,
- no shell is built into the firmware image,
- but UiApp is available in the firmware image,
we should preferably not just hang in BdsEntry() with:
DEBUG ((EFI_D_ERROR, "[Bds] Unable to boot!\n"));
CpuDeadLoop ();
while the user sits at the TianoCore logo page, wondering what's going on.
Print an informative message to the console, wait for a keypress, and then
return to the Boot Manager Menu forever.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Star Zeng <star.zeng@intel.com>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=513 Suggested-by: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
chenc2 [Mon, 20 Nov 2017 07:34:17 +0000 (15:34 +0800)]
SecurityPkg/SecureBootConfigDxe: Fix deleting signature data issue.
Replace "(UINT8 *)NewVariableData" with (UINT8 *)NewVariableData + Offset"
to avoid the header of EFI_SIGNATURE_LIST being copied to the front of
NewVariableData every time and update ListWalker when handling the current
EFI_SIGNATURE_LIST finishes.
Ard Biesheuvel [Wed, 15 Nov 2017 15:36:07 +0000 (15:36 +0000)]
EmbeddedPkg Omap35xxPkg: remove EBL and associated libraries
EBL is a deprecated, small memory footprint alternative for the
UEFI Shell that is no longer in use by any platforms in EDK2 or
in edk2-platforms. To avoid confusion, let's remove it from the
tree.
This module is not used anywhere under edk2 or edk2-platforms, so let's
remove it. This removes the only dependency on ArmPlatformLib from ArmPkg.
While at it, remove a mention of ArmPlatformPkg from a comment in the
.dec file as well.
Leif Lindholm [Sat, 25 Nov 2017 13:16:20 +0000 (13:16 +0000)]
EmbeddedPkg: get rid of BdsLib dependency from Android*Boot
The sum use these applications made of BdsLib was one invocation of the
IS_DEVICE_PATH_NODE macro, and (incorrectly) being able to leave out a
dependency on gEfiLoadedImageProtocolGuid.
So expand the macro in place and add the missing dependency.
Then clean up the .dsc, .inf and #includes accordingly.
Gary Lin [Wed, 22 Nov 2017 04:43:56 +0000 (12:43 +0800)]
CryptoPkg/IntrinsicLib: Fix the warning on memset
Gcc issued the warning when compiling CryptoPkg:
CryptoPkg/Library/Include/CrtLibSupport.h:135:17: warning: type of 'memset' does not match original declaration [-Wlto-type-mismatch]
void *memset (void *, int, size_t);
^
CryptoPkg/Library/IntrinsicLib/MemoryIntrinsics.c:27:8: note: type mismatch in parameter 2
void * memset (void *dest, char ch, size_t count)
^
This commit changes the type of ch from char to int to match the
declaration.
Cc: Qin Long <qin.long@intel.com> Cc: Ting Ye <ting.ye@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Qin Long <qin.long@intel.com>
Jian J Wang [Thu, 23 Nov 2017 01:48:33 +0000 (09:48 +0800)]
MdeModulePkg/DxeCore: Filter out all paging capabilities
Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as really
set attributes and change memory paging attribute accordingly.
But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by
value from Capabilities in GCD memory map. This might cause
boot problems. Clearing all paging related capabilities can
workaround it. The code added in this patch is supposed to
be removed once the usage of EFI_MEMORY_DESCRIPTOR.Attribute
is clarified in UEFI spec and adopted by both EDK-II Core and
all supported OSs.
Laszlo did a thorough test on OVMF emulated platform. The details
can be found at
https://bugzilla.tianocore.org/show_bug.cgi?id=753#c10
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Jian J Wang [Mon, 23 Oct 2017 06:49:02 +0000 (14:49 +0800)]
UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map
More than one entry of RT_CODE memory might cause boot problem for some
old OSs. This patch will fix this issue to keep OS compatibility as much
as possible.
More detailed information, please refer to
https://bugzilla.tianocore.org/show_bug.cgi?id=753
Laszlo did a thorough test on OVMF emulated platform. The details can be found
at
https://bugzilla.tianocore.org/show_bug.cgi?id=753#c10
Cc: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Jiaxin Wu [Fri, 17 Nov 2017 03:50:11 +0000 (11:50 +0800)]
CryptoPkg/TlsLib: Change the return type of TlsInitialize().
V2:
* Correct the commit log.
Currently, the return code of OPENSSL_init_ssl(0 or 1) and RandomSeed
(TRUE or FALSE) are not checked in TlsInitialize(). Also "VOID" is used
as the return type of TlsInitialize(), which can't be used to capture
the returned value for error handling.
From Long Qin (CryptoPkg owner):
The early version of OPENSSL_init_ssl() use the "VOID" as the return
value, which was updated to "int" later because the function changes
can fail.
So, this patch is to change the return type of TlsInitialize() to
follow up the OPENSSL_init_ssl() update.
Cc: Ye Ting <ting.ye@intel.com> Cc: Long Qin <qin.long@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: Long Qin <qin.long@intel.com>
Jian J Wang [Thu, 23 Nov 2017 00:56:46 +0000 (08:56 +0800)]
MdeModulePkg/Core: Fix potential array overflow
In the method DumpGuardedMemoryBitmap() and SetAllGuardPages(), the code
didn't check if the global mMapLevel is legal value or not, which leaves
a logic hole causing potential array overflow in code followed.
This patch adds sanity check before any array reference in those methods.
Cc: Wu Hao <hao.a.wu@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Wu Hao <hao.a.wu@intel.com>
Jian J Wang [Thu, 23 Nov 2017 01:17:49 +0000 (09:17 +0800)]
MdeModulePkg/Core: Add missing header files into inf
The coding style requires that header files must be also added in module's inf
file, as long as they're included by c files. This patch will fix this issue.
Cc: Dandan Bi <dandan.bi@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Jiaxin Wu [Wed, 22 Nov 2017 06:34:30 +0000 (14:34 +0800)]
NetworkPkg/HttpDxe: Fix the incorrect SizeofHeaders in HttpTcpReceiveHeader().
Commit 19bd133562df951ae7ff7e1fff99b11a25b4cb6d is to fix the incorrect SizeofHeaders
returned from HttpTcpReceiveHeader(). But it missed the "\r\n\r\n" calculation, which
will cause the later HttpHeaders parsing failure.
This patch is fix the above issue.
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: Fu Siyuan <siyuan.fu@intel.com>
Ard Biesheuvel [Wed, 22 Nov 2017 09:41:44 +0000 (09:41 +0000)]
ArmVirtPkg: create QemuVirtMemInfoLib version for ArmVirtQemu
The QemuVirtMemInfoLib ArmVirtMemInfoLib implementation created for
ArmVirtQemuKernel does exactly what we need for ArmVirtQemu, the only
difference being that the latter is PrePeiCore based, and so it uses
a different method to ensure that PcdSystemMemorySize is set when
ArmVirtGetMemoryMap() is called.
On ArmVirtQemu, we currently abuse the implied ordering guarantees
provided by ArmPlatformLib, by implementing this as follows:
ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.inf [ArmVirtPkg/ArmVirtQemu.dsc]
InitializeMemory() [ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.c]
ArmPlatformInitializeSystemMemory() [ArmVirtPkg/Library/ArmVirtPlatformLib/Virt.c]
//
// set PcdSystemMemorySize from the DT
//
MemoryPeim() [ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c]
InitMmu() [ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c]
ArmPlatformGetVirtualMemoryMap() [ArmVirtPkg/Library/ArmVirtPlatformLib/VirtMem.c]
//
// consume PcdSystemMemorySize
//
Given that we are trying to get rid of ArmPlatformLib, or at least remove
some of these API functions that are never used for their original purpose
by any platforms, we need to move the PCD assignment elsewhere.
So create a PEIM-only version of QemuVirtMemInfoLib especially for
ArmVirtQemu, and add the PCD assignment code to its constructor.
Create a new ArmVirtMemInfoLib for ArmVirtQemuKernel by cloning the
existing ArmPlatformGetVirtualMemoryMap () for this platform,
(ArmQemuRelocatablePlatformLib *not* ArmVirtPlatformLib), and cleaning
it up:
- remove support for uncached DRAM mappings
- replace EFI_D_xxx with DEBUG_xxx throughout
- use a temp variable to hold the top of the physical address space
- use AllocatePool () instead of AllocatePages (), given that we use
160 bytes only, and the memory is never freed.
In a future patch, we will add this library to the ordinary ArmVirtQemu
platform as well.
Clone the existing ArmPlatformGetVirtualMemoryMap () for this platform,
clean it up slightly (by using a static buffer rather than a heap
allocation, and removing the support for uncached DRAM mappings), and
turn it into a new ArmVirtMemInfoLib implementation.
Ard Biesheuvel [Fri, 17 Nov 2017 13:55:17 +0000 (13:55 +0000)]
ArmVirtPkg: introduce ArmVirtMemInfoLib library class
As part of the effort to get rid of ArmPlatformLib (which incorporates
far too many duties in a single library), introduce ArmVirtMemInfoLib
which will be invoked by our ArmVirtMemoryInitPeiLib implementation to
get a description of the virtual address space. This will allow us to
remove this functionality from ArmPlatformLib later, or, in the case of
ArmVirtXen and ArmVirtQemuKernel, drop ArmPlatformLib altogether.
Ard Biesheuvel [Fri, 17 Nov 2017 13:33:15 +0000 (13:33 +0000)]
ArmVirtPkg/ArmVirtPlatformLib: remove support for uncached mappings
QEMU/KVM has very little tolerance for using anything except writeback
cacheable mappings of DRAM, so let's remove the 'feature' that allows
us to select uncached mappings at build time.
ArmPlatformStackLib has hooks into primary/secondary core PCDs and
other ArmPlatformLib related junk, so let's simply set the stack
pointer directly. This is trivial given that our PrePi is unicore
only.
Ard Biesheuvel [Fri, 17 Nov 2017 11:09:44 +0000 (11:09 +0000)]
ArmVirtPkg/PrePi: move DRAM discovery code into PrePi
ArmVirtQemuKernel and ArmVirtXen use essentially the same code to
retrieve DRAM information from the DT /memory node at early boot,
and invoke it via the ArmPlatformPeiBootAction () hook exposed by
ArmPlatformLib. Let's move this code into the PrePi implementation
these platforms share between them (and not with any other platforms)
so we can eliminate another dependency on the messy ArmPlatformLib.
Ard Biesheuvel [Fri, 17 Nov 2017 10:54:59 +0000 (10:54 +0000)]
ArmVirtPkg/PrePi: remove bogus primary core check
QEMU and KVM based ARM/AARCH64 virtual machines only enter UEFI on
a single core, so ArmPlatformIsPrimaryCore() always returns true.
And even if it didn't, our code does absolutely nothing meaningful
based on its return value, so don't bother calling it, and remove
another frivolous dependency on ArmPlatformLib.
Ard Biesheuvel [Mon, 13 Nov 2017 15:09:30 +0000 (15:09 +0000)]
ArmVirtPkg/PrePi: run all library constructors by hand
Instead of invoking the library constructors of some libraries by
hand, invoke the generated function ProcessLibraryConstructorList
in AutoGen.c so all constructors are executed.
Ard Biesheuvel [Tue, 21 Nov 2017 16:02:14 +0000 (16:02 +0000)]
BaseTools/tools_def AARCH64 ARM: suppres PIE sections via linker script
Recent distro builds of GCC 6 enable PIE linking by default, and allow
the previous behavior to be restored by passing the -no-pie command line
argument. Support for this was implemented by commits 1894a7c64c0a and 3380a591232d but unfortunately, it turns out that GCC 5 does not support
this command line argument, and exits with an error.
To avoid the need for yet another toolchain tag, to distinguish between
GCC 5 and GCC 6, let's use our GCC linker scripts when building objects
from .aslc files. This will ensure that the extra sections that are added
by the PIE linker are discarded from the ELF binary, and so they will not
corrupt the resulting .acpi file.
This reverts
1894a7c64c0a BaseTools/tools_def AARCH64 ARM: disable PIE linking 3380a591232d BaseTools/tools_def AARCH64 ARM: disable PIE linking for .aslc sources
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Leo Duran <leo.duran@amd.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Leo Duran [Tue, 31 Oct 2017 17:54:52 +0000 (01:54 +0800)]
PcAtChipsetPkg: Define FixePCD's for RTC register values
Define FixedPCD's to replace macros in RTC driver, to allow
for platform-specific configurations.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Leo Duran <leo.duran@amd.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Done:
if (EFI_ERROR (Status)) {
if (PciIo != NULL && Enabled) {
PciIo->Attributes (
PciIo,
EfiPciIoAttributeOperationSet,
OriginalAttributes,
NULL
);
}
}
In above codes, VS2012/VS2010 will report that "OriginalAttributes"
will be used without initialization. But in fact, when the if expression
is true(if (PciIo != NULL && Enabled)), the "OriginalAttributes" must be
initialized. In order to fix this false positive issue, we initialize the
"OriginalAttributes" after declaration.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
projects / mirror_edk2.git / log