summaryrefslogtreecommitdiffstats
path: root/lib/efi_loader
Commit message (Collapse)AuthorAgeFilesLines
* dm: part: Drop the block_drvr tableSimon Glass2016-05-171-11/+16
| | | | | | | This is not needed since we can use the functions provided by the legacy block device support. Signed-off-by: Simon Glass <sjg@chromium.org>
* efi_loader: Handle memory overflowsAndreas Färber2016-04-181-4/+4
| | | | | | | | | | jetson-tk1 has 2 GB of RAM at 0x80000000, causing gd->ram_top to be zero. Handle this by either avoiding ram_top or by using the same type as ram_top to reverse the overflow effect. Cc: Alexander Graf <agraf@suse.de> Signed-off-by: Andreas Färber <afaerber@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de>
* efi_loader: Expose ascending efi memory mapAlexander Graf2016-04-181-2/+7
| | | | | | | | | | | | The EFI memory map does not need to be in a strict order, but 32bit grub2 does expect it to be ascending. If it's not, it may try to allocate memory inside the U-Boot data memory region. We already sort the memory map in descending order, so let's just reverse it when we pass it to a payload. Signed-off-by: Alexander Graf <agraf@suse.de> Tested-by: Andreas Färber <afaerber@suse.de>
* efi_loader: Always flush in cache line size granularityAlexander Graf2016-04-181-1/+9
| | | | | | | | | | | | The cache line flush helpers only work properly when they get aligned start and end addresses. Round our flush range to cache line size. It's safe because we're guaranteed to flush within a single page which has the same cache attributes. Reported-by: Marek Vasut <marex@denx.de> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Andreas Färber <afaerber@suse.de> Tested-by: Andreas Färber <afaerber@suse.de>
* efi_loader: Increase path string to 32 charactersAlexander Graf2016-04-181-2/+2
| | | | | | | | | | | | 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: Add el torito supportAlexander Graf2016-04-181-0/+35
| | | | | | | | | | 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: Split drive add into functionAlexander Graf2016-04-181-37/+47
| | | | | | | | The snippet of code to add a drive to our drive list needs to get called from 2 places in the future. Split it into a separate function. Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_loader: Always allocate the highest available addressAlexander Graf2016-04-011-0/+29
| | | | | | | | | | | | Some EFI applications (grub2) expect that an allocation always returns the highest available memory address for the given size. Without this, we may run into situations where the initrd gets allocated at a lower address than the kernel. This patch fixes booting in such situations for me. Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_loader: Fix some entry/exit pointsAlexander Graf2016-03-272-7/+11
| | | | | | | | | | | | When switching between EFI context and U-Boot context we need to swap the register that "gd" resides in. Some functions slipped through here, with efi_allocate_pool / efi_free_pool not doing the switch correctly and efi_return_handle switching too often. Fix them all up to make sure we always have consistent register state. Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_loader: Add GOP supportAlexander Graf2016-03-272-0/+153
| | | | | | | | | | | | 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-6/+0
| | | | | | | | | | | | | | | | | 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: hook up in build environmentAlexander Graf2016-03-152-0/+21
| | | | | | | | | | | Now that we have all the bits and pieces ready for EFI payload loading support, hook them up in Makefiles and KConfigs so that we can build. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> [trini: Enable only when we of OF_LIBFDT, disable on kwb and colibri_pxa270] Signed-off-by: Tom Rini <trini@konsulko.com>
* efi_loader: Implement memory allocation and mapAlexander Graf2016-03-151-0/+319
| | | | | | | | | | | | | | | | | | | The EFI loader needs to maintain views of memory - general system memory windows as well as used locations inside those and potential runtime service MMIO windows. To manage all of these, add a few helpers that maintain an internal representation of the map the similar to how the EFI API later on reports it to the application. For allocations, the scheme is very simple. We basically allow allocations to replace chunks of previously done maps, so that a new LOADER_DATA allocation for example can remove a piece of the RAM map. When no specific address is given, we just take the highest possible address in the lowest RAM map that fits the allocation size. Signed-off-by: Alexander Graf <agraf@suse.de> Tested-by: Simon Glass <sjg@chromium.org>
* efi_loader: Add disk interfacesAlexander Graf2016-03-151-0/+218
| | | | | | | | | | | | | | | A EFI applications usually want to access storage devices to load data from. This patch adds support for EFI disk interfaces. It loops through all block storage interfaces known to U-Boot and creates an EFI object for each existing one. EFI applications can then through these objects call U-Boot's read and write functions. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> [trini: Update for various DM changes since posting] Signed-off-by: Tom Rini <trini@konsulko.com>
* efi_loader: Add runtime servicesAlexander Graf2016-03-152-3/+293
| | | | | | | | | | | | | | | | | After booting has finished, EFI allows firmware to still interact with the OS using the "runtime services". These callbacks live in a separate address space, since they are available long after U-Boot has been overwritten by the OS. This patch adds enough framework for arbitrary code inside of U-Boot to become a runtime service with the right section attributes set. For now, we don't make use of it yet though. We could maybe in the future map U-boot environment variables to EFI variables here. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
* efi_loader: Add console interfaceAlexander Graf2016-03-151-0/+360
| | | | | | | | | | | | | | One of the basic EFI interfaces is the console interface. Using it an EFI application can interface with the user. This patch implements an EFI console interface using getc() and putc(). Today, we only implement text based consoles. We also convert the EFI Unicode characters to UTF-8 on the fly, hoping that everyone managed to jump on the train by now. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
* efi_loader: Add boot time servicesAlexander Graf2016-03-151-0/+781
| | | | | | | | | | | | | | When an EFI application runs, it has access to a few descriptor and callback tables to instruct the EFI compliant firmware to do things for it. The bulk of those interfaces are "boot time services". They handle all object management, and memory allocation. This patch adds support for the boot time services and also exposes a system table, which is the point of entry descriptor table for EFI payloads. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
* efi_loader: Add PE image loaderAlexander Graf2016-03-151-0/+188
EFI uses the PE binary format for its application images. Add support to EFI PE binaries as well as all necessary bits for the "EFI image loader" interfaces. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
OpenPOWER on IntegriCloud