This adds all the required modules and library dependencies so that
the ArmVirtualizationQemu platform can be built with support for
UEFI Secure Boot. This support consists of the OpenSSL crypto
library (whose source needs to be downloaded separately), the
authenticated variable store, and authentication of executables
before launching them.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <olivier.martin@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17356 6f19259b-4bc3-4df7-8a09-765794883524
LzmaDecompress support is moving from IntelFrameworkPkg to
MdeModulePkg.
This change ensures ArmPlatformPkg reflects this future change.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
Reviewed-by: Ronald Cron <ronald.cron@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17133 6f19259b-4bc3-4df7-8a09-765794883524
The "virt" machine type of qemu-system-(arm|aarch64) had no PCIe support
prior to qemu commit
4ab29b82 arm: Add PCIe host bridge in virt machine
With that commit, the "virt" board acquired the capability to expose an
XHCI controller. Using a USB keyboard as example, the command line options
were
-device nec-usb-xhci -device usb-kbd
However, due to a slight XHCI emulation bug in QEMU -- dating back to
several years earlier -- edk2's XHCI driver would encounter a failed
ASSERT().
This emulation problem has been fixed in QEMU commit
aa685789 xhci: generate a Transfer Event for each Transfer TRB with the
IOC bit set
and now edk2's XHCI driver works well on QEMU's "nec-usb-xhci" device.
Let's enable the driver in ArmVirtualizationQemu, as XHCI emulation is
reportedly more virtualization-friendly than EHCI, consuming less CPU.
(ArmVirtualizationXen is not modified because it includes no USB-related
drivers at all.)
This patch should not regress existing QEMU command lines (ie. expose the
failed ASSERT()) because QEMU's "-device nec-usb-xhci" has never before
resulted in USB devices that worked with edk2 firmware builds, hence users
have never had a reason to add that option.
Now that they learn about XHCI support in ArmVirtualizationQemu by reading
this commit message, they (or their packagers) will also know to update
qemu to aa685789 or later (in practice that means the upcoming 2.3
release), at least if they want to use '-device nec-usb-xhci' with edk2,
for the first time ever.
Cc: Leif Lindholm <Leif.Lindholm@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Alexander Graf <agraf@suse.de>
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: Leif Lindholm <leif.lindholm@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17053 6f19259b-4bc3-4df7-8a09-765794883524
This enables -D DEBUG_PRINT_ERROR_LEVEL=0x8040004F style command line
options.
Since we're massaging the debug message bitmask anyway, let's update the
description of the individual bits too in the comments, so that they match
"MdePkg/Include/Library/DebugLib.h".
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: Leif Lindholm <leif.lindholm@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16986 6f19259b-4bc3-4df7-8a09-765794883524
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.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <olivier.martin@arm.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@16959 6f19259b-4bc3-4df7-8a09-765794883524
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.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Olivier Martin <olivier.martin@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.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@16956 6f19259b-4bc3-4df7-8a09-765794883524
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.
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>
Reviewed-by: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16923 6f19259b-4bc3-4df7-8a09-765794883524
Similarly to the previous patch, we can now multiplex input from the USB
keyboard.
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@16914 6f19259b-4bc3-4df7-8a09-765794883524
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
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
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
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
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
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
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
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
Ard Biesheuvel
Ruiyu Ni
Olivier Martin
Laszlo Ersek
Jordan Justen
Michael Casadevall