summaryrefslogtreecommitdiff
path: root/fs
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 /fs
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 'fs')
0 files changed, 0 insertions, 0 deletions