In some cases, such as MD RAID1 in Linux, the bootloader may be in a
nested EFI system partition partition. For example, sda1 and sdb1 are
combined as md0 and the first partition of md0, md0p1, is an EFI system
partition. Then, the bootloader can be located by the following device
paths:
PCI()/SATA(sda)/Partition(sda1)/Partition(md0p1)/File(bootloader.efi)
PCI()/SATA(sdb)/Partition(sdb1)/Partition(md0p1)/File(bootloader.efi)
To make the boot option more resilient, we may create a boot option with
the short-form device path like "Partition(md0p1)/File(bootloader.efi)".
However, BmMatchPartitionDevicePathNode() only matched the first
partition node and ignored the nested partitions, so the firmware would
refuse to load bootloader.efi since "Partition(md0p1)" doesn't match
either "Partition(sda1)" or "Partition(sda2)".
This commit modifies BmMatchPartitionDevicePathNode() to iterate all
nested partitions so that the above boot option could work.
v2 - Simplify the node matching logic
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
The newly added standalone MM versions of the FTW and variable runtime
drivers were included in MdeModulePkg.dsc to get test coverage when
building the package from its own .dsc, but the resulting modules are
non-functional since they incorporate some dummy libraries.
Dandan reports that these modules don't build cleanly when using the
EBC or XCODE5 compilers, so given the above, let's just ignore them
in this case.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Bi Dandan <dandan.bi@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323
Merge EmuVariable and Real variable driver.
CacheOffset could be removed in UpdateVariable() after
//
// update the memory copy of Flash region.
//
CopyMem (
(UINT8 *)mNvVariableCache + CacheOffset,
(UINT8 *)NextVariable, VarSize
);
is moved to be before mVariableModuleGlobal->NonVolatileLastVariableOffset
value is updated, like right before
mVariableModuleGlobal->NonVolatileLastVariableOffset +=
HEADER_ALIGN (VarSize);
Except for the movement above, the patch also capitalizes the first
character of "update the memory copy of Flash region".
This patch prepares for adding emulated variable NV mode
support in VariableRuntimeDxe.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Julien Grall <julien.grall@arm.com>
Acked-by: Julien Grall <julien.grall@arm.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323
Merge EmuVariable and Real variable driver.
Add macro NV_STORAGE_VARIABLE_BASE.
Not get NV PCD in VariableWriteServiceInitialize, but in
FtwNotificationEvent/SmmFtwNotificationEvent, then
VariableWriteServiceInitialize could be not aware the NV
storage is real or emulated.
This patch prepares for adding emulated variable NV mode
support in VariableRuntimeDxe.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Tested-by: Julien Grall <julien.grall@arm.com>
Acked-by: Julien Grall <julien.grall@arm.com>
Permit CheckUefiLib to be used by MM_STANDALONE modules. Since this
library has a constructor, change the library's module type into
BASE so its constructor prototype is compatible with MM_STANDALONE
as well.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
For build testing coverage, add the newly introduced MM_STANDALONE
versions of the fault tolerant write (FTW) and variable runtime
driver to MdeModulePkg.dsc. Note that the resulting binaries will
not be able to run, since they rely on dummy implementations of
MemoryAllocationLib and HobLib.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>.
Add MM_STANDALONE to the list of permitted module types of the
VarCheckLib library implementation.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>.
Add MM_STANDALONE to the list of permitted module types of the
AuthVariableLibNull library implementation.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>.
MdeModulePkg/Universal/DebugSupportDxe/DebugSupportDxe.inf does not
build for AARCH64 since it does not provide the needed PlDebugSupport.h
header. So move the module to a x86 only section.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>.
In order to permit MM_STANDALONE modules to be built without relying
on StandaloneMmPkg, provide a BASE type NULL implementation of
MemoryAllocationLib.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>.
In order to permit MM_STANDALONE modules to be built without relying
on StandaloneMmPkg, provide a BASE type NULL implementation of HobLib.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>.
Reuse most of the existing code to implement a variable runtime
driver that will be able to execute in the context of standalone
MM.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
In preparation of providing a standalone MM based variable runtime
driver, move the existing SMM driver to the new MM services table,
and factor out some pieces that are specific to the traditional
driver, mainly related to the use of UEFI boot services, which are
not accessible to standalone MM drivers.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Implement a new version of the fault tolerant write driver that can
be used in the context of a standalone MM implementation.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
In preparation of providing a standalone MM based FTW driver, move
the existing SMM driver to the new MM services table, and factor out
some pieces that are specific to the traditional driver, mainly
related to the use of UEFI boot services, which are not accessible
to standalone MM drivers.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
The SMM based FTW and variable drivers are going to depend on
MmServicesTableLib after a subsequent patch, so add a resolution
for it to MdeModulePkg.dsc.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
((Facs->Flags & EFI_ACPI_4_0_OSPM_64BIT_WAKE__F) != 0))
In above code, Facs->OspmFlags should be used instead.
EFI_ACPI_4_0_OSPM_64BIT_WAKE__F is a bit in OSPM Enabled Firmware
Control Structure Flags field, not in Firmware Control Structure
Feature Flags.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1430
Cc: Aleksiy <oleksiyy@ami.com>
Cc: Jian Wang <jian.j.wang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Add SDMA, ADMA2 and 26b data length support.
If V4 64 bit address mode is supported in capabilities register,
program controller to enable V4 host mode and use appropriate
SDMA registers supporting 64 bit addresses.
If V4 64 bit address mode is supported in capabilities register,
program controller to enable V4 host mode and use appropriate
ADMA descriptors supporting 64 bit addresses.
If host controller version is above V4.0, enable ADMA2 with 26b data
length support for better performance. HC 2 register is configured to
use 26 bit data lengths and ADMA2 descriptors are configured appropriately.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1359
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1417
Since BaseLib API AsmLfence() is a x86 arch specific API and should be
avoided using in generic codes, this commit replaces the usage of
AsmLfence() with arch-generic API SpeculationBarrier().
Please note that speculation execution barriers are intended to be
asserted for SMM codes, hence, this commit still preserve an empty
implementation of the speculation execution barrier for the DXE codes.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Take MAX_ALLOC_ADDRESS into account in the implementation of the
page allocation routines, so that they will only return memory
that is addressable by the CPU at boot time, even if more memory
is available in the GCD memory map.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Update the GCD memory map initialization code so it disregards
memory that is not addressable by the CPU at boot time. This
only affects the first memory descriptor that is added, other
memory descriptors are permitted that describe memory ranges
that may be accessible to the CPU itself only when executing
under the OS.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1405
Background as below.
Problem:
As static configuration from the PCDs, the binary PeiCore (for example
in FSP binary with dispatch mode) could not predict how many FVs,
Files or PPIs for different platforms.
Burden:
Platform developers need configure the PCDs accordingly for different
platforms.
To solve the problem and remove the burden, we can update code to
remove the using of PcdPeiCoreMaxFvSupported, PcdPeiCoreMaxPeimPerFv
and PcdPeiCoreMaxPpiSupported by extending buffer dynamically for FV,
File and PPI management.
This patch removes the using of PcdPeiCoreMaxPpiSupported in PeiCore.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Chasel Chiu <chasel.chiu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1405
Background as below.
Problem:
As static configuration from the PCDs, the binary PeiCore (for example
in FSP binary with dispatch mode) could not predict how many FVs,
Files or PPIs for different platforms.
Burden:
Platform developers need configure the PCDs accordingly for different
platforms.
To solve the problem and remove the burden, we can update PeiCore to
remove the using of PcdPeiCoreMaxFvSupported, PcdPeiCoreMaxPeimPerFv
and PcdPeiCoreMaxPpiSupported by extending buffer dynamically for FV,
File and PPI management.
This patch removes the using of PcdPeiCoreMaxFvSupported in PeiCore.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Chasel Chiu <chasel.chiu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1405
Background as below.
Problem:
As static configuration from the PCDs, the binary PeiCore (for example
in FSP binary with dispatch mode) could not predict how many FVs,
Files or PPIs for different platforms.
Burden:
Platform developers need configure the PCDs accordingly for different
platforms.
To solve the problem and remove the burden, we can update code to
remove the using of PcdPeiCoreMaxFvSupported, PcdPeiCoreMaxPeimPerFv
and PcdPeiCoreMaxPpiSupported by extending buffer dynamically for FV,
File and PPI management.
This patch removes the using of PcdPeiCoreMaxPeimPerFv in PeiCore.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Chasel Chiu <chasel.chiu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
UEFI SCT crashed and failed in NonDiscoverablePciDeviceDxe becase
required checks were not performed. Perform parameters validation in
NonDiscoverablePciDeviceDxe.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Struct packing is only necessary for data structures whose in-memory
representation is covered by the PI or UEFI specs, and may deviate
from the ordinary C rules for alignment.
So in case of FileExplorerLib, this applies to the device path struct
only, and other structures used to carry program data should not be
packed, or we may end up with alignment faults on architectures such
as ARM, which don't permit load/store double or multiple instructions
to access memory locations that are not 32-bit aligned.
E.g., the following call in FileExplorerLibConstructor()
InitializeListHead (&gFileExplorerPrivate.FsOptionMenu->Head);
which is emitted as follows for 32-bit ARM/Thumb2 by Clang-5.0
3de0: b510 push {r4, lr}
3de2: 4604 mov r4, r0
...
3de8: e9c4 4400 strd r4, r4, [r4]
3dec: bd10 pop {r4, pc}
will perform a double-word store on the first argument, passed in
register r0, assuming that the pointer type of the argument is
enough to guarantee that the value is suitably aligned.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1376
Today's implementation reuses the 32bit MMIO resource requested by
all PCI devices MMIO BARs when shadowing the option ROM.
Take a simple example, a system has only one PCI device. It requires
8MB 32bit MMIO and contains a 4MB option ROM. Today's implementation
only requests 8MB (max of 4M and 8M) 32bit MMIO from
PciHostBridgeResourceAllocation protocol. Let's assume the MMIO range
[3GB, 3GB+8MB) is allocated. The 3GB base address is firstly
programmed to the option ROM BAR for option ROM shadow. Then the
option ROM decoding is turned off and 3GB base address is programmed
to the 32bit MMIO BAR.
It doesn't cause issues when the device doesn't request too much
MMIO.
But when the device contains a 64bit MMIO BAR which requests 4GB MMIO
and a 4MB option ROM. Let's assume [3GB, 3GB+8MB) 32bit MMIO range is
allocated for the option ROM. When the option ROM is being shadowed,
64bit MMIO BAR is programmed to value 0, which means [0, 4GB) MMIO is
given to the 64bit BAR.
The range overlaps with the option ROM range which may cause the
device malfunction (e.g.: option ROM cannot be read out) when the
device has two separate decoders: one for MMIO BAR, the other for
option ROM.
The patch requests dedicated MEM32 resource for Option ROMs and
moves the Option ROM shadow logic after all MMIO BARs are programmed.
The MMIO BAR setting to 0 when shadowing Option ROM is also skipped
because the MMIO BAR already contains the correct value.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
