- 19 10月, 2016 1 次提交
-
-
由 Alexander Graf 提交于
We want to be able to add configuration table entries from our own code as well as from EFI payload code. Export the boot service function internally too, so that we can reuse it. Signed-off-by: NAlexander Graf <agraf@suse.de> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
- 18 10月, 2016 4 次提交
-
-
由 Alexander Graf 提交于
EFI allows an OS to leverage firmware drivers while the OS is running. In the generic code we so far had to stub those implementations out, because we would need board specific knowledge about MMIO setups for it. However, boards can easily implement those themselves. This patch provides the framework so that a board can implement its own versions of get_time and reset_system which would actually do something useful. While at it we also introduce a simple way for code to reserve MMIO pointers as runtime available. Signed-off-by: NAlexander Graf <agraf@suse.de>
-
由 Stefan Brüns 提交于
Currently each allocation creates a new mapping. Readding the mapping as free memory (EFI_CONVENTIONAL_MEMORY) potentially allows to hand out an existing mapping, thus limiting the number of mapping descriptors in the memory map. Mitigates a problem with current (4.8rc7) linux kernels when doing an efi_get_memory map, resulting in an infinite loop. Space for the memory map is reserved with allocate_pool (implicitly creating a new mapping) and filled. If there is insufficient slack space (8 entries) in the map, the space is freed and a new round is started, with space for one more entry. As each round increases requirement and allocation by exactly one, there is never enough slack space. (At least 32 entries are allocated, so as long as there are less than 24 entries, there is enough slack). Earlier kernels reserved no slack, and did less allocations, so this problem was not visible. Signed-off-by: NStefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: NAlexander Graf <agraf@suse.de> Signed-off-by: NAlexander Graf <agraf@suse.de>
-
由 Stefan Brüns 提交于
We need a functional free_pool implementation, as otherwise each allocate_pool causes growth of the memory descriptor table. Different to free_pages, free_pool does not provide the size for the to be freed allocation, thus we have to track the size ourselves. As the only EFI requirement for pool allocation is an alignment of 8 bytes, we can keep allocating a range using the page allocator, reserve the first 8 bytes for our bookkeeping and hand out the remainder to the caller. This saves us from having to use any independent data structures for tracking. To simplify the conversion between pool allocations and the corresponding page allocation, we create an auxiliary struct efi_pool_allocation. Given the allocation size free_pool size can handoff freeing the page range, which was indirectly allocated by a call to allocate_pool, to free_pages. Signed-off-by: NStefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: NAlexander Graf <agraf@suse.de> Signed-off-by: NAlexander Graf <agraf@suse.de>
-
由 Stefan Brüns 提交于
We currently handle efi_allocate_pool() in our boot time service file. In the following patch, pool allocation will receive additional internal semantics that we should preserve inside efi_memory.c instead. As foundation for those changes, split the function into an externally facing efi_allocate_pool_ext() for use by payloads and an internal helper efi_allocate_pool() in efi_memory.c that handles the actual allocation. While at it, change the magic 0xfff / 12 constants to the more obvious EFI_PAGE_MASK/SHIFT defines. Signed-off-by: NStefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: NAlexander Graf <agraf@suse.de> Signed-off-by: NAlexander Graf <agraf@suse.de>
-
- 07 6月, 2016 1 次提交
-
-
由 Alexander Graf 提交于
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: NAlexander Graf <agraf@suse.de>
-
- 28 5月, 2016 2 次提交
-
-
由 Alexander Graf 提交于
Some hardware that is supported by U-Boot can not handle DMA above 32bits. For these systems, we need to come up with a way to expose the disk interface in a safe way. This patch implements EFI specific bounce buffers. For non-EFI cases, this apparently was no issue so far, since we can just define our environment variables conveniently. Signed-off-by: NAlexander Graf <agraf@suse.de>
-
由 Simon Glass 提交于
This code does not currently build with driver model enabled for block devices. Update it to correct this. Signed-off-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NAlexander Graf <agraf@suse.de>
-
- 27 5月, 2016 1 次提交
-
-
由 Alexander Graf 提交于
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: NAlexander Graf <agraf@suse.de>
-
- 19 4月, 2016 1 次提交
-
-
由 Alexander Graf 提交于
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: NAlexander Graf <agraf@suse.de>
-
- 27 3月, 2016 1 次提交
-
-
由 Alexander Graf 提交于
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: NAlexander Graf <agraf@suse.de>
-
- 16 3月, 2016 7 次提交
-
-
由 Alexander Graf 提交于
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: NAlexander Graf <agraf@suse.de>
-
由 Alexander Graf 提交于
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: NAlexander Graf <agraf@suse.de> Tested-by: NSimon Glass <sjg@chromium.org>
-
由 Alexander Graf 提交于
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: NAlexander Graf <agraf@suse.de> Reviewed-by: NSimon Glass <sjg@chromium.org> Tested-by: NSimon Glass <sjg@chromium.org> [trini: Update for various DM changes since posting] Signed-off-by: NTom Rini <trini@konsulko.com>
-
由 Alexander Graf 提交于
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: NAlexander Graf <agraf@suse.de> Reviewed-by: NSimon Glass <sjg@chromium.org> Tested-by: NSimon Glass <sjg@chromium.org>
-
由 Alexander Graf 提交于
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: NAlexander Graf <agraf@suse.de> Reviewed-by: NSimon Glass <sjg@chromium.org> Tested-by: NSimon Glass <sjg@chromium.org>
-
由 Alexander Graf 提交于
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: NAlexander Graf <agraf@suse.de> Reviewed-by: NSimon Glass <sjg@chromium.org> Tested-by: NSimon Glass <sjg@chromium.org>
-
由 Alexander Graf 提交于
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: NAlexander Graf <agraf@suse.de> Reviewed-by: NSimon Glass <sjg@chromium.org> Tested-by: NSimon Glass <sjg@chromium.org>
-