Ard Biesheuvel [Sat, 28 Feb 2015 20:33:11 +0000 (20:33 +0000)]
Ovmf/Xen: move XenBusDxe to abstract XENIO_PROTOCOL
While Xen on Intel uses a virtual PCI device to communicate the
base address of the grant table, the ARM implementation uses a DT
node, which is fundamentally incompatible with the way XenBusDxe is
implemented, i.e., as a UEFI Driver Model implementation for a PCI
device.
Ard Biesheuvel [Sat, 28 Feb 2015 20:33:00 +0000 (20:33 +0000)]
Ovmf/Xen: add separate driver for Xen PCI device
Prepare for making XenBusDxe suitable for use with non-PCI devices
(such as the DT node exposed by Xen on ARM) by introducing a separate
DXE driver that binds to the Xen virtual PCI device and exposes the
abstract XENIO_PROTOCOL for XenBusDxe to bind against.
Ard Biesheuvel [Sat, 28 Feb 2015 20:32:50 +0000 (20:32 +0000)]
Ovmf/Xen: introduce XENIO_PROTOCOL
This introduces the abstract XENIO_PROTOCOL that will be used to
communicate the Xen grant table address to drivers supporting this
protocol. Primary purpose is allowing us to change the XenBusDxe
implementation so that it can support non-PCI Xen implementations
such as Xen on ARM.
Ard Biesheuvel [Sat, 28 Feb 2015 20:32:39 +0000 (20:32 +0000)]
Ovmf/Xen: move XenBusDxe hypercall code to separate library
This moves all of the Xen hypercall code that was private to XenBusDxe
to a new library class XenHypercallLib. This will allow us to reimplement
it for ARM, and to export the Xen hypercall functionality to other parts
of the code, such as a Xen console SerialPortLib driver.
This refactors the Xen hypercall implementation that is part of the
XenBusDxe driver, in preparation of splitting it off entirely into
a XenHypercallLib library. This involves:
- removing the dependency on XENBUS_DEVICE* pointers in the XenHypercall()
prototypes
- moving the discovered hyperpage address to a global variable
- moving XenGetSharedInfoPage() to its only user XenBusDxe.c (the shared info
page is not strictly part of the Xen hypercall interface, and is not used
by other expected users of XenHypercallLib such as the Xen console version
of SerialPortLib
- reimplement XenHypercall2() in C and move the indexing of the hyperpage
there; the existing asm implementations are renamed to __XenHypercall2() and
invoked from the new C implementation.
Ard Biesheuvel [Sat, 28 Feb 2015 20:32:16 +0000 (20:32 +0000)]
Ovmf/Xen: fix pointer to int cast in XenBusDxe
On ARM, xen_pfn_t is 64 bits but the size of a pointer is only
32 bits, so casting between them needs to go via (UINTN). Also
move the xen_pfn_t cast outside the shift so that we can avoid
shifting 64-bit quantities on 32-bit architectures, which may
require runtime library support.
Ard Biesheuvel [Sat, 28 Feb 2015 20:32:06 +0000 (20:32 +0000)]
Ovmf/Xen: move Xen interface version to <xen.h>
Tiancore has its private copy of the Xen headers, and all drivers
that depend on it should use the same Xen interface version, so
let's move the #define to xen.h itself.
This implements the function InterlockedCompareExchange16 () for all
architectures, using architecture and toolchain specific intrinsics
or primitive assembler instructions.
Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Olivier Martin <olivier.martin@arm.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16966 6f19259b-4bc3-4df7-8a09-765794883524
Note: these functions are implemented using the exclusive monitor,
which implies that they can only be used after the caches (and hence
the MMU) have been enabled.
Ard Biesheuvel [Sat, 28 Feb 2015 20:31:18 +0000 (20:31 +0000)]
ArmVirtualizationPkg: allow patchable PCD for FV and DT base addresses
Allow the use of patchable PCDs for gArmTokenSpaceGuid.PcdFvBaseAddress
and gArmVirtualizationTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress
by moving them from the [FixedPcd] to the [Pcd] section in the INF file of
PlatformPeiLib.
This implements a MemoryInitPeiLib instance that differs from the
stock ArmPlatformPkg version only in the fact that it does not remove
the memory used by the flash device (FD). The reason is that, when using
PrePi, the DXE core is started immediately and never returns so there is
no reason to preserve any of the memory that the flash device occupied
originally, and it is preferable to release is so that the OS loader
can reuse it. This is especially important for the relocatable PrePi
configuration, which is aimed at being launched from a boot loader that
itself adheres to the Linux arm64 boot protocol.
Ard Biesheuvel [Sat, 28 Feb 2015 20:26:20 +0000 (20:26 +0000)]
ArmVirtualizationPkg: add a relocatable version of PrePi
This patch introduces a relocatable PrePi, which can execute
from arbitrary offsets in RAM. This is intendend to be run
from a boot loader which passes a description of the actual
platform in a device tree, for instance.
This module is based on the PrePi implementations residing under
ArmPlatformPkg.
Ard Biesheuvel [Sat, 28 Feb 2015 20:26:10 +0000 (20:26 +0000)]
ArmVirtualizationPkg: add padding to FDT allocation
Our primary user QEMU/mach-virt presents us with a FDT blob padded
to 64 KB with plenty of room to set additional properties. However,
in the general case, we should only add properties after making sure
there is enough room available.
Ard Biesheuvel [Sat, 28 Feb 2015 20:26:00 +0000 (20:26 +0000)]
ArmVirtualizationPkg: use a HOB to store device tree blob
Instead of using a dynamic PCD, store the device tree address in a HOB
so that we can also run under a configuration that does not support
dynamic PCDs.
This also adds MemoryAllocationLib to the [LibraryClasses] section of
ArmVirtualizationPlatformLib/ArmVirtualizationPlatformLib.inf, as this
dependency was formerly satisfied transitively through one of the
library dependencies that were dropped.
Ard Biesheuvel [Sat, 28 Feb 2015 20:25:48 +0000 (20:25 +0000)]
ArmVirtualizationPkg: move early UART discovery to PlatformPeim
This is partially motivated by the desire to use PrePi in a virt
environment, and in that configuration, ArmPlatformInitializeSystemMemory()
is never called. But actually, this is a more suitable place anyway.
Ard Biesheuvel [Sat, 28 Feb 2015 20:25:38 +0000 (20:25 +0000)]
ArmVirtualizationPkg: allow patchable PCD for device tree base address
To allow a runtime self relocating PrePi instance to discover the base
address of the device tree at runtime, allow the use of a patchable PCD
for gArmVirtualizationTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress.
We will not be using the build time patch tool in this case, but using
a patchable PCD will make the build system aware that its value is not
a compile time constant.
Ard Biesheuvel [Sat, 28 Feb 2015 20:25:26 +0000 (20:25 +0000)]
ArmVirtualizationPkg: add GICv3 detection to VirtFdtDxe
This adds support for detecting the presence of a GICv3 interrupt
controller from the device tree, and recording its distributor and
redistributor base addresses in their respective PCDs.
Ard Biesheuvel [Sat, 28 Feb 2015 20:25:17 +0000 (20:25 +0000)]
ArmPlatformPkg: allow patchable PCD for FD base address
This moves the reference to gArmTokenSpaceGuid.PcdFdBaseAddress
from the [FixedPcd] to the [Pcd] section in the INF file of
PrePiArmPlatformGlobalVariableLib so that its users may choose
to use a patchable PCD instead.
to include PcdsPatchableInModule. This makes the build system correctly
distinguish fixed PCDs from PCDs whose value may be different from the
assigned value at compile time.
Note that this only affects platforms that explicitly mark these PCDs as
PatchableInModule in the DSC. All existing platforms that use FixedPcd
will not be affected by this change.
Ard Biesheuvel [Sat, 28 Feb 2015 20:24:57 +0000 (20:24 +0000)]
ArmPkg: allow HYP timer interrupt to be omitted
The DT binding for the ARM generic timer describes the secure,
non-secure, virtual and hypervisor timer interrupts, respectively.
However, under virtualization, only the virtual timer is usable, and
the device tree may omit the hypervisor timer interrupt. (Other timer
interrupts cannot be omitted simply due to the fact that the virtual
timer is listed third)
Ronald Cron [Thu, 26 Feb 2015 10:57:27 +0000 (10:57 +0000)]
ArmPlatformPkg/ArmJunoDxe: Set the platform dependent FDT device path
The MIDR register of the CPU on which the UEFI firmware is running on
is used to infer if the platform is a Juno r0 or a Juno r1. The right
device path to the platform FDT is then stored in the
"gEmbeddedTokenSpaceGuid.PcdFdtDevicePaths" dynamic PCD.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ronald Cron <Ronald.Cron@arm.com> Reviewed-by: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16939 6f19259b-4bc3-4df7-8a09-765794883524
Ronald Cron [Thu, 26 Feb 2015 10:56:20 +0000 (10:56 +0000)]
ArmPlatformPkg/ArmJunoPkg : Use FdtPlatformDxe driver to install the FDT
Remove the installation of the FDT for Juno into the UEFI Configuration
Table from the Juno specific DXE driver. Use the FdtPlatformDxe driver to
do it instead.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ronald Cron <Ronald.Cron@arm.com> Reviewed-by: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16938 6f19259b-4bc3-4df7-8a09-765794883524
Bruce Cran [Thu, 26 Feb 2015 06:49:31 +0000 (06:49 +0000)]
Clean up GCC build.
Make the Unix Vlv2TbltDevicePkg scripts executable, add shebangs and skip the requirement to press a key when displaying usage text from Build_IFWI.sh.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Bruce Cran <bruce.cran@gmail.com> Reviewed-by: David Wei <david.wei@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16936 6f19259b-4bc3-4df7-8a09-765794883524
The 'setfdt' EFI Shell command allows to define a new FDT
as the prefered one for development purposes. It allows to
trigger the run of the FDT installation process as well.
Please refer to the README.txt file for more comprehensive
description.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ronald Cron <Ronald.Cron@arm.com> Reviewed-by: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16934 6f19259b-4bc3-4df7-8a09-765794883524
Olivier Martin [Wed, 25 Feb 2015 19:15:39 +0000 (19:15 +0000)]
ArmPlatformPkg/ArmVExpressPkg: Added support to differentiate ARMv8 FVP variants
There are three FVP variants for the Base and Foundation models:
- model with GICv2 legacy memory map (same location as the Versatile Express model)
- model with GICv2 and Base model memory map
- model with GICv3 and Base model memory map
The new code detects the variants to load the appropriate device tree.
Olivier Martin [Wed, 25 Feb 2015 19:04:59 +0000 (19:04 +0000)]
ArmPkg/BdsLib: Added support to change the given DevicePath of a Boot Entry
Some boot entries might not have a EFI Device Path FilePath
attached to it (eg: EFI device Path for removable device path).
This patch allows a support loader to edit the EFI Device Path
and for instance add \EFI\BOOT\BOOT(ARM|AA64).EFI
Olivier Martin [Wed, 25 Feb 2015 18:49:51 +0000 (18:49 +0000)]
ArmPlatformPkg/ArmJuno: Use EFI Stub and updated the command line
- 'earlycon' is the new name for 'earlyprintk'
- Support Linux EFI stub by default
- The command line is expected to be in unicode when
booting an EFI application.
Olivier Martin [Wed, 25 Feb 2015 18:42:36 +0000 (18:42 +0000)]
ArmPkg/ArmGic: Fix GICv3 in GICv2 legacy mode
- GIC distributor needs to be programmed to target interrupts
on the boot CPU using the Interrupt Processor Targets Registers
- Enabling the GIC Distributor is different following the value
of GICD_CTLR.ARE_NS.
Detect the video displays dynamically, and add them to the console and
error output variables.
Add a short-form, "wild card" USB_CLASS_DEVICE_PATH to the console input
variable, which causes the USB keyboard to be handled automatically.
Add the fixed location serial console to all of the console input, console
output, and error output variables.
This patch enables QEMU users to drop "addr=..." PCI address
specifications from the -device options (or to use whatever addresses they
like). For example, the following works:
Laszlo Ersek [Wed, 25 Feb 2015 17:53:55 +0000 (17:53 +0000)]
ArmVirtualizationPkg: PlatformIntelBdsLib: remove ties to ARM BDS
In this patch we remove all dependencies on ARM BDS libraries. We also
remove empty and/or unneeded functions, includes, etc.
PlatformIntelBdsLib "goes back to basics" temporarily -- there are no
consoles configured, and it's practically not possible to interact with
the user interface. Bisection remains available in the sense that
"ArmVirtualizationQemu.dsc" continues to build and should boot preexistent
boot options, but user interaction does regress temporarily.
The reason for this is that it's preferable to keep this patch and the
next one separate for readability's sake -- they amount to a rewrite from
scratch.
Olivier Martin [Wed, 25 Feb 2015 02:24:04 +0000 (02:24 +0000)]
MdeModulePkg/FvSimpleFileSystemDxe: Fixed ARM compiler error
Some compilers requires an empty line at the end of the file.
ARM compiler version 5 is one of these compilers:
error #1-D: last line of file ends without a newline
Alex Graf's QEMU patchset enables "-device VGA" for the virt machtype as
well. We can now include OvmfPkg/QemuVideoDxe in the firmware, and set
PcdDefaultConOutPaths such that the console output is multiplexed to the
video window as well. (Our platform BDS lib doesn't (yet) locate the VGA
device automatically.)
OvmfPkg/PlatformDxe is included too; it allows users to select a video
resolution. (Note that PcdSetupVideoHorizontalResolution and
PcdSetupVideoVerticalResolution are independent; see git commit 848834cb
(SVN r16311) for explanation.)
PlatformBdsPolicyBehavior()
PlatformBdsConnectConsole()
InitializeConsolePipe() x 3
BdsConnectDevicePath() [ArmPkg/Library/BdsLib/BdsFilePath.c]
the three InitializeConsolePipe() function calls pass through
- (&gST->ConsoleOutHandle, &gST->ConOut),
- (&gST->ConsoleInHandle, &gST->ConIn),
- (&gST->StandardErrorHandle, &gST->StdErr)
to BdsConnectDevicePath(), in ArmPkg's BdsLib.
At least when more than one console device paths are specified in the
ConIn / ConOut / ErrOut variables, the above resuls in:
- unchanged protocol interfaces (ConOut, ConIn, StdErr) in the system
table (because ConSplitterDxe installs its non-NULL interfaces first),
- but, changed handles in the system table.
This effectively separates the handle fields in the system table from the
protocol interfaces in the same that should always be associated with the
handles. The end result is that clients using the handles break (splitting
/ multiplexing doesn't work for them), while clients directly using the
protocol interfaces work.
Therefore, do not attempt to connect consoles separately. ConSplitterDxe
is dispatched before PlatformBdsPolicyBehavior() is called (the latter
happens in the BDS phase), and ConSplitterDxe installs virtual handles and
protocol interfaces for input / output / error.
BdsLibConnectAll() covers all devices, including consoles; as those
consoles are connected, ConPlatformDxe and ConSplitterDxe pick them up
nicely as "slaves". We just need to make sure that the variables are set
first, for the variables -> ConPlatformDxe -> ConSplitterDxe dependency
chain.
Laszlo Ersek [Mon, 23 Feb 2015 16:04:16 +0000 (16:04 +0000)]
ArmVirtualizationPkg: PlatformIntelBdsLib: kernel boot should provide ACPI
If there is a PCI host, then PCI enumeration (which happens inside
BdsLibConnectAll()) blocks ACPI table installation (correctly). Make sure
we install ACPI tables before trying to direct-boot a QEMU kernel.
Laszlo Ersek [Mon, 23 Feb 2015 16:04:11 +0000 (16:04 +0000)]
ArmVirtualizationPkg/ArmVirtualizationQemu: enable PCI support
Beyond including the foundational drivers in the DSC and FDF files, we
enable virtio-over-PCI, and turn on QemuBootOrderLib's OFW-to-UEFI device
path translation for PCI devices.
Laszlo Ersek [Mon, 23 Feb 2015 16:04:07 +0000 (16:04 +0000)]
ArmVirtualizationPkg: clone BasePciExpressLib, cache PCIe config base
The BarExisted() function in
"MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c" raises the TPL to
TPL_HIGH_LEVEL before accessing PCI config space.
The PciExpressLib instance under "MdePkg/Library/BasePciExpressLib" --
serving the PCI config space access -- calls
PcdGet64(PcdPciExpressBaseAddress) in turn, for each such call.
The PcdGet64() function, when issued at TPL_HIGH_LEVEL, triggers an
ASSERT(). PcdGet64() is based on a protocol in this UEFI phase, and
protocol handler services are not allowed above TPL_NOTIFY (see Table 23
"TPL Restrictions" in the UEFI spec).
Clone the library, and in a new constructor, cache the PCD in a global
variable.
Laszlo Ersek [Mon, 23 Feb 2015 16:04:00 +0000 (16:04 +0000)]
ArmVirtualizationPkg/PciHostBridgeDxe: handle 0 in GetProposedResources()
When there are no devices connected to the root bridge, no resources are
needed. GetProposedResources() currently considers this an invalid
condition (the PI spec doesn't regulate it).
Emitting an empty set of EFI_ACPI_ADDRESS_SPACE_DESCRIPTORs, followed by
the required EFI_ACPI_END_TAG_DESCRIPTOR, allows
PciHostBridgeResourceAllocator() [MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c]
to advance.
Laszlo Ersek [Mon, 23 Feb 2015 16:03:56 +0000 (16:03 +0000)]
ArmVirtualizationPkg/PciHostBridgeDxe: skip 0 AddrLen in SubmitResources()
According to Volume 5 of the PI spec, 10.8.2 PCI Host Bridge Resource
Allocation Protocol, SubmitResources(),
It is considered an error if no resource requests are submitted for a
PCI root bridge. If a PCI root bridge does not require any resources, a
zero-length resource request must explicitly be submitted.
If ConstructAcpiResourceRequestor() finds no resources to request (for
example because no PCI devices are on the root bridge), it places a
zero-length EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR followed by an
EFI_ACPI_END_TAG_DESCRIPTOR in "AcpiConfig"; satisfying the PI spec.
However, PciHostBridgeDxe's SubmitResources() function does not expect
such input; the following part of the code rejects it:
Skip EFI_ACPI_ADDRESS_SPACE_DESCRIPTORs with zero AddrLen early. Also,
allow PciHostBridgeResourceAllocator() to proceed to the AllocateResources
phase by setting "ResourceSubmited" to TRUE.
In the EfiPciHostBridgeAllocateResources phase, we allocate memory BARs
bottom up, from whichever MMIO range comes first and has room left.
Unfortunately, this places memory BARs into MMIO ranges that belong to
other devices. (Arguably, their respective drivers should not just add,
but immediately allocate those ranges as well.)
(
This problem is not seen in OVMF / PcAtChipsetPkg, because there we
allocate bottom-up from the range
[max(2GB, top-of-low-RAM), 0xFC000000).
(See the MMIO resource descriptor HOB created in MemMapInitialization()
[OvmfPkg/PlatformPei/Platform.c].)
That MMIO range fits in the static [2GB, 4GB) aperture given in
"mResAperture" in PcAtChipsetPkg/PciHostBridgeDxe; plus other MMIO
ranges (IO-APIC, HPET, LAPIC, flash chip) are higher than 0xFC000000.
Hence the bottom-up BAR allocation in OvmfPkg always finds the right
MMIO range first.
)
In ArmVirtualizationPkg/PciHostBridgeDxe we can solve the problem by
working our way downwards from the top of our own aperture.
Because the IO aperture is based at zero, the first allocation happens to
get the zero address. However, a zero address for a PCI BAR is considered
unmapped; see eg.:
Laszlo Ersek [Mon, 23 Feb 2015 16:03:42 +0000 (16:03 +0000)]
ArmVirtualizationPkg/PciHostBridgeDxe: MMIO aperture must not be uncached
Quite non-intuitively, we must allow guest-side writes to emulated PCI
MMIO regions to go through the CPU cache, otherwise QEMU, whose accesses
always go through the cache, may see stale data in the region.
This change makes no difference for QEMU/TCG, but it is important for
QEMU/KVM, at the moment.
Because gDS->SetMemorySpaceAttributes() is ultimately implemented by
EFI_CPU_ARCH_PROTOCOL.SetMemoryAttributes() -- see
"MdeModulePkg/Core/Dxe/Gcd/Gcd.c" and "ArmPkg/Drivers/CpuDxe/" -- we add
the CPU architectural protocol to the module's DepEx.
In order to allow PCI enumeration to allocate IO and MMIO resources from
the above ranges for devices, we must add the ranges to the Global
Coherency Domain.
There are two ways for that:
- building resource descriptor HOBs in the HOB producer phase (basically,
PEI), and letting the DXE core process them,
- calling gDS->AddIoSpace() and gDS->AddMemorySpace() during DXE.
We opt for the second method for simplicity.
In the address space maps, the corresponding ranges change from
"nonexistent" to "IO" and "MMIO", from which the gDS->AllocateIoSpace()
and gDS->AllocateMemorySpace() services can later allocate PCI BARs.
Set gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize to 16, which determines the
maximum "I/O address width".
This ensures, through the BuildCpuHob() call in
"ArmPkg/Drivers/CpuPei/CpuPei.c", that the inital I/O Space Map will
consist of a 16-bit wide "splittable" entry, when the DXE core starts (see
CoreInitializeGcdServices() in "MdeModulePkg/Core/Dxe/Gcd/Gcd.c"):
GCD:Initial GCD I/O Space Map
GCDIoType Range
========== =================================
NonExist 0000000000000000-000000000000FFFF
Otherwise this range would have size 0, and (since it could not be split)
any gDS->AddIoSpace() calls would fail.
Laszlo Ersek [Mon, 23 Feb 2015 16:03:28 +0000 (16:03 +0000)]
ArmVirtualizationPkg/PciHostBridgeDxe: accommodate general address spaces
The RootBridgeIoCheckParameter() function currently relies on the range
limit being of the form (2^n - 1). This assumption is not necessarily
true; handle the general case.
Laszlo Ersek [Mon, 23 Feb 2015 16:03:21 +0000 (16:03 +0000)]
ArmVirtualizationPkg/PciHostBridgeDxe: IO space is emulated with MMIO
There is no IO space on ARM, and there are no special instructions that
access it. QEMU emulates the IO space for PCI devices with a special MMIO
range. We're ready to use it at this point, we just have to switch the
Io(Read|Write)(8|16|32) primitives to their MMIO counterparts, because in
"MdePkg/Library/BaseIoLibIntrinsic/IoLibArm.c", the IO primitives
correctly ASSERT (FALSE).
Laszlo Ersek [Mon, 23 Feb 2015 16:03:16 +0000 (16:03 +0000)]
ArmVirtualizationPkg/PciHostBridgeDxe: translate addresses for IO
Unlike the one in PcAtChipsetPkg, our PciHostBridgeDxe module must handle
address space translation. IO addresses expressed in the respective
aperture are mapped to a different base in CPU address space.
Laszlo Ersek [Mon, 23 Feb 2015 16:03:11 +0000 (16:03 +0000)]
ArmVirtualizationPkg/PciHostBridgeDxe: abort if there's no PCI host bridge
If VirtFdtDxe found no PCI host in the DTB, then the config space base
address will be left at zero -- the default is set in the DSC --, and we
should exit PciHostBridgeDxe immediately.
This causes gEfiPciRootBridgeIoProtocolGuid not to be installed, which in
turn prevents MdeModulePkg/Bus/Pci/PciBusDxe from binding (see
PciBusDriverBindingSupported()).
Laszlo Ersek [Mon, 23 Feb 2015 16:03:06 +0000 (16:03 +0000)]
ArmVirtualizationPkg/PciHostBridgeDxe: set Root Bridge apertures from PCDs
Our PciHostBridgeDxe module creates one root bridge on the one and only
host bridge. The resource apertures of the root bridge (bus range, IO
space, MMIO space) are configured with the "mResAperture" array, which at
the moment carries static values inherited from PcAtChipsetPkg.
Set the array as first thing from the PCDs that we parsed from the device
tree.
Laszlo Ersek [Mon, 23 Feb 2015 16:03:02 +0000 (16:03 +0000)]
ArmVirtualizationPkg/PciHostBridgeDxe: ECAM enables 4KB config space
The Enhanced Configuration Access Mechanism provides access to 4096
register bytes per PCIe B/D/F. The MAX_PCI_REG_ADDRESS macro that we're
changing here is used by RootBridgeIoCheckParameter() for verifying config
space boundaries in EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Pci.Read() and
.Write().
Laszlo Ersek [Mon, 23 Feb 2015 16:02:55 +0000 (16:02 +0000)]
ArmVirtualizationPkg/PciHostBridgeDxe: clone from PcAtChipsetPkg
MdeModulePkg/Bus/Pci/PciBusDxe depends on
EFI_PCI_HOST_BRIDGE_RESOURCE_ALLOCATION_PROTOCOL and
EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL. Here we clone the driver that produces
these from PcAtChipsetPkg, with the following immediate changes:
- a new FILE_GUID is generated;
- the assembly-language Ia32 / X64 specific IoFifo "accelerators" are not
copied, and their client code (which would be dead code anyway) is
removed;
- UNI files are not copied: they are used in conjunction with the UEFI
Packaging Tool (UPT), but the driver under ArmVirtualizationPkg will not
be part of UDK.
In the Linux kernel tree,
"Documentation/devicetree/bindings/pci/host-generic-pci.txt" describes the
device tree bindings of a Generic PCI host controller.
Recent QEMU patches from Alexander Graf implement such a controller on the
"virt" machine type of qemu-system-(aarch64|arm):
Olivier Martin [Mon, 23 Feb 2015 11:13:58 +0000 (11:13 +0000)]
ShellPkg/UefiShellLib: Fixed ARM compiler error
ARM Compiler version 5 raises the warning/error (warning treated as error):
#191-D: type qualifier is meaningless on cast type
The compiler team said the warning is valid because from the C90 standard,
section 6.5.3 it is specified that "The properties associated with
qualified types are meaningful only for expressions that are lvalues."
Laszlo Ersek [Thu, 19 Feb 2015 23:46:27 +0000 (23:46 +0000)]
OvmfPkg: AcpiPlatformDxe: make dependency on PCI enumeration dynamic
SVN r16411 delayed ACPI table installation until PCI enumeration was
complete, because on QEMU the ACPI-related fw_cfg files should have been
downloaded only after PCI enumeration. Said commit implemented the
dependency by tightening the module's depex.
This patch replaces the EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL depex with a
matching protocol registration callback. The depex was static, and it
could not handle dynamically discovered situations when the dependency
would turn out invalid.
Namely:
- At the moment, the depex in "QemuFwCfgAcpiPlatformDxe.inf" assumes
that "ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc"
lacks PCI support. However, PCI support is about to become run-time
discoverable on that platform. If PCI support is missing, then
ArmVirtualizationPkg will set PcdPciDisableBusEnumeration to TRUE.
Hence, when PcdPciDisableBusEnumeration is TRUE, we invalidate the
dependency by not registering the callback and installing the ACPI
tables right away.
- InitializeXen() in "OvmfPkg/PlatformPei/Xen.c" sets
PcdPciDisableBusEnumeration to TRUE. This causes
PciBusDriverBindingStart() in "MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c"
to set gFullEnumeration to FALSE, which in turn makes PciEnumerator() in
"MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c" branch to
PciEnumeratorLight(). The installation of
EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL at the end of PciEnumerator() is
not reached.
Which means that starting with SVN r16411, AcpiPlatformDxe is never
dispatched on Xen.
Hence, when PcdPciDisableBusEnumeration is TRUE, we invalidate the
dependency by not registering the callback and installing the ACPI
tables right away.
Laszlo Ersek [Thu, 19 Feb 2015 23:45:57 +0000 (23:45 +0000)]
OvmfPkg: AcpiPlatformDxe: extract common entry point
Currently the entry point functions of both driver builds
(AcpiPlatformDxe.inf and QemuFwCfgAcpiPlatformDxe.inf) directly contain
the logic that is different between the two builds.
Because we're going to restructure the entry point logic soon, we'd have
to duplicate the same new code between both entry point functions.
Push down the logic in which they differ to a new function:
- InstallAcpiTables() [AcpiPlatform.c]
- InstallAcpiTables() [QemuFwCfgAcpiPlatform.c]
and extract a common entry point function:
- AcpiPlatformEntryPoint() [EntryPoint.c]
which we can soon modify without code duplication.
Andrew Fish [Tue, 17 Feb 2015 00:05:41 +0000 (00:05 +0000)]
OvmfPkg/build.sh: Use XCODE5 for newer OS X releases
Update OS Major number checking to future proof it, and default to
XCODE5 (clang + lldb).
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Andrew Fish <afish@apple.com> Reviewed-by: Bruce Cran <bruce.cran@gmail.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16879 6f19259b-4bc3-4df7-8a09-765794883524
Ard Biesheuvel [Mon, 16 Feb 2015 10:27:02 +0000 (10:27 +0000)]
ArmPkg/ArmGic: enable ARE bit before driving GICv3 in native mode
The GICv3 driver must use native mode to drive a GICv3 due to
the fact that v2 compatibility is optional in the v3 spec.
However, if v2 compatibility is implemented, it is the default
and needs to be disabled first by setting the Affinity Routing
Enable (ARE) bit.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Olivier Martin <olivier.martin@arm.com>
[added PCD that allows forcing the GICv3 driver to drive the GIC in v2 mode] Signed-off-by: Olivier Martin <olivier.martin@arm.com> Tested-by: Ard Biesheuvel <ard@linaro.org> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16875 6f19259b-4bc3-4df7-8a09-765794883524
Olivier Martin [Mon, 16 Feb 2015 10:23:42 +0000 (10:23 +0000)]
ArmPkg/ArmGic: Use the GIC Redistributor instead of GIC Distributor for GICv3
GICv3 controller with no GICv2 legacy support must use the GIC
Redistributor registers instead of the GIC Distributor registers
for some operations (eg: enable/disable interrupts).
Olivier Martin [Mon, 16 Feb 2015 10:22:07 +0000 (10:22 +0000)]
ArmPkg/ArmGic: Function to locate the current CPU GIC redistributor
CPU GIC Registributors are located next to each other in the GIC Redistributor
space.
The CPU GIC Redistributor is identified by its CPU affinity Aff3.Aff2.Aff1.Aff0.
This function returns the base address of the GIC Redistributor of
the calling CPU.
Olivier Martin [Mon, 16 Feb 2015 10:21:06 +0000 (10:21 +0000)]
ArmPkg/ArmGic: Added GICv3 specific definitions
ARM GICv3 specification introduces some new components and registers.
This patch adds their definitions.
The most important GICv3 component is the GIC Redistributor. It supports
LPIs (Locality-specific peripheral Interrupt), 8+ CPU configuration.
Some GIC distributor registers have moved to the GIC redistributor.
Gabriel Somlo [Fri, 13 Feb 2015 19:50:05 +0000 (19:50 +0000)]
OvmfPkg/SMBIOS: Provide default Type 0 (BIOS Information) structure
Insert a default, OVMF-specific Type 0 (BIOS Information) structure
into the SMBIOS table, unless the underlying guest VM supplies its
own, overriding instance.
As an example, QEMU, while allowing the user to specifically force
generation of a Type 0 structure, will not generate one by default,
considering that task to be the responsibility of the BIOS itself.
Based on an earlier out-of-tree patch by Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16868 6f19259b-4bc3-4df7-8a09-765794883524