Pull armpkg no connectall2 #665
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 6 commits
June 5, 2020 18:17
The way the BDS handles the short-form USB device path of the console keyboard relies on USB host controllers to be locatable via their PCI metadata, which implies that these controllers already have a PCI I/O protocol installed on their handle. This is not the case for non-discoverable USB host controllers that are supported by the NonDiscoverable PCI device driver. These controllers must be connected first, or the BDS will never notice their existence, and will not enable any USB keyboards connected through them. Let's work around this by connecting these handles explicitly. This is a bit of a stopgap, but it is the cleanest way of dealing with this without violating the UEFI driver model entirely. This ensures that platforms that do not rely on ConnectAll() will keep working as expected. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Leif Lindholm <leif@nuviainc.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
In preparation of hiding the UEFI Shell boot option as an ordinary boot option, make sure we can invoke it directly using the 's' hotkey. Without ConnectAll() having been called, this results in a shell that may have no block devices or other things connected, so don't advertise the 's' in the console string that is printed at boot - for novice users, we will go through the UiApp which connects everything first. For advanced use, having the ability to invoke the UEFI shell without any devices connected may be an advantage, so let's keep this behavior as is for now. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
As a last resort, drop into the UiApp application when no active boot options could be started. Doing so will connect all devices, and so it will allow the user to enter the Boot Manager submenu and pick a network or removable disk option. Note that this only occurs if even the default removable filepath could not be booted (e.g., \EFI\BOOT\BOOTAA64.EFI on AArch64) Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
UEFI boot options may exist but have the LOAD_OPTION_ACTIVE flag cleared. This means that the boot option should not be selected by default, but it does not mean it should be omitted from the boot selection presented by the boot manager: for this purpose, another flag LOAD_OPTION_HIDDEN exists. Given that the latter flag exists solely for the purpose of omitting boot options from the boot selection menu, and LOAD_OPTION_XXX flags can be combined if desired, hiding inactive boot options as well is a mistake, and violates the intent of paragraph 3.1.3 of the UEFI specification (revision 2.8 errata A). Let's fix this by dropping the LOAD_OPTION_ACTIVE check from the code that populates the boot selection menu. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Leif Lindholm <leif@nuviainc.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Without ConnectAll() being called on the boot path, the UEFI shell will be entered with no block devices or anything else connected, and so for the novice user, this is not a very accommodating environment. Now that we have made the UiApp the last resort on boot failure, and made the UEFI Shell accessible directly via the 's' hotkey if you really need it, let's hide it as an ordinary boot option. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
In order to avoid boot delays from devices such as network controllers that may not even be involved in booting at all, drop the call to EfiBootManagerConnectAll () from the boot path. It will be called by UiApp, so when going through the menu, all devices will be connected as usual, but for the default boot, it is really not necessary so let's get rid of this. Enumerating all possible boot options and creating Boot#### variables for them is equally unnecessary in the default case, and also happens automatically in UiApp, so drop that as well. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.