Given the agreement on the edk2-devel regarding the fact that the
notion whether or not a 'platform has ACPI' is a universal one, move
the PlatformHasAcpi GUID to MdeModulePkg.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: "Zeng, Star" <star.zeng@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Having a three way conditional with callbacks would make sense if the
callbacks weren't (a) identical and (b) didn't return TRUE all the
time. So get rid of the kludge.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Ryan Harkin <ryan.harkin@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
We are switching the Juno platform to the generic host bridge driver,
which involves implementing PciHostBridgeLib for this platform, and
plugging it into MdeModulePkg's PciHostBridgeDxe.inf.
Since the platform descriptions no longer live in upstream EDK2, the
PciHostBridgeLib implementation (which reuses some of the code removed
here) will live there as well. But this PciHostBridgeDxe driver is no
longer used, so remove it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Ryan Harkin <ryan.harkin@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
The ArmJunoDxe driver code registers a callback for the EndOfDxe event,
at which time it does some manipulation of the PCI peripherals on the
board. Given that R0 has no working PCIe, instead of conditionally
performing these operations, omit the registration of the
callback altogether on that platform.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Ryan Harkin <ryan.harkin@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Replace the open coded reimplementation of 'PCI emulation' with a pair
of calls into NonDiscoverableDeviceRegistrationLib to register the OHCI
and EHCI controllers. These will be picked up by the generic driver instead.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Ryan Harkin <ryan.harkin@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
The ArmJunoDxe driver does not actually depend on the deprecated BdsLib
so remove the dependency declaration from the INF file.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Ryan Harkin <ryan.harkin@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Remove ArmShellCmdRunAxf's dependency on the deprecated BdsLib by
cloning the ShutdownUefiBootServices() routine into a local source
file; this is the only BdsLib feature 'runaxf' depends on.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Ryan Harkin <ryan.harkin@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jeff Fan <jeff.fan@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Fix the incorrect comparison between pointer and constant zero character.
https://bugzilla.tianocore.org/show_bug.cgi?id=416
V2: The pointer StringPtr points to a string returned
by ExtractConfig/ExportConfig, if it is NULL, function
InternalHiiIfrValueAction will return FALSE. So in
current usage model, the StringPtr can not be NULL before
using it, so we can add ASSERT here.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Update the method to get PCD information and support empty section.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hess Chen <hesheng.chen@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
Instead of parsing all content of DEC file, just get the package
path only to save time.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hess Chen <hesheng.chen@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
The relocatable build of ArmVirtQemuKernel is designed to be executed
from RAM, and contains some scratch memory at the start of the image
to use as a stack very early on, and to preserve the DTB image received
from QEMU while it discovers and initializes memory.
It turns out that 8 KB is a bit on the small side here, especially when
executing with secure world emulation enabled, in which case there are
additional nodes present.
So increase the slack space to 32 KB.
While at it, remove a stale Xen reference that was copy/pasted when this
file was created.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
In some cases, (e.g., when running QEMU with TrustZone emulation), the
DT may contain DT nodes whose status is set to 'secure'. Similarly, the
status may be set to 'disabled' if the consumer of the DT image is
expected to treat it as if it weren't there.
So check whether a 'status' property is present, and if so, ignore the
node if the status is not 'okay'.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
In some cases, (e.g., when running QEMU with TrustZone emulation), the
DT may contain DT nodes whose status is set to 'secure'. Similarly, the
status may be set to 'disabled' if the consumer of the DT image is
expected to treat it as if it weren't there.
So check whether a 'status' property is present, and if so, ignore the
node if the status is not 'okay'.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
In some cases, (e.g., when running QEMU with TrustZone emulation), the
DT may contain memory nodes whose status is set to 'secure'. Similarly,
the status may be set to 'disabled' if the consumer of the DT image is
expected to treat it as if it weren't there.
So check whether a 'status' property is present, and if so, ignore the
node if the status is not 'okay'.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Add check logic and error message for some keywords validity.
show target address in URL format and MAC address correctly.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo <lubo.zhang@intel.com>
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Cc: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
All the Shell 2.2 features are implemented except DMEM/MM
changes which are pending on spec change.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Kinney D Michael <kinney.d.michael@intel.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
SmmProfile feature required to protect all SMM ranges by structure
mProtectionMemRangeTemplate. This update is to add additonal save SMM ranges
into mProtectionMemRangeTemplate besides the range specified by
mCpuHotPlugData.SmrrBase/mCpuHotPlugData.SmrrSiz.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Internal function IsInSmmRanges() is added t check SMM range by saved SMM ranges
beside by mCpuHotPlugData.SmrrBase/mCpuHotPlugData.SmrrSiz.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Shell 2.2 spec defines =0x/=0X, =H/=h, =S, =L and =P for
hex number, hex array, ascii string, unicode string and
device path data.
The patch adds such support.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chen A Chen <chen.a.chen@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Jeff Fan <jeff.fan@intel.com>
To give platforms some room to decide which DTB is suitable and where
to load it from, load the DTB image indirectly via the new
DtPlatformDtbLoaderLib library class.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Introduce an implementation of the new DtPlatformDtbLoaderLib library
class that simply retrieves the first raw section of an FV file named
'gDtPlatformDefaultDtbFileGuid'.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
To abstract the way a platform reasons about which DTB is appropriate,
and the way it ultimately supplies the DTB image, introduce a new library
class to encapsulate this functionality.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Add the new DtPlatformDxe driver to EmbeddedPkg's .dsc file so that
we can build it outside the context of a platform.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
In general, we should not present two separate (and inevitably different)
hardware descriptions to the OS, in the form of ACPI tables and a device
tree blob. For this reason, we recently added the logic to ArmVirtQemu to
only expose the ACPI 2.0 entry point if no DT binary is being passed, and
vice versa.
However, this is arguably a regression for those who relied on DT
descriptions being available, even if the former behavior can be
restored by passing the -no-acpi switch to QEMU.
So allow a secret handshake with the UEFI Shell, to set a variable that
will result in ACPI to be disabled on subsequent boots even if -no-acpi
was not passed on the QEMU command line.
setvar -nv -bs -guid 50bea1e5-a2c5-46e9-9b3a-59596516b00a ForceNoAcpi =01
To delete the variable and revert to the old situation, simply omit the
value after the =
setvar -nv -bs -guid 50bea1e5-a2c5-46e9-9b3a-59596516b00a ForceNoAcpi =
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Recent changes to the PlatformBootManagerLib implementation in ArmPkg
require its users to define a resolution for BootLogoLib. So add this
missing resolution to Beagle.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
ArmCpuLib is not used, and will be removed. So drop the reference from
our .DSC
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
ArmCpuLib is never used anywhere, and is about to be removed. So remove
any references from our .DSC files.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
As a security measure, some distro toolchains now default to PIC code
generation, allowing executables (as opposed to shared libraries) using
the objects to be built as PIE binaries, which can be loaded at a random
virtual offset.
However, our ELF to PE/COFF generation code does not deal with the
resulting relocation types (i.e., GOT based), and so the use of PIC code
leads to GenFw errors.
Given that
a) our non-PIC PE/COFF executables are already relocatable,
b) PIC code leads to all symbol references to be indirected via GOT
entries containing absolute addresses, each requiring an entry in the
relocation table,
c) the AArch64 ISA makes it perfectly feasible to built PIE executables
from non-PIC code,
there is absolutely no upside to using PIC code for building EDK2 modules,
and so we're better off simply disabling it unconditionally.
Note that when running under the OS, the GOT has an additional advantage,
i.e., that all .text/.rodata pages remain clean and so can be shared between
processes. This does not apply to the UEFI environment, however.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
The new algorithm finds out the more optimal MTRR solution for
current memory type settings.
Compare against the original algorithm, the new one guarantees
to find the correct MTRR solution, but doesn't guarantee to
find the most optimal MTRR solution.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
V2:
- Update correct patch info
V1:
- Add x mode for Brotli and BrotliCompress
- Change Brotli and BrotliCompress format from DOS to UNIX
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bell Song <binx.song@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Issue reported at bugzillar 445.
Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>