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
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
