| cee752fa | 11-Apr-2016 |
Alexander Graf <agraf@suse.de> |
efi_loader: Expose ascending efi memory map
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 insid
efi_loader: Expose ascending efi memory map
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>
show more ...
|
| ecbe1a07 | 11-Apr-2016 |
Alexander Graf <agraf@suse.de> |
efi_loader: Increase path string to 32 characters
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 -
efi_loader: Increase path string to 32 characters
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>
show more ...
|
| 8c3df0bf | 11-Apr-2016 |
Alexander Graf <agraf@suse.de> |
efi_loader: Add el torito support
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 f
efi_loader: Add el torito support
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>
show more ...
|
| 0f4060eb | 04-Mar-2016 |
Alexander Graf <agraf@suse.de> |
efi_loader: Pass proper device path in on boot
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
efi_loader: Pass proper device path in on boot
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>
show more ...
|
| ed980b8c | 04-Mar-2016 |
Alexander Graf <agraf@suse.de> |
efi_loader: hook up in build environment
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:
efi_loader: hook up in build environment
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>
show more ...
|
| 5d00995c | 04-Mar-2016 |
Alexander Graf <agraf@suse.de> |
efi_loader: Implement memory allocation and map
The EFI loader needs to maintain views of memory - general system memory windows as well as used locations inside those and potential runtime service
efi_loader: Implement memory allocation and map
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>
show more ...
|
| 2a22d05d | 04-Mar-2016 |
Alexander Graf <agraf@suse.de> |
efi_loader: Add disk interfaces
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 inte
efi_loader: Add disk interfaces
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>
show more ...
|
| 50149ea3 | 04-Mar-2016 |
Alexander Graf <agraf@suse.de> |
efi_loader: Add runtime services
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 t
efi_loader: Add runtime services
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>
show more ...
|
| c1311ad4 | 04-Mar-2016 |
Alexander Graf <agraf@suse.de> |
efi_loader: Add console interface
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 us
efi_loader: Add console interface
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>
show more ...
|
| bee91169 | 04-Mar-2016 |
Alexander Graf <agraf@suse.de> |
efi_loader: Add boot time services
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 i
efi_loader: Add boot time services
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>
show more ...
|