Move some PCD settings outs of the [PcdsFixedAtBuild.AARCH64] block,
so that they apply to 32-bit ARM as well. Without this change, the
ARM build doesn't work.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
QEMU/mach-virt is rather unhelpful when it comes to tracking down
NULL pointer dereferences that occur while running in UEFI: since
we have NOR flash mapped at address 0x0, inadvertent reads go
unnoticed, and even most writes are silently dropped, unless you're
unlucky and the instruction in question is one that KVM cannot
emulate, in which case you end up with a QEMU crash like this:
error: kvm run failed Function not implemented
PC=000000013f7ff804 X00=000000013f7ab108 X01=0000000000000064
X02=000000013f801988 X03=00000000800003c4 X04=0000000000000000
X05=0000000096000044 X06=fffffffffffd8270 X07=000000013f7ab4a0
X08=0000000000000001 X09=000000013f803b88 X10=000000013f7e88d0
X11=0000000000000009 X12=000000013f7ab554 X13=0000000000000008
X14=0000000000000002 X15=0000000000000000 X16=0000000000000000
X17=0000000000000000 X18=0000000000000000 X19=0000000000000000
X20=000000013f81c000 X21=000000013f7ab170 X22=000000013f81c000
X23=0000000009000018 X24=000000013f407020 X25=000000013f81c000
X26=000000013f803530 X27=000000013f802000 X28=000000013f7ab270
X29=000000013f7ab0d0 X30=000000013f7fee10 SP=000000013f7a6f30
PSTATE=800003c5 N--- EL1h
and a warning in the host kernel log that load/store instruction
decoding is not supported by KVM.
Given that the first page of the flash device is not actually
used anyway, let's reduce the mappings of the peripheral space
and the flash device (both of which cover page #0) to only cover
what is actually required:
ArmVirtQemu.fdf:
> 0x00001000|0x001ff000
> gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize
ArmVirtQemuKernel.fdf:
> 0x00008000|0x001f8000
> gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize
For ArmVirtQemu, the resulting virtual mapping looks roughly like:
- [0, 4K) : flash, unmapped
- [4K, 2M) : flash, mapped as WB+X RAM
- [2M, 64M) : flash, unmapped
- [64M, 128M) : varstore flash, will be mapped by the NOR flash driver
- [128M, 256M) : peripherals, mapped as device
- [256M, 1GB) : 32-bit MMIO aperture, translated IO aperture, ECAM,
will be mapped by the PCI host bridge driver
- [1GB, ...) : RAM, mapped.
After this change, any inadvertent read or write from/to the first
physical page will trigger a translation fault inside the guest,
regardless of the nature of the instruction, without crashing QEMU.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The primary FV contains the firmware boot image, which is not
runtime updatable in our case. So exposing it to the NOR flash
driver is undesirable, since it may attempt to modify the NOR
flash contents. It is also rather pointless, since we don't
keep anything there that we care to expose. (the SEC and PEI
phase modules are not executable from DXE context, and the
contents of the embedded DXE phase FV are exposed by the DXE
core directly via the FVB2 protocol)
So let's disregard the NOR flash block that covers the primary
FV.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
PcdPrePiCpuMemorySize is no longer used so drop the PCD overrides
from all platform descriptions in ArmVirtPkg.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Derive the size of the GCD memory space map directly from the CPU's
information registers rather than from the PcdPrePiCpuMemorySize PCD,
which will be removed.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Use the new ArmLib helper to read the CPU's physical address limit
so we can drop our own homecooked one.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Currently, we map DRAM as EFI_MEMORY_WB, and the remainder of the
entire virtual address space is mapped with EFI_MEMORY_UC attributes,
regardless of whether any devices actually reside there.
Now that we are relaxing the address space limit to more than 40 bits,
mapping all that address space actually takes up more space in page
tables than we have so far made available as temporary RAM. So let's
get rid of the mapping rather than increasing the available RAM, given
that the mapping is not particularly useful anyway.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Up until now, we have been getting away with not declaring the ECAM
and translated I/O spaces at all in the GCD memory map, simply because
we map the entire address space with device attributes in the early PEI
code, and so the ECAM space will be mapped wherever it ends up.
Now that we are about to make changes to how ArmVirtQemu reasons
about the size of the address space, it would be better to get rid
of this mapping of the entire address space, since it can get
arbitrarily large without real benefit.
So start by mapping the ECAM and translated I/O spaces explicitly,
instead of relying on the early PEI mapping.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
NorFlashQemuLib is one of the last remaining drivers in ArmVirtPkg
that are not based on the device tree received from QEMU.
For ArmVirtQemu, this does not really matter, given that the NOR
flash banks are always the same: the PEI code is linked to execute
in place from flash bank #0, and the fixed varstore PCDs refer to
flash bank #1 directly.
However, ArmVirtQemuKernel can execute at any offset, permitting it
to be used as an intermediary loader when running QEMU with secure
world emulation enabled, in which case NOR flash bank #0 is secure
only and contains the secure world firmware. In this case,
NorFlashQemuLib should not expose the first flash bank at all.
To prevent introducing too much internal knowledge about which flash
bank is accessible under which circumstances, let's switch to using
the DTB to decide which flash banks to expose to the NOR flash driver.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
DT has a [pseudo-]standardized 'status' property that can be set on
any node, and which signifies that a node should be treated as
absent unless it is set to 'ok' or 'okay'. So take this into account
when iterating over nodes.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
When setting up the stack in the startup code and jumping into C code
for the first time, ensure that the frame pointer register is cleared
so that backtraces terminate correctly. Otherwise, output like the
below is shown when encountering an exception on a DEBUG build:
Synchronous Exception at 0x0000000078A14780
PC 0x000078A14780 (0x000078A00000+0x00014780) [ 0] ArmVeNorFlashDxe.dll
PC 0x000078A10634 (0x000078A00000+0x00010634) [ 0] ArmVeNorFlashDxe.dll
PC 0x000078A11CF0 (0x000078A00000+0x00011CF0) [ 0] ArmVeNorFlashDxe.dll
PC 0x000078A11DD0 (0x000078A00000+0x00011DD0) [ 0] ArmVeNorFlashDxe.dll
PC 0x00007BC9D87C (0x00007BC98000+0x0000587C) [ 1] PartitionDxe.dll
PC 0x00007BC99B3C (0x00007BC98000+0x00001B3C) [ 1] PartitionDxe.dll
PC 0x00007F362F50 (0x00007F359000+0x00009F50) [ 2] DxeCore.dll
PC 0x00007BD63BB0 (0x00007BD5B000+0x00008BB0) [ 3] BdsDxe.dll
PC 0x00007BD6EE00 (0x00007BD5B000+0x00013E00) [ 3] BdsDxe.dll
PC 0x00007BD67C70 (0x00007BD5B000+0x0000CC70) [ 3] BdsDxe.dll
PC 0x00007F3724F0 (0x00007F359000+0x000194F0) [ 4] DxeCore.dll
PC 0x00004008FC30
PC 0x000040090130
PC 0x5800F6025800F5E1
Recursive exception occurred while dumping the CPU state
which is rather unhelpful, given that this prevent the remaining debug
output from being printed (register dump, stack dump, fault related
system registers etc)
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
The class name for the "PeiResourcePublicationLib" instance is just
"ResourcePublicationLib", not "PeiResourcePublicationLib". However, no
module included in the ArmVirtPkg platforms depends on this lib class;
remove its resolution.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Add the IPv6 stack to ArmVirtQemu with a cumulative port of the following
OvmfPkg commits:
* 36c6413f76 "OvmfPkg: enable the IPv6 support", 2014-12-19
* 96302b80d9 "OvmfPkg: Enable Network2 Shell Commands for IPv6",
2016-03-08
* 6d0f8941bd "OvmfPkg: always resolve OpenSslLib, IntrinsicLib and
BaseCryptLib", 2017-01-17
* 32e22f20c9 "OvmfPkg: correct the IScsiDxe module included for the IPv6
stack", 2017-01-17
The IPv6-enabled IScsiDxe driver depends on BaseCryptLib, and the
"CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf" instance depends on
IntrinsicLib and OpensslLib. This is why commit 6d0f8941bd is relevant.
However, unlike in OvmfPkg, in ArmVirtPkg we'll precisely track the
firmware features that require these library classes. (The OvmfPkg
discussion was quite complex, and the OvmfPkg solution was a compromise:
<http://mid.mail-archive.com/1484569332-13440-1-git-send-email-jiaxin.wu@intel.com>.)
The ArmVirtXen platform is not extended with the relevant drivers because
currently it doesn't include any networking support.
Cc: Julien Grall <julien.grall@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1007
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Removing rules for Ipf sources file:
* Remove the source file which path with "ipf" and also listed in
[Sources.IPF] section of INF file.
* Remove the source file which listed in [Components.IPF] section
of DSC file and not listed in any other [Components] section.
* Remove the embedded Ipf code for MDE_CPU_IPF.
Removing rules for Inf file:
* Remove IPF from VALID_ARCHITECTURES comments.
* Remove DXE_SAL_DRIVER from LIBRARY_CLASS in [Defines] section.
* Remove the INF which only listed in [Components.IPF] section in DSC.
* Remove statements from [BuildOptions] that provide IPF specific flags.
* Remove any IPF sepcific sections.
Removing rules for Dec file:
* Remove [Includes.IPF] section from Dec.
Removing rules for Dsc file:
* Remove IPF from SUPPORTED_ARCHITECTURES in [Defines] section of DSC.
* Remove any IPF specific sections.
* Remove statements from [BuildOptions] that provide IPF specific flags.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chen A Chen <chen.a.chen@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Switch to the new IoLib implementation that will only use KVM
safe instructions to perform MMIO memory accesses.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Consumers of status code reports may rely on a status code to be
reported when the ReadyToBoot event is signalled. For instance,
FirmwarePerformanceDxe will fail to install the FPDT ACPI table
in this case. So add the missing call.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Resolve the PciCapLib, PciCapPciSegmentLib, and PciCapPciIoLib classes to
their single respective instances under OvmfPkg. Later patches will use
those lib classes in OvmfPkg drivers, some of which are included in
ArmVirt platforms.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Virtio RNG devices are never boot devices, so in commit ff1d0fbfba we
stopped connecting them. This is a problem because an OS boot loader may
depend on EFI_RNG_PROTOCOL to seed the OS's RNG.
Connect Virtio RNG devices again. And, while commit ff1d0fbfba removed
that from PlatformBootManagerAfterConsole(), reintroduce it now to
PlatformBootManagerBeforeConsole() -- this way Driver#### options launched
between both functions may access EFI_RNG_PROTOCOL too.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Fixes: ff1d0fbfba
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1579518
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Port OvmfPkg commit 5c3481b0b6 to ArmVirtPkg. Some explanation should
be in order (because 5c3481b0b6 doesn't offer any):
- The UefiDevicePathLibDevicePathProtocol instance uses the Device Path
Utilities Protocol, produced by DevicePathDxe, for formatting and
parsing the textual device path representation. This allows for a
lighter weight lib instance that gets linked into several DXE modules.
In comparison, the more standalone UefiDevicePathLib instance includes
the formatting and parsing routines in every client module.
- The DXE core needs DevicePathLib before it dispatches DevicePathDxe, so
it needs to stick with the standalone instance.
- DevicePathDxe itself also needs the standalone instance, for
implementing the protocol.
- The DXE-phase PCD driver, "MdeModulePkg/Universal/PCD/Dxe/Pcd.inf",
depends on DevicePathLib via UefiLib and DxeServicesLib at the least; so
with this update, it inherits a dependency on the protocol. In reverse,
DevicePathDxe depends on the PCD Protocol, via PcdLib. The cycle is
broken by using BasePcdLibNull in DevicePathDxe. That restricts it to
FixedAtBuild, Patch, and FeatureFlag PCDs, but that's fine.
Example space savings (using ArmVirtQemu and the GCC5 toolchain):
- NOOPT: 187KB in FVMAIN, 12KB in FVMAIN_COMPACT
- DEBUG: 147KB in FVMAIN, 20KB in FVMAIN_COMPACT
- RELEASE: 123KB in FVMAIN, 17KB in FVMAIN_COMPACT
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=940
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Commit 411a373ed6 ("ArmPkg/TimerDxe: remove workaround for KVM timer
handling") removed the virtual timer handling quirk that cleared the
mask bit in the control register when enabling the timer, under the
assumption that only ancient KVM host implementations required it.
However, Julien reports that Xen also masks the timer interrupt in the
guest view of the timer control register, and therefore needs the same
quirk.
So let's reinstate it, but using a Xen specific implementation of the
timer support library, so that other virt platforms remain unchanged.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Julien Grall <julien.grall@arm.com>
Acked-by: Julien Grall <julien.grall@arm.com>
In spite of both ArmVirtQemu and ArmVirtQemuKernel formatting the variable
store template at build time, link NvVarStoreFormattedLib into
VariableRuntimeDxe via NULL class resolution on both platforms. This lets
us test the depexes implemented in the previous patches.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Steve Capper <steve.capper@linaro.org>
Cc: Supreeth Venkatesh <Supreeth.Venkatesh@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
PlatformHasAcpiDtDxe consumes the DynamicHii PCD called
"gArmVirtTokenSpaceGuid.PcdForceNoAcpi". The PcdGetBool() library call
terminates in gRT->GetVariable(), in the MdeModulePkg/Universal/PCD/Dxe
driver. Put "gEfiVariableArchProtocolGuid" on PlatformHasAcpiDtDxe's DEPEX
so that we not attempt the call before the PCD driver can successfully
read non-volatile variables.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Steve Capper <steve.capper@linaro.org>
Cc: Supreeth Venkatesh <Supreeth.Venkatesh@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Move the TryRunningQemuKernel() call back to its original place. This
improves the UEFI boot time for VMs that have "-kernel", many disks or
NICs, and no "bootindex" properties. A well-known example is
guestfish/libguestfs.
For more info on the TryRunningQemuKernel() location, see the following
commits: 23d04b58e2, a78c4836ea, 158990b941.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Xiang Zheng <xiang.zheng@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Among other things, the header file declares the ArchInitialize()
function, which is called from "PrePi.c", and implemented (dependent on
architecture) in "AArch64/ArchPrePi.c" and "Arm/ArchPrePi.c".
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The header file declares TryRunningQemuKernel(), defined in "QemuKernel.c"
and called from "PlatformBm.c".
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Switch all users of ArmVirt.dsc.inc to the new DebugLib implementation
that was created especially for DXE_RUNTIME_DRIVER modules, ensuring
that DEBUG() calls do not touch the UART at runtime.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=800
Based on content from the following branch/commits:
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport33bab4031aca516b1a612b9f111f2e
The BootGraphicsResourceTableDxe module uses the BmpSupportLib
and SafeIntLib to convert a GOP BLT buffer to a BMP graphics image.
Add library mappings for these new library classes.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Jiewen Yao <jiewen.yao@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: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Bret Barkelew <Bret.Barkelew@microsoft.com>
ArmVirt.dsc.inc sets gEmbeddedTokenSpaceGuid.PcdCacheEnable,
which is unused and about to be deleted. Drop it.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
In order to allow the ArmVirtPkg platforms to be built using the
NOOPT target, add it explicitly to the BUILD_TARGETS define.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
ArmVirtXen is the only remaining consumer of ArmPlatformPkg's
PlatformIntelBdsLib implementation, which is tightly coupled to the
deprecated Intel BDS. So move ArmVirtXen to the generic BDS as well,
allowing us to get rid of PlatformIntelBdsLib entirely.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Julien Grall <julien.grall@linaro.org>
The TFTP command was converted from a NULL class library instance to a
dynamic shell command in commit 0961002352.
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.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
[lersek@redhat.com: extend commit message]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Build-tested-by: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
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.
* EmbeddedPkg/Library/LzmaHobCustomDecompressLib/LzmaHobCustomDecompressLib.inf
EmbeddedPkg/Library/DxeHobPeCoffLib/DxeHobPeCoffLib.inf
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
These libraries are no longer used, so remove them from the tree.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Move to the new ArmVirtMemInfoLib library to retrieve DRAM information
from the platform, so that we can phase out ArmPlatformLib going forward.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
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.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
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.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
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.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Julien Grall <julien.grall@linaro.org>
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.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
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.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
PrePi doesn't use anything defined by this package so drop the bogus
dependency.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
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.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Remove the pointless dependency on ArmPlatformLib: none of the code we
call from it actually does anything useful.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
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.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
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.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Remove GetPlatformPpi() from PrePi: it is not used anywhere.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Instead of invoking the library constructors of some libraries by
hand, invoke the generated function ProcessLibraryConstructorList
in AutoGen.c so all constructors are executed.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Switch to the new, cleaned up PL011UartLib implementation so we will
be able to remove the old one.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Now that the PL031 RTC driver library no longer depends on the ARM
platform specific ArmPlatformSysConfigLib, we no longer need to
implement ArmPlatform.h or have a resolution for that library.
This allows us to get rid of a rather dodgy practice of including
platform headers using compiler flags, which is a bad idea at various
levels.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The VariableRuntimeDxe driver may use CopyMem () on NOR flash regions,
assuming such regions always have full memory semantics. Given that
those regions cannot be mapped as ordinary memory on ARM (due to the
fact that the NOR flash requires device semantics while in write mode)
this prevents us from using BaseMemoryLibOptDxe in VariableRuntimeDxe,
since it may use unaligned accesses and/or DC ZVA instructions, both
of which are incompatible with mappings using device semantics.
Note that there is no way we can work around this by changing the
mapping type between 'memory' and 'device' when switching from read to
write mode and back, because the runtime mapping is created by the OS,
and cannot be changed at will.
So let's just switch to the unaccelerated version of BaseMemoryLib which
does not have the same problem.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Shannon Zhao <zhaoshenglong@huawei.com>
"ArmVirtXen.fdf" pulls in none of the drivers from
"MdeModulePkg/Universal/Network", therefore building them in
"ArmVirtXen.dsc", via "ArmVirt.dsc.inc", is wasted work.
Move the "MdeModulePkg/Universal/Network" drivers from "ArmVirt.dsc.inc"
to "ArmVirtQemu.dsc" and "ArmVirtQemuKernel.dsc".
Place the new block between the "Bds" and "SCSI Bus and Disk Driver"
blocks, similarly to its context in "ArmVirtQemuFvMain.fdf.inc".
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
The virt targets never use non-coherent DMA, so there is no point
in having a shared DmaLib library class resolution pointing to
ArmDmaLib. So drop it.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
A block of settings has been copied around ARM platforms for years.
These are consumed only by Ebl, and since none of the ArmVirtPkg
platforms use that, drop them.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
One of the reasons for introducing virtio-gpu support to OvmfPkg and
ArmVirtpkg was the fact that under KVM virtualization on ARM, the
legacy VGA cannot be used reliably. This is due to an implementation
detail of QEMU+KVM, which remaps cached host memory into the guest
address space as a framebuffer behind a PCI BAR. Given that the purpose
of a memory mapped framebuffer is its side effects, such BARs should
never be mapped cacheable in the guest, and the mismatched attributes
between host and guest result in a loss of coherency, visible as
corruption in the framebuffer image.
This issue does not occur under TCG emulation, nor did we expect it to
actually bring down the guest under KVM, and so it was deemed harmless
to keep support for the VGA device as well. However, as it turns out,
the fact that the framebuffer BAR is mapped using device semantics by
default may result in unalignment faults when we use the ordinary string
copy routines on the contents. In theory, we could work around this by
remapping the BAR as write combining, but it appears the generic PCI
bus driver does not actually implement this.
So let's remove the QemuVideoDxe driver altogether. This may result
in loss of functionality for use cases that rely on the framebuffer
to be directly addressable (such as EFIFB), but given that this never
worked reliably under KVM in the first place, let's not let that stop
us from dropping support for it.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
With the SerialDxe change in commit 4cf3f37c87 ("MdeModulePkg SerialDxe:
Process timeout consistently in SerialRead", 2017-07-18), setting
EFI_SERIAL_INPUT_BUFFER_EMPTY in the "Control" output parameter, in the
GetControl() SerialPortLib function, is no longer a "small optimization".
Namely, due to the SerialDxe change, the GetOneKeyFromSerial() call in
TerminalDxe's TerminalConInTimerHandler() can take very long if the input
queue is empty, even if GetOneKeyFromSerial()'s return value causes the
loop to be exited right after, in the first iteration.
This issue causes a boot hang in ArmVirtQemu: with the input queue empty,
TerminalConInTimerHandler() takes so long to return that, by the time it
returns, there's another execution queued already (due to the associated
timer event being signaled meanwhile). The boot process is stuck in the
timer event handler.
Therefore even the first GetOneKeyFromSerial() iteration must be prevented
in TerminalConInTimerHandler() if the input queue is empty, and that
requires implementing GetControl() for real.
Implement the SetAttributes(), SetControl() and GetControl() APIs (of
SerialPortExtLib origin) in FdtPL011SerialPortLib with calls to matching
PL011UartLib functions. This follows the example of
"ArmPlatformPkg/Library/PL011SerialPortLib" and also matches Star's
original idea under [1].
The patch can be considered a continuation of commit ad7f6bc2e1
("ArmVirtPkg: Use SerialDxe in MdeModulePkg instead of EmbeddedPkg",
2015-11-26), based on the mailing list threads [1] [2] [3].
[1] http://mid.mail-archive.com/1447752930-32880-12-git-send-email-star.zeng@intel.com
[2] http://mid.mail-archive.com/1448243067-1880-12-git-send-email-star.zeng@intel.com
[3] http://mid.mail-archive.com/b748580c-cb51-32c9-acf9-780841ef15da@redhat.com
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Heyi Guo <guoheyi@huawei.com>
Cc: Star Zeng <star.zeng@intel.com>
Originally-suggested-by: Star Zeng <star.zeng@intel.com>
Reported-by: Brijesh Singh <brijesh.singh@amd.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=642
Add top level License.txt file with the BSD 2-Clause
License that is used by the majority of the EKD II open
source project content. Merge copyright statements
from the BSD 2-Clause License files in each package
directory and remove the duplication License.txt
file from package directories.
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Andrew Fish <afish@apple.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
https://bugzilla.tianocore.org/show_bug.cgi?id=629
Move Contributions.txt that contains the TianoCore
Contribution Agreement 1.0 to the root of the edk2
repository and remove the duplicate Contributions.txt
files from all packages.
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Andrew Fish <afish@apple.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Commit 7b1dc6c569 'ArmVirtPkg: switch to generic ResetSystemRuntimeDxe'
replaced all references in ArmVirtPkg to the deprecated ResetRuntimeDxe
from EmbeddedPkg with the well maintained generic alternative that lives
in MdeModulePkg.
However, as it turns out, the generic driver has a dependency on the
library class ReportStatusCodeLib, whose default resolution is an
implementation that is not safe for use at runtime, resulting in crashes
when trying to invoke it from the OS.
Since we have no use for status codes in any of the ArmVirtPkg
platforms, let's replace all resolutions with a common one to the NULL
implementation.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
For obscure reasons, ARM platforms use a different implementation of
the ResetSystem() runtime service call than other platforms. So let's
switch all ArmVirtPkg platforms to the generic version instead.
Given that all platforms use an implementation of EfiResetSystemLib [as
consumed by the ResetRuntimeDxe in EmbeddedPkg that we are replacing]
which is unlikely to be depended upon by out of tree platforms, let's
simply modify this library into an implementation of ResetSystemLib
instead [which is what the generic driver in MdeModulePkg consumes]
This does mean we need to update all clients at the same time, which
is why all changes are part of the same patch.
As before, warm reset and platform specific reset are mapped onto
cold reset (which is the only thing PSCI implements, at least the
version we depend on). The new library function EnterS3WithImmediateWake()
is left unimplemented, as permitted by the ResetSystemLib library class.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Remove the functions now provided by TimeBaseLib from
PL031RealTimeClockLib. Add TimeBaseLib resolution to ArmVirtPkg
in same commit to prevent breakage.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Include XenPlatformHasAcpiDtDxe and PlatformHasAcpiDtDxe in the 32-bit
builds too.
Please see https://bugzilla.tianocore.org/show_bug.cgi?id=524
why it is needed. With this patch my arm uefi VM boots.
Fixes: 3a2c1548fe
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Nerijus Baliūnas <nerijus@users.sourceforge.net>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: move long subj to commit msg body, add short subj]
[lersek@redhat.com: add Fixes reference]
[lersek@redhat.com: keep ACPI DXE modules grouped in QEMU DSCs]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Remove the library class resolution for ARM's BdsLib: no included
module actually depends on it, and it will be removed shortly.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
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>
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>
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>
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>
The build flag and the FeaturePCD have no effect any longer, remove them.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
This will let QEMU's "-no-acpi" option exclusively expose DT vs. ACPI to
the guest. Showing both is never needed (it is actually detrimental to the
adoption of standards, such as SBSA / SBBR).
* Without "-no-acpi", the firmware logs (from PlatformHasAcpiDtDxe)
> Found FwCfg @ 0x9020008/0x9020000
> Found FwCfg DMA @ 0x9020010
> InstallProtocolInterface: [EdkiiPlatformHasAcpi] 0
plus the usual messages. Later the guest kernel logs
> [ 0.000000] efi: SMBIOS 3.0=0x13bdb0000 ACPI 2.0=0x138440000
> MEMATTR=0x13a675018
before it lists the ACPI tables one by one.
In addition, in the guest, the "/sys/firmware/devicetree/*" shell pattern
matches no files, while the "/sys/firmware/acpi/tables/*" pattern matches
the ACPI tables.
* With "-no-acpi", the firmware logs:
> PlatformHasAcpiDtDxe | Found FwCfg @ 0x9020008/0x9020000
> PlatformHasAcpiDtDxe | Found FwCfg DMA @ 0x9020010
> PlatformHasAcpiDtDxe | InstallProtocolInterface:
> PlatformHasAcpiDtDxe | [EdkiiPlatformHasDeviceTree] 0
> FdtClientDxe | OnPlatformHasDeviceTree: exposing DTB @
> FdtClientDxe | 0x13FFBF000 to OS
> ...
> DXE_CORE | Driver [AcpiTableDxe] was discovered but not
> DXE_CORE | loaded!!
> DXE_CORE | Driver [QemuFwCfgAcpiPlatform] was discovered but
> DXE_CORE | not loaded!!
> ...
> RamDiskDxe | RamDiskAcpiCheck: Cannot locate the EFI ACPI
> RamDiskDxe | Table Protocol, unable to publish RAM disks to
> RamDiskDxe | NFIT.
(BootGraphicsResourceTableDxe's ReadyToBoot callback --
InstallBootGraphicsResourceTable() -- handles the lack of
EFI_ACPI_TABLE_PROTOCOL silently.) Later the guest kernel logs
> [ 0.000000] efi: SMBIOS 3.0=0x13bdb0000 MEMATTR=0x138caa018
In addition, in the guest, the "/sys/firmware/devicetree/*" shell pattern
matches the directory "/sys/firmware/devicetree/base", which contains a
large number of DT nodes, while the "/sys/firmware/acpi/tables/*" pattern
matches no files.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1430262
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Replace the dependency on PcdPureAcpiBoot with a Platform Has Device Tree
notification callback. Move the sysconfig table installation from the
entry point function to the callback.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
In this patch, the ACPI protocol / driver chain is enabled dynamically,
when appropriate. This is being done in one larger patch, because
ArmVirt.dsc.inc, where AcpiTableDxe is built, is used by all the platform
DSCs.
No change in behavior should be observable after this patch on any
ArmVirtPkg platform.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
This driver produces the EDKII Platform Has ACPI and Platform Has Device
Tree protocols, exactly matching the current ACPI / DT exposure on Xen,
according to ARM vs. AARCH64. At this point it differs from the QEMU
driver PlatformHasAcpiDtDxe in that this one always installs the DT.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
This driver produces the EDKII Platform Has ACPI and Platform Has Device
Tree protocols, exactly matching the current ACPI / DT exposure on QEMU,
according to ARM vs. AARCH64, and (in the latter case) to PcdPureAcpiBoot.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
This reverts commit 18f6d4df9e.
We realized that DXE drivers that are independent of AcpiPlatformDxe (that
is, independent of QEMU's ACPI generation), such as RamDiskDxe and
BootGraphicsResourceTableDxe, may produce and/or manipulate ACPI tables,
at driver dispatch or even at Ready To Boot.
This makes it unsafe for us to check for ACPI presence in the UEFI system
config table in a Ready To Boot callback, in order to decide about
exposing the DT.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
This reverts commit 78c41ff519.
We realized that DXE drivers that are independent of AcpiPlatformDxe (that
is, independent of QEMU's ACPI generation), such as RamDiskDxe and
BootGraphicsResourceTableDxe, may produce and/or manipulate ACPI tables,
at driver dispatch or even at Ready To Boot.
This makes it unsafe for us to check for ACPI presence in the UEFI system
config table in a Ready To Boot callback, in order to decide about
exposing the DT.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Currently, the file GUID reference of the UEFI Shell app is indirected
via the PCD gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile,
which is set to a fixed value for our platforms.
So instead, use the new symbolic GUID added for this purpose, and drop
the reference to this PCD, and to the IntelFrameworkModulePkg package
entirely.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Instead of looking at the PCD gArmTokenSpaceGuid.PcdSystemMemoryBase
to decide which DT node covers the memory we are already using, query
the GCD memory space map, which is the authoritative source for this
kind of information
This fixes a problem observed by Michael on platforms where this PCD
is of the 'Patchable' type, which means updates to its value do not
propagate to other modules.
Reported-by: Michael Zimmermann <sigmaepsilon92@gmail.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Instead of invoking gDS->SetMemorySpaceAttributes to set the EFI_MEMORY_XP
attribute on newly added regions, which is guaranteed to fail if the same
attribute was not declared as a capability of the region when it as added,
invoke the CPU arch protocol directly to set the EFI_MEMORY_XP attribute
if our memory protection policy demands it.
Reported-by: Michael Zimmermann <sigmaepsilon92@gmail.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
At this point we're ready to retire QemuFwCfgS3Enabled() from the
QemuFwCfgLib class, together with its implementations in:
- ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
- OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
Extend all modules that call the function with a new QemuFwCfgS3Lib class
dependency. Thanks to the previously added library class, instances, and
class resolutions, we can do this switch now as tightly as possible.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
QemuFwCfgS3Enabled() in "ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c"
returns constant FALSE.
The same implementation is now available factored-out in
"OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3Base.c".
Resolve QemuFwCfgS3Lib to BaseQemuFwCfgS3LibNull.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Instead of having a build time switch to prevent the FDT configuration
table from being installed, make this behavior dependent on whether we
are passing ACPI tables to the OS. This is done by looking for the
ACPI 2.0 configuration table, and only installing the FDT one if the
ACPI one cannot be found.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Defer FDT configuration table installation until ReadyToBoot is signaled.
This allows any driver to make modifications in the mean time, and will
also allow us to defer the decision of whether to install it in the first
place to later on in the boot.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Disable the PL031 RTC DT node unconditionally rather than only when
the DT will be exposed to the OS. This allows us to defer the decision
whether to expose it to the OS to a later time without creating an
additional dependency on the FDT client code by the RTC driver.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Include DXE_CORE in the BuildOptions that are set to force 4 KB section
alignment for PE/COFF images in order to allow them to be mapped with
strict memory permissions.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Now that ARM has grown support for managing memory permissions in
ArmMmuLib, we can enable the non-executable DXE stack for all virt
platforms. Note that this includes the AARCH64 Xen platform as well.
Note that this is not [entirely] redundant: the non-executable stack
is configured before DxeCore is invoked. The image and memory protection
features configured during DXE only take affect when the CPU arch
protocol implementation is registered.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Like for AARCH64, enable PE/COFF image and NX memory protection for all
32-bit ARM virt platforms.
Note that this does not [yet] protect EfiLoaderData regions, due to
compatibility issues with GRUB.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
This sets the recently introduced PCD PcdDxeNxMemoryProtectionPolicy to
a value that protects all memory regions except code regions against
inadvertent execution.
Note that this does not [yet] protect EfiLoaderData regions, due to
compatibility issues with shim and GRUB.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Recent changes to ShellPkg require a resolution for UefiBootManagerLib
for all platforms in ArmVirtPkg. So move the resolution to the shared
include ArmVirt.dsc.inc.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Using DxeServices::SetMemorySpaceAttributes to set cacheability
attributes has the side effect of stripping permission attributes,
given that those are bits in the same bitfield, and so setting the
Attributes argument to EFI_MEMORY_WB implies not setting EFI_MEMORY_XP
or EFI_MEMORY_RO attributes.
In fact, the situation is even worse, given that the descriptor returned
by DxeServices::GetMemorySpaceDescriptor does not reflect the permission
attributes that may have been set by the preceding call to
DxeServices::AddMemorySpace if PcdDxeNxMemoryProtectionPolicy has been
configured to map EfiConventionalMemory with non-executable permissions.
Note that this applies equally to the non-executable stack and to PE/COFF
sections that may have been mapped with R-X or RW- permissions. This is
due to the ambiguity in the meaning of the EFI_MEMORY_RO/EFI_MEMORY_XP
attributes when used in the GCD memory map, i.e., between signifying
that an underlying RAM region has the controls to be configured as
read-only or non-executable, and signifying that the contents of a
certain UEFI memory region allow them to be mapped with certain
restricted permissions.
So let's check the policy in PcdDxeNxMemoryProtectionPolicy directly,
and set the EFI_MEMORY_XP attribute if appropriate for
EfiConventionalMemory regions.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
This removes the PCD PcdArmUncachedMemoryMask from ArmPkg, along with
any remaining references to it in various platform .DSC files. It is
no longer used now that we removed the virtual uncached pages protocol
and the associated DebugUncachedMemoryAllocationLib library instance.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
The only observeable effect of having PcdPerformanceLibraryPropertyMask
set to 1 is that a EfiReservedMemory region of 4 pages is allocated right
below the 4 GB mark. This region is out of bounds for the OS, which means
it is not even allowed to map it, to avoid speculative loads from it.
On Linux, this may prevent the kernel from using a 1 GB block mapping for
this region, and instead it has to carve up the block as follows:
0xffffffff80000000-0xffffffffbe000000 992M PMD CON BLK
0xffffffffbe000000-0xffffffffbfe00000 30M PMD BLK
0xffffffffbfe00000-0xffffffffbfff0000 1984K PTE CON
0xffffffffbfff0000-0xffffffffbfffc000 48K PTE
where it would otherwise use a single 1 GB mapping (*), i.e.,
0xffffffff80000000-0xffffffffc0000000 1G PGD
To clarify, the latter is a single 8 byte entry in the top level page
table, whereas in the former case, we have two additional levels of
paging, requiring two extra 4 KB pages (on a 4 KB pagesize kernel).
The real cost, however, is the TLB footprint, which goes up from a
single entry to a number between 90 and 1020, depending on whether
contiguous hints are honoured by the hardware.
So let's remove PcdPerformanceLibraryPropertyMask until we find a reason
why we need it.
(*) provided that no other allocations were deliberately located right
below the 4 GB mark, and that we are running with more than 3 GB of
memory, in which case most allocations will be over 4 GB, given EDK2's
default top-down allocation policy.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The OpensslLibCrypto library instance (which does not contain libssl
functions) is sufficient for the Secure Boot feature. It would not be
sufficient for HTTPS booting (which requires TLS), but in ArmVirtPkg, we
don't even enable plaintext HTTP booting for the time being.
Ease security analysis by excluding libssl functionality from the
OpensslLib instance we use.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Tomas Hoger <thoger@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Enable the new DXE image protection for all image, i.e., FV images but
also external images that originate from disk or the network, such as
OS loaders.
This complements work that is underway on the arm64/Linux kernel side,
to emit the OS loader with 4 KB section alignment, and a suitable split
between code and data.
http://marc.info/?l=linux-arm-kernel&m=148655557227819
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The debug implementation of the UncachedMemoryAllocationLib library
class relies on the creation of an uncached alias of a memory range,
while keeping the original cached mapping, but with read-only attributes
to trap inadvertent write accesses.
This is not a terribly good idea, given that the ARM architecture does
not allow mismatched attributes, and so creating them deliberately is
not something we should encourage by doing it in reference code.
So remove the library, and replace all references to it with a reference
to the non-debug version (unless the platform does not require a resolution
for it in the first place, in which case all UncachedMemoryAllocationLib
references can be removed altogether).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
We are now sufficiently equipped to implement the new QemuFwCfgSkipBytes()
API.
The previous patch and this one enable ArmVirtPkg/QemuFwCfgLib to
overwrite part of a writeable fw_cfg file, which will be particularly
useful for the upcoming QEMU_LOADER_WRITE_POINTER command in
OvmfPkg/AcpiPlatformDxe.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
We use the "InternalQemuFwCfgReadBytes" static function pointer to
dispatch the reading of fw_cfg bytes between MMIO and DMA. This pointer is
initialized to MMIO, and we set it to DMA in the library constructor if
DMA is available.
Unlike the above, we write fw_cfg bytes only with MMIO at the moment.
Extend the write functionality so that it follows the read pattern:
- introduce the new function typedef WRITE_BYTES_FUNCTION,
- extract the current (MMIO-only) write internals from
QemuFwCfgWriteBytes() to MmioWriteBytes(),
- provide a DMA-based implementation in DmaWriteBytes() -- a thin wrapper
around DmaTransferBytes(),
- set the new static function pointer "InternalQemuFwCfgWriteBytes"
according to the DMA feature provided by QEMU,
- In QemuFwCfgWriteBytes(), call the best available method through
"InternalQemuFwCfgWriteBytes".
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The DmaReadBytes() function that we currently use only for reading --
through the InternalQemuFwCfgReadBytes function pointer, in case the DMA
interface is available -- is suitable with minimal changes for two more
operations provided by the DMA interface, WRITE and SKIP. Expose the
Control parameter in the function prototype, rename the function to
DmaTransferBytes(), and rebase DmaReadBytes() to it.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
While debugging OS for ACPI BGRT support (especially on VMs),
it is very useful to have the EFI firmware to export the
ACPI BGRT table.
This patch tries to add this support in ArmVirtPkg.
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
InternalQemuFwCfgIsAvailable() is an API that is incorrectly exposed by
the "OvmfPkg/Include/Library/QemuFwCfgLib.h" library class header; the API
is meant to be used internally to library instances (if it's needed at
all). ArmVirtPkg's instance has no use for it actually, so simplify the
code and remove the function definition.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
These are deprecated / disabled under the
DISABLE_NEW_DEPRECATED_INTERFACES feature test macro.
Introduce a variable called PcdStatus, and use it to assert the success of
these operations (there is no reason for them to fail here).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=165
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # RVCT
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
These are deprecated / disabled under the
DISABLE_NEW_DEPRECATED_INTERFACES feature test macro.
Introduce a variable called PcdStatus, and use it to assert the success of
these operations (there is no reason for them to fail here).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=165
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # RVCT
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
These are deprecated / disabled under the
DISABLE_NEW_DEPRECATED_INTERFACES feature test macro.
Introduce a variable called PcdStatus, and use it to assert the success of
these operations (there is no reason for them to fail here).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=165
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # RVCT
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
These are deprecated / disabled under the
DISABLE_NEW_DEPRECATED_INTERFACES feature test macro.
Introduce a variable called PcdStatus, and use it to assert the success of
these operations (there is no reason for them to fail here).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=165
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # RVCT
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
These are deprecated / disabled under the
DISABLE_NEW_DEPRECATED_INTERFACES feature test macro.
Introduce a variable called PcdStatus, and use it to assert the success of
these operations (there is no reason for them to fail here).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=165
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # RVCT
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
These are deprecated / disabled under the
DISABLE_NEW_DEPRECATED_INTERFACES feature test macro.
Introduce a variable called PcdStatus, and use it to assert the success of
these operations (there is no reason for them to fail here).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=165
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # RVCT
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Recording the top of SEC visible system memory in a global variable is
not necessary, and violates the constraints of the SEC/PEI environment,
given that it may execute from NOR flash. So remove it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Since All the GIC base address variables has been aligned to 64-bit, it
doesn't make sense to continue use MAX_UINT32 in ASSERT() statement, so
this patch uses MAX_UINTN to adapt to this kind of change.
Contributed-under: TianoCore Contribution Agreement 1.0
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Dennis Chen <dennis.chen@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
The entry point function of any UEFI_DRIVER that conforms to the UEFI
driver model must install an instance of the EFI_DRIVER_BINDING_PROTOCOL
on the image handle. Beyond that, the following protocols are optional:
- EFI_COMPONENT_NAME_PROTOCOL
- EFI_COMPONENT_NAME2_PROTOCOL
- EFI_DRIVER_CONFIGURATION_PROTOCOL
- EFI_DRIVER_CONFIGURATION2_PROTOCOL
- EFI_DRIVER_DIAGNOSTICS_PROTOCOL
- EFI_DRIVER_DIAGNOSTICS2_PROTOCOL
The UefiLib functions
- EfiLibInstallAllDriverProtocols()
- EfiLibInstallAllDriverProtocols2()
- EfiLibInstallDriverBindingComponentName2()
are convenience helpers for such UEFI_DRIVERs. They simplify the
installation of the above protocols.
The UefiLib instance in "MdePkg/Library/UefiLib/UefiDriverModel.c" allows
platforms to control these functions through the MdePkg feature PCDs
- PcdComponentNameDisable
- PcdComponentName2Disable
- PcdDriverDiagnosticsDisable
- PcdDriverDiagnostics2Disable
If any of these PCDs are set to TRUE, then the helper functions will not
install the corresponding protocol interfaces on the image handle, even if
the driver passes in non-NULL protocol interfaces.
In other words, at build time, a platform can forcibly prevent all drivers
that employ UefiLib from producing these protocols.
In ArmVirtPkg, that's what we've been doing forever, for no reason at all.
This is why we haven't been seeing component and driver names from the DH,
DEVICES, DRIVERS and DEVTREE shell commands, unlike in OvmfPkg.
The default value for all these PCDs is FALSE, in "MdePkg/MdePkg.dec".
Revert ArmVirtPkg to the sane defaults.
This bug dates back to the inception of ArmVirtPkg (called
ArmPlatformPkg/ArmVirtualizationPkg at the time).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Fixes: 6f5872b1f4
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
One of the following patches will change QemuVideoDxe driver
to use the new FrameBufferLib.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek at redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Prototype of BootLogoEnableLogo will change in following patches, so
do not call BootLogoEnableLogo to avoid build failure.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
The BaseMemoryLibStm implementation under ArmPkg/ is being deprecated,
in favor of the generic versions under MdePkg, now that ARM and AARCH64
support has been added to both the generic C version (BaseMemoryLib) and
the accelerated version (BaseMemoryLibOptDxe). The latter uses unaligned
accesses and special cache maintenance instructions, and can therefore
not be used when the MMU is off.
So move to BaseMemoryLibOptDxe for the DXE phase and later, and to the
generic BaseMemoryLib before that.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Use the FDT client protocol rather than parsing the DT directly using
fdtlib. While we're at it, update the code so it deals correctly with
memory nodes that describe multiple disjoint regions in their "reg"
properties, and make the code work with #address-cells/#size-cells
properties of <1> as well as <2>.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Add high level methods to iterate over all 'reg' properties of all DT
nodes whose device_type properties have the value "memory". Since we are
modifying the FdtClient protocol, update the protocol and the only existing
implementation at the same time.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The FDT client protocol methods dealing with "reg" properties return
the size of a "reg" element. Currently, we have hardcoded this as '8',
since #address-cells == #size-cells == 2 in most cases. However, for
different values, have a single 'reg' element size is not unambiguous,
since - however unlikely - if #address-cells != #size-cells, we do not
know which is which.
So before adding more methods to the protocol, fix up this oversight.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Currently, the code in FdtClientDxe assumes #address-cells/#size-cells
values of <2>. Since DT "reg" properties always consist of <base, size>
tuples, this means the size of the entire property should always be a
multiple of 16 bytes (i.e, 4 * sizeof(UINT32), not 8. So fix this.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
When parsing the device tree to find the memory node, we are still running
with the MMU off, which means unaligned memory accesses are not allowed.
Since the FDT only mandates 32-bit alignment, 64-bit quantities are not
guaranteed to appear naturally aligned, and so should be accessed using
32-bit accesses instead.
Reported-by: Julien Grall <julien.grall@arm.com>
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, on an ARM system, mapping normal memory as device memory may
have unintended side effects, given that unaligned accesses or loads and
stores with special semantics (e.g., load/store exclusive) may fault or
may not work as expected.
Under KVM, the situation is even worse, since the host may not expect the
guest to perform uncached accesses, and so writes to such an uncached
region may get lost completely.
Since the only safe mapping type under KVM is EFI_MEMORY_WB, remove all
other memory type attributes.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The various ArmLib flavors are identical in practice, and a new
ArmBaseLib has been introduced that can replace all of them. So replace
all occurrences with ArmBaseLib.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
According to the ACPI 6.0/6.1 spec, the physical base address of GICC,
GICD, GICR and GIC ITS is 64-bit. So change the type of the various GIC
base address PCDs to 64-bit, and fix up all users.
Contributed-under: TianoCore Contribution Agreement 1.0
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Dennis Chen <dennis.chen@arm.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Now that the PCI root bridge driver and various host controller drivers
have been fixed, remove the 4 GB limit on PCI DMA allocation for QEMU's
ECAM PCI host bridge.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
GCC 4.8 in RELEASE mode complains about GetPciIoTranslation () potentially
not assigning IoTranslation, but does not notice that it returns failure in
this case, which means IoTranslation is never referenced *unless* it has
been assigned. So simply set IoTranslation to zero to help the compiler.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
This code is now no longer used, so remove it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=65
If the pci-host-ecam-generic DT node describes a 64-bit MMIO region,
account for it in the PCI_ROOT_BRIDGE description that we return to
the generic PciHostBridgeDxe implementation, which will be able to
allocate BARs from it without any further changes.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=65
Wire up the FdtPciHostBridgeLib introduced in the previous patch
to the generic PciHostBridgeDxe implementation, and drop the special
ArmVirtPkg version. The former's dependency on gEfiCpuIo2ProtocolGuid
is satisfied by adding ArmPciCpuIo2Dxe.inf as well, and adding the PCD
gArmTokenSpaceGuid.PcdPciIoTranslation as a dynamic PCD.
In terms of functionality, no changes are intended.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=65
Implement PciHostBridgeLib for DT platforms that expose a PCI root bridge
via a pci-host-ecam-generic DT node. The DT parsing logic is copied from
the PciHostBridgeDxe implementation in ArmVirtPkg, with the one notable
difference that we don't set some of the legacy PCI attributes for IDE
and VGA I/O ranges.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=65
Add handling of the PcdPciIoTranslation PCD, so that modules that include
this library via NULL resolution are guaranteed that it will be set before
they reference it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=65
Setting the linux,pci-probe-only was intended to align OSes booting via
DT with OSes booting via ACPI in the way they honor the PCI configuration
performed by the firmware. However, ACPI on arm64 does not currently honor
the firmware's PCI configuration, and the linux,pci-probe-only completely
prevents any PCI reconfiguration from occurring under the OS, including
what is needed to support PCI hotplug.
Since the primary use case was OS access to the GOP framebuffer (which
breaks when the framebuffer BAR is moved when the OS reconfigures the
PCI), we can undo this change now that ArmVirtQemu has moved to a GOP
implementation that does not expose a raw framebuffer in the first place.
This effectively reverts commit 8b816c624d ("ArmVirtPkg/VirtFdtDxe: set
/chosen/linux,pci-probe-only to 1 in DTB")
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=65
In ARM/AARCH64 guests that run on KVM, we can now use virtio-gpu-pci, so
PcdKludgeMapPciMmioAsCached is no longer necessary. Standard VGA continues
to work on TCG without the kludge.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
At this stage, the driver builds, and suffices for testing binding and
unbinding.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Since we now have EBC support for AArch64, enable it by default
on both QEMU and Xen platforms.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ard Biesheuvel
Ruiyu Ni
Laszlo Ersek
chenc2
Gerd Hoffmann
Michael D Kinney
Leif Lindholm
Star Zeng
Paulo Alcantara
Nerijus Baliūnas
Bhupesh Sharma
Dennis Chen