In some cases, (e.g., when running QEMU with TrustZone emulation), the
DT may contain DT nodes whose status is set to 'secure'. Similarly, the
status may be set to 'disabled' if the consumer of the DT image is
expected to treat it as if it weren't there.
So check whether a 'status' property is present, and if so, ignore the
node if the status is not 'okay'.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
In some cases, (e.g., when running QEMU with TrustZone emulation), the
DT may contain DT nodes whose status is set to 'secure'. Similarly, the
status may be set to 'disabled' if the consumer of the DT image is
expected to treat it as if it weren't there.
So check whether a 'status' property is present, and if so, ignore the
node if the status is not 'okay'.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Currently, the file GUID reference of the UEFI Shell app is indirected
via the PCD gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile,
which is set to a fixed value for our platforms.
So instead, use the new symbolic GUID added for this purpose, and drop
the reference to this PCD, and to the IntelFrameworkModulePkg package
entirely.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
At this point we're ready to retire QemuFwCfgS3Enabled() from the
QemuFwCfgLib class, together with its implementations in:
- ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
- OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
Extend all modules that call the function with a new QemuFwCfgS3Lib class
dependency. Thanks to the previously added library class, instances, and
class resolutions, we can do this switch now as tightly as possible.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Disable the PL031 RTC DT node unconditionally rather than only when
the DT will be exposed to the OS. This allows us to defer the decision
whether to expose it to the OS to a later time without creating an
additional dependency on the FDT client code by the RTC driver.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
We are now sufficiently equipped to implement the new QemuFwCfgSkipBytes()
API.
The previous patch and this one enable ArmVirtPkg/QemuFwCfgLib to
overwrite part of a writeable fw_cfg file, which will be particularly
useful for the upcoming QEMU_LOADER_WRITE_POINTER command in
OvmfPkg/AcpiPlatformDxe.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359
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: Jordan Justen <jordan.l.justen@intel.com>
We use the "InternalQemuFwCfgReadBytes" static function pointer to
dispatch the reading of fw_cfg bytes between MMIO and DMA. This pointer is
initialized to MMIO, and we set it to DMA in the library constructor if
DMA is available.
Unlike the above, we write fw_cfg bytes only with MMIO at the moment.
Extend the write functionality so that it follows the read pattern:
- introduce the new function typedef WRITE_BYTES_FUNCTION,
- extract the current (MMIO-only) write internals from
QemuFwCfgWriteBytes() to MmioWriteBytes(),
- provide a DMA-based implementation in DmaWriteBytes() -- a thin wrapper
around DmaTransferBytes(),
- set the new static function pointer "InternalQemuFwCfgWriteBytes"
according to the DMA feature provided by QEMU,
- In QemuFwCfgWriteBytes(), call the best available method through
"InternalQemuFwCfgWriteBytes".
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359
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: Jordan Justen <jordan.l.justen@intel.com>
The DmaReadBytes() function that we currently use only for reading --
through the InternalQemuFwCfgReadBytes function pointer, in case the DMA
interface is available -- is suitable with minimal changes for two more
operations provided by the DMA interface, WRITE and SKIP. Expose the
Control parameter in the function prototype, rename the function to
DmaTransferBytes(), and rebase DmaReadBytes() to it.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359
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: Jordan Justen <jordan.l.justen@intel.com>
InternalQemuFwCfgIsAvailable() is an API that is incorrectly exposed by
the "OvmfPkg/Include/Library/QemuFwCfgLib.h" library class header; the API
is meant to be used internally to library instances (if it's needed at
all). ArmVirtPkg's instance has no use for it actually, so simplify the
code and remove the function definition.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
These are deprecated / disabled under the
DISABLE_NEW_DEPRECATED_INTERFACES feature test macro.
Introduce a variable called PcdStatus, and use it to assert the success of
these operations (there is no reason for them to fail here).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=165
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> # RVCT
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
These are deprecated / disabled under the
DISABLE_NEW_DEPRECATED_INTERFACES feature test macro.
Introduce a variable called PcdStatus, and use it to assert the success of
these operations (there is no reason for them to fail here).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=165
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> # RVCT
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
These are deprecated / disabled under the
DISABLE_NEW_DEPRECATED_INTERFACES feature test macro.
Introduce a variable called PcdStatus, and use it to assert the success of
these operations (there is no reason for them to fail here).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=165
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> # RVCT
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
These are deprecated / disabled under the
DISABLE_NEW_DEPRECATED_INTERFACES feature test macro.
Introduce a variable called PcdStatus, and use it to assert the success of
these operations (there is no reason for them to fail here).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=165
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> # RVCT
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
These are deprecated / disabled under the
DISABLE_NEW_DEPRECATED_INTERFACES feature test macro.
Introduce a variable called PcdStatus, and use it to assert the success of
these operations (there is no reason for them to fail here).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=165
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> # RVCT
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
These are deprecated / disabled under the
DISABLE_NEW_DEPRECATED_INTERFACES feature test macro.
Introduce a variable called PcdStatus, and use it to assert the success of
these operations (there is no reason for them to fail here).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=165
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> # RVCT
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Since All the GIC base address variables has been aligned to 64-bit, it
doesn't make sense to continue use MAX_UINT32 in ASSERT() statement, so
this patch uses MAX_UINTN to adapt to this kind of change.
Contributed-under: TianoCore Contribution Agreement 1.0
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Dennis Chen <dennis.chen@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Prototype of BootLogoEnableLogo will change in following patches, so
do not call BootLogoEnableLogo to avoid build failure.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
The FDT client protocol methods dealing with "reg" properties return
the size of a "reg" element. Currently, we have hardcoded this as '8',
since #address-cells == #size-cells == 2 in most cases. However, for
different values, have a single 'reg' element size is not unambiguous,
since - however unlikely - if #address-cells != #size-cells, we do not
know which is which.
So before adding more methods to the protocol, fix up this oversight.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
When parsing the device tree to find the memory node, we are still running
with the MMU off, which means unaligned memory accesses are not allowed.
Since the FDT only mandates 32-bit alignment, 64-bit quantities are not
guaranteed to appear naturally aligned, and so should be accessed using
32-bit accesses instead.
Reported-by: Julien Grall <julien.grall@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
In general, on an ARM system, mapping normal memory as device memory may
have unintended side effects, given that unaligned accesses or loads and
stores with special semantics (e.g., load/store exclusive) may fault or
may not work as expected.
Under KVM, the situation is even worse, since the host may not expect the
guest to perform uncached accesses, and so writes to such an uncached
region may get lost completely.
Since the only safe mapping type under KVM is EFI_MEMORY_WB, remove all
other memory type attributes.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
According to the ACPI 6.0/6.1 spec, the physical base address of GICC,
GICD, GICR and GIC ITS is 64-bit. So change the type of the various GIC
base address PCDs to 64-bit, and fix up all users.
Contributed-under: TianoCore Contribution Agreement 1.0
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Dennis Chen <dennis.chen@arm.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Now that the PCI root bridge driver and various host controller drivers
have been fixed, remove the 4 GB limit on PCI DMA allocation for QEMU's
ECAM PCI host bridge.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
GCC 4.8 in RELEASE mode complains about GetPciIoTranslation () potentially
not assigning IoTranslation, but does not notice that it returns failure in
this case, which means IoTranslation is never referenced *unless* it has
been assigned. So simply set IoTranslation to zero to help the compiler.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
If the pci-host-ecam-generic DT node describes a 64-bit MMIO region,
account for it in the PCI_ROOT_BRIDGE description that we return to
the generic PciHostBridgeDxe implementation, which will be able to
allocate BARs from it without any further changes.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=65
Implement PciHostBridgeLib for DT platforms that expose a PCI root bridge
via a pci-host-ecam-generic DT node. The DT parsing logic is copied from
the PciHostBridgeDxe implementation in ArmVirtPkg, with the one notable
difference that we don't set some of the legacy PCI attributes for IDE
and VGA I/O ranges.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=65
Add handling of the PcdPciIoTranslation PCD, so that modules that include
this library via NULL resolution are guaranteed that it will be set before
they reference it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=65
This updates all assembly source files under ArmVirtPkg to mark
exported functions as ASM_FUNC(), which puts them in a separate
section, allowing the linker to prune code that is left unused.
At the same time, clean up the code to get rid of LoadConstantToReg()
instances involving symbol references, each of which emits an absolute
literal, and hence and entry in the PE/COFF .reloc table.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
(This patch ports OvmfPkg commit 2eb3589860 to ArmVirtPkg. That
functionality was not added to QemuBootOrderLib, because it was (and is)
independent from QEMU and fw_cfg.)
Remove any boot options that point to binaries built into the firmware and
have become stale due to any of the following:
- FvMain's base address or size changed (historical -- see commit
e191a3114f),
- FvMain's FvNameGuid changed,
- the FILE_GUID of the pointed-to binary changed,
- the referenced binary is no longer built into the firmware.
For example, multiple such "EFI Internal Shell" boot options can coexist.
They technically differ from each other, but may not describe any built-in
shell binary exactly. Such options can accumulate in a varstore over time,
and while they remain generally bootable (thanks to the efforts of
BmGetFileBufferByFvFilePath()), they look bad.
Filter out any stale options.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Fixes: https://github.com/tianocore/edk2/issues/107
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
This patch ports Gary's OvmfPkg commit 14b2ebc30c to ArmVirtPkg.
Turns out Gary's argument in 14b2ebc30c is not only valid for Xen. The
same situation arises with QEMU if:
- the user specifies no boot order via fw_cfg at all (so QemuBootOrderLib
won't touch the boot order), and
- the varstore file has just been created from the varstore template.
In this case the user is dropped to the UEFI shell (because the shell is
registered earlier than all the auto-generated options), which is likely
not what the user wants.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Lin <glin@suse.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Switch all users of ArmLib that depend on the MMU routines to the new,
separate ArmMmuLib. This needs to occur in one go, since the MMU
routines are removed from ArmLib build at the same time, to prevent
conflicting symbols.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
The interface to PL011UartInitializePort has changed in
ArmPlatformPkg/Drivers/PL011Uart with the title:
"ArmPlatformPkg: Add support to configure PL011 UART clock"
This patch updates the calls to PL011UartInitializePort(), in line with
that change, adding a parameter value using the PCD previously used
directly by the driver.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Evan Lloyd <evan.lloyd@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
ArmVirtPkg's Platform BDS has never had a progress bar. We can easily add
one, by copying the PlatformBootManagerWaitCallback() function verbatim
from
Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
It can be tested by passing the following option to QEMU (5 seconds):
-boot menu=on,splash-time=5000
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
In the course of porting ArmVirtPkg to the MdeModulePkg BDS, commit
1f73aef50c
ArmVirtPkg/PlatformBootManagerLib: add EnableQuietBoot & DisableQuietBoot
open-coded the EnableQuietBoot() function (and its dependencies / friends)
from IntelFrameworkModulePkg BDS.
This code duplication can be avoided; the functionality is available from
the following three libraries in MdeModulePkg:
- BootLogoLib: provides the BootLogoEnableLogo() function. It does not
provide the internal ConvertBmpToGopBlt() function -- that one is
delegated to ImageDecoderLib (function DecodeImage()).
- ImageDecoderLib: a general library that registers decoder plugins for
specific image formats, and provides the generic DecodeImage() on top.
- BmpImageDecoderLib: one of said decoder plugins, for handling BMP images
(which is the format of our logo).
In this patch, we revert 1f73aef50c, and atomically incorporate the
above libraries. This is inspired by Nt32Pkg commit 859e75c4fc42:
Nt32Pkg: Use BootLogoLib for logo and progress bar drawing.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
With OvmfPkg's original QemuBootOrderLib (and USE_OLD_BDS) gone, we no
longer need the BootOptionList parameter in the SetBootOrderFromQemu()
prototype. Update the library class header file (including the function's
documentation), and adapt the library instance and the call sites.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
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: Jordan Justen <jordan.l.justen@intel.com>
UefiBootManagerLib does not provide these functions, we have to implement
them. (EnableQuietBoot() puts up the nice TianoCore logo.)
OvmfPkg commits 817fb3ac2a and 8e8fd30377 have extracted these
functions already,
- from "IntelFrameworkModulePkg/Library/GenericBdsLib/BdsConsole.c"
- to "OvmfPkg/Library/PlatformBootManagerLib/QuietBoot.c".
Copy the latter file, with minimal changes.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
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: Ruiyu Ni <ruiyu.ni@Intel.com>
QemuBootOrderLib can only filter out and reorder boot options; it cannot
create boot options. It relies on Platform BDS to auto-generate all
possible boot options first (for example, for new virtual devices that
have been configured since the last run of the virtual machine). Then it
will decide, case-by-case, whether each of those auto-generated boot
options should be preserved (and at what position), or removed.
Thus far, the only implementation of SetBootOrderFromQemu(), used in
connection with IntelFrameworkModulePkg BDS, has expected said complete
boot option list as an input parameter:
BdsEntry() [IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c]
// create empty list
InitializeListHead (
&BootOptionList
)
PlatformBdsPolicyBehavior( [ArmVirtPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c]
BootOptionList
)
BdsLibConnectAll()
BdsLibEnumerateAllBootOption(
BootOptionList
)
// at this point, BootOptionList starts with the preexistent boot
// options, and ends with the auto-generated options
SetBootOrderFromQemu( [OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c]
BootOptionList
)
// write out changed boot order to UEFI variables
// The "BootOrder" variable may have changed. Refresh BootOptionList
// from it, and return it to BdsEntry().
With MdeModulePkg BDS, a BootOptionList is not propagated from BdsEntry()
to SetBootOrderFromQemu() and back. All processing is based directly on
the underlying "BootOrder" and "Boot####" variables.
In OvmfPkg, commit d27ec22d11 introduced a new instance of
QemuBootOrderLib, called QemuNewBootOrderLib. It is based on
UefiBootManagerLib, and rather than taking a complete BootOptionList as a
parameter, it expects that the "BootOrder" and "Boot####" variables are
complete in the above sense.
Rebase the boot order manipulation to UefiBootManagerLib and
QemuNewBootOrderLib, while keeping the requirement satisfied, like this:
BdsEntry() [MdeModulePkg/Universal/BdsDxe/BdsEntry.c]
PlatformBootManagerAfterConsole() [ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c]
EfiBootManagerConnectAll()
EfiBootManagerRefreshAllBootOption()
// at this point all auto-generated options exist at the end of
// "BootOrder"
SetBootOrderFromQemu() [OvmfPkg/Library/QemuNewBootOrderLib/QemuBootOrderLib.c]
// read boot options from "BootOrder" and "Boot####", then
// manipulate them
This patch parallels OvmfPkg commit 04fe914ba5.
Once the USE_OLD_BDS fallback is removed from OvmfPkg, the parameter list
of the SetBootOrderFromQemu() prototype can be updated to VOID.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
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: Ruiyu Ni <ruiyu.ni@Intel.com>
Register the Enter key as the continue key (hot key to skip the boot
timeout). Map the F2 and ESC keys to the UI. Register the memory-mapped
Shell boot option.
The patch parallels OvmfPkg commit 07dd96e820. The
PlatformRegisterFvBootOption() and PlatformRegisterOptionsAndKeys()
functions are copied almost verbatim. The only changes are: internal
linkage for these functions (i.e., STATIC), and mentioning the ESC key in
the comments.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
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: Ruiyu Ni <ruiyu.ni@Intel.com>
MdeModulePkg/BDS doesn't launch the UI (Boot Manager Menu) from the
platform side. The platform is expected to store the boot timeout only, in
PcdPlatformBootTimeOut. This is usually done in
PlatformBootManagerBeforeConsole().
(ArmVirtXen is not modified, as it uses PlatformIntelBdsLib from
ArmPlatformPkg, not ArmVirtPkg.)
The patch parallels OvmfPkg commit 8dc0f0a6aa.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
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: Ruiyu Ni <ruiyu.ni@Intel.com>
With IntelFrameworkModulePkg BDS, the platform code is responsible for
updating console variables (e.g., with BdsLibUpdateConsoleVariable()), and
then connecting them (e.g., with BdsLibConnectAllDefaultConsoles()). This
is usually (although not necessarily) done in PlatformBdsPolicyBehavior().
With MdeModulePkg BDS, the platform is responsible for updating the
console variables in PlatformBootManagerBeforeConsole(). When that
function returns, BdsEntry() will automatically connect the consoles; the
platform is not responsible for the connection.
IntelFrameworkModulePkg MdeModulePkg
BdsEntry BdsEntry
PlatformBdsInit PlatformBootManagerBeforeConsole
+----> EfiBootManagerUpdateConsoleVariable
|
dispatch Driver#### | dispatch Driver####
| +> connect consoles
| |
PlatformBdsPolicyBehavior | | PlatformBootManagerAfterConsole
BdsLibUpdateConsoleVariable <--+ |
BdsLibConnectAllDefaultConsoles <+
display splash screen display splash screen
Thus, move the console variable massaging from the beginning of
PlatformBootManagerAfterConsole() (originally PlatformBdsPolicyBehavior())
to the end of PlatformBootManagerBeforeConsole(), and drop the explicit
BdsLibConnectAllDefaultConsoles() call.
This patch parallels OvmfPkg commit e9e9ad644f.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
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: Ruiyu Ni <ruiyu.ni@Intel.com>
The general BDS helper functions are now provided by MdeModulePkg's
UefiBootManagerLib, and no longer by IntelFrameworkModulePkg's
GenericBdsLib.
This patch parallels OvmfPkg commit 2b23b8d45b.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
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: Ruiyu Ni <ruiyu.ni@Intel.com>
In this rather mechanical patch, we replace the calls to GenericBdsLib's
BdsLibUpdateConsoleVariable() with calls to UefiBootManagerLib's
EfiBootManagerUpdateConsoleVariable(), which has the same purpose.
The latter uses CONSOLE_TYPE enum constants from
"MdeModulePkg/Include/Library/UefiBootManagerLib.h", for identifying the
console type / underlying UEFI variable in the first parameter.
This patch parallels OvmfPkg commit 9dc08ec657.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
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: Ruiyu Ni <ruiyu.ni@Intel.com>