-
-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No UEFI Shell #208
base: dasharo
Are you sure you want to change the base?
No UEFI Shell #208
Conversation
…RK_ENABLE When trying to build without EFI Shell, a build issue appears saying that PcdAllowHttpConnections is not declared in DEC files referenced in INF files in FDF. It occurred that NetworkPcds.dsc.inc initializes a that PCD, but modules that use this PCD are only built and included into the image if NETWORK_ENABLE is TRUE. As a result a PCD was defined, but not a single module actually existed in the image to use it, i.e. use the NetworkPkg.dec file. This bug lived silently until EFI Shell was removed, because one of the EFI Shell module INF files included NetworkPkg.dec. To solve this, guard the network defines with NETWORK_ENABLE, so that the PCD is only initialized in case where network is actually enabled. Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
…oot options When updating firmware to a build without UEFI Shell, the settings may be preserved, including the boot options from previous firmware, which results in the non-existent UEFI Shell still being presented as an active boot option. To avoid confusion, check the existence of a file before registering a boot option. Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
The UefiDevicePathLib from MdePkg is used everywhere, so no need to define the same library three times in different places. Removed redunant entries with UefiDevicePathLib. Also the FileHandleLib seems to be used by QEMU Q35 target and is not compiled when Shell is removed. Move it to common section with libraries. Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Tested on VP3230 without shell, then with shell to see if the Shell option is created back. Workflows that build all platforms with and without UEFI Shell: https://github.com/Dasharo/coreboot/actions/runs/13203150358 |
@@ -141,6 +153,8 @@ PlatformRegisterFvBootOption ( | |||
ASSERT_EFI_ERROR (Status); | |||
FreePool (DevicePath); | |||
|
|||
// No need to guard here, because an error would be displayed on the screen |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need to guard here
in front of an if
is confusing without knowing context of this commit. Would be clearer to mention file existence explicitly.
Status = EfiBootManagerAddLoadOptionVariable (&NewOption, MAX_UINTN); | ||
ASSERT_EFI_ERROR (Status); | ||
} else if (OptionIndex != -1 && !FileExists) { | ||
// Option exists but no longer in the image. Remove it from boot option list. | ||
Status = EfiBootManagerDeleteLoadOptionVariable (BootOptions[OptionIndex].OptionNumber, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes function for adding an option to remove an already existing one.
I don't really have a better way of implementing it (need some place which can drop all outdated entries and there might be none), but an update to a comment on PlatformRegisterFvBootOption()
to warn about this unexpected behaviour seems warranted.
Necessary fixes for no-Shell builds. Details in commit messages.