diff options
| author | Alexander Graf <agraf@suse.de> | 2016-03-10 00:27:20 +0100 |
|---|---|---|
| committer | Tom Rini <trini@konsulko.com> | 2016-03-15 21:29:47 -0400 |
| commit | b9939336d09ddc01e9e9d4e6a654f54f28decb12 (patch) | |
| tree | 4a6773b84eb83c6cca9622acdf7e5c9b44203e3c /configs/odroid-xu3_defconfig | |
| parent | 2a22d05d335975279a7616809c47a3bf03e42994 (diff) | |
| download | u-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 'configs/odroid-xu3_defconfig')
0 files changed, 0 insertions, 0 deletions