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