Enable resizable BAR support so that BARs for, e.g., GPU cards that are
sized conservatively by default, but can be resized to cover all of the
GPU's VRAM, are resized by the firmware before handing over to the OS.
This is a more appropriate time to perform the resize, as usually, the
boot time GPU driver and the GOP will be up during PCI discovery of the
OS.
Tested on Overdrive B1 with an AMD GPU based on the Oland ASIC and the
Linux radeon driver (which does not implement PCI BAR resizing in the
first place)
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
The VariablePolicyHelperLib is now used by a number of driver types, so
instead of duplicating it, move it into the LibraryClasses.common section.
Signed-off-by: Rebecca Cran <quic_rcran@quicinc.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
BdsDxe depends on VariablePolicyHelperLib, so move it out from
VariableRuntimeDxe.inf and add it to LibraryClasses.DXE_DRIVER and
LibraryClasses.DXE_RUNTIME_DRIVER.
This fixes the build of AMD/OverdriveBoard and
SoftIron/Overdrive1000Board.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3246
MdeLibs.dsc.inc was added for some basic/default library
instances provided by MdePkg and RegisterFilterLibNull Library
was also added into it as the first version of MdeLibs.dsc.inc.
So update platform dsc to consume MdeLibs.dsc.inc for
RegisterFilterLibNull which will be consumed by IoLib and BaseLib.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <leif@nuviainc.com>
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Add the resolution for TimeBaseLib to the various Styx DSCs, which is
now required to build the EmbeddedPkg RTC driver.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
OpenSSL now requires an RngLib. Since we have EFI_RNG_PROTOCOL,
add MdePkg/Library/DxeRngLib/DxeRngLib.inf to fix Overdrive build.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Leif Lindholm <leif@nuviainc.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
The AMD Seattle based platforms have been kept up to date in recent
years, even though the hardware is obsolete and was never available
that widely in the first place.
However, one aspect that has sadly been left behind is the support for
the builtin network controllers. These are only wired up and enabled
on the Overdrive board to begin with, and the driver was only made
available as two separate binary blobs implementing the SNP protocol
for each controller separately, without taking the UEFI driver model
into account.
Even worse, the PHY initialization code that needs to run at boot in
order for the OS to be able to use the device never executes unless
the upper networking layers start the SNP protocol, which doesn't
happen on a fast boot (one that does not use ConnectAll()) unless the
boot target is a network device path.
We cannot fix the driver, but fortunately, there is another way out:
protocols that are installed on a handle during the execution of the
entrypoint of a driver will be connected by the DXE core, and so we
can ensure that the old behavior is retained regardless of whether
ConnectAll() is ever invoked, by reordering the load sequence so that
the upper layer drivers have all been registered by the time the
entrypoints of the SNP drivers are called.
This relies on FV contents to be dispatched in the order they appear
in the .FDF file. The AMD SNP driver as well as the upper layer
drivers in NetworkPkg are UEFI_DRIVER modules, which means their
DEPEXes are implicitly defined as the full set of architectural
PI protocols. This means that all these modules become available for
dispatch at the same time, and their dispatch order is fully defined
by the order of appearance in the FV. Unfortunately, this is an
implementation detail rather than something that is supported by the
PI spec, but this is unlikely to ever change since other platforms
undoubtedly exist that depend on this behavior as well.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Commit 7a1cd6efbb updated the stream ID
assignment for various masters on the Seattle SoC, primarily to address
a conflict between the second SATA port and the crypto accelerator on
platforms that implement them (B1 silicon). Unfortunately, B0 variants
turn out to exist where the stream ID assignment deviates from the
observed assignment on the B0 Overdrive that I tested these changes on,
leading to DMA access faults when using the first SATA port.
Since that port does not share its SMMU with any other masters, let's
revert the change to its stream ID assignment in the device tree, and
switch back to matching the entire range [0x0, 0x1f].
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
DT unit addresses are hex quantities but they should not include
the 0x prefix. Note that this is a cosmetic change only.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Align the DT description of the SMMU topology and stream IDs with the
actual routing of the SoC. As with the preceding IORT change, this is
mostly a cleanup exercise, but it does actually fix an issue with the
CCP crypto accelerator on B1 silicon.
Since the CCP shares its SMMU with the second SATA controller, which
is only enabled on B1 silicon, we can drop the logic that disables
this SMMU on B0 silicon or on platforms that do not expose any SATA
ports on the second controller (such as the Cello).
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
Changes to the core EDK2 repository have caused the build for
Overdrive to break. Move the existing FileHandleLib resolution
to global scope to get things working again.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
This patch updates the platform DSC/FDF files to use the include fragment
files provided by NetworkPkg.
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1722
BaseUefiDecompressLib in MdePkg is the
base UEFI decompress Library.
BaseUefiTianoCustomDecompressLib in MdeModulePkg
implements the base UEFI decompress functionality and
Tiano decompress functionality.
1. TIANOCOMPRESSED rule in OverdriveBoard.fdf
is not used, so remove it.
2. Platform doesn't use the TianoCompress, so do
not have to use BaseUefiTianoCustomDecompressLib,
can use the BaseUefiDecompressLib in MdePkg directly.
3. A common UefiDecompressLib resolution can apply to
all module types now. So keep the common one in
[LibraryClasses.common] section and remove all others.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
We have had capsule support enabled on this platform for a while now, so
let's drop the hacked up flasher tool that we no longer have a need for.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Add the X64 emulator to the build if '-D X64EMU_ENABLE=TRUE' is passed
on the build command line.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Now that DebugAgentSymbolsBaseLib from ArmPkg no longer requires
a DefaultExceptionHandlerLib resolution, drop the overrides from
the [LibraryClasses.SEC] sections of various platforms.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
