summaryrefslogtreecommitdiff
path: root/cmd/Kconfig
diff options
context:
space:
mode:
authorAlexander Graf <agraf@suse.de>2016-03-10 00:27:20 +0100
committerTom Rini <trini@konsulko.com>2016-03-15 21:29:47 -0400
commitb9939336d09ddc01e9e9d4e6a654f54f28decb12 (patch)
tree4a6773b84eb83c6cca9622acdf7e5c9b44203e3c /cmd/Kconfig
parent2a22d05d335975279a7616809c47a3bf03e42994 (diff)
downloadu-boot-imx-b9939336d09ddc01e9e9d4e6a654f54f28decb12.zip
u-boot-imx-b9939336d09ddc01e9e9d4e6a654f54f28decb12.tar.gz
u-boot-imx-b9939336d09ddc01e9e9d4e6a654f54f28decb12.tar.bz2
efi_loader: Add "bootefi" command
In order to execute an EFI application, we need to bridge the gap between U-Boot's notion of executing images and EFI's notion of doing the same. The best path forward IMHO here is to stick completely to the way U-Boot deals with payloads. You manually load them using whatever method to RAM and then have a simple boot command to execute them. So in our case, you would do # load mmc 0:1 $loadaddr grub.efi # bootefi $loadaddr which then gets you into a grub shell. Fdt information known to U-boot via the fdt addr command is also passed to the EFI payload. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> [trini: Guard help text with CONFIG_SYS_LONGHELP] Signed-off-by: Tom Rini <trini@konsulko.com>
Diffstat (limited to 'cmd/Kconfig')
-rw-r--r--cmd/Kconfig7
1 files changed, 7 insertions, 0 deletions
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 2ed0263..7cdff04 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -148,6 +148,13 @@ config CMD_BOOTM
help
Boot an application image from the memory.
+config CMD_BOOTEFI
+ bool "bootefi"
+ depends on EFI_LOADER
+ default y
+ help
+ Boot an EFI image from memory.
+
config CMD_ELF
bool "bootelf, bootvx"
default y