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.)
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16913 6f19259b-4bc3-4df7-8a09-765794883524
In the following call chain:
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.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16912 6f19259b-4bc3-4df7-8a09-765794883524
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.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16911 6f19259b-4bc3-4df7-8a09-765794883524
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.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16910 6f19259b-4bc3-4df7-8a09-765794883524
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.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16909 6f19259b-4bc3-4df7-8a09-765794883524
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.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16908 6f19259b-4bc3-4df7-8a09-765794883524
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.
Under MdeModulePkg/Bus/Pci/PciBusDxe/, we have:
PciHostBridgeResourceAllocator() [PciLib.c]
ConstructAcpiResourceRequestor(..., &AcpiConfig) [PciEnumerator.c]
PciResAlloc->SubmitResources(..., &AcpiConfig)
ASSERT_EFI_ERROR ()
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:
switch (Ptr->ResType) {
case 0:
//
// Check invalid Address Sapce Granularity
//
if (Ptr->AddrSpaceGranularity != 32) {
return EFI_INVALID_PARAMETER;
}
Skip EFI_ACPI_ADDRESS_SPACE_DESCRIPTORs with zero AddrLen early. Also,
allow PciHostBridgeResourceAllocator() to proceed to the AllocateResources
phase by setting "ResourceSubmited" to TRUE.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16907 6f19259b-4bc3-4df7-8a09-765794883524
This is our MMIO space map:
> GCD:AddMemorySpace(Base=0000000010000000,Length=000000002EFF0000)
> GcdMemoryType = MMIO
> Capabilities = 0000000000000001
> Status = Success
> GCDMemType Range Capabilities Attributes
> ========== ================================= ================ ================
> NonExist 0000000000000000-0000000003FFFFFF 0000000000000000 0000000000000000
> MMIO 0000000004000000-0000000007FFFFFF C000000000000001 8000000000000001
NorFlashDxe adds this, but does not allocate it.
> NonExist 0000000008000000-000000000900FFFF 0000000000000000 0000000000000000
> MMIO 0000000009010000-0000000009010FFF C000000000000001 8000000000000001
Added by RealTimeClockRuntimeDxe, but also not allocated.
> NonExist 0000000009011000-000000000FFFFFFF 0000000000000000 0000000000000000
> MMIO 0000000010000000-000000003EFEFFFF C000000000000001 0000000000000000
Added by ourselves.
> NonExist 000000003EFF0000-000000003FFFFFFF 0000000000000000 0000000000000000
> SystemMem 0000000040000000-00000000BFFFFFFF 800000000000000F 0000000000000008*
> NonExist 00000000C0000000-0000FFFFFFFFFFFF 0000000000000000 0000000000000000
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.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16906 6f19259b-4bc3-4df7-8a09-765794883524
Currently we allocate IO BARs bottom-up in the
EfiPciHostBridgeAllocateResources phase of the enumeration.
> GCD:AddIoSpace(Base=0000000000000000,Length=0000000000010000)
> GcdIoType = I/O
> Status = Success
> GCDIoType Range
> ========== =================================
> I/O 0000000000000000-000000000000FFFF
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.:
- <http://www.pcisig.com/reflector/msg00459.html>,
- the (new_addr == 0) part in QEMU, pci_bar_address() [hw/pci/pci.c]:
new_addr = pci_get_long(d->config + bar) & ~(size - 1);
last_addr = new_addr + size - 1;
/* Check if 32 bit BAR wraps around explicitly.
* TODO: make priorities correct and remove this work around.
*/
if (last_addr <= new_addr || new_addr == 0 || last_addr >= UINT32_MAX)
{
return PCI_BAR_UNMAPPED;
}
We can avoid this problem by allocating top-down in the IO aperture.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16905 6f19259b-4bc3-4df7-8a09-765794883524
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.
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: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16904 6f19259b-4bc3-4df7-8a09-765794883524
VirtFdtDxe parses the following address space properties from the DTB (and
saves them in PCDs) :
ProcessPciHost: Config[0x3F000000+0x1000000)
Bus[0x0..0xF]
Io[0x0+0x10000)@0x3EFF0000
Mem[0x10000000+0x2EFF0000)@0x0
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.
GCD:AddIoSpace(Base=0000000000000000,Length=0000000000010000)
GcdIoType = I/O
Status = Success
GCDIoType Range
========== =================================
-> I/O 0000000000000000-000000000000FFFF
GCD:AddMemorySpace(Base=0000000010000000,Length=000000002EFF0000)
GcdMemoryType = MMIO
Capabilities = 0000000000000001
Status = Success
GCDMemType Range Capabilities Attributes
========== ================================= ================ ================
NonExist 0000000000000000-0000000003FFFFFF 0000000000000000 0000000000000000
MMIO 0000000004000000-0000000007FFFFFF C000000000000001 8000000000000001
NonExist 0000000008000000-000000000900FFFF 0000000000000000 0000000000000000
MMIO 0000000009010000-0000000009010FFF C000000000000001 8000000000000001
NonExist 0000000009011000-000000000FFFFFFF 0000000000000000 0000000000000000
-> MMIO 0000000010000000-000000003EFEFFFF C000000000000001 0000000000000000
NonExist 000000003EFF0000-000000003FFFFFFF 0000000000000000 0000000000000000
SystemMem 0000000040000000-00000000BFFFFFFF 800000000000000F 0000000000000008*
NonExist 00000000C0000000-0000FFFFFFFFFFFF 0000000000000000 0000000000000000
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16903 6f19259b-4bc3-4df7-8a09-765794883524
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.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16902 6f19259b-4bc3-4df7-8a09-765794883524
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.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16901 6f19259b-4bc3-4df7-8a09-765794883524
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).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16900 6f19259b-4bc3-4df7-8a09-765794883524
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.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16899 6f19259b-4bc3-4df7-8a09-765794883524
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()).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16898 6f19259b-4bc3-4df7-8a09-765794883524
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.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16897 6f19259b-4bc3-4df7-8a09-765794883524
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().
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.Martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16896 6f19259b-4bc3-4df7-8a09-765794883524
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.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16895 6f19259b-4bc3-4df7-8a09-765794883524
This setting makes OvmfPkg/AcpiPlatformDxe not wait for PCI
enumeration to complete before installing ACPI tables.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16886 6f19259b-4bc3-4df7-8a09-765794883524
Roughly, there are two ways to "measure ticks" in UEFI:
- the SetTimer() boot service, which sets up a one-shot or periodic event
callback, and takes the interval length in units of 100ns,
- the Stall() boot service, which stalls the caller (but does not yield
the CPU) for the interval specified. The interval is taken as a number
of microseconds.
If the platform in question also follows the PI (Platform Init)
specification, then it is recommended to implement the above UEFI services
on top of the following DXE Architectural Protocols (described in PI
Volume 2):
- Timer Architectural Protocol:
"Used to set up a periodic timer interrupt using a platform specific
timer, and a processor-specific interrupt vector. This protocol enables
the use of the SetTimer() Boot Service. [...]"
- Metronome Architectural Protocol:
"Used to wait for ticks from a known time source in a platform. This
protocol may be used to implement a simple version of the Stall() Boot
Service. [...]"
Edk2 in general, and ArmVirtualizationQemu in particular, follow the above
pattern.
SetTimer() works correctly. The underlying Timer Architectural Protocol is
provided by "ArmPkg/Drivers/TimerDxe", and that driver calls the internal
function ArmGenericTimerGetTimerFreq() to retrieve the timer frequency.
Ultimately it boils down to reading the CNTFRQ_EL0 register.
The correct behavior of SetTimer() can be observed for example:
- in the grub-efi countdown ("grub-core/kern/arm/efi/init.c"),
- in the Intel BDS front page countdown
("IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c").
However, Stall() doesn't work correctly. The underlying Metronome
Architectural Protocol is provided by "EmbeddedPkg/MetronomeDxe", which
further delegates the job to the TimerLib library class. That in turn is
resolved to the "ArmPkg/Library/ArmArchTimerLib" instance, which
(finally!) takes the timer frequency from "PcdArmArchTimerFreqInHz".
In ArmVirtualizationQemu we currently specify 100MHz for this PCD. Alas,
that's incorect for:
- both QEMU/TCG (which emulates 62.5MHz, see GTIMER_SCALE in
"target-arm/internals.h"),
- and KVM (where the host's virtualized timer can tick at 50 MHz, for
example).
Set the PCD to 0, asking ArmArchTimerLib to interrogate CNTFRQ_EL0 as
well.
The change can be tested with eg. the following callers of Stall():
- the UEFI Shell's countdown -- before it runs "startup.nsh" -- relies on
Stall(),
- the UEFI shell command "stall" also uses Stall(). (Time it with a
stopwatch.)
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16692 6f19259b-4bc3-4df7-8a09-765794883524
A number of tools depend on passing the kernel image, the initial ramdisk,
and the kernel command line to the guest on the QEMU command line (options
-kernel, -initrd, -append, respectively). At the moment, these QEMU
options work, but the guest kernel loaded this way is launched by a
minimal binary firmware that is dynamically composed by QEMU. As a
consequence, such a kernel has no UEFI environment.
This patch enables -kernel, -initrd, -append to work on top of the
ArmVirtualizationQemu firmware build. The approach it takes is different
from how the same functionality is implemented in OvmfPkg.
OvmfPkg contains a full-fledged Linux boot loader (see
"OvmfPkg/Library/PlatformBdsLib/QemuKernel.c" and
"OvmfPkg/Library/LoadLinuxLib/"). OVMF's LoadLinuxLib sets up the required
kernel environment in a sophisticated way (including x86-specific
artifacts like the GDT), calls ExitBootServices() itself (for legacy
kernels without EFI handover protocol), and jumps to the kernel (using x86
assembly).
In ArmVirtualizationPkg's PlatformIntelBdsLib, we require the kernel being
loaded to have an EFI stub -- that is, to be a genuine UEFI application.
(The EFI stub is not an additional burden for guest kernels -- the EFI
stub is a hard requirement anyway because it needs to process the DTB
heavily:
- it removes memory nodes,
- it removes memreserve entries,
- it adds UEFI properties to the "chosen" node,
- it calculates and installs virt-to-phys mappings with
SetVirtualAddressMap() in a way that enables kexec [planned].
Kudos to Ard Biesheuvel for summarizing the above.)
An EFI-stubbed Linux guest kernel can be loaded with plain
gBS->LoadImage(). The EFI stub will look up its own
EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL instance (ie. the device path where
it has been loaded from), and it will locate the initial ramdisk named by
the "initrd" command line parameter as a *sibling file* on the same
device.
The initrd file is then loaded using the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.
This approach enables the EFI stub to load the initial ramdisk from normal
EFI System Partitions, from remote PXE/TFTP directories -- and it enables
us to provide the initrd from memory as well.
In this patch:
- We download the kernel image, the initrd image, and the kernel command
line, using QEMU's fw_cfg interface.
- We create a read-only EFI_SIMPLE_FILE_SYSTEM_PROTOCOL instance that has
just a root directory, with the three downloaded files in it.
- The handle that carries the simple file system has a single-node
VenHw(...) device path (not counting the terminator node).
- We load the EFI-stubbed kernel (which is a UEFI application) with
gBS->LoadImage(), passing "VenHw(...)/kernel" as device path. This
causes gBS->LoadImage() to call back into our filesystem.
- Appended to the downloaded command line, we pass "initrd=initrd" to the
EFI stub.
- Once the EFI stub is running, it loads the initial ramdisk from the
"sibling" device path "VenHw(...)/initrd", also calling back into our
filesystem.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16578 6f19259b-4bc3-4df7-8a09-765794883524
The default value of this PCD (in "IntelFrameworkModulePkg.dec")
identifies the "old shell" from EdkShellBinPkg. Our build includes the
"new" shell from ShellBinPkg/UefiShell/UefiShell.inf; let's specify the
FILE_GUID of that.
Otherwise, no boot option will be generated for the Shell application.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16577 6f19259b-4bc3-4df7-8a09-765794883524
We have all the required pieces in place. Let's call
SetBootOrderFromQemu() in PlatformBdsPolicyBehavior().
We disable OFW-to-UEFI device path fragment translation for virtio-pci,
and enable it only virtio-mmio at this time.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16576 6f19259b-4bc3-4df7-8a09-765794883524
Installing VenHw() device paths with this GUID, for the virtio-mmio
transports that we detect, enables other modules to recognize those
VenHw() nodes. (Note that the actual value doesn't change.)
In addition, to avoid reusing GUIDs in unrelated contexts, detach the
driver's FILE_GUID from its previous value.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16573 6f19259b-4bc3-4df7-8a09-765794883524
In PlatformBdsPolicyBehavior() we should follow the same pattern as in
OvmfPkg's: after the consoles are connected,
- connect all drivers and devices,
- enumerate all boot options,
- enter the Intel BDS FrontPage if the user presses a key different from
Enter.
We set the countdown to 3 seconds, similarly to the timeout that we
specify for ARM BDS.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16569 6f19259b-4bc3-4df7-8a09-765794883524
In the next patch(es) we'll customize the PlatformBdsLib instance used by
ArmVirtualizationQemu.dsc. Let's clone it first verbatim from
ArmPlatformPkg/Library/PlatformIntelBdsLib, changing only its FILE_GUID.
(Also, coding style errors like "missing space before open parenthesis"
and "missing space after comma or semicolon" have been cleaned up.)
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16568 6f19259b-4bc3-4df7-8a09-765794883524
After reviewing OvmfPkg's use of its own QemuFwCfgLib instances, it is
clear that its only pre-DXE fw_cfg dependency concerns S3 support (the
QemuFwCfgS3Enabled() call in "PlatformPei/Platform.c").
For ARM guests, S3 is in the distant future, but we can see several
shorter term applications for fw_cfg that all reside in DXE:
- controlling boot order (to be implemented in PlatformBdsLib for Intel
BDS),
- supporting -kernel / -initrd / -append boot on QEMU (to be implemented
in PlatformBdsLib for Intel BDS, similarly),
- loading and linking ACPI tables,
- installing SMBIOS tables.
Therefore it makes sense to add a simple MMIO-based fw_cfg client library
to ArmVirtualizationPkg that for the moment is only available to
DXE_DRIVER modules.
Because MMIO accesses are costly on KVM/ARM, InternalQemuFwCfgReadBytes()
accesses the fw_cfg data register in full words. This speeds up transfers
almost linearly.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16567 6f19259b-4bc3-4df7-8a09-765794883524
Qemu's firmware configuration interface for ARM consists of two MMIO
registers, a 16-bit selector, and a 64-bit data register that allows the
guest to transfer data with 8, 16, 32, and 64-bit wide accesses. Parse the
base address from the DTB, and expose the registers to the rest of DXE via
dynamic PCDs.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16566 6f19259b-4bc3-4df7-8a09-765794883524
Some AArch64 platforms have RAM and flash devices >4GB.
Update some additional Pcd entries to 64-bit, and change
the corresponding PcdGet32 calls to PcdGet64.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16325 6f19259b-4bc3-4df7-8a09-765794883524
The library already supports UEFI_DRIVER, we just need to relax the
restriction list.
This allows ArmVirtualizationPkg platforms to build applications, like the
UEFI shell.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-By: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16219 6f19259b-4bc3-4df7-8a09-765794883524
Only ArmVirtualizationPkg based platforms are expected to use
the dynamic method to choose between SMC and HVC to invoke PSCI.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16204 6f19259b-4bc3-4df7-8a09-765794883524
This adds support for executing UEFI in a QEMU/mach-virt emulated environment.
The following assumptions are made about the target:
- DRAM base at 0x4000_0000, containing the device tree blob
- DRAM size at least 1 MB
- device tree uses 64-bit physical base addresses and sizes
- ARM architected timer
- Cortex-A15 CPU (if built for 32-bit)
The following information is retrieved from the device tree:
- PL011 UART base address
- GIC base addresses
- virtual timer interrupt
- PL031 RTC base address
- DRAM size, must be at least 128 MB
- virtio MMIO transports
- PSCI 0.2 availability (for reset and poweroff)
The device tree image is relocated and installed as a configuration table
so an EFI stub enabled kernel can be booted directly without the need for
a bootloader.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Casadevall <michael.casadevall@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-By: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16141 6f19259b-4bc3-4df7-8a09-765794883524
This adds 2 implementations of SerialPortLib for device tree based platforms
using a PL011 UART:
- an 'early' one which is completely stateless and uses only fixed PCDs
- a normal one which takes its base address from a HOB containing the base
address discovered in the PEI phase
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-with-remarks-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-By: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16140 6f19259b-4bc3-4df7-8a09-765794883524
This GUID will identify a customized HOB that carries the base address of
the PL011 serial port, for clients that cannot access PCDs.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-By: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16139 6f19259b-4bc3-4df7-8a09-765794883524
This is an implementation of ArmPlatformLib that discovers the size of system
DRAM from a device tree blob located at the address passed in
gArmTokenSpaceGuid.PcdDeviceTreeBaseAddress, which should equal the value in
gArmTokenSpaceGuid.PcdSystemMemoryBase.
As the device tree blob is passed in system DRAM, this library can only be used
if sufficient DRAM is available (>= 128 MB) and if not using shadowed NOR. The
reason for this is that it makes it easier to guarantee that such a device tree
blob at base of DRAM will not be clobbered before we get a chance to preserve it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Casadevall <michael.casadevall@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-By: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16138 6f19259b-4bc3-4df7-8a09-765794883524
This driver enumerates the device nodes in the device tree located at the
base address passed in gArmTokenSpaceGuid.PcdDeviceTreeBaseAddress, and
installs drivers for devices it cares about (GIC interrupt controller, RTC,
architected timer interrupt)
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16137 6f19259b-4bc3-4df7-8a09-765794883524
This is a fork of the ARM PlatformPeiLib for virtual machines. The main
purpose of having this specific implementation is that it allows us to
preserve the device tree blob if it was passed to us in system DRAM.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16136 6f19259b-4bc3-4df7-8a09-765794883524
Introduce gArmVirtualizationTokenSpaceGuid.PcdDeviceTreeBaseAddress and
PcdDeviceTreeInitialBaseAddress, which will be used by virtual machine ports
that discover the system configuration from a flattened device tree DTB image.
The latter is FixedPcd only, and should contain the initial offset of the DTB,
the former may be declared as dynamic, and updated at runtime if the DTB is
relocated before the DXE phase.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16135 6f19259b-4bc3-4df7-8a09-765794883524
To allow a dynamically discovered UART base address, we parse the device
tree early and store the base address in a HOB. To prevent circular
constructor dependencies from interfering with bringing up the serial port
using this dynamic base address, use our own private HobLib with no
dependencies on DebugLib either directly or indirectly through UefiLib.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16134 6f19259b-4bc3-4df7-8a09-765794883524
This adds an implementation of NorFlashPlatformLib that exposes the
two 64 MB NOR flash banks that are provided by QEMU's mach-virt
emulation both in 32-bit and 64-bit mode.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16133 6f19259b-4bc3-4df7-8a09-765794883524
This include file contains platform specific defines, and is shared by
various modules.
Contributed-under: TianoCore Contribution Agreement 1.0
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-By: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16132 6f19259b-4bc3-4df7-8a09-765794883524
Laszlo Ersek
Jordan Justen
Olivier Martin
Leif Lindholm
Michael Casadevall
Ard Biesheuvel