HMAC MD5 is not secure any longer.
Remove the HMAC MD5 support from edk2.
Change the HMAC MD5 field name in EDKII_CRYPTO_PROTOCOL to indicate the
function is unsupported any longer.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Add the unrequired aes_ecb files in process_files.pl and run it
thru perl.
It would remove the unrequired aes_ecb files from OpensslLib inf.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Aes Ecb mode is not secure any longer.
Remove the Aes Ecb mode support from edk2.
Change the Aes Ecb mode field name in EDKII_CRYPTO_PROTOCOL to indicate the
function is unsupported any longer.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
This patch is create by adding the setting "no_des" of
process_files.pl and running it thru perl.
It would remove the TDES from OpensslLib.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
TDES is not secure any longer.
Remove the Tdes support from edk2.
Change the Tdes field name in EDKII_CRYPTO_PROTOCOL to indicate the
function is unsupported any longer.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
This patch is create by adding the setting "no_rc4" of
process_files.pl and running it thru perl.
It would remove the ARC4 from OpensslLib.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
ARC4 is not secure any longer.
Remove the ARC4 support from edk2.
Change the ARC4 field name in EDKII_CRYPTO_PROTOCOL to indicate the
function is unsupported any longer.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
This patch is create by adding the setting "no_md4" of
process_files.pl and running it thru perl.
It would remove the MD4 from OpensslLib.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
MD4 is not secure any longer.
Remove the MD4 support from edk2.
Change the MD4 field name in EDKII_CRYPTO_PROTOCOL to indicate the
function is unsupported any longer.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Add a internal worker function to indicate the deprecated functions.
It would print out debug messages and asserts to inform the consumer
they are using a deprecated function.
Change the Name of BaseCryptLibServciceNotEnabled to correct spelling
BaseCryptLibServiceNotEnabled.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Remove the orginal Fmp Capsule Dependency implement, and use new
FmpDependencyLib, FmpDependencyCheckLib and FmpDependencyDeviceLib
APIs instead.
A platform can perform the dependency check in a platform specific
manner by implementing its own FmpDependencyCheckLib.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Signed-off-by: Wei6 Xu <wei6.xu@intel.com> Reviewed-by: Sean Brogan <sean.brogan@microsoft.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* This library class provides platform specific services to support
dependency check during updating firmware image. Platform can perform
dependency check in platform specific manner by implementing its own
FmpDependencyCheckLib.
* Add FmpDependencyCheck instance to provide a sample of dependency
check. The sample instance only checks the dependency from capsule
image. The dependency from other FMP instances isn't checked here.
* Add NULL instance as an option to skip the dependency check.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Signed-off-by: Wei6 Xu <wei6.xu@intel.com> Reviewed-by: Sean Brogan <sean.brogan@microsoft.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* Add unit tests for EvaluateDependency API in FmpDependencyLib.
* Add Test/FmpDeviceHostPkgTest.dsc to build host based unit test.
* Update FmpDevicePkg.dsc to build target based unit test.
* Update FmpDevicePkg.ci.yaml to build and run host based test.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Signed-off-by: Wei6 Xu <wei6.xu@intel.com> Reviewed-by: Sean Brogan <sean.brogan@microsoft.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Oleksiy Yakovlev [Wed, 13 May 2020 19:52:46 +0000 (03:52 +0800)]
MdePkg: Bootable NVDIMM namespaces
Provided a mechanism for UEFI FW to identify and hand off bootable
NVDIMM namespaces to the OS by standardizing the EFI device path.
EFI device path for physical NVDIMM devices changed from an ACPI
_ADR device to an ACPI NVDIMM device for correctness.
(UEFI 2.8 mantis 1858)
Oleksiy Yakovlev [Wed, 13 May 2020 19:52:45 +0000 (03:52 +0800)]
BaseTools: Bootable NVDIMM namespaces
Provided a mechanism for UEFI FW to identify and hand off bootable
NVDIMM namespaces to the OS by standardizing the EFI device path.
EFI device path for physical NVDIMM devices changed from an ACPI
_ADR device to an ACPI NVDIMM device for correctness.
(UEFI 2.8 mantis 1858)
The assert comes from InitializeHiiPackage() after an attempt to
retrieve HII package list from ImageHandle.
Xcode still doesn't support HII resource section and
LinuxInitrdDynamicShellCommand depends on it. Likewise 277a3958d93a
("OvmfPkg: Don't include TftpDynamicCommand in XCODE5 tool chain"),
disable initrd command if built with Xcode toolchain
Fixes: ec41733cfd10 ("OvmfPkg: add the 'initrd' dynamic shell command") Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Liming Gao <liming.gao@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
Message-Id: <20200514134820.62047-1-r.bolshakov@yadro.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Shenglei Zhang [Sat, 9 May 2020 06:33:36 +0000 (14:33 +0800)]
MdeModulePkg/RegularExpressionDxe: Optimize the code infrastructure
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>
To enhance FSP silicon initialization flexibility an optional
Multi-Phase API is introduced and FSP header needs update for
new API offset. Also new SecCore module created for
FspMultiPhaseSiInit API
New ARCH_UPD introduced for enhancing FSP debug message
flexibility now bootloader can pass its own debug handler
function pointer and FSP will call the function to handle
debug message.
To support calling bootloader functions, a FspGlobalData field
added to indicate if FSP needs to switch stack when FSP running
on separate stack from bootloader.
Cc: Maurice Ma <maurice.ma@intel.com> Cc: Nate DeSimone <nathaniel.l.desimone@intel.com> Cc: Star Zeng <star.zeng@intel.com> Signed-off-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
StandaloneMmPkg: switch to MM communicate 2 protocol
Update the reference to MM communicate to refer to the MM communicate 2
protocol instead. This makes no difference for the MM side of the
implementation, but is more accurate nonetheless, since the original MM
protocol does not work in combination with standalone MM.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
ArmPkg/MmCommunicationDxe: expose MM Communicate 2 protocol
Implement the new MmCommunication2 protocol which supports the use
of standalone MM at runtime inside an address space that has been
virtually remapped by the OS.
Note that the implementation of the old MM Communicate protocol is
removed: it never worked correctly so there is no point in keeping it.
MdeModulePkg/SmmIpl: expose MM communicate 2 protocol
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.
Now that an XCODE5 specific CpuExceptionHandlerLib library is in place,
revert the changes made to the ExceptionHandlerAsm.nasm in commit 2db0ccc2d7fe ("UefiCpuPkg: Update CpuExceptionHandlerLib pass XCODE5 tool
chain") so that binary patching of flash code is not performed.
Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Liming Gao <liming.gao@intel.com> Acked-by: Bret Barkelew <bret.barkelew@microsoft.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <810f67d8604c054c09d17a22f0bcfaeb41ee8e3b.1588856809.git.thomas.lendacky@amd.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
During the SEC phase, use the XCODE5 CpuExceptionHandlerLib library in
place of the standard library when building with the XCODE5 toolchain.
The SEC XCODE5 version of the library performs binary patching and should
only be used when building with the XCODE5 toolchain.
Commit 2db0ccc2d7fe ("UefiCpuPkg: Update CpuExceptionHandlerLib pass
XCODE5 tool chain") introduced binary patching into the exception handling
support. CPU exception handling is allowed during SEC and this results in
binary patching of flash, which should not be done.
Separate the changes from commit 2db0ccc2d7fe into an XCODE5 toolchain
specific file, Xcode5ExceptionHandlerAsm.nasm, and create a new SEC INF
file for the XCODE5 version of CpuExceptionHandlerLib.
Since binary patching is allowed when running outside of flash, switch
the Dxe, Pei and Smm versions of the CpuExceptionHandlerLib over to use
the Xcode5ExceptionHandlerAsm.nasm file to retain current functionality.
Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <9075570487616c731033a5738f6a444a15d71b74.1588856809.git.thomas.lendacky@amd.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
Rebecca Cran [Fri, 1 May 2020 20:00:44 +0000 (04:00 +0800)]
BaseTools: add repo name option to SetupGit.py
Allow users who didn't clone one of the TianoCore repos from a
canonical URL to specify the name of the repo (edk2, edk2-platforms
or edk2-non-osi) when running SetupGit.py to allow them to configure
their repo properly.
The new option is:
-n repo, --name repo set the repo name to configure for, if not
detected automatically
Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Krzysztof Koch [Wed, 25 Mar 2020 09:39:24 +0000 (17:39 +0800)]
ShellPkg: acpiview: Check if SBBR mandatory ACPI tables are installed
For Arm-based platforms, count the instances of installed tables for
each ACPI table listed as 'mandatory' in any Server Base Boot
Requirements (SBBR) specification.
Validate that the all the mandatory SBBR tables present. Report an error
for each missing table.
This new feature is optional and can be enabled with the -r command line
parameter.
Reference(s):
- Arm Server Base Boot Requirements 1.2, September 2019
- Arm Server Base Boot Requirements 1.1, May 2018
- Arm Server Base Boot Requirements 1.0, March 2016
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com> Reviewed-by: Sami Mujawar <Sami.Mujawar@arm.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Krzysztof Koch [Wed, 25 Mar 2020 09:39:23 +0000 (17:39 +0800)]
ShellPkg: acpiview: Add library for SBBR ACPI requirements validation
For Arm-based platforms, define and implement an interface for Server
Base Boot Requirements (SBBR) compliance checks. The library is
responsible for validating that all mandatory ACPI tables are installed
on the platform.
Internally, the library maintains a data structure which tracks
instance counts for ACPI tables which are labeled as 'mandatory' in any
SBBR specification version. The provided interface allows:
- resetting all instance counts to 0
- incremementing the instance count for a table with a given signature
- validating the instance counts against the requirements in SBBR
The ACPI table requirements for each SBBR spec version are represented
internally as a list of table signatures.
Every missing mandatory table (for the input SBBR version) is reported
to the user as a separate error. If all requirements are met, an info
message is displayed.
Reference(s):
- Arm Server Base Boot Requirements 1.2, September 2019
- Arm Server Base Boot Requirements 1.1, May 2018
- Arm Server Base Boot Requirements 1.0, March 2016
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com> Reviewed-by: Sami Mujawar <Sami.Mujawar@arm.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Krzysztof Koch [Wed, 25 Mar 2020 09:39:22 +0000 (17:39 +0800)]
ShellPkg: acpiview: Add -r parameter for table requirements validation
Define a new command line parameter '-r' to enable checking if all
mandatory ACPI tables listed in a specification are present.
The -r parameter takes an integer value to specify which specification
the validation should be performed against.
The parameter is used to set two Acpiview variables. An interface to
access these variables is implemented in this patch.
The new functionality is aimed at Arm-based platforms, however,
there are no restriction on extending it to other architectures.
For the 32-bit and 64-bit Arm architectures, the possible values for
the -r parameter are:
0: Arm Server Base Boot Requirements 1.0, March 2016
1: Arm Server Base Boot Requirements 1.1, May 2018
2: Arm Server Base Boot Requirements 1.2, September 2019
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com> Reviewed-by: Sami Mujawar <Sami.Mujawar@arm.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Microsoft signtool supports creation of attached P7's with any OID payload
via the "/p7co" parameter. It is necessary to check the data before get
the string.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Signed-off-by: Guomin Jiang <guomin.jiang@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Zero the allocated buffer in case GetImageInfo `continue` in the middle of
a loop. This will cause unexpected GetImageInfo failure not clearing the
corresponding entry and lead to GP faults when dereferencing this entry.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Wei6 Xu <wei6.xu@intel.com> Reviewed-by: Guomin Jiang <guomin.jiang@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
This patch fixes a file permission issue introduced by accident.
Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Leo Duran <leo.duran@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Eric Dong <eric.dong@intel.com>
Nikita Leshenko [Mon, 4 May 2020 21:06:07 +0000 (00:06 +0300)]
OvmfPkg/MptScsiDxe: Reset device on ExitBootServices()
This causes the device to forget about the reply frame. We allocated the
reply frame in EfiBootServicesData type memory, and code executing after
ExitBootServices() is permitted to overwrite it.
Nikita Leshenko [Mon, 4 May 2020 21:06:06 +0000 (00:06 +0300)]
OvmfPkg/MptScsiDxe: Implement the PassThru method
Machines should be able to boot after this commit. Tested with different
Linux distributions (Ubuntu, CentOS) and different Windows
versions (Windows 7, Windows 10, Server 2016).
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390 Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200504210607.144434-12-nikita.leshchenko@oracle.com>
[lersek@redhat.com: MPT_SCSI_DMA_ADDR_HIGH: drop redundant space char]
Nikita Leshenko [Mon, 4 May 2020 21:06:05 +0000 (00:06 +0300)]
OvmfPkg/MptScsiDxe: Initialize hardware
Reset and send the IO controller initialization request. The reply is
read back to complete the doorbell function but it isn't useful to us
because it doesn't contain relevant data or status codes.
See "LSI53C1030 PCI-X to Dual Channel Ultra320 SCSI Multifunction
Controller" technical manual for more information.
Nikita Leshenko [Mon, 4 May 2020 21:06:01 +0000 (00:06 +0300)]
OvmfPkg/MptScsiDxe: Report targets and one LUN
The controller supports up to 8 targets in practice (Not reported by the
controller, but based on the implementation of the virtual device),
report them in GetNextTarget and GetNextTargetLun. The firmware will
then try to communicate with them and create a block device for each one
that responds.
Support for multiple LUNs will be implemented in another series.
Nikita Leshenko [Mon, 4 May 2020 21:05:59 +0000 (00:05 +0300)]
OvmfPkg/MptScsiDxe: Probe PCI devices and look for MptScsi
The MptScsiControllerSupported function is called on handles passed in
by the ConnectController() boot service and if the handle is the
lsi53c1030 controller the function would return success. A successful
return value will attach our driver to the device.
The PL180 SD host controller driver is only used on emulated ARM
platforms, uses an obsolete version of the MMC host protocol and
does not adhere to the UEFI driver model.
It has been moved into edk2-platforms alongside the only platforms
that use it, so we can drop it from the EDK2 core repository.
EmbeddedPkg: remove ISP 1716 USB host controller driver
The ISP 1716 USB host controller driver does not implement the UEFI
driver model, and is not a suitable example for new drivers to be
based on. Also, it is currently only used on a limited set of ARM
development platforms.
Due to this, it has been moved into the edk2-platforms repository,
alongside its remaining users, which have been updated to refer to it in
its new location. So drop this version from EmbeddedPkg.
EmbeddedPkg: remove SiI3132 SATA controller driver
The SiI3132 SATA controller driver does not implement the UEFI driver
model, and is not a suitable example for new drivers to be based on.
Also, it is currently only used on a limited set of ARM development
platforms.
Due to this, it has been moved into the edk2-platforms repository,
alongside its remaining users, which have been updated to refer to it in
its new location. So drop this version from EmbeddedPkg.
The Lan9118 network controller driver does not implement the UEFI driver
model, and is not a suitable example for new drivers to be based on.
Also, it is currently only used on a limited set of ARM development
platforms.
Due to this, it has been moved into the edk2-platforms repository,
alongside its remaining users, which have been updated to refer to it in
its new location. So drop this version from EmbeddedPkg.
The Lan91x network controller driver does not implement the UEFI driver
model, and is not a suitable example for new drivers to be based on.
Also, it is currently only used on a limited set of ARM development
platforms.
Due to this, it has been moved into the edk2-platforms repository,
alongside its remaining users, which have been updated to refer to it in
its new location. So drop this version from EmbeddedPkg.
The Synopsys DesignWare eMMC host controller driver does not implement
that SD/MMC host controller protocol that the UEFI spec defines, but an
obsolete EDK2-specific one that predates it. It also does not implement
the UEFI driver model.
Due to this, it has been moved into the edk2-platforms repository,
alongside its remaining users, which have been updated to refer to it in
its new location. So drop this version from EmbeddedPkg.
On bhyve, the ACPI timer is located at a fixed IO address; it need
not be programmed into, nor fetched from, the PMBA -- power
management base address -- register of the PCI host bridge.
EmbeddedPkg: rename gEfiMmcHostProtocolGuid to gEmbeddedMmcHostProtocolGuid
In EDK2, identifiers carrying the EFI prefix are reserved for ones
that are defined in the UEFI or PI specifications.
Since the MMC host protocol defined in EmbeddedPkg is not the one that
the UEFI spec defines, and given the confusion around this, let's rename
it to from gEfiMmcHostProtocolGuid to gEmbeddedMmcHostProtocolGuid.
MdeModulePkg/DeviceManagerUiLib: connect all before creating menu page
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.
In PEI phase, AP already been waked up through ApInitConfig,
so it can directly wake up it through change wakup buffer
instead of use ApInitReconfig flag. It can save some time.
Change code to only use ApInitReconfig flag in DXE phase
which must need to update the wake up buffer.
Regression-tested-by: Laszlo Ersek <lersek@redhat.com> Cc: Chandana Kumar <chandana.c.kumar@intel.com> Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
This patch fixes an assertion because AP can't find the CpuMpData.
When AP is waken up through Init-Sipi-Sipi, AP's IDT should
be restored to pre-allocated buffer so AP can get the CpuMpData
through the IDT base address.
Current code already has logic to handle this when CpuMpData->
InitFlag is ApInitConfig but misses the logic
when CpuMpData->InitFlag is ApInitReconfig.
This patch fixes this gap.
Reviewed-by: Ray Ni <ray.ni@intel.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> Cc: Chandana Kumar <chandana.c.kumar@intel.com> Signed-off-by: Eric Dong <eric.dong@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2692
BrotliCompress submodule change for BaseTools causes untracked
files in BaseTools after building. This is regression for git.
We don't distribute UEFI_DRIVER modules stand-alone that were built as
part of an ArmVirtQemu* platform. ArmVirtQemu* UEFI_DRIVERs are allowed to
inherit platform dependencies.
By enabling UEFI_DRIVERs to consume QemuFwCfgLib, we can hook fw_cfg-based
NULL class libraries into UEFI drivers, e.g. in order to set dynamic PCDs.
OvmfPkg: control PXEv4 / PXEv6 boot support from the QEMU command line
Add a minimal, NULL class library called "PxeBcPcdProducerLib" for setting
the "PcdIPv4PXESupport" and "PcdIPv6PXESupport" PCDs of NetworkPkg, from
fw_cfg.
These PCDs control whether the UefiPxeBcDxe driver supports PXEv4 / PXEv6
boot. If a PXE version is disabled, the corresponding LoadFile protocol
instance is not produced by UefiPxeBcDxe, and so
EfiBootManagerRefreshAllBootOption() in UefiBootManagerLib does not
generate corresponding *new* boot options either. (Existent boot options
are not deleted.)
Hook the library into the UefiPxeBcDxe driver. (The driver is already
included from "NetworkComponents.dsc.inc", but we can list it again in the
DSC file, for providing <LibraryClasses> overrides.)
In OVMF, the PCDs could be set in PlatformPei too, but ArmVirtQemu does
not have fw_cfg access in the PEI phase. Hence a NULL class library that
can be linked into UefiPxeBcDxe.
When listing the PCDs under [PcdsDynamicDefault], stick with the DEC
default values.
We don't distribute UEFI_DRIVER modules stand-alone that were built as
part of an OVMF platform. OVMF's UEFI_DRIVERs are allowed to inherit
platform dependencies.
By enabling UEFI_DRIVERs to consume QemuFwCfgDxeLib, we can hook
fw_cfg-based NULL class libraries into UEFI drivers, e.g. in order to set
dynamic PCDs.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Per Sundstrom <per_sundstrom@yahoo.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2681 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200424075353.8489-5-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
OvmfPkg/PlatformPei: use QemuFwCfgParseBool in UPDATE_BOOLEAN_PCD_FROM_...
The UPDATE_BOOLEAN_PCD_FROM_FW_CFG() macro currently calls the
module-private helper function GetNamedFwCfgBoolean(). Replace the latter
with QemuFwCfgParseBool() from QemuFwCfgSimpleParserLib.
This change is compatible with valid strings accepted previously.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Per Sundstrom <per_sundstrom@yahoo.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2681 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200424075353.8489-4-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>