summaryrefslogtreecommitdiffstats
path: root/cmd/bootefi.c
Commit message (Collapse)AuthorAgeFilesLines
* cmd: bootefi: cosmeticSergey Kubushyn2016-06-241-1/+1
| | | | | | | | | | | | | | | | | | Short help (description) in bootefi command has a trailing "\n" that breaks the "help" command output (empty line after "bootefi"). Nothing important, doesn't affect anything but better be fixed in the upcoming release. Still working on i.MX6 and their siblings NAND U-Boot update -- it works here but not ready for a submission yet. Anyway it is for the next cycle, not going to go into this release because it is too big and may affect something else. Also have some thoughts about fastboot (using multiple devices) but this will go into separate email with RFC. Signed-off-by: Sergey Kubushyn <ksi@koi8.net>
* efi_loader: Move to normal debug infrastructureAlexander Graf2016-06-061-3/+1
| | | | | | | | | | | | We introduced special "DEBUG_EFI" defines when the efi loader support was new. After giving it a bit of thought, turns out we really didn't have to - the normal #define DEBUG infrastructure works well enough for efi loader as well. So this patch switches to the common debug() and #define DEBUG way of printing debug information. Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_loader: Add exit supportAlexander Graf2016-06-061-0/+6
| | | | | | | | | | | Some times you may want to exit an EFI payload again, for example to default boot into a PXE installation and decide that you would rather want to boot from the local disk instead. This patch adds exit functionality to the EFI implementation, allowing EFI payloads to exit. Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_loader: Add network access supportAlexander Graf2016-05-271-0/+7
| | | | | | | | | | | | | We can now successfully boot EFI applications from disk, but users may want to also run them from a PXE setup. This patch implements rudimentary network support, allowing a payload to send and receive network packets. With this patch, I was able to successfully run grub2 with network access inside of QEMU's -M xlnx-ep108. Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_loader: Pass fdt address directly to bootefi cmdAlexander Graf2016-04-181-20/+16
| | | | | | | | | | | | | | | The bootefi cmd today fetches its device tree pointer from either the location appointed by "fdt addr" with a fallback to the U-Boot control fdt. This integration is unusual for U-Boot and diverges from the way we usually handle parameters to boot commands. So let's pass the fdt directly into the bootefi command instead and move the control fdt logic into the distro boot script. Signed-off-by: Alexander Graf <agraf@suse.de> Acked-by: Stephen Warren <swarren@wwwdotorg.org> Reviewed-by: Andreas Färber <afaerber@suse.de>
* efi_loader: Put fdt into convenient locationAlexander Graf2016-04-181-4/+26
| | | | | | | | | | | | The uEFI spec doesn't dictate where the device tree should live at, but legacy 32bit ARM grub2 has some assumptions that it may stay at its place when it's already loaded by the firmware. So let's put it somewhere where Linux that comes after would happily find it - around the recommended 128MB line. Signed-off-by: Alexander Graf <agraf@suse.de> Tested-by: Andreas Färber <afaerber@suse.de>
* efi_loader: Use system fdt as fallbackAlexander Graf2016-04-181-6/+31
| | | | | | | | | | | | | | | | When the user did not pass any device tree or the boot script didn't find any, let's use the system device tree as last resort to get something the payload (Linux) may understand. This means that on systems that use the same device tree for U-Boot and Linux we can just share it and there's no need to manually provide a device tree in the target image. While at it, also copy and pad the device tree by 64kb to give us space for modifications. Signed-off-by: Alexander Graf <agraf@suse.de> Tested-by: Andreas Färber <afaerber@suse.de>
* efi_loader: Increase path string to 32 charactersAlexander Graf2016-04-181-1/+1
| | | | | | | | | | | | Whenever we want to tell our payload about a path, we limit ourselves to a reasonable amount of characters. So far we only passed in device names - exceeding 16 chars was unlikely there. However by now we also pass real file path information, so let's increase the limit to 32 characters. That way common paths like "boot/efi/bootaa64.efi" fit just fine. Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_loader: Pass file path to payloadAlexander Graf2016-04-181-7/+25
| | | | | | | | | | | | | | The payload gets information on where it got loaded from. This includes the device as well as file path. So far we've treated both as the same thing and always gave it the device name. However, in some situations grub2 actually wants to find its loading path to find its configuration file. So let's split the two semantically separte bits into separate structs and pass the loaded file name into our payload when we load it using "load". Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_loader: Add el torito supportAlexander Graf2016-04-181-0/+14
| | | | | | | | | | When loading an el torito image, uEFI exposes said image as a raw block device to the payload. Let's do the same by creating new block devices with added offsets for the respective el torito partitions. Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_loader: Add GOP supportAlexander Graf2016-03-271-0/+3
| | | | | | | | | | | | The EFI standard defines a simple boot protocol that an EFI payload can use to access video output. This patch adds support to expose exactly that one (and the mode already in use) as possible graphical configuration to an EFI payload. With this, I can successfully run grub2 with graphical output. Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_loader: Pass proper device path in on bootAlexander Graf2016-03-151-9/+25
| | | | | | | | | | | | | | | | | EFI payloads can query for the device they were booted from. Because we have a disconnect between loading binaries and running binaries, we passed in a dummy device path so far. Unfortunately that breaks grub2's logic to find its configuration file from the same device it was booted from. This patch adds logic to have the "load" command call into our efi code to set the device path to the one we last loaded a binary from. With this grub2 properly detects where we got booted from and can find its configuration file, even when searching by-partition. Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_loader: Call fdt preparation functionsAlexander Graf2016-03-151-0/+8
| | | | | | | | | | | We have a nice framework around image fils to prepare a device tree for OS execution. That one patches in missing device tree nodes and fixes up the memory range bits. We need to call that one from the EFI boot path too to get all those nice fixups. This patch adds the call. Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_loader: Add "bootefi" commandAlexander Graf2016-03-151-0/+182
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>
OpenPOWER on IntegriCloud